選擇測試之路-路上的迷茫

2010年12月31日，由于部門搬遷至北京，選擇了離開網(wǎng)易，當(dāng)時作為技術(shù)主管負(fù)責(zé)整個體育頻道賽事系統(tǒng)產(chǎn)品線。

在網(wǎng)易從事多年開發(fā)，還是依依不舍離開了，面臨的是完全從零開始的職位：SQA，tester。

當(dāng)時非常迷茫，畢業(yè)后工作目標(biāo)是：架構(gòu)師。怎么就突然畫風(fēng)轉(zhuǎn)變了呢？

Raymond跟我說是團(tuán)隊(duì)需要，但對于為什么被選擇做軟件質(zhì)量保證，而不是繼續(xù)在研發(fā)上進(jìn)取，我持有保留態(tài)度：憑什么要我轉(zhuǎn)型，不是別人？于是Raymond把我的優(yōu)點(diǎn)暴露出來了：認(rèn)真、心細(xì)、負(fù)責(zé)；基于以上幾點(diǎn)，只有“我行”，話都說到這份上了，只能給力了，安慰自己船到橋頭自然直。

那時塞人到每個崗位，而我的優(yōu)點(diǎn)可以勝任新崗位。

打心底對質(zhì)量管理、SQA等概念，無從入手，沒啥概念，腦子里面沒有太全面的認(rèn)知，即使Raymond講過一些（覺得他也是半桶水有木有），還是覺得不夠全面，不知道業(yè)界是如何做的？所以心里多多少少有點(diǎn)擔(dān)心！擔(dān)心什么呢？擔(dān)心做不好，搞砸了。

幾個人成立一個新團(tuán)隊(duì)，什么都是從零開始，關(guān)鍵還是要有一些流程，這幾年開發(fā)中也積累了些經(jīng)驗(yàn)，總結(jié)了些問題。在12月底，我提交了《軟件質(zhì)量保證第一季度計劃》，這個計劃后來也成為了整個質(zhì)量保證體系的核心，大概 綱要如下：

1、搭建項(xiàng)目管理平臺

2、搭建持續(xù)集成平臺

3、規(guī)范開發(fā)流程

4、制定軟件質(zhì)量保證規(guī)范流程

5、建立缺陷管理

6、建立風(fēng)險管理庫、經(jīng)驗(yàn)教訓(xùn)庫（長遠(yuǎn)計劃）

2011年1月25日，苦于沒有規(guī)范的流程，做起事來還是不夠順暢，在奮戰(zhàn)多日之后，制定了《產(chǎn)品研發(fā)質(zhì)保流程手冊》，簡單來說劃分了：需求、開發(fā)、發(fā)布三個階段，每個階段定義驗(yàn)收的產(chǎn)物。

為什么要制定這個？必須有章可依，否則步伐不穩(wěn)健，走的再遠(yuǎn)，也會亂。

另外在調(diào)研期間，我意識到持續(xù)集成很重要，并按照當(dāng)前的需求，重點(diǎn)關(guān)注以下幾點(diǎn)：持續(xù)測試、持續(xù)審查、持續(xù)反饋。

?圖：早期的開發(fā)、測試流程原型圖。

期間發(fā)生的一些故事，順帶提一下。

個人方向感出現(xiàn)偏差，Raymond指出（感覺有人知道自己工作的重點(diǎn)，偏離方向的時候拉一把是好事，遇到一個靠譜的leader是很幸運(yùn)的），于是我反思總結(jié)：

首先：個人這陣子存在一定問題，心態(tài)方面，在一個新的道路上，沒有學(xué)會爬，就想跑，是非常不切實(shí)際的做法，應(yīng)該學(xué)習(xí)《熱血教練》里面的卡特教練的方式，先把基本功練扎實(shí)了，才能有勝算。不然，就得做很多次“俯臥撐”和“自殺”。

其次：個人價值應(yīng)該迎合集體價值，不應(yīng)該存在分歧，更不應(yīng)該夸大個人形象。如果想做的更高、更有成就，就得付出的更多，這個我非常認(rèn)同。

再次：我相信，圓圈，已經(jīng)畫好了，只要認(rèn)真實(shí)施決策，圈將會被填充成餅圖，即使填充過程中遇到困難，也是可以溝通解決的。而這個填充的力度，在于每個人的付出程度。

為什么這個時期容易發(fā)生偏差？剛開始做測試有點(diǎn)浮躁、摸不清思路，看不見遠(yuǎn)景，并且很著急找到成就感！

下了狠心：既然選擇了測試，就必須突破它?。?！發(fā)動封閉式的助攻。

