不知道大家有沒有一個感覺，就是在做測試的過程中，某些方法、術語、理論總感覺並不陌生，並且有些理論我們好像早就知道了，只是沒有系統化而已。
那麼，有這種感覺其實是正常的。因爲很多知識其實古人早就總結出來了，並且通過典故形成了成語，然後現如今被現代人應用到各個領域。
本文就結合我們熟知的成語來說一說測試過程中的一些知識點，我相信你一定會感覺特別親切。
測試的目的之一，就是使自己確信產品是能夠正常工作的。測試人員的基本素質之一就是具備懷疑一切的態度。
那麼，大家在日常生活中，對某個事物表示懷疑的時候，經常會說：耳聽爲虛，眼見爲實。在漢·劉向《說苑·政理》中，也有類似的說法：“夫耳聞之，不如目見之；目見之，不如足踐之。”
也就是說凡事講究證據，道聽途說不可信。
還有一個詞就是無徵不信，出自《禮記·中庸》，意思是沒有證據的話或事不可信，沒有驗證的事不可相信。
在我之前的項目中，經常出現這樣的情況：開發人員在發佈版本轉測試的時候，經常口頭上說，他們做過了自測試，沒有問題，滿足提測條件。但是，往往一轉過來，測試人員一測，就發現冒煙測試不通過，各種阻塞性問題，白白浪費了很多人力。
究其根本，有的時候是開發人員測試方法不對，有的時候是開發人員自測不夠充分，有的時候甚至是開發人員並沒有真正的進行自測。
所以，後來測試對開發提測質量進行了嚴格的要求：提測必須提供開發自測報告、靜態代碼掃描報告，缺一不可。沒有這些證明材料，測試絕對不相信開發的一面之詞，正所謂無徵不信，耳聽爲虛眼見爲實。
另外，在測試過程文檔中，提到的測試方針和測試策略，在古語中也有類似的見地。
測試方針
測試方針：描述組織的測試目標和目的。方針一詞，原指羅盤針，指引地理方向。現常指指導工作或事業前進的方向和目標。
說白了，測試方針就是測試活動的大方向。
以我之前做軟件維護測試的項目爲例，由於維護測試項目的特點：改動小，主要是解決客戶問題。
所以一般情況下測試方針都是：給客戶解決的問題迴歸測試通過，修改點相關的模塊無修改引入問題。這就是測試方針，至於如何實現這個方針，那就是通過制定測試策略來保證了。
測試策略
測試策略：描述組織中通用的、不按項目而變化的測試方法。
策略相關的成語：
出謀劃策
謀：謀略，劃：籌劃，即制定計謀策略，出處：明代馮夢龍《東周列國志》第六十九回。此處，策即指策略。
一般在古代戰爭中，給將軍出謀劃策的叫做軍師。軍師制定的計謀和策略主要是指揮軍隊通過什麼樣的方法能夠打勝仗。
而在測試活動中，制定的測試策略也同樣是指揮測試團隊通過怎樣的測試方法，實現測試目標（測試方針）的。
制定測試策略的“軍師”，在不同的組織中形式不太相同。有的組織是TSE（測試系統工程師）制定測試策略，有的組織是測試經理制定測試策略，有的組織是測試經理、測試分析師共同討論完成測試策略的制定。
繼續以上一節中引用的項目爲例，爲了實現測試方針（給客戶解決的問題迴歸測試通過，修改點相關的模塊無修改引入問題），我們通過制定相應的測試策略來指揮測試人員開展測試活動：
1、所有承諾解決的客戶問題，使用手工測試的方式，進行充分的迴歸測試；
2、通過執行修改相關的模塊的自動化用例來進行繼承功能的迴歸測試；
3、其他的模塊不需要測試。
有勇無謀
只有勇氣，沒有計謀。指做事或打仗只是猛打猛衝，缺乏計劃，不講策略，只會魯莽的去做事，從不會投機取巧。出自唐代陸贄的《論兩河及淮西利害狀》。這裏邊的謀，就對應着測試策略中的策略。
這讓我想到了一個活生生血淋淋的例子：一個測試團隊成員，由於沒有按照測試策略執行，導致了嚴重的後果。
事情的經過是這樣的：本來已經制定好的測試策略是，按照測試用例的優先級從高到低執行，目的是儘早發現重點功能的缺陷。
但是，該測試人員自作主張，認爲執行的先後順序並沒有太大影響，然後竟然先從容易執行的用例開始執行，執行難度大、場景較複雜的用例放在了最後執行，這其中就有優先級爲高的測試用例。
最後，悲劇出現了，有一條高優先級的用例測試出了缺陷。而這個時候，已經到了整個項目的中後期，代碼的改動風險很大，但是又沒有辦法，存在問題的功能雖然不是十分核心的功能，但是也是客戶提出來的需求，不得不改。
所以，最後在修復這個缺陷的同時，增加了不少周邊相關的用例進行加固測試，這才降低了修改的風險。
該案例中的這位測試人員正是有勇無謀的代表。有好的策略沒有嚴格的落地，和沒有好的策略，在本質上沒有區別，結果都是釀成惡果。
我們在測試過程中，爲了提高測試效率會引入自動化工具進行測試執行和測試管理。
那麼在古代，人們早就總結出來了“善假於物”，出自《荀子·勸學》：君子生非異也，善假於物也。
意爲君子的資質與一般人沒有什麼區別，君子之所以高於一般人，是因爲他能善於利用外物。善於利用已有的條件，是君子成功的一個重要途徑。
如果項目中多一些“君子”，多借助“物”，那麼項目成功的概率就會大很多。試想一下，測試中如果少“物”或者無“物”，將是一個什麼樣的場景。
如果沒有缺陷管理系統，那麼測試人員發現缺陷，通過文本工具記錄和跟蹤，可想而知，要浪費多少溝通成本，並且可繼承性、可追溯性特別差。
如果迴歸測試用例沒有實現自動化，那麼每個版本測試人員都通過手工測試的方式進行迴歸測試，如果用例數量達到了一定的規模，可想而知，花在迴歸測試工作上的人力成本將是怎樣的。
如果沒有測試儀器儀表，想要模擬收發各種類型的報文幾乎是不可能的。
另外，測試管理和項目管理理論中都有提到風險管理。基於風險的測試基於風險的測試包含四個主要活動：風險識別、風險評估、風險緩解、風險管理。對於風險肯定是早預防早發現早處理爲最優。
預防風險
關於預防風險，古人有云：未雨綢繆，防患於未然。意思是趁着天沒下雨，先修繕房屋門窗。比喻事先做好準備工作，預防意外的事情發生，出自《詩經·豳風·鴟鴞》。
人們現在做項目，預防風險的意識已經越來越強了。在開發生命週期中，測試經常左移，旨在提前發現需求和設計上的問題，起到良好的預防風險的作用。
另外，再比如對於重要項目，提前充分做好人力儲備，以備不時之需，未雨綢繆，也是預防風險的實例。
減輕風險
關於減輕風險，古人有云：亡羊補牢，爲時未晚。羊逃跑了再去修補羊圈，還不算晚。比喻出了問題以後想辦法補救，免得以後繼續受損失，出自《戰國策·楚策》。
風險發生了，及時制定有效措施，減輕風險，是風險緩解常用的策略。
比如，軟件測試人員經常通過分析線上反饋的缺陷，以此作爲依據形成新的測試用例，作爲對現有用例庫的補充，應用到後續的測試活動中。這正是“亡羊補牢”的一個過程，起到了很好的止血效果，防止再犯類似的錯誤。
前面提到的通過線上問題，總結教訓，進行測試用例優化，除了是亡羊補牢，同時也是在做測試過程改進。
下面我們就說說測試過程改進：
項目回顧（例如經驗教訓），是過程改進活動的組成部分。測試結束過程一個重要的工作就是進行總結經驗教訓，通過總結來自測試項目和整個軟件開發生命週期中的重要經驗教訓，來實現過程改進。
成語前車之鑑，意思是吸取前面車子翻倒的教訓。比喻先前的失敗，可以作爲以後的教訓。
做項目一多，“翻車”時有發生。但是，只要好好總結經驗教訓，吸取“翻車”的教訓，引以爲鑑，就一定不會再犯同樣的錯誤了。反之，就很可能會重蹈覆轍。
之前項目有個版本，由於低估了某一個需求的重要性及複雜性，將該需求交給一個新員工進行測試分析、測試設計和測試執行。
由於新員工的經驗不足，測試場景沒有考慮全面。隨着測試進程在一步一步向前推進，發現越來越多的缺陷都和該需求相關，並且這些缺陷的改動特別大，甚至涉及到代碼重構。所以，最終決策該需求當前版本不上線，不得不遺留到下個版本繼續優化。
測試結束時，通過對這次“翻車”事件的分析，發現在測試團隊與產品經理、開發人員的溝通方面比較欠缺。後續需要針對每個需求的重要性、複雜性進行詳細評估，並且測試需要針對重要需求，與產品、開發進行測試方案的討論。這樣就可以很好的避免類似的情況再次發生。
所以，只要我們牢記“前事不忘後事之師”，吸取以前的經驗教訓，作爲今後行事的借鑑，將會把項目做得越來越出色。
通過本文將測試過程與成語聯繫起來，你是否體會到測試理論更加有趣了呢？你是否也更加佩服古人的智慧了呢？你也可以擴展聯想一下，其他測試術語與成語的聯繫呀，還是蠻有趣的。
FunTester，騰訊雲年度作者、Boss直聘簽約作者，GDevOps官方合作媒體，非著名測試開發。
-
FunTester測試框架架構圖初探 -
FunTester測試項目架構圖初探 -
Selenium4 IDE特性：彈性測試、循環和邏輯判斷 -
Groovy在JMeter中應用專題 -
測試模型中理解壓力測試和負載測試 -
選擇手動測試還是自動化測試？ -
Web端自動化測試失敗原因彙總 -
性能測試誤差分析文字版-上 -
性能測試誤差分析文字版-下 -
性能測試誤差統計實踐 -
性能測試誤差對比研究（一）
本文分享自微信公衆號 - FunTester（NuclearTester）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。