做軟件測試的人,往往會(huì )有這樣的想法:由于軟件的復雜導致了測試的復雜,所以不能指望培訓能給我們很多工作中的實(shí)際指導。偏重理論是肯定的,但并非沒(méi)有意義,雖然理論同樣可以從相關(guān)的文獻資料上得到。因為測試時(shí)從來(lái)不希望檢測被測系統所有可能的輸入、路徑和狀態(tài),那么應該選擇什么?什么時(shí)候應該停止測試?什么時(shí)候應該暫停測試?怎樣編寫(xiě)一個(gè)測試包,它可以檢測足夠多的消息和狀態(tài)的組合來(lái)說(shuō)明沒(méi)有失敗的操作,但是從實(shí)用性來(lái)說(shuō)它又足夠的小?
測試提出了許多基本的但卻令人困惑的難題,帶著(zhù)這些問(wèn)題,所以參加了幾次實(shí)用軟件測試培訓。
仔細思考后,我覺(jué)得此目標包含三個(gè)含義。
這似乎是個(gè)不言而喻的事實(shí),但有必要再次強調。因為有時(shí)開(kāi)發(fā)小組要測試員只是為了證實(shí)軟件可以運行,而不是找缺陷。在這種情況下,測試人員也就缺乏不懈努力發(fā)現缺陷的探索精神和熱情。所以做好測試的首要條件是明確軟件測試員的基本目標是發(fā)現軟件缺陷。
轉自項目管理者聯(lián)盟
項目管理培訓
因為軟件的修復費用,隨著(zhù)時(shí)間的推移,將數十倍的增長(cháng),所以軟件測試員應盡可能早地找出軟件缺陷。對于大型的軟件,在軟件開(kāi)發(fā)的同時(shí),就應該有緊隨其后的測試,如果等到產(chǎn)品已經(jīng)開(kāi)發(fā)完畢才開(kāi)始測試,非常有可能引起大量耗時(shí)費力的返工。而如何盡可能早的找出缺陷?理論上有一些測試方法:靜態(tài)黑盒測試、動(dòng)態(tài)黑盒測試、靜態(tài)白盒測試、動(dòng)態(tài)白盒測試;配置測試、兼容性測試、易用性測試……,怎樣才能有效的用這些方法盡早的發(fā)現軟件缺陷,需要在工作實(shí)踐中不斷的摸索、總結,不斷的提高測試能力。針對公司的情況,如果軟件的規模不是很大,開(kāi)發(fā)中的測試工作可能由開(kāi)發(fā)人員完成比較合適。
并不是每個(gè)軟件缺陷都有必要修復的??赡苁怯捎跊](méi)有足夠的時(shí)間、不算作真正的軟件缺陷、修復的風(fēng)險太大等原因,產(chǎn)品開(kāi)發(fā)小組決定對一些軟件缺陷不作修復。但是,測試人員必需確保找出的軟件缺陷得以關(guān)閉,也就是說(shuō)一旦登記了軟件缺陷,就要跟蹤其生命周期,監視其狀態(tài),提供必要的信息確保其得到修復和關(guān)閉。
有個(gè)很簡(jiǎn)潔明了的定義,software development engineers produce software, software test engineers produce testware. 那么testware包含哪些內容呢?test strategy, test plan, test specifications, test procedures, test cases, test reports, test data, test scripts,defects data等等。同軟件一樣,testware也需要很好地維護。例如,由于修復缺陷改變了軟件的接口,那么case和自動(dòng)測試腳本script都要做相應的修改。
軟件的產(chǎn)品功能說(shuō)明書(shū)對產(chǎn)品最終需要實(shí)現的功能作了描述。這些功能是最終確定的需要滿(mǎn)足的客戶(hù)需求,也包括軟件必須具備的能力。在規范的軟件開(kāi)發(fā)流程中,產(chǎn)品功能說(shuō)明書(shū)應在確定用戶(hù)需求后,進(jìn)行系統概要設計前確定。
至于為什么要進(jìn)行產(chǎn)品說(shuō)明書(shū)的測試,統計資料表明,很多軟件的缺陷都是因為產(chǎn)品功能說(shuō)明書(shū)不夠全面,經(jīng)常更改造成的;另外,只有詳細的閱讀了產(chǎn)品功能說(shuō)明書(shū),確認產(chǎn)品需要實(shí)現的功能,才能擬定切實(shí)可行的測試方案。
原文轉自:https://blog.51cto.com/u_15239049/4353026