由於咱們的受眾測試人員，有測試老鳥，也有新入手的菜鳥。所以筆者準備一篇基礎篇，一篇技術篇，這樣就是你好，我好，大家都好！老鳥就只當複習了，溫故而知新嘛。
作為乙個測試工程師，我們最基本的工作就是寫測試用例，執行測試用例。而想寫乙個覆蓋度特別全的測試用例，避免不了的，我們在寫測試用例的時候，加入很多測試方法，才能寫出乙個有含量的測試用例。今天就談談常用的測試方法。
1.等價類劃分
等級類劃分，分為有效等價類，無效等級類。有效等價類：針對被測物件，有效的，合理的，被系統接收的輸入。那麼無效等級類就是無效的，不合理的，不被系統接收的輸入。例如，使用者名稱輸入限定在6-20位，輸入這個範圍內的屬於有效等價類。範圍外的輸入無效等級類。
2.邊界值
邊界是指相對於輸入等價類和輸出等價類而言，稍高於其邊界值及稍低於其邊界值的一些特定情況。例如，使用者名稱輸入限定在6-20位，可以6-19位，5-19位等。下拉城市列表，選擇第一位或者最後一位，都屬於邊界值範疇。
3.判定表
判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。判定表分為：條件樁，條件項，動作樁，動作項。
其步驟如下：
1.確定規則的個數.假如有n個條件。每個條件有兩個取值（0,1）,故有2的n次方種規則。
2.列出所有的條件樁和動作樁。
3.填入條件項。
4.填入動作項。得到初始判定表。
5.簡化.合併相似規則
舉例問題描述：「對於功率大於50馬力的汽車，並且維修記錄不全或已執行10年以上的機器，應給予優先的維修處理」
條件樁：
c1：功率大於50馬力嗎？
c2：維修記錄不全嗎？
c3：執行超過10年嗎？
動作樁：
a1：進行優先處理
a2：作其他處理
4.因果圖
在乙個介面中有多個控制項，如果控制項之間有組合關係或者限制關係，不同的控制項組合會產生不同的輸出結果。為了弄清不同的輸入組合會產生怎樣的輸出結果，可以使用因果圖。表達的是因（輸入結果）和果（輸出結果）之間的關係。
例如：a=0，且a=b，那麼b=0。
5.測試大綱法
序包含多個視窗，每個視窗中又有多個功能，這些功能之間又有一定的聯絡。為了梳理清楚視窗之間以及視窗不同功能之間的聯絡，使用測試大綱法。
如：安裝程式的測試
1. 分析需求列出視窗以及每個視窗中的功能
2. 根據大綱，找到視窗及功能之間的關係，編寫測試用例
6.流程分析法
又叫場景設計法，此方法用於既定業務流。
舉例:乙個登陸系統的業務流，我們可以分為「基本流」，「備選流」「異常流」三個場景設計用例。基本流就是正常輸入使用者名稱密碼，然後成功登入。
備選流就是我們輸入錯誤一到兩次密碼或者使用者名稱，然後輸入正確登入。
異常流：輸入錯誤的密碼或者使用者名稱。然後細化測試用例。
7.錯誤推斷法
基於經驗和直覺推測程式中所有可能存在的各種錯誤 , 從而有針對性的設計測試用例的方法 .其分析如下三條所示：
1.程式中所有可能的錯誤
2. 容易發生錯誤的特殊情況
3.以前產品測試中曾經發現的錯誤.
根據上述三條，設計錯誤推斷的測試用例。
當然還有其他的方法，小編認為上述是比較常用的，有其他方法的同學歡迎討論。小編vx 公 眾 號 王大哥自動化測試 更早的發布文章，講解測試，完全免費，非機構歡迎關注。
軟體測試工程師
首先，最根本的還是要看企業自身的需要，綜合自己的測試團隊力量，自己公司的研發狀況，當然還有公司的資金 到底到測試這塊公司願意投入多少money呢?另外要搞清楚自己公司招聘測試人員的目的是什麼?比如，如果公司暫時還沒有測試團隊，這個時候公司剛好有財力，同時研發力量比較大的時候，因為發展的需要，必須要組...
軟體測試工程師
理解產品的功能要求，並對其進行測試，檢查軟體有沒有缺陷，測試軟體是否具有穩定性 安全性 易操作性等效能，寫出相應的測試規範和測試用例的專門工作人員。最重要的客戶是軟體的使用者。測試工程師需要站在客戶的使用和需求角度測試軟體，報告問題。軟體測試只能證明軟體存在錯誤，不能保證軟體沒有錯誤，不可能找出全部...
測試工程師由深到淺 軟體測試流程
作為乙個測試工程師，幾乎每次面試都要問的的乙個問題就是講講你們公司的專案 測試流程。千萬別傻傻的說我們公司沒什麼流程，或者，敏捷開發，流程很簡單，這樣基本上你就pass掉了。其實還是有個基本流程的框架呢，其順序如下 立項 需求編寫 需求評審 確認需求 測試計畫 測試用例編寫 研發要寫研發設計了 用例...