軟體測試回顧(3)
軟體測試回顧(3)
07章：如何高效寫缺陷報告?
提BUG是測試和開發溝通問題的路徑,怎麼寫好無歧義的bug,個人認為是非常重要的一件事
缺陷報告是測試工程師與開發工程師交流溝通的重要橋樑，也是測試工程師日常工作的重要輸出。作為優秀的測試工程師，最基本的一項技能就是，把發現的缺陷準確無歧義地表達清楚。
缺陷報告本身的品質將直接關係到缺陷被修復的速度以及開發工程師的效率，同時還會影響測試工程師的信用、測試與開發人員協作的有效性。
你必須牢牢記住的是，好的缺陷報告絕對不是大量資訊的堆疊，而是以高效的方式提供準確有用的資訊
提交bug前
遞交缺陷報告前,通常會去缺陷管理系統搜索一下是否已經有人遞交過類似的缺陷。
bug標題
缺陷標題通常是別人最先看到的部分，是對缺陷的概括性描述，通常採用「在什麼情況下發生了什麼問題」的模式。
- 對「什麼問題」的描述不僅要做到清晰簡潔，最關鍵是要足夠具體，切忌不能採用過於籠統的描述。
- 描述「什麼問題」的同時還必須清楚地表述發生問題時的上下文，也就是問題出現的場景。
- 標題應該儘可能描述問題本質，而避免只停留在問題的表面。
- 缺陷標題不易過長，對缺陷更詳細的描述應該放在「缺陷概述」里。
不要描述表面問題可太真實了，曾經的領導和我說過，提交bug，直接告訴開發修哪裡，這才叫爽。 還有在提交一個bug前，我建議可以思考下，假如一個不知道這個情況的人，能不能讀懂你的資訊，
bug概述
缺陷概述通常會提供更多概括性的缺陷本質與現象的描述，用清晰簡短的語句將問題的本質描述清楚是關鍵。清晰簡潔地描述缺陷，使開發工程師能夠聚焦缺陷的本質
bug影響
缺陷影響決定了缺陷的優先順序（Priority）和嚴重程度（Severity）
測試工程師準確描述缺陷影響的前提是，必須對軟體的應用場景以及需求有深入的理解，這也是對測試工程師業務基本功的考驗。
嚴重程度是缺陷本身的屬性，通常確定後就不再變化，而優先順序是缺陷的工程屬性，會隨著項目進度、解決缺陷的成本等因素而變動。
- 缺陷越嚴重，優先順序就越高；
- 缺陷影響的範圍越大，優先順序也會越高；
- 有些缺陷雖然從用戶影響角度來說不算嚴重，但是會妨礙測試或者是自動化測試的執行，這類缺陷屬於典型的嚴重程度低，但是優先順序高；
- 有些缺陷雖然嚴重程度比較高，但是考慮到修復成本以及技術難度，也會出現優先順序較低的情況。
確實，不深入了解業務的測試，往往就定位錯bug的優先順序。
環境配置
環境配置用以詳細描述測試環境的配置細節，為缺陷的重現提供必要的環境資訊。
環境配置的內容通常是按需描述，也就是說通常只描述那些重現缺陷的環境敏感資訊。
之前遇到過一個公司，無論什麼bug，都需要填寫很詳細的環境配置，這就導致很簡單的ui問題也要提一個很長的bug單
前置條件
前置條件是指測試步驟開始前系統應該處在的狀態，其目的是減少缺陷重現步驟的描述。合理地使用前置條件可以在描述缺陷重現步驟時排除不必要的干擾，使其更有針對性
重現步驟
缺陷重現步驟是整個缺陷報告中最核心的內容，其目的在於用簡潔的語言向開發工程師展示缺陷重現的具體操作步驟。
操作步驟通常是從用戶角度出發來描述的，每個步驟都應該是可操作並且是連貫的，所以往往會採用步驟列表的表現形式。
需要注意的點：
- 確保缺陷的可重現性；
- 找到最短的重現路徑，過濾掉那些非必要的步驟
這就意味著不斷的重現bug，可能一開始浪費了一定時間，後期熟練可能就不會操作過多的遍數
對於缺陷重現步驟的描述應該盡量避免以下3個常見問題：
- 籠統的描述，缺乏可操作的具體步驟。
- 出現與缺陷重現不相關的步驟。
- 缺乏對測試數據的相關描述。
當你描述期望結果時，需要說明應該發生什麼，而不是什麼不應該發生；而描述實際結果時，你應該說明發生了什麼，而不是什麼沒有發生。
就按照寫測試用例的方式來寫重現步驟，要每一步都可以執行
變通方案
臨時繞開當前缺陷而不影響產品功能的方式，通常由測試工程師或者開發工程師完成，或者他們一同決定。
根因分析
如果你能在發現缺陷的同時，定位出問題的根本原因，清楚地描述缺陷產生的原因並回饋給開發工程師，那麼開發工程師修復缺陷的效率就會大幅提升，而且你的技術影響力也會被開發認可。
但大多數情況下，測試沒辦法接觸到業務程式碼，或者沒有能力去追bug，最多測試能追到的bug，開發一眼就看出來了。
個人覺得根本原因就是：測試不能深入業務程式碼，別說深入業務程式碼了，大多數甚至連設計方案，實現邏輯都不知道
附件
對於那些很難用文字描述清楚的GUI介面布局的缺陷，你可以採用截圖並高亮顯示應該關注的區域的方式去提交缺陷報告。
最難受的莫過於，你辛辛苦苦寫完復現步驟，開發不看，直接叫你復現。
08章：制定測試計劃
對於很多非產品型的互聯網公司，由於採用了敏捷開發模式，的確很少去制定傳統意義上的測試計划了，但這並不是說它們就不再制定測試計划了。
只不過是，測試計劃的表現形式已經不再是傳統意義上龐大的、正式的測試計劃文檔了，而更多的是體現在每個迭代（sprint）的計劃環節，而且這樣的短期測試計劃可以非常迅速地根據項目情況實時調整。
測試計劃依舊存在，只是從原來的一次性集中制定測試計劃，變成了以迭代的方式持續制定測試計劃
一份好的測試計劃要包括：測試範圍、測試策略、測試資源、測試進度和測試風險預估，這五大方面，並且每一部分都要給出應對可能出現問題的解決辦法。
1.測試範圍
測試範圍中需要明確「測什麼」和「不測什麼」。
2.測試策略
測試策略簡單來講就是需要明確「先測什麼後測什麼」和「如何來測」這兩個問題。
測試策略還需要說明，採用什麼樣的測試類型和測試方法
1.功能測試
對於功能測試，應該根據測試需求分析的思維導圖來設計測試用例。
通常應該先實現主幹業務流程的測試自動化
通常需要先列出主要的功能測試點，並決定哪些測試點適合採用自動化測試，並且決定具體使用什麼樣的框架和技術。
對於需要手工測試的測試點，你要決定採用什麼類型的測試用例設計方法，以及如何準備相關的測試數據。
測試策略主要是把優先順序搞出來，再把自動化和手工挑出來，在對手工測試點進行設計用例(一般會讓細化測試點)
2.兼容性測試
兼容性測試的實施，往往是在功能測試的後期，也就是說需要等功能基本都穩定了，才會開始兼容性測試。
兼容性測試用例的選取，往往來自於已經實現的自動化測試用例。道理很簡單，因為兼容性測試往往要覆蓋最常用的業務場景，而這些最常用的業務場景通常也是首批實現自動化測試的目標。
兼容最後做的結果就是：測試說 不支援某個環境，開發說要更改成本太大了，發布日期又迫在眉睫，項目經理就會說：那就不支援了吧(哈哈哈哈)
所以要在最後做兼容性測試，就一定要把必須支援的功能前期驗證出來
3.性能測試
需要在明確了性能需求（並發用戶數、響應時間、事務吞吐量等）的前提下，設計性能測試場景並確定性能測試框架。
首先，需要根據你想要解決的問題，確定性能測試的類型；然後，根據具體的性能測試類型開展測試。
3.測試資源
測試資源就是需要明確「誰來測」和「在哪裡測」這兩個問題。
- 測試人員的資源通常有兩個維度：一是，測試工程師的數量；二是，測試工程師的個人經驗和能力。
- 測試工程師的經驗和能力不足，很難通過測試人員的數量來彌補。
- 把具體的任務清晰地落實到每個人的身上，這將有利於建立清晰的責任機制，避免後續可能發生的扯皮
測試資源我覺得最重要的是對環境和數據的準備，老師在文章說測試環境可以使用docker進行復用，可是有些公司是不允許和生產環境不一致上測試的，否則會視為無效測試，再加上整體的伺服器資源少，在搭建一套主備機、集群下來，每個人分到的就又很少了。其次是測試數據，測試數據大家不共享，都在各搞各的，每個人都是資訊孤島，導致效率及其低下，我還沒見過標準的共享測試數據的公司(大哭)
4.測試進度
測試進度主要描述各類測試的開始時間，所需工作量，預計完成時間，並以此為依據來建議最終產品的上線發布時間。
版本接受測試（Build Acceptance Test）的工作量，冒煙測試（Smoke Test）的工作量，自動化腳本開發的工作量，缺陷修復的驗證工作量，需要幾輪迴歸測試、每一輪迴歸測試的工作量等等。
還有測試進度受開發和測試經理的腦子影響比較大，開發品質差就會導致延期、加人手。測試經理腦子不好，就會造成「趕工」的情況，為了完成測試經理吹的nb。
5.測試風險評估
在制定測試計劃時，你就要預估整個測試過程中可能存在的潛在風險，以及當這些風險發生時的應對策略。
對於需求變更，比如增加需求、刪減需求、修改需求等，一定要重新進行測試需求分析，確定變更後的測試範圍和資源評估，並與項目經理和產品經理及時溝通因此引起的測試進度變化。測試經理/測試負責人切忌不能有自己咬牙扛過去的想法，否則無論是對測試團隊還是對產品本身都不會有任何好處。
隨著測試的開展，你可能會發現前期對於測試工作量的預估不夠準確，也可能發現需要增加更多的測試類型，也可能發現因為要修改測試架構的嚴重缺陷而導致很多的測試需要全回歸，還有可能出現開發遞交測試版本延期，或者人員變動等各種情況。
這塊太真實了，出現變動(需求變動、技術方案調整)如果不進行風險評估並且上報，就想著自己扛下來，那就是在作死(變更的風險本來由PM、開發承擔，結果由測試隱瞞不報，就變成自己的了)
