不要測(cè)試它

做為一名測(cè)試人員，我們也許會(huì)問我們自己很多問題：

• 我們可以立即執(zhí)行的***的測(cè)試是什么？
• 我將要使用的測(cè)試方法是什么？
• 這是一個(gè) Bug 嗎？
• 我已經(jīng)測(cè)試完成了嗎？

但是我們之中會(huì)有多少人提出以下的這些問題呢？

• 這個(gè)組件需要一直被測(cè)試到嗎？
• 需要由我來測(cè)試它嗎？
• 如果它不工作，誰會(huì)去在意它呢？

[[61603]]

在我看來，我們提出的問題中和以上三個(gè)問題類似的還遠(yuǎn)遠(yuǎn)不夠?？赡苓@是因?yàn)槲覀円呀?jīng)被告知要測(cè)試一切東西。甚至我們的一部分人會(huì)在其質(zhì)量團(tuán)隊(duì)中有一個(gè)流程，要求某個(gè)人把每一個(gè)組件都貼上“已測(cè)試”的標(biāo)簽。我們對(duì)待測(cè)試就像一個(gè)常規(guī)的工廠程序，我們甚至有時(shí)候引以自豪的說…

“我是測(cè)試工程師。因此，所有的東西都需要被測(cè)試…由我來做…即使非測(cè)試人員已經(jīng)測(cè)試過了…即使我已經(jīng)知道它將會(huì)通過測(cè)試…即使需要一個(gè)程序員告訴我怎么去測(cè)試…我必須測(cè)試它，沒有例外！”

這類想法可能會(huì)讓測(cè)試人員有一個(gè)壞名聲。由于欠缺思考的過程導(dǎo)致它強(qiáng)調(diào)了測(cè)試的重要性，而不是給一些人提供最有價(jià)值信息的服務(wù)。

James Bach 帶著以下的測(cè)試觀點(diǎn)出現(xiàn):

基本的觀點(diǎn)：“如果它存在，我就要去測(cè)試它”

正如前面內(nèi)容和我經(jīng)常發(fā)布的文章中，我不同意這個(gè)觀點(diǎn)。盡管如此，我完全同意 James 在 2006 年 8 月 7 日，他在博客發(fā)布的完整版本中關(guān)于這部分的介紹：

“如果它存在，我就要去測(cè)試它（唯一的例外是我有更重要的事情要做）”

第二句話是可以有很多的理解方式！為什么呢？因?yàn)槲覀兘?jīng)常會(huì)有更重要的事情去做，通常是另外的測(cè)試工作！不幸的是，重要性往往不是區(qū)分的很明顯。所以與其衡量重要性，我更喜歡提出上面的三個(gè)問題，去尋找那些可能不值得浪費(fèi)我的時(shí)間去測(cè)試的東西。下面八個(gè)例子是我討論的內(nèi)容：

0. 不會(huì)在產(chǎn)品中出現(xiàn)的組件- 我的團(tuán)隊(duì)中在每次迭代中都有這些內(nèi)容。例如增強(qiáng)功能中的錯(cuò)誤記錄表或者跟蹤生產(chǎn)活動(dòng)中的審查報(bào)告。在敏捷開發(fā)的團(tuán)隊(duì)中這些被歸入開發(fā)者用戶故事（Developer User Stories）。這些內(nèi)容不會(huì)隨便的在產(chǎn)品中出現(xiàn)并且由于其本質(zhì)不會(huì)直接影響到用戶。

1. 關(guān)鍵產(chǎn)品問題的補(bǔ)丁不會(huì)很糟糕 – 一天下午客戶給我們的技術(shù)支持打電話，由于我們的產(chǎn)品的一個(gè)阻塞性質(zhì)的 bug 導(dǎo)致他們處于錯(cuò)過一個(gè)關(guān)鍵***期限（DeadLine）的邊緣。我們只有一個(gè)小時(shí)交付修復(fù)的產(chǎn)品。程序員很快的修復(fù)了問題，由于當(dāng)前的產(chǎn)品是無效的，所以對(duì)修復(fù)之后進(jìn)一步的產(chǎn)品存在的風(fēng)險(xiǎn)來說這是微不足道的。想要當(dāng)英雄嗎？不要讓事情慢下來?？焖俚淖尞a(chǎn)品通過測(cè)試。如果需要以后再去測(cè)試。

