• 軟體測驗回顧(3)
  • 07章：如何高效寫缺陷報告?
    • 提交bug前
    • bug標題
    • bug概述
    • bug影響
    • 環境配置
    • 前置條件
    • 重現步驟
    • 變通方案
    • 根因分析
    • 附件
  • 08章：制定測驗計劃
    • 1.測驗范圍
    • 2.測驗策略
      • 1.功能測驗
      • 2.兼容性測驗
      • 3.性能測驗
    • 3.測驗資源
    • 4.測驗進度
    • 5.測驗風險評估

軟體測驗回顧(3)

07章：如何高效寫缺陷報告?

提BUG是測驗和開發溝通問題的路徑,怎么寫好無歧義的bug,個人認為是非常重要的一件事

缺陷報告是測驗工程師與開發工程師交流溝通的重要橋梁，也是測驗工程師日常作業的重要輸出，作為優秀的測驗工程師，最基本的一項技能就是，把發現的缺陷準確無歧義地表達清楚，

缺陷報告本身的質量將直接關系到缺陷被修復的速度以及開發工程師的效率，同時還會影響測驗工程師的信用、測驗與開發人員協作的有效性，

你必須牢牢記住的是，好的缺陷報告絕對不是大量資訊的堆疊，而是以高效的方式提供準確有用的資訊

提交bug前

遞交缺陷報告前,通常會去缺陷管理系統搜索一下是否已經有人遞交過類似的缺陷，

bug標題

缺陷標題通常是別人最先看到的部分，是對缺陷的概括性描述，通常采用“在什么情況下發生了什么問題”的模式，

• 對“什么問題”的描述不僅要做到清晰簡潔，最關鍵是要足夠具體，切忌不能采用過于籠統的描述，
• 描述“什么問題”的同時還必須清楚地表述發生問題時的背景關系，也就是問題出現的場景，
• 標題應該盡可能描述問題本質，而避免只停留在問題的表面，
• 缺陷標題不易過長，對缺陷更詳細的描述應該放在“缺陷概述”里，

不要描述表面問題可太真實了，曾經的領導和我說過，提交bug，直接告訴開發修哪里，這才叫爽， 還有在提交一個bug前，我建議可以思考下，假如一個不知道這個情況的人，能不能讀懂你的資訊，

bug概述

缺陷概述通常會提供更多概括性的缺陷本質與現象的描述，用清晰簡短的陳述句將問題的本質描述清楚是關鍵，清晰簡潔地描述缺陷，使開發工程師能夠聚焦缺陷的本質

bug影響

缺陷影響決定了缺陷的優先級（Priority）和嚴重程度（Severity）

測驗工程師準確描述缺陷影響的前提是，必須對軟體的應用場景以及需求有深入的理解，這也是對測驗工程師業務基本功的考驗，

嚴重程度是缺陷本身的屬性，通常確定后就不再變化，而優先級是缺陷的工程屬性，會隨著專案進度、解決缺陷的成本等因素而變動，

1. 缺陷越嚴重，優先級就越高；
2. 缺陷影響的范圍越大，優先級也會越高；
3. 有些缺陷雖然從用戶影響角度來說不算嚴重，但是會妨礙測驗或者是自動化測驗的執行，這類缺陷屬于典型的嚴重程度低，但是優先級高；
4. 有些缺陷雖然嚴重程度比較高，但是考慮到修復成本以及技術難度，也會出現優先級較低的情況，

確實，不深入了解業務的測驗，往往就定位錯bug的優先級，

環境配置

環境配置用以詳細描述測驗環境的配置細節，為缺陷的重現提供必要的環境資訊，

環境配置的內容通常是按需描述，也就是說通常只描述那些重現缺陷的環境敏感資訊，

之前遇到過一個公司，無論什么bug，都需要填寫很詳細的環境配置，這就導致很簡單的ui問題也要提一個很長的bug單

前置條件

前置條件是指測驗步驟開始前系統應該處在的狀態，其目的是減少缺陷重現步驟的描述，合理地使用前置條件可以在描述缺陷重現步驟時排除不必要的干擾，使其更有針對性

重現步驟

缺陷重現步驟是整個缺陷報告中最核心的內容，其目的在于用簡潔的語言向開發工程師展示缺陷重現的具體操作步驟，

操作步驟通常是從用戶角度出發來描述的，每個步驟都應該是可操作并且是連貫的，所以往往會采用步驟串列的表現形式，

需要注意的點：

1. 確保缺陷的可重現性；
2. 找到最短的重現路徑，過濾掉那些非必要的步驟

這就意味著不斷的重現bug，可能一開始浪費了一定時間，后期熟練可能就不會操作過多的遍數

對于缺陷重現步驟的描述應該盡量避免以下3個常見問題：

1. 籠統的描述，缺乏可操作的具體步驟，
2. 出現與缺陷重現不相關的步驟，
3. 缺乏對測驗資料的相關描述，

當你描述期望結果時，需要說明應該發生什么，而不是什么不應該發生；而描述實際結果時，你應該說明發生了什么，而不是什么沒有發生，

就按照寫測驗用例的方式來寫重現步驟，要每一步都可以執行

變通方案

臨時繞開當前缺陷而不影響產品功能的方式，通常由測驗工程師或者開發工程師完成，或者他們一同決定，

根因分析

如果你能在發現缺陷的同時，定位出問題的根本原因，清楚地描述缺陷產生的原因并反饋給開發工程師，那么開發工程師修復缺陷的效率就會大幅提升，而且你的技術影響力也會被開發認可，

但大多數情況下，測驗沒辦法接觸到業務代碼，或者沒有能力去追bug，最多測驗能追到的bug，開發一眼就看出來了，

