2023年從學校畢業到參加工作一年時間，一直在從事著軟體測試的工作，先後通過兩位測試同事的合作與學習，再加上這一年來大大小小的軟體測試經驗，總結了一些心得。
首先是測試流程，流程相對於工作不光是規範，同時也是在告訴我們每個階段需要做什麼。
然後是測試用例，主要是說明測試用例的必要性和編寫的方法。
第三是缺陷管理，包括了缺陷的生命週期以及錄入乙個缺陷生命週期需要哪些要素。
第四是測試報告，簡要說明測試報告應該包含的內容。
第五是其他測試。
一、測試流程
1）專案啟動時，專案經理根據專案的需求，向測試部門提出測試人員需求，應該包括以下內容：專案週期、專案目標以及完成標準；
2）測試部門在接到專案組的測試需求後，進行需求評審，需要給出相應的團隊資訊，團隊人員、分工；
3）測試主管需要寫測試計畫，對整個專案的開展進行排期，同時也包括了測試人員的分工和工作排期；
4）測試人員在接到工作任務安排的時，
4-1）首先要詳細閱讀需求文件和原型，分析需求時，可能會遇到需求文件描述的不清晰或者功能邏輯遺漏的情況，所以在寫測試用例之前，最好要有乙份測試分析文件，測試分析針對系統功能拆分進行粗略的書寫，在測試分析時就要找產品部門進行需求核對，把不符合邏輯的地方討論清楚；
4-2）測試分析完成後，參照已有的測試分析，就可以進行測試用例的書寫，測試用例和開發寫程式的時間是並行的，可能提早；
4-3）完成測試用例編寫後，測試部門內部需要對測試用例進行評審並修改；
5）在開發將war包提交給測試部門後，測試部門可以將已經準備好的測試環境搭建發版，首先收到開發人員的郵件說明（需@專案組），哪些頁面哪些功能可以進行測試，然後測試人員有正對性地對相應的功能進行一輪冒煙測試，檢視是否達到測試准入的規範，
5-1）不通過測試准入，鑑於沒有引入相應的獎懲措施，可以回覆開發的轉測郵件，說明問題影響測試工作；
6）執行測試用例過程中，進行日程bug管理、回歸測試；
7）測試通過，輸出測試報告；
8）專案上線，正式環境測試；
二、測試用例
1）簡述：用文字描述出系統測試時的操作步驟
2）好處：
2-1）清晰思路、避免遺漏
當系統功能多且複雜時，根據系統每個模組，拆分功能點，花點時間思考並整理成文件，盡可能結合功能與業務，模擬不同場景，從根本上避免了直接測試系統的「手忙腳亂」。
2-2）明確測試進展
參考測試用例，可以清晰看到哪些用例執行了，哪些用例沒有執行，從中看到測試進行到哪一步，以及結合問題管理平台，直觀地從測試角度，分析專案進展。
2-3）系統模組缺陷率
根據測試用例發現的問題，可以看到哪個功能模組出現的bug較多。
3）方法：
3-1）等價類劃分：輸入的子集中選擇，假如輸入要求輸入數字1到10，那麼輸入4和7去驗證；
3-2）邊界值：輸入支援的最大值，假如乙個文字輸入框最大值為100，輸入的內容超過101；
3-3）因果圖：判定表，通過因果關係判定；
3-4）錯誤推測法：基於測試經驗推測系統在什麼樣的操作可能會出現錯誤；
4）元素：
4-1）目錄
根據拆分的系統功能點，每個功能點可以用目錄的方式區分，如乙個系統的系統管理-使用者管理-使用者新增，那麼系統管理就是一級目錄，使用者管理就是二級目錄，使用者新增就是**目錄；
4-2）測試項
同上，根據**目錄，一般使用者新增包括的元素有使用者名稱、密碼輸入框、儲存按鈕、取消，那麼每個元素都可以分成乙個測試項；
4-3）操作步驟
每乙個測試項，都對應相應的操作步驟，可以分成操作步驟1、操作步驟2，操作步驟可以細化到，點選新增使用者的按鈕、輸入框輸入某某使用者名稱密碼點選儲存按鈕；
4-4）預期結果
操作步驟，在完成一系列動作之前，都要有對應預期結果作為參考，這個參考就是最初業務部門提供的需求分析文件，根據需求分析文件來告訴我們每乙個功能要有什麼樣的結果；
4-5）實際結果
操作步驟，完成之後，需要記錄實際的情況，如果與預期結果不符，就可以歸於bug；
考慮是否可以將實際結果改成注釋，避免與預期結果一一對應關係，解耦合。
4-6）優先順序
5）探索性測試
在設計測試用例時，並不能完全保證每個功能每個場景都設計到位，而且單純執行測試的時候非常枯燥，那麼加入一點發散性思維，進行一些非常規性操作，以使用者的心態去使用系統，或是盡情地「破壞」系統，發現系統的問題。
真正的探索性測試需要對產品的深入了解，以及軟體開發技術有一定的深度和寬度。
6）用例評審
測試用例編寫完成後，需要在測試內部進行一次評審，評審的內容包括：功能是否完整、需求是否符合，使每乙個測試人員在系統測試過程中，不存在主體思維的偏差。
同時用例評審也是乙個很好的學習過程，每一位測試人在介紹系統時，能夠意識到各自設計用例時的不足，包括自動化、效能都可以進行技術的**。
7）不需要用例情況：
7-1）功能過於簡單
7-2）急於交付，弊端就是不能保證測試的覆蓋率。
三、缺陷管理
1）缺陷生命週期：
1-1）提交bug、指派解決人員、確認問題、處理問題、回歸測試、關閉問題
1-2）確認問題時，如果開發未發現問題情況，需要測試進一步驗證，驗證完後再次提交；
1-3）回歸測試時，如果測試未通過，需要打回處理，相關措施可以參照准入流程郵件傳送；
2）缺陷要素
2-1）重現環境，需要註明作業系統、什麼瀏覽器及版本、還有在測試環境下哪個資料庫；
2-2）問題型別，redmine有系統異常、操作指導、新需求；
2-3）缺陷等級，等級可以由低——>中——>高——>緊急來劃分，高優先順序的任務必須要求開發人員優先處理；
2-4）缺陷狀態，有新建、處理中、已解決等；
2-5）操作步驟，描述發現問題時的操作場景；
2-6）預期結果，描述發現問題時的操作步驟，應該是什麼樣的結果；
2-7）測試結論，簡要說明問題情況以及結論；
2-8）截圖，tomcat的log日誌；
1）測試結論（測試是否通過/是否滿足發布要求/是否能夠發布）
2）羅列發現的主要問題（或者說該版本存在的主要風險）
4）測試內容（測試範圍）
5）測試用例執**況（一共多少，執行了多少，未執行多少，通過多少，失敗多少）
6）發現的嚴重缺陷有哪些（僅僅羅列最嚴重級別的bug）
7）郵件的附件是測試計畫執行結果檔案
五、使用者容忍度與易用性測試
很多時候，專案組對待軟體的質量會與使用者容忍度有一定的關係，像是交付性的軟體，只需要做完之後然後交付給使用者，甚至uat不需要測試部門內部進行，那麼這樣的情況下，我們更關心的應該是功能的實現。
舉個不恰當的栗子，當你很口渴的時候有個水壺，你需要乙個杯子，那麼你關心的只是這個杯子能不能裝水能不能喝，此時杯子需要的特性就是：能用、乾淨。
但是如果這個杯子被放在**的展櫃上時，那麼需要的特性就非常的多了，如下拆分：
1）功能測試。杯子是否能裝水，還能否裝下其他液體，杯子的容量如何，是否有刻度，能支援最大的熱量和最低的溫度是多少；
2）介面測試。杯子的外觀如何，顏色和形狀怎麼樣，重量如何，是否有異味；
3）效能測試。能否裝100°以上的水，泡茶泡麵，能否放在冷藏櫃裡冰凍，杯子盛水後長時間是否會漏水，是否會被壓碎；
4）安全性測試。杯子是否有毒，是否易碎，碎後時候會割手，易生細菌，會不會**或融化；
5）易用性測試。杯子形狀在手上好不好拿，導熱如何會不會燙手，是否防滑，形狀設計是否容易被喝到；
有時候不要為了測試去測試，為了體現自己的價值，非揪著某個問題不放，對專案進展沒有幫助性的工作。對此，我並不是說測試人員可以放棄自己的測試原則，只是說當前的環境並不支援或適合你去開展測試工作。
為貢獻產品的發展測試遠比為了測試了測試所帶來的價值大得多；所以站在產品的發展上去看待測試工作更能體現自己的價值。
一年工作總結
離職了。從我來深圳這邊的第一家公司離職。工作10個月多幾天。不抱怨在之前i的那家公司的不努力了，不抱怨之前跟cto許諾 不介意再待一年 了。一切都跟我沒關係了。此時只想逃離這個公司。都說創業公司累啊，我深刻體會到了。苦啊，我也體會到了。可是累的不值，總感覺自己在搬磚，累，是因為現有系統已完成差不多，...
我的一年工作總結
demo，背背 人最起碼要有貨。2.業務方面。由於是給自己公司做軟體，沒有需求說明書之類的文件，需求常常一改在改，全憑領導說了算，很是頭疼，很多東西靠想象。3.處事方面 在為人處事方面，我很感謝hh對我的幫助，我是乙個不善於言談的人，會做不會說。以後一定要改變。來了公司，讓我學會了不少的東西。在我的...
10年軟體測試工作總結
讀完文章感覺醍醐灌頂，目前我做測試已經進入了乙個瓶頸期，之前比較懶，疏於學習，現在必須要突破自己，更上一層樓，2017，加油 原文如下 時光荏苒，從畢業到現在已經10年，10年來一直從事著軟體測試的工作。從乙個什麼都不會，到測試技術人員再到測試管理，期間有迷茫，有痛苦，有彎路，有捷徑。今天對自己過去...