軟件生命周期：

1、 市場需求調研 2、可行性分析3、產品項目立項、 4、需求調研開發 5、設計開發測試 6、發布運行維護

軟件公司業務形式：自研公司、外包公司

研發團隊人員構成：

1、 研發組長 2、美工/頁面制作人員 3、系統架構師

4開發工程師

測試團隊人員構成：

1測試主管 2、測試組長 3、環境保障人員 4、配置管理員

5、 測試設計人員 6、測試工程師

按技術構成可分為黑盒測試技術人員、白盒測試技術人員、自動化測試工程師和項目管理技術人員。

軟件研發模型：

瀑布模型：（計劃、需求分析、設計、編碼、測試、運行維護）自上而下相互銜接固定 有序逐級下落

有點：節約成本、分析透徹、詳細，設計簡單

缺點：試介入晚、人員閑置嚴重，后續工作跟不上、不適應規模的變更

原型模型：在瀑布模型基礎上演變而來，再確認用戶需求中調整修改、在需求分析環節 評價原型設計

優點：測試介入早、關注需求正確性、及時調整、解決問題、降低開發風險 提高研發效率

缺點：告知用戶重新生產該產品、用戶接受度低不利于開發

螺旋模型

RUG模型

敏捷模型：將一個大項目分為多個相互聯系、也可獨立運行的小項目。迭代較快。

優點：靈活更新快 缺點：成本高

軟件測試模型

V模型：自上而下，從左至右研發人員進行需求分析、概要設計、詳細設計、編碼開發 生成對應關系的測試模型。有瀑布模型演化而來。需求對驗收、概要對系統、 詳細對集成、編碼對單元

優點：節約人力、物力 缺點：成本高、滯后性強

W模型：由V模型演變而來、每個階段都有一個測試和一個計劃。強調對文檔的測試

優點：測試介入早、能夠及時發現、解決問題

缺點：浪費人力物力

X模型:

H模型

敏捷測試模型

軟件測試：檢驗被測對象與預期是否一致

源代碼：開發人員開發的代碼

驗證活動：對軟件進行測試是否滿足客戶需求

數據配置：支撐軟件的相關數據

軟件測試目的：1、發現、并解決缺陷 2、了解被測對象為決策提供依據3、預防缺陷出現 降低風險

通過測試活動，檢測被測對象與預期一致

軟件缺陷：檢測被測對象與預期不一致

產生原因：1、需求表達理解編寫有誤 2、系統架構設計有誤 3、開發中溝通、監督不到位

4、 編程有誤 5、開發工具有問題 6、軟件復雜度高 7、與用戶需求不符

8、 電堿輻射

四種類型：遺漏、錯誤、冗余、不滿意

缺陷報告內容：1、缺陷ID 2、概要描述 3、發現人 4、發現時間 5、修復時間 、

6、所屬版本 7、所屬模塊 8、缺陷狀態 9、缺陷嚴重度 10、修復優先級

11、 下部處理人 12、詳細描述 13、附件

缺陷管理流程：有測試工程師、測試負責人、開發負責人、開發人員、項目經理等人員構成

測試人員發現缺陷定義新建（new）狀態、發現人自檢確認卻先后交由下處 理人并將狀態表示為打開（open）、開發人員確認缺陷成立修復將狀態標記 為fix、測試工程師確認缺陷成功修復后將該缺陷狀態表示為close。若修復 未能測地修復礽存在缺陷則將狀態標為reopen、并將重新修復處理。再次 叫有測試人員測試處理。標記為reject。

軟件測試原則：1、證明軟件存在缺陷 2、不可能進行窮盡測試 3、測試應盡早啟動、盡早 介入 4、缺陷存在群集現象 5、殺蟲劑悖論 6、不同測試活動依賴于不同的 測試背景 7、不存在缺陷的謬論

軟件測試對象：文檔、源代碼、配置數據等。

軟件測試級別：需求測試、組件/單元測試、集成測試、系統測試、驗收測試、alpha測試、 beta測試、UAT（用戶接受度）測試、

軟件測試類型：功能測試、性能測試、負載測試、壓力測試、容量測試、安全測試、兼容性

測試、可靠性測試、可用性測試、移植測試、維護測試、確認測試、回歸測 試

測試方法： 按是否關注邏輯代碼變化、輸出結果分為：黑盒測試、白盒測試、灰盒測試

按是否執行代碼分為：靜態測試、動態測試

按是否人工手動操作：自動化測試、手工測試

軟件測試流程：計劃 范圍 標準 時間 人力 風險

設計 測試的策略 測試的方法和類型

實現 環境搭建 測試用例編寫 測試用例評審

執行 執行測試用例 缺陷跟蹤 回歸測試 測試報告

軟件質量特性：功能性、可靠性、易用性、效率、可維護性、可移植性

測試用例設計：等價類、邊界值、判定表、因果圖、正交試驗、狀態遷移、場景設計法

用例評審：覆蓋度、用例結構、優先級、用例冗余、不滿意、遺漏

什么是測試用例、

測試人員測試用的文檔（測試人員為特定目的去設計的一組輸入輸出的例子）

為什么要寫測試用例？

答：1、加深對需求的理解 2、提高覆蓋度 3、幫助測試人員分析問題 4、指導測試執行

5、幫助測試人員后續質量分析