終于到了春節(jié)，可以緩一口氣了，感覺自己還沒有ready，需要充電，趕緊追上去，為了摸清楚業(yè)界是如何去做，2011年春節(jié)，我放棄了一切活動，呆在家里，認(rèn)真研讀之前買的幾本書：質(zhì)量管理、缺陷預(yù)防、軟件測試、持續(xù)集成等等之類，并且通過互聯(lián)網(wǎng)了解一些公司是如何開展測試和質(zhì)量管理的?？赡苡泻芏嗳瞬焕斫猓y得放假，何不好好玩玩，放松呢？

犧牲了一個長假期，是多么可貴，反而收獲更大，懂得人自然會get到。

或許大家會覺得到這個時候都很順利，其實(shí)不是，春節(jié)期間，再一次迷茫了，憑什么放棄了開發(fā)的樂趣，測試的樂趣究竟在哪里？如果繼續(xù)研發(fā)道路，會越來越接近架構(gòu)師；而現(xiàn)在，完全從零開始折騰了。（后來證明，如果你堅持了一件事情，你不能證明它是對的，那你就是錯的），后來跟Raymond在電話進(jìn)行了爭論，最終把目標(biāo)定了下來，也許是這個時候，更加堅定了決心。

這件事，讓我想起：

人的一生有許多難以取舍，

? ? 困惑不已的鎖事所糾纏著，

? ? 這時所需的就是斷然的舍棄與明智的抉擇，

? ? 唯一會限制我們的，

? ? 是我們自己的決心。

從業(yè)的道路上，難免遭遇坎坷，要不斷提升自己，也有三點(diǎn)切身體會：

1、如電影《熱血教練》中卡特教練所說，先把基本功練扎實(shí)了，才能有勝算。既然從零開始，就不要被困惑不已的瑣事所糾纏著，下決心突破，可以研讀：質(zhì)量管理、缺陷預(yù)防、軟件測試、持續(xù)集成等書籍，并且通過互聯(lián)網(wǎng)了解一些公司是如何開展測試和質(zhì)量管理的方方面面。

2、個人價值迎合團(tuán)隊(duì)價值，果斷取舍，為團(tuán)隊(duì)利益著想。

3、堅定信念，避免浮躁，把握遠(yuǎn)景，不要急于尋求成就感。

無悔選擇測試之路-路上的抉擇、進(jìn)取

有了流程規(guī)范，接下來是實(shí)施和持續(xù)改進(jìn)。這些規(guī)范運(yùn)用在一個項(xiàng)目上，先做了三個月，不停地測試，編寫功能測試用例，也走了2條彎路：

用例花了大量時間編寫，就連打開瀏覽器、輸入xx、點(diǎn)擊登錄，這些也記錄了（這種是早期狀況）。 我居然還請纓加入開發(fā)，因?yàn)榭吹揭恍┤蝿?wù)完成不了。后來雷叔也指明，測試做測試應(yīng)該去做的，如果我當(dāng)時幫忙做開發(fā)，那么很多測試都完成不了，一樣保證不了質(zhì)量。

測試人員除了要了解業(yè)務(wù)，使用簡單、清晰的語言結(jié)構(gòu)來進(jìn)行測試之外，還應(yīng)該準(zhǔn)確定位自己，明白自己在整個版本迭代中，控制質(zhì)量的位置！

事后想想，那段日子鍛煉了什么？那三個月無法忘記，每天高強(qiáng)度測試，用的最多的就是：功能測試（邊界值、場景法），白盒測試。其實(shí)就是鍛煉了測試的基礎(chǔ)技能和流程管理。

后來測試管理流程逐步建立起來，但是在測試過程中，應(yīng)當(dāng)如何提高代碼質(zhì)量？這個階段我們參考了敏捷開發(fā)中高質(zhì)量 Java 代碼開發(fā)實(shí)踐，做了一些適合團(tuán)隊(duì)的改進(jìn)，見下圖：

這種迭代版本中java代碼質(zhì)量提升的模式，已經(jīng)采用了將近一年，非常有效。

同年Q2，我們對測試管理進(jìn)行了改進(jìn)，其中是受到@段念-段文韜《組織敏捷測試》影響，采用類似“一頁紙計劃”的測試文檔（在此要感謝@段念-段文韜）在redmine進(jìn)行管理。之前每次整理測試計劃，發(fā)送給開發(fā)人員，實(shí)際上耗費(fèi)了一些時間，并且成效不大，現(xiàn)在的任務(wù)：需求、開發(fā)、測試，全部交給redmine管理，所有事情一目了然，對任何人都是可見的，有沒有完成，進(jìn)度如何，非常清晰。

為了規(guī)范整個開發(fā)測試流程的管理，包括開發(fā)、測試的交互，我們又制定了輕量級的 SQA框架，見下圖：

圖 最初制定的SQA框架（2011年3月31日）

