我們需要什么樣的測試?

　　左耳朵耗子發表了《我們需要全職的QA嗎?》后，一石激起千重浪，贊成者有之，激烈反對者有之;有人說文中對QA的定義不對，還有人說以偏概全…… 的確，在需不需要專職的QA角色這個問題上，很難用一個簡單的“需要”或“不需要”來回答。前兩天我寫了一篇對該文的回應文章，但由于文章寫就得比較倉促，很多觀點來不及完整表述，因此，在“真理越辯越明”的原則下，在這篇文章中，我準備就“我們需要什么樣的測試”這個問題說說我自己的看法。

　　首先要說明的是，這篇文章完全不是討論“我們是否需要專職QA”這個問題的，也不是討論“各種情況下QA或測試工程需要做什么”，而是從我自身對測試的認知和個人經驗出發，說一說我對不同特點的產品需要的測試的看法。

　　本文討論的前提是：“不同的產品需要不同的測試”。當我提到“產品”時，除了產品本身所對外展現的特性外，還會隱含地包含了該產品開發團隊的狀況。這篇文章沒有把行業作為一個劃分的維度，是因為我相信，即使在同一個行業中，也存在各種截然不同的產品。

　　測試是為質量服務的，測試活動圍繞質量進行。這個定義是我們今天討論的出發點。ISO 9126模型給出了一個多層次的質量模型定義，該定義包括了各個正交維度的質量屬性，這些質量屬性中既有面向用戶的，也有面向開發的。但在實際的測試工作中，一旦提到產品質量，大部分人更容易將其理解成“用戶質量”，也就是“最終用戶所能感受到的軟件的質量(例如，軟件的功能性、性能、安全性等等)”。 “用戶質量”是用戶所能夠直接感受到的產品的“好壞”，也是用戶是否愿意為產品付錢的主要原因。因此，在測試中重視“用戶質量”是必然的。設想一下，如果 A公司要為B客戶開發一個軟件，只要該軟件最終能夠達到B用戶的要求，A公司就能拿到錢，通常這也就意味著A公司“成功的完成了該軟件的開發”。從這個角度來說，“用戶質量”就是軟件開發是否成功的標準。

　　然而，如果深入看待整個軟件開發過程，事情就沒有這么簡單了。A 公司為客戶B開發的軟件并非是一錘子買賣，而是需要不斷的維護和升級的，B用戶不斷提出新的需求，而這些新的需求都要被加入到軟件中去。在這種情況下，從效益出發，A公司就不能僅僅考慮最終的產出是否能夠滿足B客戶的要求了，而是必須想辦法保證產品在持續演進的過程中始終保持好的可維護性和可測試性，這樣 A公司才能以較低的成本讓這個產品持續成功。因此，如果不把軟件開發看成一錘子買賣，而將該軟件的生命周期的維護過程考慮進去，我們就不得不關注“用戶質量”之外的“開發質量”，這里的“開發質量”就是指產品內在的，是否容易被修改、是否容易被移植、是否容易被驗證的特點。

　　1.“用戶質量”和“開發質量”就是我通常用來分析一個產品究竟需要什么樣的測試的第一個因素。

　　在這個維度下，我們可以很容易地理解，如果一個產品僅僅是 “一次性”的產品(也即，開發后不再需要維護和持續演化)，那么測試的重點一定就是“用戶質量”(只需要關心該產品是否在用戶面前表現得夠好就可以了);代碼是不是夠爛，設計是不是不合理并不重要。而如果一個產品是需要持續演進較長時間的，那就必須關心代碼和設計的質量(“開發質量”)。例如，一個采用付費下載方式進行銷售的小游戲，開發團隊通常不會花太多的時間和精力在保證產品具有良好的“開發質量”上，而寧愿花更多的時間去調整外部的細節表現，音效，圖像上。

　　2. 另一個直接決定了產品需要什么樣的測試的緯度是“產品對缺陷的容忍程度”。

　　測試工程師有時候喜歡把“零缺陷”作為標榜測試工作的口號(我在很長一段時間內也是如此)，但，仔細想想，如果發現一個缺陷的成本比讓這個缺陷留在產品中帶來的損失更大，那是否還值得去發現這個缺陷?我想，從項目的角度來說，答案是不言而喻的。測試是一個資源權衡的活動，也是一個基于風險的活動，因此，產品的缺陷帶來的影響越小，影響越容易被消除(修復)，這個缺陷的價值就越小，值得投入用來發現缺陷的資源也就越少。

　　拿互聯網產品和傳統的桌面產品來比較，對桌面型產品來說，缺陷的修復成本足夠高(只能通過軟件召回或是發布補丁的方式)，因此對缺陷的容忍度就低;而對于互聯網產品來說，由于其產品的修復成本足夠低(對一個已知的缺陷，可能只需要花上幾分鐘到幾十分鐘就能完全修復了)，因此相對而言，其對缺陷的容忍程度更高(當然，對于那些會導致用戶數據損失或是帶來其他不可逆破壞的缺陷，那又另當別論了)，對互聯網產品開發來說，及時識別缺陷(發現那些用戶已經遇到的缺陷)，快速定位缺陷和快速修復缺陷的能力往往要比在系統測試階段發現缺陷的能力更重要。而要能有強大的識別缺陷和定位缺陷的能力，就必須依靠產品內建的“開發質量”了。

原文轉自：http://www.uml.org.cn/Test/201210084.asp