續一篇：類比醫學檢測看軟件測試

上一篇blog（http://blog.csdn.net/superqa/article/details/7216934）貼出來後在weibo上引起了不少同行的討論，也給了我一些新的啓發，繼續寫一篇，也結合大家不同的一些觀點。

對應weibo的地址在這裏，http://weibo.com/1659525945/y316NCTai，列舉一些評論，大家各自發表自己的觀點，也沒有人當得了裁判。在此也表示感謝！

“MiniStarClub001-邰曉梅：很好的測試思考和啓發！ 就是文章最後的觀點 認爲測試還是要靠標準的方法和技術 改進纔好進行 以及測試將來的方向是將標準的方法和過程工具化 不太認同 我更傾向於認爲以人爲中心的測試技能提升是測試的方向 而不是以工具、方法、流程爲中心的技術 (1月29日 16:45)”

“崔啓亮-北京ISTQB：測試發展的最終形式是流程化和自動化，缺陷可視化檢查和警告及預防，測試人員的作用是確定測試策略，發揮行業領域知識，規劃典型測試場景。大項目測試成功的關鍵是流程，小項目靠某些個體的經驗和能力。 (1月29日 23:08)”

“盧曰萬：回覆@MiniStarClub001-邰曉梅:工具、方法、流程是持續改進的目標，也是基礎，同時測試是良心活，人的技能和工作意願是測試改進的驅動力，確保面向應用場景的驗證高質量完成。 (1月29日 23:19)”

“MiniStarClub001-邰曉梅：回覆 @盧曰萬:我還是覺得人的技能是基礎 流程 方法 工具是輔助 最近讀的一篇博文闡述了類似的觀點 供參考 http://t.cn/zOvB8UW (51分鐘前)”

“盧曰萬：回覆@MiniStarClub001-邰曉梅:對團隊而言，鐵打的營盤流水的兵，人是會流動的，但工具流程方法可以基線下來成爲基石 (34分鐘前)”

首先我想澄清一點，我並沒有因爲認爲有了這些多樣的標準的檢測手段，就不需要人的經驗了，因爲:

1. 這些檢測技術還在不斷髮展，都是有經驗技術、能力和意願的人在推動

   新的技術的出現，老的技術的改進，變得跟簡便、方便和便宜。

   這些就好比我們的測試技術的改進一樣，也是需要人去研究，試驗和實驗的，並結合臨牀的經驗來調整和改進。

2. 如果來使用技術和解讀測試結果做出判斷也需要人的經驗技能

   如果只是一項檢測結果，解讀起來可能比較容易，因爲牽涉得東西不多，但是實際中對於一個疾病的診斷，通常都不會是隻依賴於一項檢測結果，那麼如果綜合這些結果來分析其實也是很需要經驗和能力的。否則，醫生怎麼會有高低之分呢，大家在同一個醫院拿到的檢測結果是一樣的，但不是每個人都能同樣做出準確的診斷。

但是我不認同將經驗和技能停留在經驗和技能。這裏拿中醫和西醫做個對比，無意冒犯，只是做個類比。

在傳統中醫（現在大點的所謂中醫院裏，西醫的各種器和術都有）裏看病，講究說學逗唱，啊不是，望聞問切。比如看舌苔，摸脈搏，看氣色等等。我不否認有很高明的中醫，基於自己高深的技術和多年的經驗，能很好的運用這些，來進行準確的診斷和對症的治療。

但是現實中，我們都依賴於這些含糊的說不清楚的經驗，好像難以應付那麼多人的看病的需求，而且高明的中醫似乎太少。他們的這些經驗都是靠日積月累，難以傳承。

這是一種困境，我們看到的現實還是西醫的思維在主導（有多少人是老中醫看好病的？），而且大家真正生病的時候大部分還是靠的西醫。因爲一些標準化和定量的東西更容易普及和推廣，而這些很多時候體現在具體的設備和工具。

大家來看看西醫的方法，有很大一部分的時間（包括患者花的錢）都是在前期的檢測，其中的監測和後面的複查。這其實也說明了測試的價值（這裏厚顏的把這些都攬成測試）。不說別的，看看那些大家每年體驗的科目就知道很多了，這裏不一一列舉。

分享我自己的一個例子。