不過此后這個框架也發(fā)生了比較大的變化，做得更好、更輕量級。無獨(dú)有偶，我偶然的機(jī)會買了一本@朱少民老師的：《全程軟件測試》，發(fā)覺這個SQA框架也是滲透到目前的每個環(huán)節(jié)，更適合目前團(tuán)隊(duì)的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，不然可以少走很多彎路！?。?/p>

大家可能會問：Scrum模式、用戶故事，測試人員怎么利用？為什么想到這個？如果遺漏了測試場景，團(tuán)隊(duì)會很不爽，怎么避免呢？結(jié)合@Aullyxiao的《軟件測試之魂》提到分層測試的想法，想了想，還可以這么整：

對于目前的開發(fā)架構(gòu)來說，一個用戶故事，涉及這四個點(diǎn)，可以從這四個點(diǎn)入手來進(jìn)行質(zhì)量保證。如何做呢？單元測試就開發(fā)人員處理了；代碼審查，測試人員可以參與和監(jiān)督，其實(shí)就是要保證：將開發(fā)任務(wù)與提交到SVN的代碼進(jìn)行關(guān)聯(lián)。這樣一來，當(dāng)測試人員檢查開發(fā)任務(wù)的時候，就可以找到改變過的代碼。我曾經(jīng)試過從這些代碼里面查看邏輯，找到分支場景，補(bǔ)充到測試用例里面。

另外在此期間，還看過@架構(gòu)師Jack原創(chuàng)的《功能測試用例基礎(chǔ)設(shè)計模型》，這個文檔2天轉(zhuǎn)發(fā)已超過150次，我也向所有同行推薦該測試設(shè)計模型實(shí)例化的測試用例，供大家消化該設(shè)計模型。也借鑒了@季哥來自淘寶的《探索式測試》系列文章，包括：《探索式測試的秘密——記在淘兩年》、《組合測試法中的全對偶測試法》、《探索式測試實(shí)踐之缺陷大掃除和結(jié)對測試》。

當(dāng)然這么多東西，我覺得自己還需要時間來消化。

繼續(xù)測試之路-路上的風(fēng)景

也許會有人問：有沒有后悔做tester？

我過去也常問自己：做得開心嗎？產(chǎn)品質(zhì)量提升了嗎？看到自己的前景了嗎？找到high點(diǎn)了嗎？

現(xiàn)在我可以回答：OK，我做到了，并且還可以持續(xù)做得更好。

可能有很多測試人員會問：測試人員的價值到底何在？在這里，我套用和整合朱少民老師的一些術(shù)語，給出我的回答。

我認(rèn)為，Scrum中測試人員價值應(yīng)當(dāng)體現(xiàn)在：

1、預(yù)防缺陷的手段，提高洞察力，增強(qiáng)業(yè)務(wù)知識。

缺陷在需求、開發(fā)前期就已經(jīng)存在了，關(guān)鍵是用什么手段去挖掘出來預(yù)防。在sprint前獲取到的需求，測試人員可以站在客戶角度上來闡述自己的觀點(diǎn)，與開發(fā)人員進(jìn)行充分交流和討論，使自己在用戶體驗(yàn)、業(yè)務(wù)邏輯等等方面的經(jīng)驗(yàn)充分體現(xiàn)出來。? ?

2、開發(fā)過程的質(zhì)量反饋

在開發(fā)過程中，測試人員除了站在客戶的角度進(jìn)行測試，還應(yīng)當(dāng)提供更全面的質(zhì)量反饋，包括代碼質(zhì)量的檢查，這個可以通過redmine與SVN雙向關(guān)聯(lián)來做檢查依據(jù)。目前整個過程測試人員尚未參與代碼編寫，應(yīng)當(dāng)參與并推進(jìn)代碼評審，將代碼問題及時反饋出來；并且參與或者推進(jìn)單元測試，檢查單元測試狀態(tài)（確保單元測試達(dá)到80%以上覆蓋率，幫助開發(fā)人員開發(fā)出具有良好可測試性的代碼），自始至終將質(zhì)量問題及時反饋出來，保證在sprint的整個過程中質(zhì)量受到足夠的關(guān)注，提高質(zhì)量改進(jìn)的持續(xù)性和可視性。

3、隨著版本任務(wù)的增加，每個版本回歸測試的成本增加，可以適當(dāng)考慮部分穩(wěn)定功能進(jìn)行自動化測試。當(dāng)然，這是遠(yuǎn)景。

4、持續(xù)改進(jìn)、反饋，充分發(fā)揮每個版本統(tǒng)計報告的作用，對缺陷進(jìn)行分析，總結(jié)出一些規(guī)律，幫助開發(fā)人員建立良好的習(xí)慣，改進(jìn)代碼的質(zhì)量。

