基礎篇：如何作一名專業的軟件測試工程師

做爲一個軟件測試工程師，在面試過程當中，如何表達本身的核心競爭力？如何體現本身的專業性？這是個值得思考的問題。

 

一、缺陷的生命週期

總結：是否能夠準確清晰的描述缺陷的生命週期，以及每一個流轉過程當中你應該作什麼？怎麼作？（敲黑板，思考！！！）

 

二、對缺陷錯誤狀態的定義

• 新建(New)：測試中新報告的軟件缺陷；

• 打開 (Open)：被確認並分配給相關開發人員處理；

• 修正(Fixed)：開發人員已完成修正，等待測試人員驗證；

• 拒絕(Declined):拒絕修改缺陷；

• 延期(Deferred): 不在當前版本修復的錯誤，下一版修復；

• 關閉(Closed)：錯誤已被修復；

總結：軟件測試工程師的職責是主動發現暴露軟件存在的缺陷，並輔助開發工程師一塊兒確保缺陷被修復，提升交付軟件質量和交付速率的崗位，每一個不一樣的軟件缺陷狀態，做爲一個測試工程師，你應該作什麼？

 

三、人員角色的不一樣權限

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：測試主管/測試工程師

總結：應該明確在一個項目或者一個部門裏，你的權限職責，不一樣同事的權限職責，以及遇到問題須要協商溝通，應該找誰，怎麼解決！

 

四、缺陷管理流程要點

爲了保證錯誤的正確性，須要有豐富測試經驗的測試人員驗證發現的錯誤是不是真正的錯誤，書寫的測試步驟是否準確，能夠重複；

每次對錯誤的處理都要保留處理信息，包括處理姓名，時間，處理方法，處理意見，Bug狀態；

拒絕或延期錯誤不能由程序員單方面決定，應該由項目經理，測試經理和產品經理共同決定；

錯誤修復後必須由報告錯誤的測試人員驗證後，確認已經修復，才能關閉錯誤；

增強測試人員與程序員的交流，對於某些不能重複的錯誤，能夠請測試人員補充詳細的測試步驟和方法，以及必要的測試用例；

總結：上述幾點，其實主要思想仍是圍繞第一部分--在缺陷的整個生命狀態流轉中，應該如何管理，什麼狀態須要什麼對應的管理方法，靈活應用！

 

五、用例設計規範

新建測試用例時要求選擇對應的產品模塊、用例類型、適用階段和相關需求，用例類型通常選擇功能測試，適用階段通常選擇系統測試；

用例標題要求描述對象功能明確，並儘可能作到簡潔；

根據須要填寫適當的前置條件，要求在業務流程上前置條件以後能夠銜接第一步操做；

操做步驟要表述清楚具體步驟和檢查點及其所在的位置，UI元素和控件須要標識清楚；

預期結果須要明確，原則上不該有無預期結果的操做步驟；

總結：談到用例設計，有最基本的「八要素」，以及設計用例的2個思路（按模塊仍是按業務流），對業務依賴、異常如何思考處理？如何提升覆蓋率？這些均可以從設計用例的規範裏面思考找到答案！

 

六、缺陷提交規範

提交缺陷時要求選擇對應的產品模塊、所屬項目、影響版本、優先級、嚴重程度和相關需求；

缺陷標題要求可以確切地描述缺陷，包括缺陷出現的位置和表現，要注意避免冗長；

重現步驟中必須包括步驟，結果和指望，狀況容許的話須要提供測試數據供開發人員迅速重現問題（日誌截圖，報錯方法）；另外，比較複雜的UI要求截圖；

總結：提交缺陷，必須記住四要素：when、how、what、why！即表達一個問題必須知足的四個條件：什麼時間執行了什麼操做，發生了什麼問題，爲何會發生（或能夠理解爲怎麼解決的）！

 

七、缺陷優先級定義

被不少其餘功能或檢查點依賴，或者形成blocking issue的缺陷定義爲P1，要求開發人員最高優先解決；

被其餘功能或檢查點依賴的功能或檢查點所屬的缺陷定義爲P2，要求開發人員次優先解決；

獨立的功能或檢查點所屬的缺陷定義爲P3，要求開發人員將P1和P2級別缺陷處理完成後再着手解決；

較小的功能缺陷或頁面樣式問題定義爲P4，要求開發人員將P一、P2和P3級別缺陷處理完成後再着手解決；

一些功能和樣式方面的建議也能夠登記到系統並標識優先級別爲P4，通常能夠放到後續版本中解決；

總結：缺陷優先級和嚴重程度有很大的關係，以及綜合考慮對上線發佈，對用戶的影響！

          測試結果質量評估的最低標準：測試結果最低限度的符合需求而且能夠正常運行！

 

八、缺陷嚴重程度定義

特別嚴重的問題，好比嚴重的樣式問題，數據錯誤，主要流程卡死等，要求標示嚴重級別爲S1；

比較嚴重的問題，好比較嚴重的樣式問題，主要功能缺陷等，要求標示嚴重級別爲S2；

通常嚴重度的樣式或功能問題，要求標示嚴重級別爲S3；

輕微的樣式或功能問題，要求標示嚴重級別爲S4；

測試人員在測試過程當中發現的一些能夠改進優化的地方，一樣應該記錄下來並提交到缺陷管理工具上，能夠標示嚴重級別爲S4，通常能夠放到後續版本中跟進；

總結：關於缺陷嚴重程度，學會取捨，作什麼和不作什麼？若是作，怎麼作？若是如今不作，何時作？

這些內容，其實都是軟件測試人員入門必須瞭解的知識，但如何在工做中正確的運用所學的知識，倒是一門學問，紙上得來終覺淺，絕知此事要躬行！

知識是很碎片化，又很體系化的，要學會實踐總結，將其變爲本身知識體系的一部分！！！

推薦一高性價比JMeter測試教程：http://edu.51cto.com/course/13251.html

出處：

https://www.cnblogs.com/imyalost/p/8606173.html

版權申明：內容來源網絡，版權歸原創者全部。除非沒法確認，咱們都會標明做者及出處，若有侵權煩請告知，咱們會當即刪除並表示歉意。謝謝。