估算
測試對軟件工作量的估算的准確性
測試評估軟件系統的狀況的准確性
關注點：
- 不准確的估算
- 不適當的開發過程
- 不真實的狀態報告
如何知道對工作量的估算是正確的
估算工作量的工具很容易出錯
對軟件工作量的估算需要策略
五個一般的方法
- 推測
- 加入一些約束條件
- 以一些數據為基礎
- 模擬進行工作
- 將一些參數模型化
參數模型
- 回歸模型：將現有的參數與已有的歷史數據相擬和。
- 啟發式模型：對歷史數據進行觀察和解釋
- 現象模型：假設軟件開發過程可以依據一些更廣泛的可適用的過程解釋。
模型遵循的共同模式
- 估算軟件的大小
- 將大小轉化成人力的估算，並且作出可能的成本的估算
- 依據項目的特性進行估算的調整
- 將整體的估算划分到不同的項目階段中
- 估算不包括技巧上面的人力和計算機的運行時間
- 將以上內容相加
對估算進行檢驗
- 檢驗估算模型的合理性
- 檢驗模型是否包含了必須的測試要素
- 檢驗模型的正確性
檢驗估算模型的正確性
- 重新進行估算:輸入是否正確;輸入是否合理;對數據的計算是否合理有效
- 比較延期的估算是否符合項目實際情況
- 讓謹慎的人來作測試驗證工作
- 對軟件中的冗余價值估算
影響估算正確與否的因素
- 軟件規模
- 新設計新代碼的比例
- 復雜程度
- 設計和編碼的困難
- 使用什么語言
- 安全性
- 需求的揮發性
- 組織因素:項目計划/人員/開發環境/硬件資源/人員利用率/膨脹因素
- 估算就是估算，不是保證書
追蹤測試工作的瓶頸
- 工作完成點
- 同配置管理系統緊密的結合
- 如何使用:模塊列表/里程碑/工作完成點
- 用計算所有工作的完成度來檢查系統工作過程。
測試計划
開發測試計划
目標:
詳細的描述怎樣能成功的完成測試工作，其中應包含必須的資源和實施計划。
可能的不利因素：
- 沒有得到足夠的培訓
- 心里准備不足
- 缺乏測試工具
- 缺乏管理的標准和支持
- 缺乏客戶和最終使用者的參與
- 沒有足夠的時間進行測試
- 對於獨立的測試人員過度信任
- 版本改變的太快
- 測試人員處於不受重視的情況中
- 不能說不
實施過程
- 聽取各方面的意見和建議
- 標明項目風險:測試要素/聯系測試矩陣
- 建立測試計划
- 對計划進行評審
建立測試計划
定義測試目標
開發測試矩陣
- 軟件模型
- 結構特性
- 批量測試的階段和用例
- 為在線系統作概念上的測試腳本
- 軟件測試矩陣
定義測試管理 - 測試計划的一般性信息
- 定義測試里程碑
- 定義管理上的檢查點
書寫測試計划
評審測試計划
涉及評審的問題
- 評審測試的開始時間是否會延期
- 有沒有抵觸評審的角色
- 一段時間內是否很難得到工作的檢查信息。
- 更換工具有可能導致他們反感評審工作
- 評審結果可能會影響對個人的工作評價
對於最終成品的檢查 - 項目的需求規格說明書
- 軟件返工/維護的文檔
- 升級后的技術文檔
- 被更改的源程序
- 測試計划
- 用戶手冊（包括在線幫助）
正式評審中的角色 - 緩和劑（SQA）
- 讀者
- 記錄者
- 作者
- 檢測員
正式評審發現的缺陷應包含的信息 - 起因
- 類型
- 分類
- 級別
評審流程
計划和組織
通篇的講解（可選）
個人准備
評審會議
修訂和反復
需求階段的測試
測試成本
被設計用來減少測試成本
IBM的數據:大約 60個缺陷/千行;2/3的缺陷產生在需求和設計階段
在需求和設計階段發現的缺陷修正的花費最小
修正系統測試階段發現的缺陷，花費是以上的10倍
發布產品以后，修正缺陷的花費是原來的100倍
生命周期的測試概念
- 在軟件開發過程中持續的進行測試
- 在盡可能早的階段點去修正缺陷
- 需要正式的開發流程來支持
- 組建測試團隊
- 當開發開始進行的時候，測試就開始進行了
需求階段的測試
所有的花費都是值得的
大部分缺陷將不會進入到設計&編碼階段
目標
- 需求正確的表現出了用戶的需要
- 需求已經被定義和文檔化了
- 花費和收益成正比
- 需求的控制被明確
- 有合理的流程可遵循
- 有合理的方法可供選擇
准備風險列表 - 確定風險組
- 確定風險（風險分析 & 風險檢查表）
- 建立控制目標
- 確定有足夠的控制力度
分析測試要素
- 需求的設計是否遵循了已定義的方法
- 提交了已定義的功能說明
- 定義了系統界面
- 已經估計了性能標准
- 容忍度被預先估計
- 預先定義了權限規則
- 需求中預先定義了文件完整性
- 預先定義了需求的變更流程
- 預先定義了失敗的影響
- 權限定義
需求走查
- 建立基本規則
- 選擇小組/通報參與者
- 項目介紹
- 問題/建議
- 形成最終報告
設計階段的測試
設計階段的測試任務
- 給測試要素打分
- 分析測試要素
- 對設計進行評審
- 檢查修改的部分
交付的產品
- 輸入說明
- 過程說明
- 文件說明
- 輸出說明
- 控制說明
- 系統流程圖
- 硬件和軟件的需求
- 操作手冊說明書
- 數據保留的策略
分析測試要素涉及的內容
- 設計了對數據完整性的控制
- 設計了權限規則
- 設計了對文件完整性的控制
- 設計了審計追蹤
- 設計了發生意外情況時的計划
- 設計了如何達到服務水平的方法
- 定義了權限流程
- 定義了完整的方法學
- 設計了保證需求一致性的方法
- 進行了易用性的設計
- 設計是可維護的
- 設計是簡單的
- 交互界面設計完畢
- 定義了成功的標准
- 需要同實際操作者溝通
對設計進行評審
選擇評審組成員
對評審組進行培訓
通報項目組
分配足夠的時間
只對文檔化的事實進行評審
和項目組一起進行評審
對評審形成建議
和項目組對建議一起進行評審
准備正式的報告
編碼階段的測試
測試的職責
- 編碼是一個純技術的工作，幾乎不需要用戶的參與
- 項目領導者有參與測試的責任
- 監督過程的有效性
形成的輸出
- 編碼說明書
- 程序文檔
- 計算機程序列表
- 可執行的程序
- 程序流程圖
- 操作介紹
- 單元測試結果
關注點
- 完成對數據完整性的控制
- 定義完畢授權的規則
- 完成對文件完整性的控制
- 實現審計追蹤
- 規划出意外情況發生后的處理計划
- 對系統如何達到預定義的服務水平做了計划
- 完成了對安全問題的處理流程
- 編碼工作是依據規定的方法完成的
- 編碼與設計相一致（正確性）
- 編碼與設計相一致（易用性）
- 代碼是可維護的
- 編碼與設計相一致（簡潔性）
- 編碼與設計相一致（耦合性）
- 已開發了操作流程
- 定義出程序成功的標准（性能上）
建議的測試方式
桌面調試
- 語法上的
- 結構上的
- 功能上的
代碼互查 - 建立基本的互查規則
- 選擇互查的team
- 對成員進行培訓
- 選擇互查的方法
- 提供互查的材料
- 流程圖，源程序，典型的處理流程
- 對互查進行必要的管理
- 給出互查結論
- 提供最終的報告
編碼階段測試需要解決的問題
- 系統是可維護的嗎？
- 系統說明是否已經完成了？
- 編碼是否按照既有的標准進行，過程是否易於實踐？
- 是否有足夠的測試計划用來評估可執行的程序？
- 是否編制了足夠的文檔。
測試階段
在需求，設計，編碼階段多進行一些測試，在系統測試階段就會少一些問題。
文檔
- 測試階段的測試計划
- 測試用例
- 前期測試的測試結果
- 第三方測試反饋，例如：計算機操作人員
- 正式的測試總結報告
測試用例的概念是簡單的
建立有效的測試用例是復雜的
設計測試文件
- 測試用例應當包含合法的和非法的輸入
- 每一個動作只進行一次關鍵操作
輸入測試數據
分析結果
嘗試將測試文件違反程序的規則進行輸入
典型的測試類型
- 手冊，回歸，功能點測試
- 一致性測試（授權）
- 功能點測試（完整性）
- 功能點測試（審計，追蹤）
- 覆蓋性的測試（測試的連續性）
- 壓力測試（服務水平）
- 一致性測試（安全性）
- 依照預先定義的測試方法
- 功能點測試（正確性）
- 支持手冊的測試（易用性）
- 檢查（可維護性）
- 災難性的測試（可攜帶性）
- 功能和回歸測試（耦合性）
- 一致性的測試（性能）
- 操作性的測試（易用性）
測試總結
測試報告
目標
- 表示出目前項目的實際狀況
- 明確什么是測試做的工作，什么是不作的工作。
- 給出系統的操作性能的評價
- 明確什么時候系統可以進行產品化的工作
關注點 - 測試報告只有真正需要的時候才有用，需要配合市場和管理
- 測試的信息是不充分的（對於評價一個項目來說）
- 測試狀況並不能真實的反應個人的狀況
測試期間的數據收集
有關測試結果的積累數據
測試任務，測試集合和測試事件的描述
缺陷分析:
- 由於計划的問題，導致沒有發現的缺陷的數據
- 嚴重的缺陷
- 缺陷類型
- 為什么缺陷沒有發現
效果
測試報告
- 報告目前的軟件狀態
- 功能/測試矩陣
- 功能測試的狀態報告，側重點分析
- 關於功能的工作時間軸
- 期望發現 VS 實際發現的缺陷比
- 沒有發現的缺陷和改正的缺陷的差距
- 按照類型分類，沒有改正的缺陷的平均值
- 缺陷分類報告
- 測試活動報告
報告匯總
- 各個階段的項目測試總結報告
- 繼承性測試報告
- 系統測試報告
- 確認測試報告