對於公***模塊的修改，怎麽更好的保證測試全面？

其實很多測試的問題都是由於系統本身設計造成的。比方說，壹個高耦合的系統總是牽壹發而動全身，妳讓別人怎麽區分公***模塊？公***包的接口老是改，妳讓調用這些接口的模塊怎麽維護？開發特別是設計人員經常忽視軟件的"可測試性",因為這在客戶角度可見度很低。為什麽我們要求測試貫穿始終？就是要所有人從需求開始到發布自始至終重視所有提交工件的“可測試性”。 好，解決這個問題以後我們可以從測試的角度來看看有什麽策略可以采用，先從常規手工測試開始。 1、假定公***模塊改變了實現方式但不改變簽名接口，這個好辦，單元測試就可以搞定。個人始終認為完整高質量的壹套單元測試套件對於保證產品的質量是至關重要的。只要原有的單元測試100%通過了，我們就有理由信任現在的代碼依然可靠。風險：低 2、單個公***模塊的接口有改變，但不影響其它模塊的接口。建議做全套單元測試，從索引中找到所有有調用關系的模塊，做集成測試，回歸測試。風險：中 3、多個公***模塊同時有變動，常見於大規模的系統重構，如應用新的設計模式。這種變動萬不得已是不建議的，因為風險太大。真的有了這種情況只能根據實際情況盡可能全面地重新測試。建議設計測試用例的時候壹定要按嚴重度分級，測試時從高到低往下做，降低潛在的損失。同時建議為用例和代碼模塊建索引，有了代碼變動相關聯的測試用例就要升級為高優先級。風險：高 4、對於新的公***模塊，在進行了較好的單元測試和接口測試以後，可以在優先級最高的測試用例中做全面的系統測試，對於其他測試用例可以當作第三方模塊（假定無缺陷)來處理。風險：高 再說自動化測試，通常我們並不特別重視自動化測試的執行開銷，因為經常是在夜裏執行。所以我們不太在乎冗余度，但是極端重視用例的覆蓋度和獨立性。舉個例子，對於業務對象我們常做的操作是C(增)R(讀)U(寫)D(刪)，那從自動化的角度來說典型的測試場景就是： 1. C->validation 2. C->R->validation 3. C->U->validation->R->validation 4. C->D->validation 5. C->U->validation 6. C->D->C->validation 很容易看出冗余度是很高的。版權聲明：原創作品，允許轉載，轉載時請務必以超鏈接形式標明文章原始出處、作者信息和本聲明，否則將追究法律責任。