一、軟件測試員的目標是盡可能早一些找出軟件缺陷,并確保其得以關閉。
或許大家會認為軟件測試員的工作目標是不言而喻的:就是找軟件缺陷,然而《軟件測試》這本書為軟件測試人員提出了更確切的目標:盡可能早一些找出軟件缺陷,并確保其得以修復。在閱讀全書并仔細思考后,我覺得此目標包含三大點含義:
1. 軟件測試員的基本目標是發現軟件缺陷。
我覺得在這里有必要把這不言而喻的事實再次強調一下,因為有時產品的開發小組要測試員只是為了證實軟件可以運行,而不是找缺陷。在這種情況下,測試人員也就缺乏不懈努力發現缺陷的探索精神和熱情。所以我覺得在心里堅信不移的認為:軟件測試員的基本目標是發現軟件缺陷,是做好測試的首要條件。
2. 軟件測試員追求的是盡可能早的找出軟件缺陷。
因為軟件的修復費用,隨著時間的推移,將數十倍的增長,所以軟件測試員應盡可能早的找出軟件缺陷。對大型的軟件,在軟件開發的同時,就應該有緊隨其后的測試,如果等到產品已經開發完畢才開始測試,非常有可能引起大量耗時費力的返工。而如何盡可能早的找出缺陷?《軟件測試》這本書向我們介紹了一些理論上的測試方法:靜態黑盒測試、動態黑盒測試、靜態白盒測試、動態白盒測試;配置測試、兼容性測試、易用性測試……,怎樣才能有效的用這些方法盡早的發現軟件缺陷,需要大家在工作實踐中不斷的摸索、總結,進而不斷的提高自己的測試能力。
3. 軟件測試人員必需確保找出的軟件缺陷得以關閉。
請注意,我們這里提的是軟件測試人員必需確保找出的軟件缺陷得以關閉,而不是要軟件缺陷得以修復。我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心:并不是我們辛苦找出的每個軟件缺陷都是必要修復的??赡苁怯捎跊]有足夠的時間、不算真正的軟件缺陷、修復的風險太大等原因,產品開發小組決定對一些軟件缺陷不作修復。
另外,測試員對軟件缺陷描述不清楚,也會使軟件測試員發現的缺陷被忽略。所以我們測試員必須在描述軟件缺陷方面狠下功夫:用簡單明了的語句描述軟件缺陷;每一件報告盡量針對一個軟件缺陷,避免多個缺陷混雜在一起,以致其中一些被忽略或忘卻;記錄引出軟件缺陷的操作步驟,使缺陷得以再現。
雖然我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心,但同時又必須堅持有始有終的原則,跟蹤每一個軟件缺陷的處理結果,確保軟件缺陷得以關閉。關閉軟件缺陷的前提可以是缺陷得以修復或決定不作修復。而缺陷是否需要修復的最終決定權在軟件的最終負責人,檢查缺陷得以關閉的責任在測試人員。
二、測試一個軟件最首要也是最重要的是測試其產品功能說明書。
1 概念
產品功能說明書:對產品最終需要實現的功能的描述。這些功能是最終確定的需要滿足的客戶需求,也包括是一些軟件必須具備的能力。
在規范的軟件生成的流程中,產品功能說明書應在用戶需求評審會議召開后,進行系統的概要設計前確定。
2 原因
(1)很多軟件的缺陷都是因為產品功能說明書不夠全面,經常更改造成的;
(2)只有詳細的閱讀了產品功能說明書,確認產品需要實現的功能,才能擬定切實可行的測試方案;
3 方法
(1)參照需求說明書,檢查產品功能說明書描述的產品將要實現的功能是否已經完整、準確、一致、合理的描述了產品的功能,并確保這些功能是可測試的
(2)研究產品說明書是否符合現有的軟件設計開發的標準或規范;
(3)研究同類軟件,預測產品的最終結果;
如果測試人員發現產品說明書不符合以上幾點,該怎么做?
測試人員需要明白,我們的責任是反映產品的缺陷,我們不需要也不能修正產品,所以同發現軟件的其它缺陷一樣,在發現產品說明書的缺陷后,應該把它們如實并詳細的記錄下來,呈報給此軟件的最終負責人,對并此缺陷的處理情況進行跟蹤。
注意同發現的軟件其它缺陷一樣,缺陷列表應該呈報給軟件的最終負責人,而不是給相關技術人員或技術主管,因為技術人員可能會以在技術的實現上有難度為推托,拒絕對缺陷的修改。
4 目前的可執行度
(1)很多軟件在開發前并沒有書面形式的產品說明書
目前我國的許多軟件公司都是小型的手工作坊式的公司,在程序開發前都沒有一個正式的、完整的、確定的產品說明書,即便是這種情況,產品說明書也是存在的,它存在在軟件設計人員、項目負責人的腦海里,在他們心中都有一個軟件的輪廓,假定了軟件將要實現的功能。我們的測試人員可以在同他們的交流和不斷的詢問中獲得這個非正式的產品說明書,值得注意的是在我們得到這些信息后還需要以書面的形式把它們一一列舉出來,再向相關人員請教,最后做到能完整、準確、一致、合理的描述了產品的功能。
(2)測試人員一般不會在項目初期就參與項目
當前還存在著這樣一種問題,公司一般不會讓軟件測試人員在項目的初期就參與項目,一般要等到軟件的雛形出來后才會讓軟件測試人員著手進行測試。對這種情況,測試人員可以通過已經建立的軟件的雛形,揣摩產品說明書,然后也是同上段所說一樣,向相關人員請教,擬定一份書面的完整的、準確的、一致的、合理的產品說說明書。值得注意的是,測試人員在運行軟件的雛形時,往往會發現一些軟件缺陷,這時千萬不要局限在這些缺陷上耗費經歷,以致忘了擬定產品說明書的主要任務,一定要記?。簻y試一個軟件最首要也是最重要的是測試其產品說明書,在產品說明書明確后,再制定具體的測試案例。
以上兩點是指在公司體系不太正規的情況下給測試員的建議,但我認為要能更好的保證軟件的質量,或許規范生成軟件的整個運作流程更為有效:產品說明書由項目負責人來主持定版比較好,因為他把握著產品發展的方向;在產品說明書定版時的會議應請負責測試的人參加,使他們對產品有一個宏觀的認識,我也不贊成測試人員過早的局限于某一項目,如果那樣他們會覺得無所事事。
三、完全測試軟件是絕不可能的,必須對測試的各項進行等價劃分。
1 概念
等價分配:軟件有無限的測試案例,我們要想辦法把軟件的相似輸入、輸出、操作分成一組,來使無限的測試案例減小到同樣有效的小范圍,這個過程稱為等價分配。
邊界條件:軟件計劃的操作界限所在的邊緣條件,即如果超出這個邊界條件,就可能會引出錯誤。
2 原因
輸入量太大
輸出結果太多
軟件實現途徑太多
軟件說明書沒有客觀標準。從不同的角度看,軟件缺陷的標準不同。
3 方法
(1)數據測試:
1) 確定輸入的邊界條件,對邊界線上的及邊界線兩邊的數據進行測試;
2) 邊界線可能是2的乘方,默認值、空白值、零值等;每一個軟件測試問題各不相同,可能包含格式各樣邊界的不同數據。
(2)狀態測試(軟件的狀態是指軟件當前所處的情況或者模式)
1) 每種狀態至少訪問一次;
2) 測試看起來最常見最普遍的狀態轉換;
3) 測試狀態之間最不常用的分支;
4) 測試所有錯誤狀態及其返回值;
5) 測試隨機狀態轉換。
4 目前的可執行度
如果為了減少測試案例的數量過度進行等價分配,測試漏掉軟件缺陷的風險就會增加。對初涉軟件測試者,一定要請經驗豐富的測試員審查預定的等價類別。
原文轉自:http://www.anti-gravitydesign.com