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