測試集優選:
由時間和進度影響決定?
由用戶影響決定?
由平均測試用例所找到的缺陷數決定? (或者考慮其他投資回報因素而決定)
挑選測試用例覆蓋了所更改的代碼,依此決定?
由所要測試的代碼復雜度決定?
項目計劃安排:
準確估計測試所需要的時間.
測試團隊如何參與決定項目整體進度計劃.
敏捷快速迭代測試的計劃安排.
測試對項目的影響:
爭取修復缺陷– i.e. 比如要求開發組修復缺陷,而他們回答"沒人會這么做!", 這個時候怎么有理有據的堅持要求修復缺陷.
設計階段的測試團隊參與 – 可測試性的分析/設計.
是否該擁有對發布/不發布的決策的影響.
測試自動化:
自動化測試用例的后期維護夢魘.
怎么模擬人眼人耳來做自動化測試(音頻/視頻測試)
產品代碼中缺乏足夠的接口來支持自動化測試(比如開發人員自己畫出來的控件)
模擬N用戶操作的自動化測試(N非常大)
模擬真實的用戶-- [隨機的用戶行為]
集成測試:
集成測試中的自動化測試
調試的責任,誰做集成測試,誰負責調試整個產品中的問題?
集成測試應該包含哪些測試用例?
其他普遍的難題:
幾個版本發布之后,積累的測試代碼變得臃腫和難以維護.
設計不好的測試代碼,重復的測試代碼,各個測試自動化隊伍之間缺乏總體的設計和架構避免冗余工作
冗余的測試用例
留住有經驗的測試人才
文章來源于領測軟件測試網 http://www.kjueaiud.com/