2. 界面問題修復(fù)要有適度的準(zhǔn)備時(shí)間 – 我們修復(fù)了一個(gè)在屏幕上出現(xiàn)的用戶錯(cuò)誤消息中的拼寫錯(cuò)誤。用戶并沒有察覺到拼寫錯(cuò)誤但是我們無論如何修復(fù)了問題。很快而且簡(jiǎn)單。觸發(fā)這個(gè)錯(cuò)誤消息需要 30 分鐘的準(zhǔn)備時(shí)間，值得嗎？

3. 直接了當(dāng)?shù)呐渲酶淖?– 去年我們產(chǎn)品開始偶爾出現(xiàn)很大的作業(yè)不能處理的問題。一個(gè)程序員嘗試改變通用配置修復(fù)問題。但在 QA 的環(huán)境中沒有一個(gè)簡(jiǎn)單的方法去創(chuàng)建一個(gè)足夠大的作業(yè)超過這個(gè)臨界值，很難去測(cè)試。我們?cè)诋a(chǎn)品中修改了配置然后用戶很高興的為我們做了測(cè)試。

4. 技術(shù)性的需要非程序員的測(cè)試 – 測(cè)試部分功能時(shí)需要實(shí)施某種行為而在代碼中設(shè)置斷點(diǎn)來復(fù)現(xiàn)競(jìng)態(tài)條件.有時(shí)測(cè)試人員與工具和程序員精通產(chǎn)品代碼的知識(shí)并不匹配。討論這個(gè)測(cè)試但是回避它。

5. 非測(cè)試人員借用 – 如果團(tuán)隊(duì)中一個(gè)非測(cè)試人員幫忙去做測(cè)試工作，或者更重要的，想幫忙測(cè)試某一組件，讓他去做吧。跟他分享測(cè)試的思路并且跟他要測(cè)試報(bào)告。如果你覺得滿意，不需要再去測(cè)試它了。

6. 沒有復(fù)現(xiàn)步驟- 程序員偶爾會(huì)嘗試某些東西。經(jīng)常會(huì)出現(xiàn)一些錯(cuò)誤報(bào)告，但是沒有人能對(duì)這些錯(cuò)誤給出確切的重現(xiàn)步驟。我們也許想對(duì)修改的區(qū)域做回歸測(cè)試，但是我們發(fā)布的時(shí)候不會(huì)阻止這種明顯的修復(fù)，因?yàn)槲覀儾恢浪懿还苡谩?/p>

7. 不足的測(cè)試數(shù)據(jù)或硬件 – 讓我們面對(duì)它吧。在我們 QA 的環(huán)境中，根據(jù)產(chǎn)品中所需要，大部分情況我們沒有足夠多負(fù)載平衡服務(wù)器。當(dāng)一個(gè)有效的測(cè)試需要的資源在產(chǎn)品使用環(huán)境之外不可用時(shí)，我們可能無法對(duì)其進(jìn)行測(cè)試。

很多人也許嘗試想像上面這些如果不去測(cè)試會(huì)導(dǎo)致的問題。我也會(huì)做這些。記住，這些事情也許不值得花費(fèi)我們的時(shí)間去測(cè)試。再次權(quán)衡你所做的事情，如果在不是很清楚的時(shí)候，去問問利益相關(guān)者。

如果你選擇不去測(cè)試某些東西，很重要的是，不能被我誤導(dǎo)。這是在我的團(tuán)隊(duì)中使用到方法。在我們進(jìn)行組件審查時(shí)，我們的（測(cè)試人員）說，“我們將不會(huì)去測(cè)試這些”。如果有人反對(duì)，我們會(huì)改變我們的想法并且測(cè)試它。如果沒有人反對(duì)，我們就“未經(jīng)審查即批準(zhǔn)（rubber stamping）”。即表明沒有被測(cè)試就讓它通過這樣可以讓他進(jìn)入到最終產(chǎn)品。

所以下次你發(fā)現(xiàn)你自己正在著手做的測(cè)試，感覺比其他你應(yīng)該做的事情更不重要時(shí)，你應(yīng)該需要考慮…不去測(cè)試它。逐漸的，你的團(tuán)隊(duì)將會(huì)尊重你的決定并受益于更少的瓶頸，以及在你實(shí)際增加的價(jià)值的地方增長的覆蓋率。

原文：Eric Jacobson

原文鏈接：http://blog.jobbole.com/15054/

【編輯推薦】

1. 軟件開發(fā)基本原則之***項(xiàng)目
2. 聘用Node.js開發(fā)者的六個(gè)建議
3. 軟件開發(fā)如同木匠做桌子
4. 網(wǎng)頁開發(fā)的6種在線調(diào)試環(huán)境
5. 基于引擎開發(fā)HTML 5游戲?qū)崙?zhàn)