發(fā)布時間: 2012-5-18 10:26 作者: 朱少民 來源: 51Testing軟件測試網(wǎng)采編
軟件測試過程中，我們應(yīng)注意和遵循一系列的具體原則，在ISTQB 軟件測試基礎(chǔ)認(rèn)證大綱上，列出了7 項(xiàng)原則，但其中最后一項(xiàng)原則“不存在缺陷（就是有用系統(tǒng)）”的謬論不能算是一項(xiàng)合格的原則，所以可以認(rèn)可的原則是6 項(xiàng)。除此之外，在這里還列出作者認(rèn)為比較重要的7 項(xiàng)原則，合起來共13 項(xiàng)原則。
1、ISTQB 的6 項(xiàng)原則
1）原則1——測試顯示缺陷的存在，但不能證明系統(tǒng)不存在缺陷。測試可以減少軟件中存在未被發(fā)現(xiàn)缺陷的可能性，但即使測試沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件或系統(tǒng)是完全正確的。
2）原則2——窮盡測試是不可能的。由于有太多的輸入組合、有太多的路徑，而且時間是有限的，無法做到完全的測試（100%測試覆蓋率）。通過運(yùn)用風(fēng)險(xiǎn)分析和不同系統(tǒng)功能的測試優(yōu)先級，來確定測試的關(guān)注點(diǎn)，從而替代窮盡測試。
3）原則3——測試盡早介入。軟件項(xiàng)目一啟動，軟件測試就應(yīng)開始，也就是從項(xiàng)目啟動的第一天開始，測試人員就應(yīng)參與項(xiàng)目的各種活動和開展對應(yīng)的測試活動。測試工作進(jìn)行得越早，軟件開發(fā)的劣質(zhì)成本就越低，并能更好地保證軟件質(zhì)量。例如，在代碼完成之前，可以進(jìn)行各種靜態(tài)測試，主導(dǎo)或積極參與需求文檔、產(chǎn)品規(guī)格說明書等的評審，將問題消滅在萌芽階段。
4）原則4——缺陷集群性。版本發(fā)布前進(jìn)行測試所發(fā)現(xiàn)的大部分缺陷和軟件運(yùn)行失效是由于少數(shù)軟件模塊引起的。一段程序中發(fā)現(xiàn)的錯誤數(shù)越多，意味著這段程序的質(zhì)量越不好。錯誤集中發(fā)生的現(xiàn)象，可能和程序員的編程水平、經(jīng)驗(yàn)和習(xí)慣有很大的關(guān)系，也可能是程序員在寫代碼時情緒不夠好或不在狀態(tài)等。如果在同樣的測試效率和測試能力的條件下，缺陷發(fā)現(xiàn)得越多，漏掉的缺陷就越多。這也就是著名的Myers 反直覺原則：在測試中發(fā)現(xiàn)缺陷多的地方，會有更多的缺陷沒被發(fā)現(xiàn)。假定測試能力不變，通過測試會發(fā)現(xiàn)產(chǎn)品中90％的缺陷。如果在模塊A 發(fā)現(xiàn)了180 個缺陷，在模塊B 發(fā)現(xiàn)了45 個缺陷，意味著模塊A 還有20 個缺陷沒被發(fā)現(xiàn)，而模塊B 只有5個缺陷未被發(fā)現(xiàn)。所以，對發(fā)現(xiàn)錯誤較多的程序段，應(yīng)進(jìn)行更深入的測試。
5）原則5——?dú)⑾x劑悖論。采用同樣的測試用例多次重復(fù)進(jìn)行測試，最后將不再能發(fā)現(xiàn)新的缺陷。為了克服這種“殺蟲劑悖論”，測試用例需要進(jìn)行定期評審和修改，同時需要不斷地增加新的不同的測試用例來測試軟件或系統(tǒng)的不同部分，從而發(fā)現(xiàn)潛在的更多的缺陷。
6）原則6——測試活動依賴于測試背景。針對不同的測試背景，進(jìn)行的測試活動也是不同的。比如，對要求安全放在第一位的軟件進(jìn)行測試，與對一般的電子商務(wù)軟件的測試是不一樣的。
2、其他重要的7 項(xiàng)原則
1）持續(xù)地測試、持續(xù)地反饋。軟件測試貫穿著整個軟件開發(fā)生命周期，隨時發(fā)現(xiàn)需求、設(shè)計(jì)或代碼中問題，及時將發(fā)現(xiàn)的問題反饋給用戶、產(chǎn)品設(shè)計(jì)人員、開發(fā)人員等，主動、積極地交流，持續(xù)提高軟件產(chǎn)品質(zhì)量，這在敏捷測試中更為重要。
2）80/20 原則。在有限的時間和資源下進(jìn)行測試，找出軟件中所有的錯誤和缺陷是不可能的，因此測試總是存在風(fēng)險(xiǎn)的。測試的一個重要目標(biāo)是盡量減少風(fēng)險(xiǎn)，抓住重點(diǎn)進(jìn)行更多的測試。根據(jù)80/20 原則，即帕累托法則（Pareto Principle），用戶80％的時間在使用軟件產(chǎn)品中20％的功能。“重點(diǎn)測試”就是測試這20％的功能，而其他80％的功能屬于優(yōu)先級低的測試范圍，占測試20%的資源。
3）建立清晰的階段性目標(biāo)。飯要一口一口地吃，不能一口就吃成胖子。測試的目標(biāo)也要逐步達(dá)到，不可能在某一瞬間就達(dá)到。根據(jù)軟件開發(fā)生命周期的不同階段性任務(wù)，我們要決定相應(yīng)的測試目標(biāo)和任務(wù)。如在需求分析階段，要參與需求評審以全面理解用戶需求、發(fā)現(xiàn)需求的問題；在功能測試執(zhí)行階段，測試人員不僅要對新功能進(jìn)行測試，而且要有效地完成回歸測試。
4）測試獨(dú)立性。測試在一定程度上帶有“挑剔性”，心理狀態(tài)是測試自己程序的障礙。同時，對于需求規(guī)格說明的錯誤理解也很難在程序員本人進(jìn)行測試時被發(fā)現(xiàn)。程序員應(yīng)避免測試自己的程序，為達(dá)到最佳的效果，應(yīng)由獨(dú)立的測試小組、第三方來完成測試。
5）確?？蓽y試性。事先定義好產(chǎn)品的質(zhì)量特性指標(biāo)，測試時才能有據(jù)可依。有了具體的指標(biāo)要求，才能依據(jù)測試的結(jié)果對產(chǎn)品的質(zhì)量進(jìn)行客觀的分析和評估，才能使軟件產(chǎn)品具有良好的可測試性。例如，進(jìn)行性能測試前，產(chǎn)品規(guī)格說明書就已經(jīng)清楚定義了各項(xiàng)性能指標(biāo)。同樣，測試用例應(yīng)確定預(yù)期輸出結(jié)果，如果無法確定所期望的測試結(jié)果，則無法進(jìn)行正確與否的校驗(yàn)。
6）計(jì)劃是一個過程。雖然通過文檔來描述軟件測試計(jì)劃，并最后歸檔，但計(jì)劃是一個過程，是指導(dǎo)各項(xiàng)軟件測試活動的持續(xù)過程。在項(xiàng)目開始時很難將所有的測試點(diǎn)、測試風(fēng)險(xiǎn)等都了解清楚，隨著時間推移，通過需求和設(shè)計(jì)的評審和探索式測試，對產(chǎn)品的理解越來越深，對測試的需求和風(fēng)險(xiǎn)越來越了解，可以進(jìn)一步細(xì)化、不斷豐富測試計(jì)劃。其次，計(jì)劃趕不上變化，軟件產(chǎn)品的需求常會發(fā)生變化，測試計(jì)劃不得不因此做出調(diào)整。所以，測試計(jì)劃是適應(yīng)實(shí)際測試狀態(tài)不斷變化而進(jìn)行調(diào)整的一個過程。
7）一切從用戶角度出發(fā)。在所有測試活動的過程中，測試人員都應(yīng)該從客戶的需求出發(fā)，想用戶所想。正如我們所知，軟件測試的目標(biāo)就是驗(yàn)證產(chǎn)品開發(fā)的一致性和確認(rèn)產(chǎn)品是否滿足客戶的需求，與之對應(yīng)的任何產(chǎn)品質(zhì)量特性都應(yīng)追溯到用戶需求。測試人員要始終站在用戶的角度去思考、分析產(chǎn)品特性，多問問類似下面這樣的問題：
這個新功能對客戶的價值是什么？
客戶會如何使用這個新功能？
客戶在使用這個功能時，會進(jìn)行什么樣的操作？
按目前設(shè)計(jì)，用戶覺得方便、舒服嗎？
如果發(fā)現(xiàn)缺陷，去判斷軟件缺陷對用戶的影響程度，系統(tǒng)中最嚴(yán)重的錯誤是那些導(dǎo)致程序無法滿足用戶需求的缺陷。軟件測試，就是揭示軟件中所存在的邏輯錯誤、低性能、不一致性等各種影響客戶滿意度的問題，一旦修正這些錯誤就能更好地滿足用戶需求和期望。
