2017年從學校畢業到參加工作一年時間，一直在從事着軟件測試的工作，先后通過兩位測試同事的合作與學習，再加上這一年來大大小小的軟件測試經驗，總結了一些心得。
首先是測試流程，流程相對於工作不光是規范，同時也是在告訴我們每個階段需要做什么。
然后是測試用例，主要是說明測試用例的必要性和編寫的方法。
第三是缺陷管理，包括了缺陷的生命周期以及錄入一個缺陷生命周期需要哪些要素。
第四是測試報告，簡要說明測試報告應該包含的內容。
第五是其他測試。
一、測試流程
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日志；
四、測試報告（第四點copy百度百科）
1）測試結論（測試是否通過/是否滿足發布要求/是否能夠發布）
2）羅列發現的主要問題（或者說該版本存在的主要風險）
3）測試版本（客戶端，服務器）（如果允許發布，附件發布包或其鏈接，包大小，以及md5校驗碼）
4）測試內容（測試范圍）
5）測試用例執行情況（一共多少，執行了多少，未執行多少，通過多少，失敗多少）
6）發現的嚴重缺陷有哪些（僅僅羅列最嚴重級別的bug）
7）郵件的附件是測試計划執行結果文件
五、用戶容忍度與易用性測試
很多時候，項目組對待軟件的質量會與用戶容忍度有一定的關系，像是交付性的軟件，只需要做完之后然后交付給用戶，甚至UAT不需要測試部門內部進行，那么這樣的情況下，我們更關心的應該是功能的實現。
舉個不恰當的栗子，當你很口渴的時候有個水壺，你需要一個杯子，那么你關心的只是這個杯子能不能裝水能不能喝，此時杯子需要的特性就是：能用、干凈。
但是如果這個杯子被放在商城的展櫃上時，那么需要的特性就非常的多了，如下拆分：
1）功能測試。杯子是否能裝水，還能否裝下其他液體，杯子的容量如何，是否有刻度，能支持最大的熱量和最低的溫度是多少；
2）界面測試。杯子的外觀如何，顏色和形狀怎么樣，重量如何，是否有異味；
3）性能測試。能否裝100°以上的水，泡茶泡面，能否放在冷藏櫃里冰凍，杯子盛水后長時間是否會漏水，是否會被壓碎；
4）安全性測試。杯子是否有毒，是否易碎，碎后時候會割手，易生細菌，會不會爆炸或融化；
5）易用性測試。杯子形狀在手上好不好拿，導熱如何會不會燙手，是否防滑，形狀設計是否容易被喝到；
有時候不要為了測試去測試，為了體現自己的價值，非揪着某個問題不放，對項目進展沒有幫助性的工作。對此，我並不是說測試人員可以放棄自己的測試原則，只是說當前的環境並不支持或適合你去開展測試工作。
為貢獻產品的發展測試遠比為了測試了測試所帶來的價值大得多；所以站在產品的發展上去看待測試工作更能體現自己的價值。