軟體測試規範
zero bug和good enough
對於相對複雜的產品或系統來說，沒有bug是不可能的，我們只能想方設法把軟體的bug數控制在可以忍受的範圍內
good enough 原則就是一種權衡投入/產出的原則：不充分的測試時不負責任的，過分的測試是一種資源的浪費
不要窮舉測試
窮舉測試指的是測試時考慮所有可能的輸入值。
開發人員不能既是運動員又是裁判員
測試應該由獨立的第三方機構來完成
軟體測試要盡早執行
實踐證明，需求分析階段引入缺陷是最多的，其修復成本是最低的，所以軟體測試要盡早執行，越早執行，風險越小
缺陷的二八定理
一般情況下，軟體80%的缺陷集中在20%的模組中，測試時要抓主要矛盾
缺陷具有免疫性（殺蟲劑悖論）
像農藥使用久了，害蟲會產生抗藥性，缺陷也具有免疫性
測試人員根據相同的測試用例進行回歸測試，就像用同一種農藥來殺害蟲一樣
軟體測試應該追溯需求
遇到乙個軟體問題，應該去追溯它的源頭，看看是由於編碼的錯誤、設計的錯誤、還是需求說明的錯誤。
軟體測試原則
1.測試證明軟體存在缺陷 無論執行什麼樣的測試操作都能證明當前軟體是有缺陷的 2.不能執行窮盡測試 有些功能是沒有辦法將所有的測試情況都邏輯出來，所以任何的測試操作都有結束的時間 3.缺陷存在群集現象 對於軟體功能說，核心功能佔20 非核心80 在實際工作中我們會集中測試20 的核心功能，所以這個部...
軟體測試基礎 軟體測試的原則
所有的軟體測試都應該追溯到使用者需求。即應該重視需求文件，明確最初的需求才能盡可能減少後期的錯誤 盡早啟動測試工作，盡可能早地發現問題。問題越是遺留到後面修改的成本越大 pareto法則適用於軟體測試，又稱28效率法則，即早期應該能夠發現大量的問題 窮盡測試是不可能的，應當做適當的風險分析 殺蟲劑免...
軟體測試的原則
1 測試用例中乙個必需部分是對預期輸出或者結果進行定義 2 程式設計師應當避免測試自己編寫的程式 3 編寫軟體的組織不應當測試自己編寫的軟體 4 應當徹底檢查每個測試的執行結果 5 測試用例的編寫不僅應當根據有效的和預料到的輸入情況，而且也應當根據無效和未預料到的輸入情況 6 檢查程式是否 未做其應...