今晚在本人創建的測試群里，邀請了一位行業大佬做了一期關於軟件測試工程師工作成長的很多“套路”的經驗分享，受用良多。。。
會分為三篇博客進行描述，這篇博客，將基礎篇做一個整理，分享出來。。。
作為一個軟件測試工程師，在面試過程中，如何表達自己的核心競爭力？如何體現自己的專業性？這是個值得思考的問題。。。
1、缺陷的生命周期
總結：是否可以准確清晰的描述缺陷的生命周期，以及每個流轉過程中你應該做什么？怎么做？（敲黑板，思考！！！）
2、對缺陷錯誤狀態的定義
新建(New)：測試中新報告的軟件缺陷；
打開 (Open)：被確認並分配給相關開發人員處理；
修正(Fixed)：開發人員已完成修正，等待測試人員驗證；
拒絕(Declined):拒絕修改缺陷；
延期(Deferred): 不在當前版本修復的錯誤，下一版修復；
關閉(Closed)：錯誤已被修復；
總結：軟件測試工程師的職責是主動發現暴露軟件存在的缺陷，並輔助開發工程師一起確保缺陷被修復，提高交付軟件質量和交付速率的崗位，每個不同的軟件缺陷狀態，作為一個測試工程師，你應該做什么？
3、人員角色的不同權限
new—tester：測試工程師
declined-not bug--Test Supervisor：測試主管/測試工程師
declined-duplicated--Test Supervisor：測試主管/測試工程師
open--Project Manager/Technical Manager：測試工程師/項目經理/技術主管
fixed—programer：開發工程師
closed—tester：測試工程師
deferred-next build--Test Supervisor：測試主管/測試工程師
deferred-next main release--Test Supervisor：測試主管/測試工程師
總結：應該明確在一個項目或者一個部門里，你的權限職責，不同同事的權限職責，以及遇到問題需要協商溝通，應該找誰，怎么解決！
4、缺陷管理流程要點
為了保證錯誤的正確性，需要有豐富測試經驗的測試人員驗證發現的錯誤是否是真正的錯誤，書寫的測試步驟是否准確，可以重復；
每次對錯誤的處理都要保留處理信息，包括處理姓名，時間，處理方法，處理意見，Bug狀態；
拒絕或延期錯誤不能由程序員單方面決定，應該由項目經理，測試經理和產品經理共同決定；
錯誤修復后必須由報告錯誤的測試人員驗證后，確認已經修復，才能關閉錯誤；
加強測試人員與程序員的交流，對於某些不能重復的錯誤，可以請測試人員補充詳細的測試步驟和方法，以及必要的測試用例；
總結：上述幾點，其實主要思想還是圍繞第一部分--在缺陷的整個生命狀態流轉中，應該如何管理，什么狀態需要什么對應的管理方法，靈活應用！
5、用例設計規范
新建測試用例時要求選擇對應的產品模塊、用例類型、適用階段和相關需求，用例類型一般選擇功能測試，適用階段一般選擇系統測試；
用例標題要求描述對象功能明確，並盡量做到簡潔；
根據需要填寫適當的前置條件，要求在業務流程上前置條件之后可以銜接第一步操作；
操作步驟要表述清楚具體步驟和檢查點及其所在的位置，UI元素和控件需要標識清楚；
預期結果需要明確，原則上不應有無預期結果的操作步驟；
總結：談到用例設計，有最基本的“八要素”，以及設計用例的2個思路（按模塊還是按業務流），對業務依賴、異常如何思考處理？如何提高覆蓋率？這些都可以從設計用例的規范里面思考找到答案！
6、缺陷提交規范
提交缺陷時要求選擇對應的產品模塊、所屬項目、影響版本、優先級、嚴重程度和相關需求；
缺陷標題要求能夠確切地描述缺陷，包括缺陷出現的位置和表現，要注意避免冗長；
重現步驟中必須包括步驟，結果和期望，情況允許的話需要提供測試數據供開發人員迅速重現問題（日志截圖，報錯方法）；另外，比較復雜的UI要求截圖；
總結：提交缺陷，必須記住四要素：when、how、what、why！
即表達一個問題必須滿足的四個條件：什么時間執行了什么操作，發生了什么問題，為什么會發生（或可以理解為怎么解決的）！
7、缺陷優先級定義
被很多其他功能或檢查點依賴，或者造成blocking issue的缺陷定義為P1，要求開發人員最高優先解決；
被其他功能或檢查點依賴的功能或檢查點所屬的缺陷定義為P2，要求開發人員次優先解決；
獨立的功能或檢查點所屬的缺陷定義為P3，要求開發人員將P1和P2級別缺陷處理完成后再着手解決；
較小的功能缺陷或頁面樣式問題定義為P4，要求開發人員將P1、P2和P3級別缺陷處理完成后再着手解決；
一些功能和樣式方面的建議也可以登記到系統並標識優先級別為P4，一般可以放到后續版本中解決；
總結：缺陷優先級和嚴重程度有很大的關系，以及綜合考慮對上線發布，對用戶的影響！
測試結果質量評估的最低標准：測試結果最低限度的符合需求並且可以正常運行！
8、缺陷嚴重程度定義
特別嚴重的問題，比如嚴重的樣式問題，數據錯誤，主要流程卡死等，要求標示嚴重級別為S1；
比較嚴重的問題，比如較嚴重的樣式問題，主要功能缺陷等，要求標示嚴重級別為S2；
一般嚴重度的樣式或功能問題，要求標示嚴重級別為S3；
輕微的樣式或功能問題，要求標示嚴重級別為S4；
測試人員在測試過程中發現的一些可以改進優化的地方，同樣應該記錄下來並提交到缺陷管理工具上，可以標示嚴重級別為S4，一般可以放到后續版本中跟進；
總結：關於缺陷嚴重程度，學會取舍，做什么和不做什么？如果做，怎么做？如果現在不做，什么時候做？
這些內容，其實都是軟件測試人員入門必須了解的知識，但如何在工作中正確的運用所學的知識，卻是一門學問，紙上得來終覺淺，絕知此事要躬行！
知識是很碎片化，又很體系化的，要學會實踐總結，將其變為自己知識體系的一部分！！！