首先測試用例設計階段衣陶，設計并維護一個各個功能入口的說明文檔柄瑰。其實這個文檔的作用很大，一方面對于bug回歸階段的人來說剪况，這是用于提醒的;另外一個方面教沾，在隨機測試的時候，隨機程度也能有所提高译断，測試人員能夠自己隨意組合可能的路徑授翻。當然，一樣一份文檔也能提升文檔設計人員孙咪，文檔閱讀人員對于模塊的整體認識
在Bug提交階段堪唐，評估阻塞用例說明。在項目初期翎蹈，尤其是版本剛提交的時候淮菠，往往會出現(xiàn)功能無法使用或者沒有實現(xiàn)的問題，這時候我們提交bug并不僅僅是說明預期沒有實現(xiàn)荤堪，更重要的是我們?nèi)绾蝹渫@件事情合陵，如何保證沒有實現(xiàn)的功能在最終版中實現(xiàn)，那么在提交bug的時候澄阳，我們需要注明拥知，哪些case被阻塞，該功能沒有驗證會影響到哪些其他模塊和功能的驗證等
Bug提交階段碎赢，在bug描述中備注回歸時的路徑說明低剔。測試工程師提交bug時是在當時的環(huán)境下的，也就是說對測試目錄肮塞，前后操作及路徑都非常清楚襟齿，對于其他可能的入口或者操作，測試工程師是知道的峦嗤，因而在提交bug的時候蕊唐，測試工程師除了提交出現(xiàn)bug的操作步驟之外，如果能補充一下其他可能的路徑說明烁设，一方面開發(fā)在修復bug的時候可以作為參考替梨，另外一方面測試工程師在bug回歸的時候也能夠進行更全面高效的回歸
接著，在Bug提交完畢装黑，對非用例內(nèi)影響因素或路徑更新到測試用例或者進行備忘副瀑。測試影響因素包括各個方面，因為測試工程師的經(jīng)驗恋谭，知識儲備等各方面原因糠睡，測試設計往往會有一定的遺漏，這是不可避免的疚颊，在測試過程中我們往往會突然想到某個影響因素或者測試路徑狈孔，這時候我們往往會去執(zhí)行一下是否有問題信认，如果有問題，則會有bug提交均抽，如果沒有bug呢?往往我們會去繼續(xù)去執(zhí)行下一條case去了嫁赏。實際上這種情況是對測試工程師腦力的一種浪費，不利于測試工程師經(jīng)驗的積累油挥。
最后在自動化測試回歸時潦蝇，盡可能與開發(fā)溝通bug原因及修改方案。這個在實際操作時是有困難的深寥，因為哪些bug需要與開發(fā)溝通攘乒，開發(fā)是否有時間等都是影響因素，當然有人會提出由開發(fā)在處理bug時提交修改說明惋鹅，這當然是最好的方式则酝，但是與國內(nèi)實際環(huán)境是不符的，因而我們是盡可能的與開發(fā)了解bug原因及修改方案负饲，然后在bug跟蹤系統(tǒng)中或者其他什么方式進行一個簡明的說明堤魁，例如是初始化數(shù)據(jù)錯誤這樣的原因喂链，那么在后期我們進行bug分析時返十，就能從一個統(tǒng)計意義上的數(shù)據(jù)來對測試的測試設計及執(zhí)行進行一個指導
