最近要做功能測試和性能測試，臨時抱佛腳，學習點可用的概念和術語，有個大概的認知。
測試需求
一個質量過硬的軟件系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。
顯式功能性需求（Functional requirement）的含義從字面上就可以很好地理解，指的是軟件本身需要實現的具體功能。
從軟件測試的維度來看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。
安全性測試
- 用戶密碼後臺存儲是否加密；
- 用戶密碼在網絡傳輸過程中是否加密；
- 密碼是否具有有效期，密碼有效期到期後，是否提示需要修改密碼；
- 不登錄的情況下，在瀏覽器中直接輸入登錄後的URL地址，驗證是否會重新定向到用戶登錄界面；
- 密碼輸入框是否不支持複製和粘貼；
- 密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看；
- 用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗證系統的返回頁面；
- 用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串，驗證系統行爲是否被篡改；
- 連續多次登錄失敗情況下，系統是否會阻止後續的嘗試以應對暴力破解；
- 同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期；
- 同一用戶先後在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
性能壓力測試
- 單用戶登錄的響應時間是否小於3秒；
- 單用戶登錄時，後臺請求數量是否過多；
- 高併發場景下用戶登錄的響應時間是否小於5秒；
- 高併發場景下服務端的監控指標是否符合預期；
- 高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；
- 長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏。
兼容性測試
- 不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
- 相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
- 不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
- 不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。
測試用例
好的測試用例
1. 概念
“好的”測試用例一定是一個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而跟能否發現缺陷無關。
2. 特徵
“好的”測試用例必須具備哪些特徵？
- 整體完備性： “好的”測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
- 等價類劃分的準確性： 指的是對於每個等價類都能保證只要其中一個輸入測試通過，其他輸入也一定測試通過。
- 等價類集合的完備性： 需要保證所有可能的邊界值和邊界條件都已經正確識別。
三種最常用的測試用例設計方法
對大多數的軟件測試而言，綜合使用等價類劃分、邊界值分析和錯誤推測這三大類方法就足夠了。
1. 等價類劃分
等價類中任意一個輸入數據對於揭露程序中潛在錯誤都具有同等效果。只要從每個等價類中任意選取一個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。
等價類劃分方法的另一個關鍵點是要找出所有“無效等價類”。
案例：
學生信息系統中有一個“考試成績”的輸入項，成績的取值範圍是0~100之間的整數，考試成績及格的分數線是60。
在考慮了無效等價類後，最終設計的測試用例爲：
- 有效等價類1：0~59之間的任意整數；
- 有效等價類2：59~100之間的任意整數；
- 無效等價類1：小於0的負數；
- 無效等價類2：大於100的整數；
- 無效等價類3：0~100之間的任何浮點數；
- 無效等價類4：其他任意非數字字符。
2. 邊界值分析方法
大量的錯誤發生在輸入輸出的邊界值上，所以需要對邊界值進行重點測試，通常選取正好等於、剛剛大於或剛剛小於邊界的值作爲測試數據。
eg. “考試成績”的例子，選取的邊界值數據應該包括：-1，0，1，59，60，61，99，100，101。
3. 錯誤推測方法
錯誤推測方法是指基於對被測試軟件系統設計的理解、過往經驗以及個人直覺，推測出軟件可能存在的缺陷，從而有針對性地設計測試用例的方法。
比如，Web界面的GUI功能測試，需要考慮瀏覽器在有緩存和沒有緩存下的表現；Web Service的API測試，需要考慮被測API所依賴的第三方API出錯下的處理邏輯；對於代碼級的單元測試，需要考慮被測函數的輸入參數爲空情況下的內部處理邏輯等等。
建立常見缺陷知識庫，在測試設計的過程中，會使用缺陷知識庫作爲檢查點列表（checklist），去幫助優化補充測試用例的設計。
建立一個簡單的wiki頁面，讓測試工程師完成測試用例的最初設計後對應這個wiki頁面先做一輪自檢，如果在後續測試中發現了新的點，就會繼續完善這個wiki頁面。
如何設計
在具體的用例設計時，首先需要搞清楚每一個業務需求所對應的多個軟件功能需求點，然後分析出每個軟件功能需求點對應的多個測試需求點，最後再針對每個測試需求點設計測試用例。
以用戶登錄爲例：
兩個關鍵點：
- 從軟件功能需求出發，全面地、無遺漏地識別出測試需求是至關重要的，這將直接關係到用例的測試覆蓋率。 比如，如果你沒有識別出用戶登錄功能的安全性測試需求，那麼後續設計的測試用例就完全不會涉及安全性，最終造成重要測試漏洞。
- 對於識別出的每個測試需求點，需要綜合運用等價類劃分、邊界值分析和錯誤推測方法來全面地設計測試用例。以“用戶登錄”的功能性測試需求爲例，你首先應該對“用戶名”和“密碼”這兩個輸入項分別進行等價類劃分，列出對應的有效等價類和無效等價類，對於無效等價類的識別可以採用錯誤猜測法（比如，用戶名包含特殊字符等），然後基於兩者可能的組合，設計出第一批測試用例。等價類劃分完後，你需要補充“用戶名”和“密碼”這兩個輸入項的邊界值的測試用例，比如用戶名爲空（NULL）、用戶名長度剛剛大於允許長度等。
其他經驗
- **只有深入理解被測試軟件的架構，你才能設計出“有的放矢”的測試用例集，去發現系統邊界以及系統集成上的潛在缺陷。**必須對內部的架構有清楚的認識，比如數據庫連接方式、數據庫的讀寫分離、消息中間件Kafka的配置、緩存系統的層級分佈、第三方系統的集成等等。
- 必須深入理解被測軟件的設計與實現細節，深入理解軟件內部的處理邏輯。單單根據測試需求點設計的用例，只能覆蓋“表面”的一層，往往會覆蓋不到內部的處理流程、分支處理，不要以開發代碼的實現爲依據設計測試用例。應該根據原始需求設計測試用例。
- 需要引入需求覆蓋率和代碼覆蓋率來衡量測試執行的完備性，並以此爲依據來找出遺漏的測試點。