為什么要做自動化測試？測試工程師存在的必然性

最近反復被測試有用嗎？測試必須測試工程師完成嗎？為什么要做自動化測試？自動化測試的價值是什么？等等一系列的問題不斷地拷問，索性就把這段時間的思考記錄下來了。

軟件測試的必要性

在混沌初開之際，軟件開發和軟件測試還是一個角色獨立完成的一個事情，后來伴隨著軟件工程的發展，開發和測試逐漸的分開，那么隨著工程化的逐漸深入，研發運營一體化的高速發展，軟件測試是否還需要單獨存在這樣的討論時不時的就會出現在各大團隊內部的會議上。軟件測試是不是存在其實蘊含著兩方面，一方面是測試工作的獨立存在，一部分是測試工程師的存在。相信說到這里很多人第一反應就是測試工程師必須存在，為什么呢？因為出問題了要有人背鍋。其實并不盡然，我們先從測試工作存在的必要性開始聊起，測試工程師存在的必然性也就順理成章了。

美國質量管理大師克勞士比(Philip Crosby)提出質量成本(Cost of quality-COQ)是指為了防止出現錯誤以及產生錯誤而引起的一切費用。假定你要提供一種優質的產品或服務給你的顧客，質量成本是指你因為不能第一次便做好(Doing the right thing the first time)而產生的所有有關成本。質量成本通常包括三方面: 預防成本(Prevention cost)、鑒定成本(Appraisal cost)及失效成本(Failure cost)，而失效成本又可分為內部的成本(Internal cost)和外部的成本(External cost)三者加起來就是所謂質量成本(Cost of qualit）。

我們引用質量成本的概念，在軟件開發過程中如果沒有測試實踐，那么軟件的缺陷就會導致類似傳統工業一樣問題，顧客會反饋“問題“，團隊要付出努力找到問題，并修復問題，在這個過程中開發團隊付出了鑒定成本，企業也因為影響了客戶的使用而需要付出更多的成本重新獲得客戶信任。測試工作就在系統交付給客戶之前用科學的方法設計測試用例并進行邏輯驗證，將問題提早暴露、提早解決的方法，讓問題不會暴露在最終用戶面前，因此賺取了額外付出挽回用戶信任的成本，同時在產品沒有直接交付到客戶側前就進行了修復，也大大降低了鑒定成本和修復成本。

講清楚測試的價值其實可以從測試過程發現的缺陷將其，相比大家都有為缺陷分類分級的經驗，那么我們一般都會按照缺陷的嚴重程度來劃分缺陷，大部分會是致命缺陷、嚴重缺陷、一般缺陷、建議缺陷，那么這些實際代表的是如果這個缺陷交付到了客戶面前我們付出的質量成本的高低，越嚴重的缺陷付出的質量成本就越高，就越應該在交付過程中解決掉，將其用內部成本的代價付出代替外部成本損失。

測試工程師存在的必然性

軟件測試這個過程的實施主體就是測試工程師。那么多少個測試工程師比較合適呢，或者換句話說如上的事情必須要測試工程師完成嗎？開發工程師不能完成如上的工作嗎？（這里就不包含技術成熟度非常優秀的團隊，我們還是說絕大部分團隊的現狀）。這里其實要強調開發工程師不能做全部的測試工作，”自我檢查類“的單元測試還是需要自己完成的。我覺得”自己不能測試自己的代碼“是每一個軟件從業者都聽說過的至理名言了，那么為什么不能自己測試自己的代碼呢？這是有關于一個人類心理學的一個“自我偏見”和“選擇性注意力”的問題。當我們欣賞自己的作品時，我們會注意到它們的優點，而忽略它們的缺點。這是因為我們已經知道了我們的作品的背景和意圖，因此我們會更容易地看到它們的優點。這種現象被稱為“選擇性注意力”。選擇性注意力是人類注意特征之一。個人不可能同時注意所有呈現的刺激，總是有選擇地注意某一刺激而忽視同時呈現的其他多種刺激。例如，課堂上的學生不可能、也不應該對作用于他們視覺和聽覺的刺激都作出反應，正常情況下只是集中注意教師的講授或演示。選擇性注意所指向的對象是受個體原有認知結構影響的，因此注意過程是一個主動的過程。同時，我們的作品通常是基于我們自己的想法和創意，因此，我們會對它們產生情感上的依戀。這種依戀可能會導致我們對自己的作品產生偏見，使我們認為它們比它們實際上更好。這種現象被稱為“自我偏見”。

如果開發工程師不適合做全部的軟件測試，那么最終用戶相比就更不適合了，否則就會引起前面所說的質量成本。測試工程師作為發現問題，避免付出質量成本的主要角色還是有他存在的必要的。站在整體的視角，通過最終用戶的視角完成測試驗證，也會避免如上的“自我偏見”和“選擇性注意力”，說白了就是測試工程師可以避免開發工程師的“燈下黑”。

服務于質量需求的軟件測試

軟件測試和質量的關系其實就如同軟件開發和業務需求的關系一樣，開發工程師通過編碼交付業務需求，測試工程師通過測試交付質量需求。

這里的質量需求有些可能是客戶顯示的提出來的，有些是隱藏在交付軟件的質量特性里而需要被交付的。無論是哪一種，質量需求最終都應該可以追溯到客戶的需求中的。所以系統的質量需求也是不完全一致的，有些系統被應用在財務、款項相關的業務中，那么數據的準確性的要求就非常重要，1分錢的錯誤都有可能出現謬之千里的問題；有些系統被應用在不同的移動設備中，需要用戶自主學習，那么兼容性和易學習性就應該更加的關注。除去最終服務的行業、用戶以及行業相關監管要求決定了質量需求之外，系統的成熟度應該也是影響質量需求的一個關鍵因素，初創期的系統、快速開發交付的系統，穩定交付的系統和被替換的系統，每一個階段的系統對于質量的需求應該都是不一樣的，所以也應該有不一樣的測試實施方案。

站在質量需求的輸入角度，可以分成“無”質量需求、不清晰的質量需求、關鍵要素的質量需求以及全面的質量需求，其實這么分無非就是為了說清楚什么樣的系統應該怎么投入測試，叫什么名字只是一個代號。

“無”質量需求往往是在項目的被替換期，項目逐漸的退出歷史舞臺，處于被其他業務替換或者不再使用，從而有很少的變更甚至沒有變更，大部分是系統的可用性維護上，這個階段不會有任何明確的質量需求被驗證，往往維護可用性就已經足夠了，這種項目不需要測試實踐保證質量，測試工程師只是在需要的時候使用原有的測試用例（如果有自動化用例就充分利用自動化用例）完成測試實踐，同時參與的測試工程師要負責再次發揮價值的測試用例是有效的和和當前系統是一致的。

不清晰的質量需求是在項目的初創期出現的，其中初創期主要是驗證想法、最小化驗證交付可行性，這里主要只站在商業價值角度的實驗，通過快速交付、快速驗證能夠將業務的想法最小之間周期進行驗證，那么這個時候，往往沒有明確的質量需求，潛在的一些質量需求在項目交付過程中也不會特別明顯的被提及，測試工程師應該在團隊中保證功能交付的正確性，這個時期的質量需求重點就是功能性，那么測試工程師主要以手工測試為主，選擇一種測試用例管理辦法，記錄測試用例資產，就足以滿足當前的質量保證要求了。

關鍵要素的質量需求是指系統在快速的交付期，需求大量積壓，系統交付的過程中并沒有明確的質量需求需要測試過程交付，保證需求的正確性是唯一一個被所有人注重的測試內容，兼顧行業監管要求。這個時候測試實踐也并不推薦使用大量的自動化測試，使用手工測試完成最終的驗收階段的功能驗證是這個時期最為重要的內容，少量非功能由于手工實現的成本非常高，通過一些工具或者自動化技術完成。

全面的質量需求是指系統已經進入了穩定的交付周期，有固定的交付周期，需求無明顯積壓，團隊保持相對穩定的需求吞吐量，每個需求都有明確的質量需求，質量需求既有產品經理分析的，也有最終用戶實際提出的，還有依據測試工程師的經驗在需求質量保證過程中提出來的。測試工程師在這個階段應該維護大量的自動化測試用例，少量的新業務有一些手工測試，大量的自動化測試用例全面保證了系統的質量，保證了系統功能的正確性，非功能測試也進行了全面的實際，測試工程師也有時間，有條件嘗試測試左移、右移的實踐。

如上僅僅是通過系統成熟度角度分析了什么情況怎么投入測試，這肯定不是唯一的分析問題的角度，其實這僅僅是一種思路，如果團隊技術成熟度非常優秀，那么測試工程師有可能就不存在，測試活動（這里還是需要一個科學的驅動開發方式，例如TDD）全靠開發角色一個人承擔，那么上面的一大堆的內容就沒什么必要了。

審核編輯：黃飛