軟體的生命週期
可行性研究，需求分析----設計，編碼，測試----軟體發布維護----淘汰
軟體生命週期的瀑布模型
軟體測試的生命週期
軟體的測試流程
軟體測試流程
測試計畫階段
制定測試計畫（包括測試目的、策略、資源、里程碑）
測試設計和開發階段
分析測試需求、設計測試用例
準備資料、開發測試工具、指令碼
測試實施階段
按照設計好的用例、準備好的資料和制定的測試策略，實施進行具體的測試過程
測試評估階段
測試總結、缺陷分析、過程評估
軟體測試計畫的書寫時機
軟體測試計畫應當盡早的制定
軟體測試計畫在測試活動中處於中心位置
它設定了測試準備工作和執行測試的必備的條件
同時形成了測試過程質量保證的基礎
測試計畫內容
一、專案簡介
1.1、目的 目的(
文件目的
,測試目的)
1.2、背景 2
1.2文件受眾:
2. 適用物件
開發經理
測試經理
公司高層領導
二、測試參考文件和測試提交文件 4
文件寫法一定要統一(
不用寫副檔名
.doc,
具體哪乙個檔案)
三、術語介紹：所有軟體測試的專業詞彙都要寫！（如果是第三方，或者是使用者要看測試計畫，要保證使用者看懂）如：缺陷的定義，功能測試，壓力測試，效能測試等
看(測試模型
(這個看受眾使用者
,如果使用者是開發團隊
,是第三方測試
,要寫清楚
)測試架構(
測試模型
)1.為什麼選擇模型
2.模型細化
,每個階段做什麼
->
輸出好幾版本
:v,螺旋
(邊測邊改
,1個計畫
,死亡線
) 用例結果帶給下乙個版本h模型)
四、測試需求
測試範圍
依據需求分析,
找測試需求
五、測試策略
1.值域測試
:2.資料庫測試
3.功能測試
4.裸機測試
5.版本驗證測試
->
冒煙測試
6介面測試
7.可用性測試
8.強度測試
9.安裝測試
10.安全性測試
11.
加密測試
12.介面測試
13.整合測試
14.配置測試
15.壓力測試
16.容量測試
17.故障轉移和恢復性測試
18.負載測試
驗收測試
注意:測試結構:功能
,效能不屬於策略
,黑白盒也不屬於策略
,測試階段也不屬於策略.
六、嚴重程度、優先順序的定義(
可寫在這裡
))1）用例的優先順序
2）缺陷的優先順序
3）缺陷的嚴重程度
七、測試進度 5模型
->
對規模再細化階段
->
里程碑->
具體每天
里程碑 -----
要加評審
(時間安排
,考慮並行的情況
:需求計畫在評審中
,寫用例
,搭建環境
,時間緊且人員充足的情況下這樣做)
需求分析
需求評審
測試計畫
計畫評審
編寫用例
用例評審
執行用例
測試總結
八、測試資源 6
系統:是實體機還是虛擬機器
,要寫清楚
硬體:不用網路就不寫.遊戲
:要寫顯示卡
硬碟工具:
研發人員開發
,內部開發的工具.
九、系統風險 (不寫)
1 系統風險
1.1 影響計畫的潛在因素
1.2 應急措施
1.3 測試的侷限性
2 測試通過標準
2.1 測試模組通過標準
2.2 系統測試通過標準(iso 9000規定,
有些公司會更嚴格一些)
當沒有發現致命性錯誤，嚴重功能性錯誤數量小於測試用例總數的2%，一般功能性錯誤數量小於測試用例總數的5%，則認為系統通過本次測試，但要以測試結果評審會的評審結果為最後標準
十、附錄：一般新增模板：計畫模板，用例模板，日誌模板，缺陷報告模板，會議記錄（記錄人，參與人，評審人）
測試說明:
各種模板
,如何使用
,如何做需求分析的?
五月三十一日
花月的結束。明天就是六一了，兒童節哦，但是要體能測試。中間還有1000公尺。本來這也沒什麼，但是太久沒運動了，直接來個1000公尺恐怕還真吃不消，跑完跑及格是沒問題的，然而後遺症會很嚴重的，會幾天都難受。網路實踐的內容又往後做了一點，完成了vpn的架設，也完成了對路由的埠對映，開通了遠端桌面。遠端桌...
五月十一日 課後總結
數論 重點 篩法 vector int ret for int i 2 i i x i while x i 0 if x 1 ret.push back x return ret 這個pushback就是推乙個數進到ret vector是stl資料標準庫里的乙個向量 但他既可以做陣列用也可以當鍊表使...
工作 德魯克日誌之六月二十一日
quote b 遊手好閒沒事做，魔鬼找活給他做。b 我們知道，工作是負擔，也是責任 是禍，也是福。很早以前我們就認識到，失業會令人心理不安，這並非由於失業造成的經濟上的窘困，而是它使人喪失自尊。工作是人性的延伸。它是一種成就。它是一種幫人定位自我 評價自身價值和品性的方式。b 行動指南 b 不要因為...