離開網易的轉型之路2：無悔選擇測試之路-路上的抉擇、進取

Infoq發佈了文章，這裏我仍是吐槽原文，未修改的，讓你們品味下：

 

2、無悔選擇測試之路-路上的抉擇、進取

 

 

有了流程規範，接下來是實施和持續改進，運用在一個項目上，先作了三個月吧，不停地測試，編寫功能測試用例，也走了2條彎路：

 

 

一、用例花了大量時間編寫，就連：打開瀏覽器，輸入xx，點擊登陸，這個也記錄了（這種是早期情況）。

 

 

二、我竟然還請纓加入開發，由於看到一些任務完成不了，後來雷叔也指明，測試作測試應該去作的，若是我當時幫忙作開發，那麼不少測試都完成不了，同樣保證不了質量。

 

 

因此，測試人員除了要了解業務以外，使用簡單、清晰的語言結構來進行測試以外，還應該準肯定位本身，明白本身在整個版本迭代中，控制質量的位置！

 

 

你們可能想知道，那段日子鍛鍊了什麼？那三個月沒法忘記，天天高強度測試，用的最多的就是，功能測試：邊界值、場景法；白盒測試。其實就是鍛鍊了測試的基礎技能和流程管理。

 

 

後來測試管理逐步創建，可是在測試過程當中，應當如何提升代碼質量，也參考了敏捷開發中高質量 Java 代碼開發實踐:http://www.ibm.com/developerworks/cn/java/j-lo-agile/，作了一些適合團隊的改進：

 

 

 

 

這6點不言而喻，這種迭代版本中java代碼質量提高的模式，已經採用了將近一年，很是有效果。

 

 

   同年Q2，對測試管理進行了改進，其中是受到，@段念-段文韜，組織敏捷測試（http://www.infoq.com/cn/news/2011/01/dn-agile-test-3）影響，採用相似「一頁紙計劃」的測試文檔（在此要感謝@段念-段文韜）在redmine進行管理，以前每次整理測試計劃，發送給開發人員，實際上耗費了一些時間，而且成效不大，如今的任務：需求、開發、測試，所有交給redmine管理，全部事情一目瞭然，對任何人都是可見的，有沒有完成，進度如何，很是清晰。

 

 

ok，以前不是講過檢查表的作法嗎？雖然覆蓋了很多範圍，用了一段時間，收效不大，決定改進，變成季度性檢查，包括的方面比較多。

 

 

後來爲了規範整個開發測試流程的管理，包括開發、測試的交互，又制定了SQA框架，輕量級的：

 

 

 

 

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

 

 

後來發生了比較大的變化，作的更好、更輕量級，無獨有偶，買了一本@朱少民老師，的：《全程軟件測試》，發覺這個SQA框架也是***到目前的每一個環節，更適合目前團隊的scrum模式，在此也要感謝@朱少民老師，真是相見恨晚，否則能夠少走不少彎路！！！

 

 

你們可能會問，scrum模式，有不少用戶故事，測試人員怎麼利用？爲何想到這個，當知道遺漏了測試場景，會很不爽，怎麼避免呢？加上@Aullyxiao的《軟件測試之魂》提到分層測試的想法，想了想，還能夠結合這麼整：

 

 

 

 

 

 

對於目前的開發架構來講，一個用戶故事，或許涉及這四個點，能夠從這個四個點入手來進行質量保證，如何作呢？單元測試就開發人員處理了，代碼審查，測試人員能夠參與和監督，其實就是要保證將：開發任務與提交到svn的代碼進行關聯，這樣子，當測試人員檢查開發任務的時候，就能夠找到改變過的代碼，曾經試過從這些代碼裏面查看邏輯，找到分支場景，補充到測試用例裏面。固然，在此期間，看過@架構師Jack，《功能測試用例基礎設計模型》，也採用了其中一些；還有@季哥來自淘寶，的探索式測試，我以爲本身還須要時間來消化。