MILY: 'Times New Roman','serif'; mso-fareast-font-family: 宋體; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">最近人們談到測試，常常會聽到：測試其實很復雜，所以很有前途。但具體怎么復雜卻不盡其詳。我覺得這篇我在微軟內部測試架構師站點里讀到的，Jim Moore 關于測試領域中有待解決的難題的文章很有啟發。讀過之后，靜心想想，技術含量如何？好像蠻高的？呵呵，也許吧。這其中有些在微軟已經解決了，有些卻也是沒有解決的。 突然發現，測試技術對一個公司來說好像還蠻秘密的，微軟很多內部測試工具測試框架都不產品化，雖然那些工具看起來是可以普遍運用到業界的。
<<翻譯開始了>>
難題可以分為這么些類別：
質量衡量標準 (標尺)
可清晰量化的衡量產品質量
測試覆蓋率-代碼塊覆蓋,功能覆蓋,用例覆蓋.... 這么多覆蓋率,每個覆蓋率,合理的目標是多少? 50%? 80% 100%
按照找到的缺陷數目,多少是被用戶找到的,多少是被內部非測試團隊找到的,多少是被測試團隊找到的,以此為衡量質量的標尺之一?
重復發生的回歸性缺陷數目
補丁和Service package數量,來衡量質量
我們有這么多可以用來衡量質量的標準,那么,哪些應該是核心的標準,最重要的普遍標準.怎么把各個標準和質量關聯上?
制定發布的質量指標,怎樣才是正確的指標,可以指導我們決定發布還是延遲發布產品直到我們達到該指標.
怎么定義測試效率?包括怎么衡量s變化對測試的影響..
怎么定義測試"完成"了?
復雜領域產品測試:
音頻和視頻質量測試
"看起來效果對嗎?"
"聽起來效果對嗎?"
效果"好"嗎?
各種主觀類型的測試判斷
測試工具對系統本身的影響(測不準原理?):
性能測試工具本身對機器性能的影響所導致的測不準效果.
測試要素的各種組合(測試范圍龐大):
測試要素組合, 覆蓋各種可能組合,將變得龐大: 操作系統 vs. 調試/發布 vs. 硬件配置 vs. 各種語言 vs. etc. vs. etc.
無窮無盡的用戶可能輸入.
有時間相關性的產品的測試.各種時間可能的窮舉是無限的.
整個產品范圍測試中的問題
整個產品的壓力測試
這個產品性能測試 vs. 各個開發組對自己模塊所作的性能測試
集成測試.
測試集優選:
由時間和進度影響決定?
由用戶影響決定?
由平均測試用例所找到的缺陷數決定? (或者考慮其他投資回報因素而決定)
挑選測試用例覆蓋了所更改的代碼,依此決定?
由所要測試的代碼復雜度決定?
項目計劃安排:
準確估計測試所需要的時間.
測試團隊如何參與決定項目整體進度計劃.
敏捷快速迭代測試的計劃安排.
測試對項目的影響:
爭取修復缺陷– i.e. 比如要求開發組修復缺陷,而他們回答"沒人會這么做!", 這個時候怎么有理有據的堅持要求修復缺陷.
設計階段的測試團隊參與 – 可測試性的分析/設計.
是否該擁有對發布/不發布的決策的影響.
自動化測試用例的后期維護夢魘.
怎么模擬人眼人耳來做自動化測試(音頻/視頻測試)
產品代碼中缺乏足夠的接口來支持自動化測試(比如開發人員自己畫出來的控件)
模擬N用戶操作的自動化測試(N非常大)
模擬真實的用戶-- [隨機的用戶行為]
集成測試:
集成測試中的自動化測試
調試的責任,誰做集成測試,誰負責調試整個產品中的問題?
集成測試應該包含哪些測試用例?
其他普遍的難題:
幾個版本發布之后,積累的測試代碼變得臃腫和難以維護.
設計不好的測試代碼,重復的測試代碼,各個測試自動化隊伍之間缺乏總體的設計和架構避免冗余工作
冗余的測試用例
留住有經驗的測試人才
文章來源于領測軟件測試網 http://www.kjueaiud.com/
