qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          軟件測試的13項原則

            軟件測試過 程中,我們應注意和遵循一系列的具體原則,在ISTQB 軟件測試基礎認證大綱上,列出了7 項原則,但其中最后一項原則“不存在缺陷(就是有用系統)”的謬論不能算是一項合格的原則,所以可以認可的原則是6 項。除此之外,在這里還列出作者認為比較重要的7 項原則,合起來共13 項原則。

            1、ISTQB 的6 項原則

            1)原則1——測試顯示缺陷的存在,但不能證明系統不存在缺陷。測試可以減少軟件中存在未被發現缺陷的可能性,但即使測試沒有發現任何缺陷,也不能證明軟件或系統是完全正確的。

            2)原則2——窮盡測試是不可能的。由于有太多的輸入組合、有太多的路徑,而且時間是有限的,無法做到完全的測試(100%測試覆蓋率)。通過運用風險分析和不同系統功能的測試優先級,來確定測試的關注點,從而替代窮盡測試。

            3)原則3——測試盡早介入。軟件項目一啟動,軟件測試就應開始,也就是從項目啟動的第一天開始,測試人員就應參與項目的各種活動和開展對應的測試活動。測試工作進行得越早,軟件開發的劣質成本就越低,并能更好地保證軟件質量。例如,在代碼完成之前,可以進行各種靜態測試,主導或積極參與需求文檔、產品規格說明書等的評審,將問題消滅在萌芽階段。

            4)原則4——缺陷集群性。版 本發布前進行測試所發現的大部分缺陷和軟件運行失效是由于少數軟件模塊引起的。一段程序中發現的錯誤數越多,意味著這段程序的質量越不好。錯誤集中發生的 現象,可能和程序員的編程水平、經驗和習慣有很大的關系,也可能是程序員在寫代碼時情緒不夠好或不在狀態等。如果在同樣的測試效率和測試能力的條件下,缺 陷發現得越多,漏掉的缺陷就越多。這也就是著名的Myers 反直覺原則:在測試中發現缺陷多的地方,會有更多的缺陷沒被發現。假定測試能力不變,通過測試會發現產品中90%的缺陷。如果在模塊A 發現了180 個缺陷,在模塊B 發現了45 個缺陷,意味著模塊A 還有20 個缺陷沒被發現,而模塊B 只有5個缺陷未被發現。所以,對發現錯誤較多的程序段,應進行更深入的測試。

            5)原則5——殺蟲劑悖論。采用同樣的測試用例多次重復進行測試,最后將不再能發現新的缺陷。為了克服這種“殺蟲劑悖論”,測試用例需要進行定期評審和修改,同時需要不斷地增加新的不同的測試用例來測試軟件或系統的不同部分,從而發現潛在的更多的缺陷。

            6)原則6——測試活動依賴于測試背景。針對不同的測試背景,進行的測試活動也是不同的。比如,對要求安全放在第一位的軟件進行測試,與對一般的電子商務軟件的測試是不一樣的。

            2、其他重要的7 項原則

            1)持續地測試、持續地反饋。軟件測試貫穿著整個軟件開發生命周期,隨時發現需求、設計或代碼中問題,及時將發現的問題反饋給用戶、產品設計人員、開發人員等,主動、積極地交流,持續提高軟件產品質量,這在敏捷測試中更為重要。

            2)80/20 原則。在 有限的時間和資源下進行測試,找出軟件中所有的錯誤和缺陷是不可能的,因此測試總是存在風險的。測試的一個重要目標是盡量減少風險,抓住重點進行更多的測 試。根據80/20 原則,即帕累托法則(Pareto Principle),用戶80%的時間在使用軟件產品中20%的功能。“重點測試”就是測試這20%的功能,而其他80%的功能屬于優先級低的測試范 圍,占測試20%的資源。

            3)建立清晰的階段性目標。飯要一口一口地吃,不能一口就吃成胖子。測試的目標也要逐步達到,不可能在某一瞬間就達到。根據軟件開發生命周期的不同階段性任務,我們要決定相應的測試目標和任務。如在需求分析階段,要參與需求評審以全面理解用戶需求、發現需求的問題;在功能測試執行階段,測試人員不僅要對新功能進行測試,而且要有效地完成回歸測試。

            4)測試獨立性。測試在一定程度上帶有“挑剔性”,心理狀態是測試自己程序的障礙。同時,對于需求規格說明的錯誤理解也很難在程序員本人進行測試時被發現。程序員應避免測試自己的程序,為達到最佳的效果,應由獨立的測試小組、第三方來完成測試。

            5)確保可測試性。事先定義好產品的質量特性指標,測試時才能有據可依。有了具體的指標要求,才能依據測試的結果對產品的質量進行客觀的分析和評估,才能使軟件產品具有良好的可測試性。例如,進行性能測試前,產品規格說明書就已經清楚定義了各項性能指標。同樣,測試用例應確定預期輸出結果,如果無法確定所期望的測試結果,則無法進行正確與否的校驗。

            6)計劃是一個過程。雖 然通過文檔來描述軟件測試計劃,并最后歸檔,但計劃是一個過程,是指導各項軟件測試活動的持續過程。在項目開始時很難將所有的測試點、測試風險等都了解清 楚,隨著時間推移,通過需求和設計的評審和探索式測試,對產品的理解越來越深,對測試的需求和風險越來越了解,可以進一步細化、不斷豐富測試計劃。其次, 計劃趕不上變化,軟件產品的需求常會發生變化,測試計劃不得不因此做出調整。所以,測試計劃是適應實際測試狀態不斷變化而進行調整的一個過程。

            7)一切從用戶角度出發。在 所有測試活動的過程中,測試人員都應該從客戶的需求出發,想用戶所想。正如我們所知,軟件測試的目標就是驗證產品開發的一致性和確認產品是否滿足客戶的需 求,與之對應的任何產品質量特性都應追溯到用戶需求。測試人員要始終站在用戶的角度去思考、分析產品特性,多問問類似下面這樣的問題:

            這個新功能對客戶的價值是什么?

            客戶會如何使用這個新功能?

            客戶在使用這個功能時,會進行什么樣的操作?

            按目前設計,用戶覺得方便、舒服嗎?

            如果發現缺陷,去判斷軟件缺陷對用戶的影響程度,系統中最嚴重的錯誤是那些導致程序無法滿足用戶需求的缺陷。軟件測試,就是揭示軟件中所存在的邏輯錯誤、低性能、不一致性等各種影響客戶滿意度的問題,一旦修正這些錯誤就能更好地滿足用戶需求和期望。

          相關鏈接:

          從1個中心到5個要素——金字塔與軟件測試

          軟件測試中的8組關系

          posted on 2012-05-21 09:55 順其自然EVO 閱讀(245) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2012年5月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 刚察县| 岳普湖县| 大洼县| 襄樊市| 胶南市| 米易县| 科技| 新余市| 泌阳县| 留坝县| 中超| 中西区| 自贡市| 柳州市| 安徽省| 宜兴市| 板桥市| 香河县| 隆林| 宜昌市| 永和县| 兴文县| 沅陵县| 巴彦县| 班玛县| 桓台县| 永德县| 庆元县| 三台县| 法库县| 三门峡市| 阜城县| 泰兴市| 泌阳县| 遵义县| 当雄县| 天津市| 商城县| 新密市| 册亨县| 蓬安县|