轉(zhuǎn)行測試。從一本書、一門考試、一遍咨詢之后，便開始了測試之路的摸索。

重畫已走過的路線，希望得到指點，少走冤枉路。

起點：最基本（LOW）的Web功能測試（無技術(shù)含量，不得不使用這個描述，很沉重）

工具：禪道項目管理軟件

測試流程：

（一）熟悉被測試系統(tǒng)

讀需求文檔，與需求人員確認有疑問的需求

（二）制定測試計劃

1. 制定測試計劃模板；

2. 測試計劃內(nèi)容，主要確認：測試范圍、測試方法、測試工具、測試提交物、測試進度，這幾項是每個項目都不同的。其他差異性不大的內(nèi)容（如測試通過準(zhǔn)則、風(fēng)險和應(yīng)急等），參考相關(guān)網(wǎng)絡(luò)資源給出的標(biāo)準(zhǔn)。

（三）測試需求分析

1. 分模塊

2. 提取功能點，寫測試點

（四）測試需求分析組內(nèi)評審

審核所寫測試點是否完整，確保達到足夠的覆蓋率。

（五）設(shè)計測試用例

1.下載禪道的用例模板，編寫完用例再上傳至禪道管理；

2.測試用例的編寫，需遵循一定的規(guī)范。

（六）執(zhí)行功能測試

執(zhí)行邏輯功能測試、界面測試、易用性測試、兼容性測試

1.在禪道運行測試用例并轉(zhuǎn)bug

2.運行完所有用例，再進行隨機測試，新增用例并提bug

（七）整理、上報測試結(jié)果

1.統(tǒng)計用例的執(zhí)行情況、bug的分布情況；

2.提交缺陷詳細列表、測試報告。

（八）回歸測試

1.推動并跟進bug的解決，驗證bug的解決，關(guān)閉bug；

2.重跑測試用例。

禪道工具相關(guān)使用規(guī)范：

（一）用例

1.用例標(biāo)題、內(nèi)容描述要簡潔規(guī)范，一看就懂；

2.注明用例的優(yōu)先等級；

3.運行用例時，若發(fā)現(xiàn)用例描述的UI名稱、樣式跟實際開發(fā)結(jié)果差異較大，要找需求人員進行確認：確認通過，則對用例進行修改；確認不通過，則提bug；

4.運行完一個模塊的用例，思考是否需要添加新的用例；

5.測試輸入數(shù)據(jù)要規(guī)范：

（1）盡量使用規(guī)范的名稱。

譬如：姓名，使用常用的人名；部門，使用常用的部門名。

（2）影響界面美觀的輸入數(shù)據(jù)，酌情刪減。

譬如：做完超長字符串的驗證，沒出現(xiàn)bug的，盡量把超長字符串刪除，不影響界面整齊。

（3）盡量保留測試輸入數(shù)據(jù)，方便開發(fā)人員確認bug。

（二）Bug

1. Bug標(biāo)題、內(nèi)容描述要簡潔規(guī)范，一看就懂；

2. 兼容性的Bug，標(biāo)題格式突出關(guān)鍵字，方便開發(fā)人員區(qū)分、指派人員解決

如：兼容性【IE11】-用戶列表-新增操作，彈窗中的按鈕錯位

3. Bug截圖建議做上標(biāo)記，突出問題所在；

4. 注明Bug的嚴(yán)重程度；

5. 用例轉(zhuǎn)Bug，Bug標(biāo)題必須重新修改；

6. 發(fā)現(xiàn)Bug，此Bug沒有對應(yīng)的用例，需先添加用例，再轉(zhuǎn)Bug；

7. Bug有屬主。誰提的Bug，需每天跟進直到Bug解決。若有新任務(wù)在身，也要保持跟進所提Bug，或交接他人跟進；

8. 建議開發(fā)人員在禪道提交Bug的解決方案時，在備注欄填寫此Bug的類型，便于后期的缺陷分析，及為提高開發(fā)質(zhì)量提供參考數(shù)據(jù)。

9. 所有Bug關(guān)閉后。把運行失敗的用例運行一遍，直到全部運行成功。主要功能的用例，不管之前運行成功與否，也全運行一遍。

此流程規(guī)范根據(jù)工作實際情況制定，希望得到同行們的建議，提高效率。

一個人走起的測試，很多不確定性，亟需得到認證。