關鍵字:軟件測試
針對這個問題,我一直在思索,都沒有得到滿意的答案。直到有一次我去美國總部出差,在那里我通過和美國總部的同事交談,得到了答案:
決定軟件測試的設計與決策的是其背后的商業利益和商業效率的考量。
簡單的說,就是軟件測試工作的投入和產出決定了測試的設計與決策。
測試的商業利益 = 測試的產出 – 測試的投入
測試的商業效率 = 測試的商業利益 ÷ 測試的投入 × 100%
為了形象的解釋這個觀點,首先把我們自己想象成一個軟件公司的CEO,在俯視公司全景的同時,思考這樣兩個問題:
公司為什么要雇傭大量的軟件測試工程師,并且人數逐年遞增?
公司為什么每年要為測試部門提供大筆的預算,并且還逐年追加投入?
原因只有一個,那就是與對軟件測試部門的投入相比,測試部門能夠減少費用支出或者避免損失。當然,從另一個角度想這其實就是在創造價值,就是測試的產出,而且這個產出一定要高于對測試部門的投入,并且其商業效率應該不低于軟件投資的平均資產增值率。否則,我們將有理由直接將測試部門從公司的部門列表中刪掉,并省下這筆投入。
所以,說軟件測試能夠保證軟件的質量也好,說測試能夠提高客戶滿意度也好,其實這些都是測試在整個軟件商業鏈條中的一種價值的體現,但并不是軟件測試存在的根本原因。如果測試的商業利益是負的,或者測試的商業效率低于平均的軟件投資的平均資產增值率,那么這樣質量應該沒有哪個軟件企業愿意去保證,這樣的客戶滿意度也沒有哪個企業愿意去提高。
真實的測試案例
以下是幾個真實的測試設計與決策的案例。一年前,我到美國總部的測試實驗室去了解那里是如何在Windows Mobile和CE上測試射頻驅動程序(此驅動程序用于驅動手機或嵌入式設備上的射頻電話模塊)的。在那里我得到了對這些案例的正確解讀。
自動化測試VS完備文檔。
在實驗室中,我見到了我所見過的最大的自動化測試系統。所有的功能測試都是通過這種自動化系統完成的。系統由數量巨大的測試設備和中心測試驅動服務器組成,測試人員只要通過遠程的客戶端安排自動化測試任務并將之提交到中心測試驅動服務器上即可,其余的工作將由中心測試驅動服務器完成。這個過程包括搜索處于空閑狀態的測試設備,啟動并控制測試設備,并在測試完成后收集日志數據信息和計算測試通過率。
這時,我突然想到了我先前的疑惑——為什么與編寫完備的測試文檔相比,我們在實際工作中更看重測試的自動化?我的美國同事給我的回答是:運行成本的原因。編寫完備的測試文檔自然是能夠幫助測試小組完整的記錄所有的測試用例,但是對于一個在操作系統上起著重要作用的驅動程序而言,每周兩次的回歸測試是才是保證驅動程序質量的根本手段?梢韵胂,如果沒有自動化測試,而是依據文檔中的測試用例,這種頻繁的回歸測試將會消耗多少人力物力。而與此同時,自動化的測試程序和用例使用統一的測試框架,并且輔助以相當的注釋,這樣測試程序和用例的代碼本身已經能夠很好的說明測試用例的詳細信息,所以在文檔中便不再需要重復的詳細信息了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/