最近要做功能測試和效能測試，臨時抱佛腳，學習點可用的概念和術語，有個大概的認知。乙個質量過硬的軟體系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。
顯式功能性需求（functional requirement）的含義從字面上就可以很好地理解，指的是軟體本身需要實現的具體功能。
從軟體測試的維度來看，非功能性需求主要涉及安全性、效能以及相容性三大方面。
1. 概念
「好的」測試用例一定是乙個完備的集合，它能夠覆蓋所有等價類以及各種邊界值，而跟能否發現缺陷無關。
2. 特徵
「好的」測試用例必須具備哪些特徵？
整體完備性： 「好的」測試用例一定是乙個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
等價類劃分的準確性： 指的是對於每個等價類都能保證只要其中乙個輸入測試通過，其他輸入也一定測試通過。
等價類集合的完備性： 需要保證所有可能的邊界值和邊界條件都已經正確識別。
對大多數的軟體測試而言，綜合使用等價類劃分、邊界值分析和錯誤推測這三大類方法就足夠了。
1. 等價類劃分
等價類中任意乙個輸入資料對於揭露程式中潛在錯誤都具有同等效果。只要從每個等價類中任意選取乙個值進行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結果。
等價類劃分方法的另乙個關鍵點是要找出所有「無效等價類」。
案例：
學生資訊系統中有乙個「考試成績」的輸入項，成績的取值範圍是0~100之間的整數，考試成績及格的分數線是60。
在考慮了無效等價類後，最終設計的測試用例為：
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的配置、快取系統的層級分布、第三方系統的整合等等。
必須深入理解被測軟體的設計與實現細節，深入理解軟體內部的處理邏輯。單單根據測試需求點設計的用例，只能覆蓋「表面」的一層，往往會覆蓋不到內部的處理流程、分支處理，不要以開發**的實現為依據設計測試用例。應該根據原始需求設計測試用例。
需要引入需求覆蓋率和**覆蓋率來衡量測試執行的完備性，並以此為依據來找出遺漏的測試點。
《軟體測試52講》讀書筆記 軟測的核心競爭力
必須要深入理解業務，但是業務知識不能等同於測試能力 測試工程的價值不能僅僅體現在特定的產品業務上，一旦離開這個業務領域，若你的經驗積累很難被有效重用的話，那你的競爭力就會下降 測試開發崗位的核心是 測試 開發 的目的是更好地服務於測試 作為測開不能只關心如何實現預先設計的功能，而完全不關心所開發的測...
《軟體測試52講》讀書筆記 軟測的核心競爭力
必須要深入理解業務，但是業務知識不能等同於測試能力 測試工程的價值不能僅僅體現在特定的產品業務上，一旦離開這個業務領域，若你的經驗積累很難被有效重用的話，那你的競爭力就會下降 測試開發崗位的核心是 測試 開發 的目的是更好地服務於測試 作為測開不能只關心如何實現預先設計的功能，而完全不關心所開發的測...
軟體測試52講讀後筆記（持續更新 ）
最近在極客讀到茹炳晟老師的 軟體測試52講 覺得觀點很正，特記錄一下自己的在意的點 ps 需付費，鐵雞勿點。從開篇詞可以了解到作為乙個測試工程，如果想要發展，你需要做到哪些，文章中分了3步，我在這裡列出了針對我個人情況需要改進的地方。關注軟體整體的質量，需要根據業務風險以及影響來制定測試策略，控制測...