第十二回 測試驅動開發

作為一名研發人員，與測試人員打交道的機會是非常多的。研發人員與測試人員是制約與被制約的關系。可惜的是研發是被測試制約，原因很簡單：測試人員決定了研發人員出活的質量好壞（從根本原因上說，質量的好壞都是研發人員做的，測試人員只是檢驗，從而讓其更好）。

測試人員的日常工作就是負責測試研發人員開發的產品是不是可用的，這就好比一個廚師炒了一盤菜，有專門的品菜員來嘗你炒的好不好吃，品完了再給客人上桌（當然現實中可能沒有這回事）。如果這個品菜員發現你辣椒放多了，那你就完了，弄不好一個月的菜都白炒了。如果品菜員沒有發現辣椒放多了，而客人吃的時候發現辣椒放多了，吃完了直打噴嚏，并因此大發雷霆，甚至叫人把店砸了，那問題就嚴重了。這時候這個嚴重的問題導致品菜員和廚師要各打50大板，這50大板是各打各的沒有任何關系，甚至廚師那邊如果不打，品菜員這邊也不管，他只挨他的打就是了，也就是廚師與品菜員是屬于不同的考評體系。因此每個合格的品菜員在品菜的時候都想盡了一切辦法，千方百計挑毛病。

研發與測試的關系就是廚師與品菜員的關系，這時候你知道了品菜員有多么關鍵，因為如果一盤不合格的菜上了桌，吃出問題麻煩就大了。因此品菜員大權在握決定了廚師炒菜的好壞。說研發一直被測試欺負一點也不為過，因為品菜員是菜品質量的最后一道關，他放過去菜就上桌了。對于產品來說，測試是產品的最后一道關，如果他沒發現問題，產品就往外賣了，如果用戶這時候發現問題，后果可想而知。因此測試可以對研發進行制約，提出質量上的各種要求，研發不服可以上訴，但是研發自己不具備對測試提出的問題拍板的權力，他只有解釋的權力。

這就是著名的測試驅動研發模型，簡單來說就是測試說了算，他說這里有問題要改，研發就要改，如果研發說不改，可以說服測試，但測試有拒絕的權力，如果研發仍堅持不改，那就要上訴。如果測試說不改（這種情況基本不存在，從上面可以理解測試人員對產品質量的要求要遠高于研發，這就好比如果品菜員覺得這盤菜炒得好，那廚師可能不管真好還是假好，馬上上桌，所以品菜員一定要把握菜品的整體質量），那研發一般默認。所以研發人員受測試人員的制約。

我在學習完三周兩天之后就開始正式上崗工作了。在日常的工作中我們主要做兩件事情：第一件事情是處理測試人員測試出來的問題或我們自己發現的問題，第二件事情是做新的開發。事實上新開發不常有，因此我們平時主要處理測試人員反饋過來的缺陷，也叫問題單。即測試人員發現問題后，將問題描述清楚，提一張單到研發這里（這張單一直存在，直到問題被解決才能關閉，保證了問題一旦發現就會被解決，不會丟失），研發開始看著單排查哪里錯了進行修改。下面我們來介紹一下問題單這個新鮮事物，因為除了開發新特性，我們平常就是在處理問題單。問題單可以形象地比喻為：你要寄一個包裹，這時候郵遞員給了你一個單子，單子上有號碼，你可以隨時查看包裹的狀態，以及有沒有到達。只是在這里這個包裹里裝的是一個問題。

問題單的處理流程也體現了測試驅動開發的特點。首先測試人員發現問題，要開發人員確認，這是第一步。也即測試人員說：這個地方錯了。研發人員要開始看，最后說確實錯了。那這個問題就是有效問題，測試人員就有績效了，因為測試出了問題。然后測試人員將問題描述清楚，比如寫上電視機在開關八次之后，不亮了，開發人員唐伯虎確認的，然后這個問題就描述在一張單里，單就送到了開發部的PL，邱道長一看：哦，唐伯虎確認的。單就走給唐伯虎進行修改。唐伯虎一看：哦，確實是我確認的。修改完成，然后再發回邱道長進行審核，邱道長一看問題單改得不對，照這么改，改完開關七次就熄火了，還有這錯了，那錯了，就會打回來重改。如果沒發現問題就走給業務專家進行審核，你改的問題涉及哪些方面都會有這方面的專家專門看你改得對不對，這個過程非常重要。業務專家如果發現問題，就再打回，你重新改，如果沒發現問題就將問題的修改結果發給產品歸檔人員（英文名叫CMO）進行歸檔，這樣修改就生效了。相當于你說電視機有毛病，這個零件壞了要換，那么歸檔人員一旦歸檔了，后面生產的電視機就按你說的這個零件來做了，可想而知如果你說錯了有多嚴重。最后這張問題單就又走給了測試人員，在產品的下一個版本中，看你改得對不對，比如電視機再開關八次看看亮不亮，如果還不亮，麻煩就大了。因為讓你改都改不對，這個罪名相當大，就像廚師做了一盤菜，品菜員說你做辣了，結果下一盤你做得更辣，你說這有多嚴重，基本上一年的辛苦就要付諸東流。因此從某種意義上講測試人員掌握了開發人員的生死命脈（也可以認為質量就是開發人員的生死命脈）。

問題單的流程確保了問題一旦發生不會丟失，因為一旦有問題單產生，始終有責任人進行跟蹤，直到修改完畢走到測試人員那里。他測試完成發現確實修改了沒有問題，這才將問題單關閉。問題單的這個修改跟蹤的流程后來用在了快遞業上面，發件人將包裹發出后，就產生了一個單號，這個單號可以一直查詢該包裹的狀態，確保了包裹不會丟失。各行各業都有自己的跟蹤方法，華為的某位員工因為該跟蹤流程去了一家物流公司，現在做到了副總裁的位置。

測試驅動開發是成熟產品開發的重要模式，開發與測試的這種制約關系保證了產品的質量，以及修改問題的有效性。一個產品如果測試人員過于軟弱，開發人員在處理問題的時候有著太高的話語權，一方面測試人員的勞動積極性就會受挫，另一方面針對缺陷的處理可能會放松，因此產品的質量就會產生風險。

因此問題單是我們日常生活中處理問題的主要形式，作為一名開發人員，問題單的處理過程要經歷幾位重要的角色，他都可以宣布你的修改無效，甚至因此說你工作做得不好。他們分別是測試人員、PL以及問題涉及的相關審核專家。這就保證了一個問題的處理經過了重重的關卡，保證是有效的處理。這也讓開發人員在處理問題單的時候，要經過三座大山。