5、分析是否所有的邏輯都能夠找到對應的用例(通過邏輯找到對應的用例),包括前面沒有考慮到的邏輯
6、分析用例是否有冗余,是否多個用例都是覆蓋的同一個邏輯(包括測試步驟和檢查點)
7、分析用例的測試方法是否有改進,是否能夠直接通過代碼靜態走讀、接口測試、自動化測試(包括編寫腳本)、引入工具等等來進一步提高我們的測試效率
C、友情提醒:
1、僅僅只能保證已有的邏輯沒有問題,但是可能出現部分情況沒有處理導致失效的情況,可以通過后面的場景用例和需求用例來補充覆蓋
2、邏輯里面異常情況考慮不充分,導致測試用例也相對比較欠缺,可以通過對每個邏輯進行頭腦風暴,分析是否有其他異常情況,并且評審時重點評審這塊
3、研發的邏輯有可能本身就是錯誤的,但是如果順著研發的邏輯去編寫用例時會導致用例也有問題,達不到測試目的,所以需要從需求和設計的角度去提前分析邏輯是否有問題
4、過程中研發的邏輯可能變化比較快,這樣會導致邏輯測試用例也要經常變化,所以需要保證研發的編碼是與設計一致的,并且邏輯是盡量根據設計來進行的
另外,邏輯用例的設計可以在編碼中后期進行,這樣的改動會少點
二、基于場景的用例設計過程:
A、用例編寫過程:
1、搞清楚客戶的原始需求,為什么需要這個功能,能夠給客戶帶來的價值是什么
2、查看需求說明書里面的客戶使用的典型用戶場景,并且整合到場景用例里面
3、在需求說明書的基礎上進一步分析客戶還可能有哪些實際的使用場景(主要是整個客戶的拓撲結構)
4、客戶會怎樣去配置該模塊以滿足什么樣的需求(頭腦風暴)
5、過程中客戶會有哪些操作(頭腦風暴)
B、用例評審過程:
1、安排相關模塊專家、規劃經理和主管來進行評審,主要是分析還可能有哪些場景沒有考慮到,最好是能夠有具體的客戶
原文轉自:http://blog.it985.com/16130.html