第一次結石發作的時候，右下腹部異常疼痛，早上去醫院急診，根據症狀，值班醫生剛開始判斷可能是闌尾炎，很像，但是不確定，後來做了個血液檢查，不太像闌尾炎的症狀，因爲白細胞計數還正常（醫學知識太少，也許不是看這個），然後進一步去做了個B超，就可以更肯定不是闌尾炎，而像是結石。

我想作爲醫生或者患者，我們都希望看到這樣的比較可靠的和結果明確的測試，而不是依靠醫生的經驗，這樣萬一碰到一個沒有經驗的，把我趕緊弄到手術室去切闌尾就悲劇了。而如果有了上面兩項的測試報告，我想有基本的醫學知識的醫生都不至於把我弄去切闌尾。

那麼這樣的測試的價值就體現出來了，至少包含了三個方面的要求：

第一他不需要執行測試的人有太深厚的經驗，當然還是要一部分的，比如做B超的，那麼多人都能勝任。

第二流程比較標準，結果比較穩定。

第三，測試報告對於看的人也不高深，能清楚的反映事實。

說了這麼多，我想我的point不在於否認測試人員的技能和經驗的重要性，或者要把一些東西僵化。但是我感覺到我們軟件測試行業這種被廣泛認可的專業性的東西還是太少，不能每次說到我們對比開發或其他軟件研發的工種的獨特價值就是我們對測試的理解、測試的策略和方法論等等，而應該是一些明確拿得出來的被普遍認可價值的有明確結果的東西。

現實一點軟件測試因爲被測對象的原因還不太可能做到醫學檢查那麼標準，所以我們花了很多的時間和精力熟悉“人”（我們的被測產品），學習或者發明檢測技術，開發儀器設備（測試工具，自動化系統等），一起執行測試，分析報告。

這些都很有價值，沒有錯，但是有些是對外而言的，對外看的是拿出來的結果，包括別人也可以用到的東西。就好比我們說一個國家航天技術的發達程度和水平，不是看他們有多少有經驗的人和知識的積累，而是發射了什麼東西出去，有沒有人在太空行走。這是倒過來看的，沒有人腦子裏的那些東西也不會出這樣的成果，但是我們對於外界的貢獻直接的而言是這些外化的東西，我想軟件測試也是一樣。

從這一點上，我比較傾向於把知識經驗技能外化或者固化到可見可用的工具或者系統上。

我還沒有想得太清楚，也許一套穩定高效的自動化測試集對於一個產品就是一個這樣的東西，因爲它同樣滿足於上面提到的三個要求。

在曾經做過的一個項目中，這一點讓我印象很深。

當時我們將大概一半，約幾千個測試用例自動化了，但是由於各種原因，daily build來用的時候總是有部分用例失敗，要去確定是用例的問題還是產品的問題需要不少時間，每天這樣做也耗不起。後來我們抽取了其中涉及主要功能點的重點用例，約200個左右，花力氣弄得比較穩定了。能達到的結果就是，只要有用例fail了，基本都是產品的bug或者一些未知的改動導致的（如果我們不能做到如此憑什麼要求產品也穩定?）。這樣運行了一段時候後，比較有信心了。我們把這一套自動化的用例集幫助開發人員在他們的環境裏面部署起來，作爲daily build的驗收測試，每天的結果郵件通知大家，不全pass的build不接受做進一步測試。

開始我們想這樣會增加開發人員的工作量，估計會比較反感。但是後來我們發現其實並非如此，因爲這套測試集比較穩定，能及時的發現問題，開發人員很積極的第一時間去看，而且覺得幫到了他們，因爲他們有時也不確定改動有沒有問題，反倒很認可這套東西的價值。

對比我這裏舉的例子，也不難理解，我們大概也很少聽到醫生討厭醫學檢測，因爲這些東西確實是在幫助他們發現問題，定位問題，或者至少提供有用的信息。

我想從這個意義上，才能實現開發和測試良好合作，因爲雙方都爲同一個目標貢獻有價值的東西。而另一個方面，測試人員要贏得別人發自內心的尊重，一定是因爲專業，而不是口頭呼籲重視測試。

我想一定還有更多的，更能普遍一點的東西，來自於測試人員能提供出來的，性能測試的一套可以實施的東西算一個嗎？安全測試的工具和報告？

都是些不成熟的思考，歡迎大家拍磚。