前言

在我們?nèi)粘５臏y試過程中，經(jīng)常會遇到這樣的問題：測試前，我們的計劃是A，每當開始實施后，總會遇到諸多問題，使得項目進行的非常艱難。因此在一輪項目測試完成后，質(zhì)量回溯變得尤為重要。

計劃和現(xiàn)實.jpeg

測試中的問題

1. 測試過程中需求是否頻繁變更？
2. 需求未收斂，不斷引入新需求？
3. 提測質(zhì)量較差，冒煙不通過？
4. 修改一個bug引發(fā)多個bug？
5. 回歸過程中發(fā)現(xiàn)之前測試通過的功能又出bug了
6. ...

流程規(guī)范

百度百科上定義規(guī)范是指群體所確立的行為標準。若想要提升團隊的合作能力，必要的規(guī)范是不可少的。從上面例舉的測試中的遇到的問題來逐一分析。

1. 測試過程中需求頻繁變更。
   這里的需求變更分兩種情況：

   • 每個項目在進行過程中，都會發(fā)現(xiàn)一些需求設(shè)計不合理的地方，但此時已經(jīng)進入了開發(fā)階段，如果這個時間點再要求開發(fā)修改代碼，甚至在提測后修改需求，會大大增加項目的風險，拖慢項目的進度。
     解決方法：在需求評審階段，提升項目組成員的參與度，在需求或者交互評審階段，就需要仔細分析需求，找出設(shè)計的漏洞。
     舉個栗子：

     
     
     需求變更.png
     
     

     以上是我測試的一個項目的需求改動，原因是賬單類型有技術(shù)和人力兩種，但是兩種類型所包含的字段其實是不同的，因此改動會影響到多個頁面的邏輯實現(xiàn)。這樣就增加了開發(fā)和QA的工作量，拖慢了項目的進度。但實際上這些問題都是可以在評審階段規(guī)避的。

   • 開發(fā)過程中交互或產(chǎn)品進行變更需求，導(dǎo)致測試時間緊張，甚至延長項目的交付時間。
     解決方法：在項目開始前，項目組內(nèi)部就要達成一致，只有新需求為緊急需求時，才允許加入。并且需要重新評估開發(fā)和測試的工作量。如果會造成項目的延期，就要將目前優(yōu)先級較低的任務(wù)延后，延期至下個版本開展

2. 需求未收斂，不斷引入新需求
   在開發(fā)過程中，還會遇到業(yè)務(wù)方增加需求的情況。
   解決方法：這個就需要我們的PM同學把關(guān)，在項目開發(fā)之前，就需要確定本次開發(fā)版本的需求內(nèi)容，并在交互設(shè)計文檔完成后，將手頭的交互設(shè)計文檔與業(yè)務(wù)方進行逐條確認，只有確認通過后，再進入項目開發(fā)階段，并不再接受新的需求。在進入測試階段前，需要PM和UI進行走查，走查通過后再進行提測，這樣能夠有效地提升提測的質(zhì)量。

3. 提測質(zhì)量較差，冒煙不通過？
   我們在測試過程中常常遇到提測后冒煙不通過的情況。就會出現(xiàn)以下的對話：
   QA：這個用例沒有通過，我點擊按鈕后沒有跳轉(zhuǎn)，這是為什么？
   開發(fā)：不可能，當時我測的時候是好的，你復(fù)現(xiàn)給我看一下。
   QA：這里切換tab為什么沒有提示？
   開發(fā)：這里需求改了呀，我和交互說了不實現(xiàn)了。
   解決方法：

   • 首先QA要在測試前詳細閱讀需求文檔，并時刻關(guān)注交互稿的變動。但有時候業(yè)務(wù)繁重時，常常會出現(xiàn)需求改動沒有跟進到的情況。這就需要QA和項目成員協(xié)商好，任何開發(fā)提出或交互提出的變動，必須及時通知到項目所有成員。（可以在每日的站會、或者在項目開發(fā)群中進行及時的同步）；
   • QA用例寫完后，一定要組織用例評審，邀請交互、開發(fā)對用例逐條分析，在此過程中，不僅可以幫助開發(fā)同學再確認一次需求實現(xiàn)的可能性，還能收集開發(fā)童鞋的意見，對我們的用例進行一次補充。
   • 建立規(guī)范，要求開發(fā)的冒煙環(huán)境必須和提測環(huán)境保持一致，且要求冒煙通過率必須保證達到100%，如果沒有達到直接打回。

4. 修改一個bug引發(fā)多個bug？
   經(jīng)常有開發(fā)在修bug的過程中，觸發(fā)多個bug。
   解決方法：QA必須和開發(fā)達成共識，建立有效的規(guī)范：開發(fā)必須對自己的代碼負責，在修復(fù)bug后，需要在測試環(huán)境對bug以及其影響到的功能點進行自測后，再將bug標記為已解決狀態(tài)，如果QA測試后，發(fā)現(xiàn)bug未修復(fù)或者觸發(fā)了其他bug，則需提高jira的優(yōu)先級；

5. 回歸過程中發(fā)現(xiàn)之前測試通過的功能又出bug了
   這種情況通常是開發(fā)在測試不知情的情況下，對代碼進行了改動。
   解決方法：引入代碼變更覆蓋率，并建立完善的自動化用例回歸集。這樣能夠幫助QA及時地跟進代碼變更情況，保證項目的質(zhì)量。

綜上分析，我們需要建立的規(guī)范重點主要包含以下幾個方面：

1. 需求必須收斂，開發(fā)階段后不接受新的需求（緊急情況除外）；
2. 交互稿出來后一定要和業(yè)務(wù)方以及開發(fā)（important!）進行逐條確認；
3. 測試計劃和測試用例需要組織評審，其中測試用例需要在tc上簡歷完備的用例集，并及時進行更新；
4. 建立冒煙規(guī)范，要求開發(fā)自測環(huán)境和提測環(huán)境保持一致，達到100%才可提測，否則一律打回，并且記錄到測試質(zhì)量報告中。
5. QA需要提升能力，引入更多的測試手段，并在質(zhì)量報告中進行記錄，在項目組中進行同步，提升項目質(zhì)量的信心。

總結(jié)

測試過程中多多少少都會遇到一些問題，作為QA最重要的是能夠在問題拋出后思考對應(yīng)的解決方案，在下次的測試過程中，盡量地規(guī)避。當然不同的項目遇到的問題也不盡相同，還需要繼續(xù)探索！