謬論：如果我們正在尋找很多程序缺陷，我們正在做重要的測試。
事實：找到很多程序缺陷的唯一好處就是告訴我們產品存在很多程序缺陷。它沒有告訴我們測試覆蓋的質量，程序缺陷的嚴重性，或是客戶將在實際中碰到它們的頻率。同樣它也沒有告訴我們遺留下多少程序缺陷。
停止找到程序缺陷的唯一確定方法就是停止測試。它看起來是荒謬的，但這個想法是有價值的。這個難題的癥結在于指出產品的什么特性確實需要研究。我已經提到產品中的許多工作流實際沒有被使用——并且如果它們沒有被使用，它們就不需要被研究。直接在你的測試計劃中合并客戶使用知識以及缺點篩余機制提高了你預測客戶影響和與缺點相關的風險概率。在你的測試計劃解決中合并基于風險和客戶分析將產生一個更加實際和實用的測試計劃。一旦你對你的測試計劃有信心，你可以在你已經執行計劃之后停止測試。 [Page]
你如何建立那種信心？開始你的測試計劃時要確定你需要測試的所有區域。讓客戶檢查和評價商業過程并使用實例以便你懂得每一個被提議的測試實例的頻率和重要性。要特別注意檢查測試漏洞。對每一個迭代要持續更新和檢查你的測試計劃和測試實例。你的目標是找到什么沒有被覆蓋到。做到這個的一種方法是通過軟件區域和測試種類來映射程序缺陷計數。如果一個軟件區域沒有被記錄缺點，它可能意味著這個區域是十分有效的或者它還沒有被測試�？慈毕菸募臅r間戳。如果最后的缺陷是去年公布的，可能它暫時不用被測試。找到錯過的程序錯誤的模式是檢查測試覆蓋的一個重要技術。
謬論：完全的測試意味著測試 100% 的需求。
事實：測試需求是重要的，但是不是充分的。你還需要測試那些遺漏的事情。有什么重要需求的沒有被列出？
找到沒有被列出的是一個有趣的挑戰。 迭代測試很早就使客戶客戶參與進來�？蛻舳盟麄兊臉I務如何進行和他們如何工作。他們可以告訴你你的應用軟件中錯過了什么，并且提出什么妨礙了他們需要完成的任務。
謬論：它是一個間歇的程序錯誤。
事實：不存在間歇的程序錯誤。問題是一直存在的——你只是沒有指出正確的條件來復制它。提供可用的工具來持續監控執行，應用軟件降級開始的自動校準，以及在降級的時候自動發出適當的數據（優先于應用軟件實際崩潰）減少內部故障診斷時間和客戶停工時間。迭代測試和迭代可用性活動都可以減少沒有被發現的程序錯誤對商業的影響。
更加實用和好用的診斷程序增加了你的產品的客戶價值。當你的產品開始升級時，通過前攝的監控環境，你可以減少分析時間甚至可以避免由于開始各種自動更正校準和工作區的例行程序而導致的停工。自治服務例行程序的這些類型增加了你的產品的可靠性，耐久性，和運行持續時間，甚至如果程序缺陷復制品的條件是未知的。 在某種意義上，自治的恢復例行程序提供了一個標準的持續的技術支持。環境記錄和處理跟蹤信息被自動收集并被發送，以用于更進一步缺點分析的開發，同時也提供了關于你的產品是如何被實際使用的重要數據。
如果我們承認程序缺陷是不可避免的，我們同樣需要認識到適當有用的例行程序的重要性。這些自診斷和自行監控功能在增加客戶價值和滿意度中是有效的，因為它們減少了客戶受程序缺陷消極影響的風險。然而即使這些例行程序增加了客戶價值，只有少數幾個開發周期被用于將這些過程歸位。
謬論：產品應當在壓力下被測試以驗證性能、可伸縮性和耐久性。
事實：上面是正確的。但它的反面也是正確的。使一個應用軟件保持在空閑，或長期處于暫停的狀態來仿效客戶去吃午飯或使應用軟件在周末暫停，并經常暴露一些問題。[Page]
我推薦在你的功能測試方法中包括睡覺，暫停，中止，中斷和睡眠狀態恢復。仿效一個地理分布式工作環境，當你的應用軟件處于中止或暫停狀態，而其中的共享工件和數據庫正在變化（正如同事們在其他人的業余時間在一個偏僻的地點工作）。測試當使用者“喚醒它”時發生了什么，這與他們被掛起的環境是不同的。然而更好的是將你的產品放到一個真實的客戶環境中并運行仿效上面的一些場景的系統測試。
謬論：客戶總是正確的。
事實：可能他不是一個正確的客戶。你不可能使用一個發布來使每一個人都滿意。因此，要在你的發布定義特性設置中有選擇性。瞄準一個特殊的，高度概括的測試場作為用戶的一種類型目標。然后對于下一個發布或迭代，選擇一個不同的人群。你將更有效地測試；當你的產品成熟的時候，你將通過在不同階段中增加滿意的客戶來增加你的客戶基礎。
謬論：自動化！自動化！自動化！
事實：在腦海中客觀的看待自動化，并考慮 ROI。測試環境越象最終產品環境，測試的可靠性越高。如果客戶的產品是100%自動化的，那么自動化！自動化！自動化！如果你的產品不打算在客戶環境中實現自動化，那么你需要將自動化的，特殊化的，探查的以及客戶場景的測試進行合并。
它同時對于擴展你的自動化定義有所幫助。自動化測試實例可以重復測試你已經手工測試過的區域。但是那不能增加你的測試覆蓋或你對使用者對于應用軟件是如何反應的理解。相反，創建自動化實際上允許你投入更多的精力在創造性的手工測試上。使事情自動化是你經常需要做的并且那將使你花費很長的時間來完成，象：
分解和建立原始環境來測試每一個構建。
對每一個構建，集成點，或迭代的全面驗收測試。
跨越各種平臺，操作系統和語言測試相同的套件，。
低級別組件的單元和命令行測試。
謬論：迭代開發行不通。
事實：它是人類對于未知和未嘗試的領域懷疑的天然屬性。在迭代開發經驗中，每一個成功階段的好處逐漸增加。因此，迭代方法的所有好處是只有在開發周期的末尾才被重視。對于第一個吃螃蟹的人來說，那個推遲的滿意可以真正地成為信念的行為。我們沒有使用方法的經驗，并且所以我們不太信任即將使用的方法。當我們認識到時間正在流逝，我們放棄了信念并拋棄了迭代過程。在恐慌狀態中，我們又回到了我們的老習慣。迭代開發多半沒有實際失敗。我們只是沒有給它一個成功的機會。
迭代測試在迭代開發的累積好處的每一個迭代中提供了可見的記號。當團隊共享增加的成功標準（例如，每一個迭代的進入和退出標準）時，站在正確的方向上是更加容易的。
因為我們根據出口標準持續監控結果，我們可以更容易地在迭代中調整我們的測試來達到我們的最終目標。例如，在中間迭代中，我們可以觀察我們關鍵的和高缺陷計數在增長，并且我們可以比修正它們更快地找到它們。因為我們早已經認識到這個趨勢，我們可以重新分配資源來加深對于關鍵路徑活動的關注。我們可以再分配研究“樂意擁有” 特性的開發人員來修正“發布定義” 特性中的缺陷，或者刪除與高缺陷計數有關的樂意擁有特性。
結論
我只接觸到了我們假設每天都會遇到的軟件開發的謬論中的少數一部分。如果我們假設做得越多，我們就會越少發現不可預知的事情——所有關于軟件測試的。
不幸的是，我們提到的謬論是非常誘人的。它們被偽裝成答案，并且它們方便地結束了對話。當我們人員不足并承受壓力時，接受假設作為事實是非常誘人的。
因為我們經常難以分辨謬論和事實，我們需要檢查我們的答案。這個簡單而有效的頌歌，總結了我已經在這篇文章中論述的所有東西，將有助于你保持在正確的軌道上：迭代測試從來都沒有滿意的正確答案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