個人覺得根本原因就是：測驗不能深入業務代碼，別說深入業務代碼了，大多數甚至連設計方案，實作邏輯都不知道

附件

對于那些很難用文字描述清楚的GUI界面布局的缺陷，你可以采用截圖并高亮顯示應該關注的區域的方式去提交缺陷報告，

最難受的莫過于，你辛辛苦苦寫完復現步驟，開發不看，直接叫你復現，

08章：制定測驗計劃

對于很多非產品型的互聯網公司，由于采用了敏捷開發模式，的確很少去制定傳統意義上的測驗計劃了，但這并不是說它們就不再制定測驗計劃了，

只不過是，測驗計劃的表現形式已經不再是傳統意義上龐大的、正式的測驗計劃檔案了，而更多的是體現在每個迭代（sprint）的計劃環節，而且這樣的短期測驗計劃可以非常迅速地根據專案情況實時調整，

測驗計劃依舊存在，只是從原來的一次性集中制定測驗計劃，變成了以迭代的方式持續制定測驗計劃

一份好的測驗計劃要包括：測驗范圍、測驗策略、測驗資源、測驗進度和測驗風險預估，這五大方面，并且每一部分都要給出應對可能出現問題的解決辦法，

1.測驗范圍

測驗范圍中需要明確“測什么”和“不測什么”，

2.測驗策略

測驗策略簡單來講就是需要明確“先測什么后測什么”和“如何來測”這兩個問題，

測驗策略還需要說明，采用什么樣的測驗型別和測驗方法

1.功能測驗

對于功能測驗，應該根據測驗需求分析的思維導圖來設計測驗用例，

通常應該先實作主干業務流程的測驗自動化

通常需要先列出主要的功能測驗點，并決定哪些測驗點適合采用自動化測驗，并且決定具體使用什么樣的框架和技術，

對于需要手工測驗的測驗點，你要決定采用什么型別的測驗用例設計方法，以及如何準備相關的測驗資料，

測驗策略主要是把優先級搞出來，再把自動化和手工挑出來，在對手工測驗點進行設計用例(一般會讓細化測驗點)

2.兼容性測驗

兼容性測驗的實施，往往是在功能測驗的后期，也就是說需要等功能基本都穩定了，才會開始兼容性測驗，

兼容性測驗用例的選取，往往來自于已經實作的自動化測驗用例，道理很簡單，因為兼容性測驗往往要覆寫最常用的業務場景，而這些最常用的業務場景通常也是首批實作自動化測驗的目標，

兼容最后做的結果就是：測驗說 不支持某個環境，開發說要更改成本太大了，發布日期又迫在眉睫，專案經理就會說：那就不支持了吧(哈哈哈哈)

所以要在最后做兼容性測驗，就一定要把必須支持的功能前期驗證出來

3.性能測驗

需要在明確了性能需求（并發用戶數、回應時間、事務吞吐量等）的前提下，設計性能測驗場景并確定性能測驗框架，

首先，需要根據你想要解決的問題，確定性能測驗的型別；然后，根據具體的性能測驗型別開展測驗，

3.測驗資源

測驗資源就是需要明確“誰來測”和“在哪里測”這兩個問題，

• 測驗人員的資源通常有兩個維度：一是，測驗工程師的數量；二是，測驗工程師的個人經驗和能力，
• 測驗工程師的經驗和能力不足，很難通過測驗人員的數量來彌補，
• 把具體的任務清晰地落實到每個人的身上，這將有利于建立清晰的責任機制，避免后續可能發生的扯皮

測驗資源我覺得最重要的是對環境和資料的準備，老師在文章說測驗環境可以使用docker進行復用，可是有些公司是不允許和生產環境不一致上測驗的，否則會視為無效測驗，再加上整體的服務器資源少，在搭建一套主備機、集群下來，每個人分到的就又很少了，其次是測驗資料，測驗資料大家不共享，都在各搞各的，每個人都是資訊孤島，導致效率及其低下，我還沒見過標準的共享測驗資料的公司(大哭)

4.測驗進度

測驗進度主要描述各類測驗的開始時間，所需作業量，預計完成時間，并以此為依據來建議最終產品的上線發布時間，

版本接受測驗（Build Acceptance Test）的作業量，冒煙測驗（Smoke Test）的作業量，自動化腳本開發的作業量，缺陷修復的驗證作業量，需要幾輪回歸測驗、每一輪回歸測驗的作業量等等，

還有測驗進度受開發和測驗經理的腦子影響比較大，開發質量差就會導致延期、加人手，測驗經理腦子不好，就會造成“趕工”的情況，為了完成測驗經理吹的nb，

5.測驗風險評估

在制定測驗計劃時，你就要預估整個測驗程序中可能存在的潛在風險，以及當這些風險發生時的應對策略，

對于需求變更，比如增加需求、刪減需求、修改需求等，一定要重新進行測驗需求分析，確定變更后的測驗范圍和資源評估，并與專案經理和產品經理及時溝通因此引起的測驗進度變化，測驗經理/測驗負責人切忌不能有自己咬牙扛過去的想法，否則無論是對測驗團隊還是對產品本身都不會有任何好處，

隨著測驗的開展，你可能會發現前期對于測驗作業量的預估不夠準確，也可能發現需要增加更多的測驗型別，也可能發現因為要修改測驗架構的嚴重缺陷而導致很多的測驗需要全回歸，還有可能出現開發遞交測驗版本延期，或者人員變動等各種情況，

這塊太真實了，出現變動(需求變動、技術方案調整)如果不進行風險評估并且上報，就想著自己扛下來，那就是在作死(變更的風險本來由PM、開發承擔，結果由測驗隱瞞不報，就變成自己的了)

標籤：其他

上一篇：萌新求助！！spark mlli訓練好的模型無法加載

下一篇：軟體測驗回顧(4)