測試靈魂三問及解決方案

上週在公司內部做了一次關於質量相關主題的分享，本文同步記錄其中的部分核心觀點。思考為主，具體案例沒有放出來，如需進一步探討，可以留言。

01

測試人員，總會在不同的場景下被這三個問題拷問。現根據自己的經驗，嘗試對這三個問題給出自己的看法。

為什麼這個 BUG 測試不出來？這個問題的本質是對測試充分性的質疑；

測試到底會不會測？這個問題的本質是對測試有效性的質疑；

測試為什麼那麼慢？ 這個問題的本質是對測試效率的質疑；

針對這類問題，當然也可以直接找各類理由懟回去（測試無法窮盡、BUG 又不是測試產生的，需求那麼亂，時間那麼緊。。。。。。），但意義不大，除了加深矛盾，沒有實質的意義。還是要嘗試去解決問題。

02

針對為什麼這個 BUG 測試不出來的問題，我們需要考慮的是如何讓測試更充分。

測試充分性包含三個層次的：程式碼層次的測試充分性、系統（功能/非功能）層次的測試充分性、業務層次的測試充分性，而 “業務層次的測試充分性” 最具決定性的。

程式碼層次：這一層次在很長一段時間內，是被測試人員忽略的（能力不夠）。萬丈高樓平地起，測試人員需要花一部分精力去關注程式碼層的交付質量：程式碼靜態分析、覆蓋率驗證、全鏈路測試、契約測試等，可以快速提升測試效率。同時，這個層次也是最適合做自動化的層次。

系統（功能/非功能）層次：大部分測試人員的主要精力都會花在這裡（自稱點工）。根據現有的需求文件或者 Story 描述，結合業務特點和自己的經驗，透過測試用例的設計，驗證功能點的正確性。並適當地開展一些非功能性測試。只關注這層，往往會忽略很多上下游業務依賴的錯誤，或者是底層程式碼在特定場景下的問題。

業務層：這裡指的是需要有端到端的業務視野，從全流程的角度去驗證複雜場景。這需要測試人員對業務非常熟悉，同時也熟悉業務關聯的上下游系統。這類測試人員其實非常難得（在製造業的某個領域，曾經半年招不到一個，但這類人其實就業面也比較窄，因為對口的業務公司也不會太多，所以專注業務的同學需要慎重選擇深入哪個業務）。

在做測試策略和測試設計時，需要針對以上三個層次都有所覆蓋，才能提升測試的充分性。

03

針對測試會不會測試的問題，其實是對測試預期（Test Oracle）的管理。在面對比較簡單的業務時，預期結果是明確的。但隨著業務複雜度的提升、細分專業領域的業務場景、大資料、海量使用者的非常規操作，都使得 Test Oracle 問題更加突出。因為如果沒有可靠的 Test Oracle，測試人員就無法判斷測試結果是否正確、無法發現軟體中的缺陷，自然，測試就無法進行。

在筆者遇到過的場景中，曾經遇到過一個場景。測試人員在 SIT 環境測試時，發現了部分淺層的問題。修復完成後，投入 UAT 測試。但是在 UAT 測試時，使用者反饋了大量的問題，透過針對這些問題的分析，其實是因為研發和測試都對這個系統的實際應用場景不夠了解，導致對系統的使用與業務不一致，導致無法發現問題（一個非常專業的製造業細分系統）。

如何解決這類問題呢？

01 必要的業務培訓：熟悉業務屬性，結合業務流程圖、系統架構圖，對業務系統有個整體的感知。瞭解業務的流轉規則、約束條件及資料流向。

02 制定明確地測試策略：根據業務特性制定對應的測試策略，做針對性的測試設計，保障更好地覆蓋。而不是根據執行人的個人經驗進行測試。

03 嚴格執行測試流程：很多人都討厭自己走流程，但更討厭別人不按流程來（是不是很熟悉？）。不要讓測試設計停留在表面上。

04 建立質量意識和責任感：作為測試人，經過自己測試過的內容，應該承擔一份責任，能夠保證產品的基本質量。測試遺漏是難免的，但是我們不能把線上問題簡單地歸結為對質量意識不強或者開發人員能力太差，測試應該有責任和能力去探查問題的根源並加以改進。

05 定期回顧和總結：著名的 PDCA 法則告訴我們，想要把事做得更好，覆盤和總結是必不可少的，透過覆盤，能夠更好地認識自己，發現問題，改進方法，提高工作效率

——以上內容可參考：迭代測試發現不了問題，怎麼辦

測試的充分性和有效性通常會耦合在一起。測試負責人需要能夠有針對性地去識別其中的問題。因為解決這兩類問題的側重點是不一樣的，雖然看起來很像。測試的充分性是測試設計的問題，測試有效性更多的是業務和流程的問題。

04

關於測試效率的提升，本質上是需要在適當的場景下做減法，去減少那些不必要的活動。但是做減法是需要勇氣的（容易背鍋）。

消除重複測試：重複的測試用例、重疊的測試流程、非必要的迴歸測試範圍

消除測試中的等待：從流程規範上，讓測試活動更順暢，讓研發過程流動更快。設定必要的 DOD，對齊每個環節的完成標準，更合理地分配 Story 研發順序（關聯優先，而不是難度優先）

消除沒有必要的測試：過度的非功能測試（是不是都要做相容性測試、效能測試）、過度的測試範圍（制定基於風險的測試策略，而不是大而全的全量覆蓋）

05

為了解決以上三個靈魂拷問，也為了對交付質量有更高的要求，提升測試人員自身的素質。測試人員需要學會去構建適合自己的質量保障體系（可參考：構建軟體質量保障體系），建立質量意識和責任感。但是，這些都需要時間和成本的投入（不論是公司流程制度的投入，還是個人技能提升的投入）。

質量不是 “希望” 的結果，它是付出的收穫。關鍵在於你願意用什麼去交換。

質量是昂貴的，在當下很多的團隊中，快比好更重要，只不過當有一天質量變成我們無法再忽視的問題時，別不知所措地想不起來質量是在哪裡搞丟的。

共勉。