這五個軟體測試痛點，是否也讓你深受困擾？
首先請思考下面的幾個場景，是否你也似曾相識：
當產品在線上運行一段時間後出現了個生產問題，並反饋到你這裡，你這才幡然醒悟為什麼這個場景如此簡單自己卻從沒有測（想）到過。
當開發人員交付產品到測試，並對你說「喏，點點看吧有沒有bug」，你感覺有點沮喪：測試根本不是點點點啊！
當你正在測試執行的時候，測試經理走過來詢問你已經測試了哪部分功能，你卻頭腦空白，忘記了已測的路徑。
當項目進行多輪迭代之後，測試用例庫已經累積了成百上千的測試用例。測試經理當然希望每次上線你都再執行一輪迴歸測試，可是你暗自懷疑這樣做能發現新的缺陷嗎。
當你參與其他項目測試類似的產品時，你感覺設計的測試用例會有些重複，但總想不起來還有哪些沒考慮到。
這些其實都是軟體測試痛點在實際工作中的典型場景。
測試專家JamesWhittaker在《探索式軟體測試》（Exploratory Software Testing）第7章中總結了軟體測試的五個痛點，並分別給出了改進的建議。他指出測試作為管理和最小化軟體錯誤的過程，其本身也存在一些嚴重的缺陷：
盲目性
重複性
暫時性
單調性
無記憶性
1.盲目性
沒有目的的生活是罪惡且可悲的。同樣，沒有目的的測試是不負責任的。敏捷團隊裏手工測試容易存在著這樣的情況：測試人員缺乏前期規劃，準備和適應性的策略，僅以隨機的方式測試產品。或許我們可以稱之為「佛系」測試：今天測試某個功能會心血來潮考慮到異常問題，明天測試類似的功能時就可能忽略了，能否測的出bug得看緣分。
不管團隊是採用哪種開發模式敏捷or傳統，我們都很難信賴以這種方式完成的測試，並且最終發布產品。記住，測試非常重要，不能隨便對待它。
定義需要測試的內容
James建議測試人員測試執行之前首先思考被測對象是什麼，其次要牢記將測試和用戶實際使用相結合。不同的測試階段中，被測對象可以是單個介面，可以是某個存儲過程，也可以是客戶端應用。無論是哪一種被測對象，我們都要牢記用戶關心的功能是什麼，因為用戶在乎的不是軟體組件的實現細節，而是使用各種組件來實現他所需要的功能。只有當我們更有目的性的去做測試，才能夠輕鬆的向測試經理解釋測試進度和覆蓋程度。
確定何時測試
理想情況下，測試人員應該盡量多的模擬真實的用戶操作，去發現隱蔽但非常重要的軟體缺陷。但是這麼做有個重要的前提，必須有效降低「缺陷噪音「的整體水平。缺陷噪音（Bug Noise）是那些讓測試人員不能高效工作的軟體中的小問題，例如，輸入框只允許輸入數字卻可以輸入字元，或者測試人員重複發現類似的問題。這些缺陷本應該在代碼評審、單元測試、開發人員自測等階段發現。否則，就意味著花在尋找更隱蔽更嚴重的問題上的測試時間會被壓縮。
確定如何測試
許多敏捷團隊在團隊成型之後開始嘗試引入探索式測試，這是一個好的開端。要注意的是，缺乏經驗的測試人員很容易錯誤的將探索測試與隨機測試劃等號，這樣會使得測試比以前更加的漫無目的。建議測試團隊不斷的總結錯誤報告，將發現缺陷的方式進行分類也很有用。Bug的發現是通過隨機測試、腳本測試還是探索式測試？如果是探索測試，又是哪種漫遊方法指向了這個bug?持續做下去，會讓測試人員逐漸明白「這種功能/特性這樣測最有效「。
2.重複性
隨著我們產品不斷地增加新的功能，我們需要對現有功能執行歷史的測試用例，並且對新功能進行新的測試，新的測試用例很快又會變成「歷史「。我們知道即使是過時的測試也有其作用，且浪費任何測試用例都是愚蠢的，於是我們有了回歸測試這個概念。然而根據Boris Beizer提出的殺蟲劑悖論（thepesticide paradox），一旦一組測試發現了其規定的bug，那些仍然存在的缺陷將不受未來重複測試的影響。所以問題來了，讓測試團隊花大量精力去完整回歸了成千上萬個用例，究竟是好是壞？如果100%執行通過，是否就意味著真的沒有缺陷了，還是這些用例無法找到仍然存在的缺陷？
知道已經做了哪些測試
就如同殺蟲劑悖論中的農民需要知道他們正在使用的農藥配方，測試人員必須知道已經做了哪些測試，並且明白重複使用相同的陳舊技術幾乎沒有錯誤的價值。這樣，測試人員才能繼續運用自己的智慧去調整測試目標和測試關注點。
了解何時注入調整
解決殺蟲劑悖論意味著農民必須修補他們的農藥配方，同樣對於測試人員來說，需要把調整注入測試用例。每次執行時修改輸入的數據，這樣簡單的改變就是一種可行的改進。另外，在回歸測試的階段，引入探索式測試也不失為一個好的方案：測試人員探索不同的途徑，以各種順序和數據去漫遊產品，確保那些潛在的缺陷從沒有遭遇過這樣的測試場景。
3.暫時性
測試人員不能以足夠現實的方式成為用戶或模擬他們的行為，找到所有重要的錯誤。測試人員的工作狀態是瞬變的，一旦應用程序完成測試並且上線，他們就會接著做下一個產品的測試。但是，有些缺陷需要掌握真實用戶的真實情況，並等到在真實環境中處理了真實的數據後，才可能被發現。所以，錯過一些問題是很正常的。但是測試人員應該努力的方向是，更趨近於一個真實的用戶，並且不要忽略產品的運營周期，即使產品到了維護階段，這段時間也仍然是測試階段的一部分。這部分的用戶場景，就需要我們去考慮。
4.單調性
我們經常聽到有人評價測試：「測試很無聊「，或者是」測試很簡單「。這些人的崗位往往是非質量保證導向的角色，比如開發人員，設計師，架構師等等。甚至不少測試人員自己也在職業生涯發展過程中，慢慢的丟失了當年找bug的激情和興奮勁，覺得測試變得單調乏味。
軟體測試的確有枯燥的部分，比如在不同的客戶端上反覆的執行同樣的測試用例。我們建議把這些測試過程中乏味並且重複的部分進行自動化。除此之外，我們要記住軟體測試終究是一項挑戰智慧的創造性工作。我們應當花費更多的時間去思考測試場景和測試極限，這些才是軟體測試有趣的部分。
5.無記憶性
測試是一項面向當前的任務。因為我們通常是計劃測試，設計用例，執行用例，分析結果，並在使用完後快速忘記它們，我們不會花大量時間思考如何在將來版本的應用程序或其他測試項目中使用它們。不僅是個人，對於整個測試團隊來說，測試通過很容易，但要做到如何分享測試經驗，如何啟發未來的測試卻很難。測試完成後，測試經理問團隊真正學到了什麼，沒人說的清楚。
建立知識庫是一種好的方法，但不要把知識庫變成測試用例庫。我們不建議團隊培訓新手時，讓他直接去閱讀測試用例。因為這意味著團隊需要花費昂貴的成本去維護測試用例，而殺蟲劑悖論也會降低歷史測試用例的價值。我們更建議團隊的知識庫把測試方法和被測對象（包括功能、特性、API、協議等）關聯起來，最終測試團隊可以快速的用最優的方法去發現問題。
總結
上述的五個軟體測試痛點主要存在於傳統的開發模型以及典型的腳本測試方法中，而探索式測試則是一個很好的解決方案：它可以讓測試人員以更強的目的性來處理他們的任務，直接解決無目標的痛點。並且探索式測試還特別推薦測試人員創建更多的變數方法，以解決重複性和單調性的痛點。此外，團隊創建測試知識庫，針對各個功能來持續記錄相對應得探索測試方法，這樣也可以解決測試團隊中存在的無記憶性問題。
那麼探索式測試是什麼呢？如何在敏捷測試中實踐探索式測試呢？請持續關注我們的公眾號，未來我們會告訴你答案。
TAG:測試之禪 |