測試人員，應(yīng)當(dāng)在自己的道路上看到風(fēng)景，以前作為開發(fā)，寫好一個功能，很high；測試人員也要有這種心境，提高了產(chǎn)品質(zhì)量，預(yù)防了缺陷，很high。找到自己的high法，才可以把測試玩得更爽 ，我知道@朱少民老師、@季哥來自淘寶、@段念-段文韜、@架構(gòu)師Jack，都玩得很爽，但是有一點(diǎn)：要爽得靠自己，多跟高手交流，有利于提升自己，但是不要刻意復(fù)制別人成功的經(jīng)驗(yàn)，因?yàn)槊總€團(tuán)隊(duì)的模式和環(huán)境不大相同。

測試路上總結(jié)

每個人離開自己熟悉的領(lǐng)域，投入到新的領(lǐng)域中（說實(shí)在軟件測試也囊括了開發(fā)領(lǐng)域），必然存在一些迷茫，不知如何入手，身邊如果有一個靠譜的高手，指點(diǎn)一下，眼前將會一片明亮?？上?，現(xiàn)實(shí)總是殘酷的，往往很多時候，都要靠自己去摸索，只有經(jīng)歷了、深刻體會了，才知道如何改變，以及如何迎接新挑戰(zhàn)，調(diào)整到恰到好處的心態(tài)。這樣子，才能夠穩(wěn)健進(jìn)入轉(zhuǎn)型的軌道。不要害怕改變和投入，一定要堅定信念，在前進(jìn)的道路上，多參考同行的成功經(jīng)驗(yàn)：@朱少民老師、@段念-段文韜、@季哥來自淘寶、@架構(gòu)師Jack、@Aullyxiao等等，迎合團(tuán)隊(duì)價值，不斷修正自己的偏差，走出一條華麗的直路！

我很慶幸，經(jīng)歷了一個測試團(tuán)隊(duì)從無到有的創(chuàng)建，同時也幫助開發(fā)人員掌握了一些測試的基本技能，用于推進(jìn)質(zhì)量保證，讓整個團(tuán)隊(duì)達(dá)到共識?，F(xiàn)在的我，只是剛過了轉(zhuǎn)型的痛苦期，測試工作也僅僅是剛剛開始，還有很多有意義的事情需要去做。

路漫漫其修遠(yuǎn)兮，吾將上下而求索！

多年后小結(jié)

1、靠譜的領(lǐng)導(dǎo)和團(tuán)隊(duì)很重要

我跟Raymond吵過不止一次，對于目標(biāo)、方向不清晰，糾結(jié)的時候可能會大干一場，這也是很多團(tuán)隊(duì)創(chuàng)業(yè)初期會遇到的問題，目標(biāo)不清晰、信任度低。優(yōu)秀的人組成一個靠譜的團(tuán)隊(duì)，可以省去很多麻煩事情。另外還有一點(diǎn)，愿意給你時間試對、試錯，并不是說浪費(fèi)資源投入去試。

2、開發(fā)=測試，越到后面越?jīng)]有邊界

當(dāng)初的目標(biāo)是架構(gòu)師，后來從業(yè)中逐步打破了開發(fā)測試的邊界，才領(lǐng)悟到：開發(fā)就是測試，測試就是開發(fā)，架構(gòu)師實(shí)際在兩者之上匯集了。需要站在一個更高角度看問題，開發(fā)的功能是否合理，架構(gòu)如何，在此架構(gòu)下的功能帶來何種體驗(yàn)，用戶體驗(yàn)是否愉悅呢？

3、敏捷開發(fā)測試是必然趨勢

所謂的敏捷，不要生搬硬套，要適合團(tuán)隊(duì)能夠本土化的才是好。過程中有個環(huán)節(jié)要重視：溝通?，F(xiàn)在分工太細(xì)化了，反而溝通成本高了，大家有沒有想過這個問題，為什么呢？以前全棧（除了切頁面）：后端+前端+運(yùn)維+測試，都是自己弄，根本沒啥溝通成本，反而效率更高，提交的功能甚至有些文檔都沒有。這個問題留給大家思考。

4、產(chǎn)品方向、面向市場的快慢程度也決定成敗

開發(fā)個小功能，厲害咯；測試沒問題，厲害咯，其實(shí)開發(fā)再多、再好，測試投入的再多再好，產(chǎn)品沒市場，沒人用，都是失敗的。有些時候，開發(fā)、測試太糾結(jié)于細(xì)節(jié)，盡快把產(chǎn)品推向市場，試對試錯才是硬道理，當(dāng)然是在一定的質(zhì)量基礎(chǔ)之上去推市場。

5、剛起步切勿浮躁

一開始就是成功的話，可能就沒有領(lǐng)悟到過程。不管總結(jié)反思，改進(jìn)，切勿害怕進(jìn)入一個新領(lǐng)域的陌生感，投入實(shí)戰(zhàn)，是對是錯還看當(dāng)下。