開發人員關於測試的總結
程序妹紙絮叨絮叨
跟一波潮流，玩玩戀與製作人，4個養成系男友。。。。。呃呃呃，來自一個單身汪的自我幻想。。。。
作為開發人員，有時候也要充當測試人員的角色，所謂哪裡需要哪裡搬。現在就軟體測試，整理一部分文檔。
需求的分析、測試的方法、測試用例表格的設計、測試用例的編寫及評審、測試用例的管理
軟體就是數據、程序、文檔的結合
測試流程：需求分析--提取測試點--測試用例編寫--測試用例評審
需求分析
業務需求--關注系統是否滿足業務
用戶需求--關注系統是否滿足用戶習慣
功能需求--關注系統是否滿足功能要求
沒有需求怎麼辦？
參考市面上已經上線的同類產品。
需求模糊怎麼辦？
1、收集整理已有需求，和產品經理逐條確認；
2、參考同類型產品的實現情況。
測試生命周期：測試計劃、測試設計、測試開發、測試執行、測試評估
測試用例評審：同行評審、小組評審、部門評審、三方評審。
三方：測試、開發、客戶
根據軟體測試的手段劃分：黑盒、灰盒、白盒
根據軟體測試的方向劃分：功能、性能、安全
根據軟體測試的測試點劃分：兼容性、易用性、UI元素
黑盒 ：軟體比作一個黑色的盒子，不知道盒子裡面的內部結構只能夠通過外面所暴露出來的介面進行測試。
灰盒 ：就是把軟體比作一個半透明的盒子，可以看到裡面少部分的東西，所以可以通過暴露的功能和盒子內部的數據進行對比得出測試結論。比如測試一個訂單生成的功能就可以通過軟體上生成的訂單和資料庫里的數據進行對比內外是否一致。白盒 ：把軟體看成一個透明的盒子通過觀察內部的結構直接推銷出是否滿足用戶的需求，白盒測試時這三種測試中技術難度最高的一種功能 ：功能測試就是驗證是否滿足用戶提出的軟體需求。
性能 ：就是測試軟體的一個工作效率。安全 ：安全測試就是是否能夠保護用戶的信息而被輕易的盜取，而獲取一下非法的利益兼容性：測試軟體在不同平台上的表現易容性：測試軟體是否友好滿足用戶的使用習慣UI元素：檢測軟體的界面布局是否一致，美觀。黑盒測試
測試用例編寫的方法：
等價類劃分發：選擇適當的數據子集，代表整個數據集。通過降低測試的數目去實現『合理的』覆蓋，覆蓋了解更多的可能數據，以發現更多的軟體缺陷。
屬於黑盒測試：在測試用例中選取有代表性的東西進行分類；一般分為有效等價類（合理的，有意義的數據，可以看我們的系統功能或性能是否符合）和無效等價類。
例如登錄郵箱 有效和無效
有效：常規郵箱賬號
無效：錯誤郵箱或字元串格式去測試
邊界值分析法：將測試邊界情況作為重點目標，選取正好等於，剛剛大於或剛剛小於邊界值的測試數據。
場景法：分析用戶使用系統的場景，（要求對需求十分熟悉）
場景法一般包含基本流和備用流，從一個流程開始，通過描述經過的路徑來確定的過程，經過遍歷所有的基本流和備用流來完成整個場景。
猜錯法：（需要經驗）通過經驗，直覺等分析可能會出錯的部分
測試用例
測試用例的作用：
1、測試工作的核心
2、一組在測試時輸入輸出的標準
3、軟體需求的具體對照
測試用例包含的內容
測試編號、用例名稱、測試背景、前置條件、重要級、優先順序、測試數據、測試步驟、預期結果、實際結果、編寫人、執行人、開發工程師、可以加上測試環境，測試類型（手工測試），測試版本，測試應用，測試階段（系統測試），備註
用例編號：唯一 --身份證號
用例名稱：用例的名字，要求言簡意賅 --姓名
測試背景：這條用例主要測試什麼東西，是什麼樣的用例，哪個項目，為什麼要測試
前置條件：執行這條措施之前應該先執行什麼條件，比如測試登錄功能，前提是要有賬 號密碼。例伺服器已有數據下發
優先順序：測試用例的優先程度
重要級：測試用例的重要程度
//注意優先順序和重要級不一定成正比關係。比如：周末出去玩，但是公司突然加班 優先順序：出去玩 重要級:回公司加班 當然結果是回去加班
測試數據：比如輸入的賬號密碼，滑鼠的操作也是一種測試數據
測試步驟：測試進行的步驟
預期結果：對應輸入數據或條件等得到對應的現象
實際結果：測試執行後的結果
備註：其他特殊情況的信息。
測試用例編寫注意以下幾點：
1、根據項目的實際情況設計測試用例表格
2、用例格式不是固定的，不要生搬硬套
3、根據具體的情況編寫
為什麼需要管理用例？
1、測試用例數量巨大
2、測試用例會隨著需求變更
3、測試用例需要補充完善
如何管理用例？
1、原始的excel管理方式
2、專業的項目管理系統
我們公司用的是禪道
推薦閱讀：