1. 軟體品質和軟體測試的含義
1.1 軟體品質的内涵
軟體品質是客戶滿意度的展現
品質是系統、部件或過程滿足
- 明确需求
- 客戶或使用者需要或期望的程度不同 IEEE <<Standard Glossary of Software Engineering Terminology>>
- 軟體品質：軟體産品具有滿足 規定的或隐含要求能力要求有關的特征與特征總和(ISO 8492)
- 軟體品質：軟體産品滿足使用要求的程度
1.2 軟體測試的概念
- 是為了發現錯誤而執行程式的過程。
- 應關心程式的效率和魯棒性等因素。
- 檢驗軟體是否滿足規定的需求。
- 弄清預期與實際結果之間的差别。
備注：所謂“魯棒性”，是英文“robust”的譯音，指強壯、健壯的意思。軟體的“魯棒性”，是指系統在一定條件下維持某些性能的特性，簡單地說，就是适應各種各樣的變化的能力。魯棒性越強，系統精确度就愈高，性能越好。
定義：
使用人工或自動手段，來運作或測試某個系統的過程。其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差别。
軟體測試活動一般包含：
- 制訂測試計劃
- 設計測試用例
- 實施測試
- 送出缺陷報告
- 測試總結
1.3 軟體品質範圍-3A
- Accountability (可說明性) – 使用者可以基于産品或服務的描述和定義進行使用. (例如: 市場需求說明書, 功能設計說明書.)
- Availability (有效性) – 産品或服務對于99.999% 客戶總是有效的 (例如: 性能測試和恢複測試)
- Accessibility (易用性) – 對于使用者, 産品或服務非常容易使用并且一定是非常有用的功能 . (例如: 确認測試和使用者可用性測試)
1.4 高品質軟體
應該是相對的無産品缺陷(Bug Free)或隻有極少量的缺陷, 它能夠準時遞交給使用者并且所用的費用都是在預算内的并且滿足客戶需求，是可維護的。但是, 有關品質的好壞最終評價依賴于使用者的回報。
“客戶”廣義定義 :
内在的定義 : 下一個環節/工序的接收者，更廣的服務的對象，周圍有任何聯系或影響的團隊、人。
軟體的設計者，程式的檢測者，項目管理者，品質管理人員 …
廣泛的定義 : 最終使用者，客戶管理
1.5 軟體品質的不同的視點
- 先驗論觀點：品質是産品一種可以認識但不可定義的性質
- 使用者觀點：品質是産品滿足使用目的之程度;
- 制造者的觀點：品質是産品性能和規格要求的符合度
- 産品觀點：品質是聯結産品固有性能的紐帶;
- 基于價值觀點：品質依賴于顧客願意付給産品報酬的數量
1.6 高品質軟體标準體系
産品品質
是人們實踐産物的屬性和行為，是可以認識，可以科學地描述的。并且可以通過一些方法和人類活動，來改進品質.
品質模型: McCall 模型, Boehm 模型, ISO 9126 模型
過程品質:
軟體能力成熟度模型 CMM ( Capability Maturity Model).
國際标準過程模型 ISO 9000
軟體過程改進和能力決斷 SPICE ( Software Process Improvement and Capability dEtermination)
在商業過程中有關的品質内容:
教育訓練、成品制作、宣傳、釋出日起、客戶、風險、成本、業務等
1.7 産品品質的标準
- 功能性 Functionality
- 可用性 Usability (簡單安裝; 輕松使用; 友好界面)
- 可靠性 Reliability (使用者使用的根本)
- 性能 Performance
- 容量 Capacity
- 可測量性 Scalability
- 可維護性 Service manageability
- 相容性 Compatibility
- 可擴充性 Extensibility
1.8 軟體品質特征（ISO9126）
- 功能：與一組功能及其指定性質有關的一組屬性，這裡的功能是滿足明确或隐含的需求的那些功能。
- 可靠：在規定的一段時間和條件下，與軟體維持其性能水準的能力有關的一組屬性。
- 易用：由一組規定或潛在的使用者為使用軟體所需作的努力和所作的評價有關的一組屬性。
- 效率：與在規定條件下軟體的性能水準與所使用資源量之間關系有關的一組屬性。
- 可維護：與進行指定的修改所需的努力有關的一組屬性。
- 可移植：與軟體從一個環境轉移到另一個環境的能力有關的一組屬性。 其中每一個品質特征都分别與若幹子特征相對應。
1.9 軟體過程品質
- 軟體能力成熟度模型 CMM ( Capability Maturity Model).
- 國際标準過程模型 ISO 9000
- 軟體過程改進和能力決斷 SPICE ( Software Process Improvement and Capability dEtermination)
1.9.1 品質保證的政策
主要分三個階段：
- 以檢測為重：産品制成之後進行檢測，隻能判斷産品品質，不能提高産品品質。
- 以過程管理為重：把品質的保證工作重點放在過程管理上，對制造過程 中的每一道工序都要進行品質控制。
- 以新産品開發為重：在新産品的開發設計階段，采取強有力的措施來消滅由于設計原因而産生的品質隐患。
1.9.2 全面品質管理
TQM = Total Quality Management 全面品質管理
- TQM是為了能夠在最經濟的水準上，并考慮到充分滿足使用者要求的條件下進行市場研究、設計、生産和服務，把企業内各部門研制品質、維持品質和提高品質的活動構成為一體的一種有效體系
- TQM内容:
- 全員參與品質管理
- 全過程品質管理。
- TQM的4個關鍵要素:
- 關注客戶
- 過程改進
- 品質的人性化因素
- 度量(即模型的測量和分析)
1.9.3 品質管理發展五個階段
2.軟體缺陷（Bug）是什麼?
2.1 軟體缺陷的含義
任何程式、系統中的問題，和産品設計書的不一緻性，不能滿足使用者的需求
2.2 問題出在哪？
- 項目沒有被很好地了解；計劃不周，最終導緻進度拖延。
- 沒有充分的文檔資料。
- 人與人的交流比寫程式困難得多。
- 軟體可靠性缺少度量的标準，品質無法保證。
- 軟體難以維護、不易更新。
2.3 解決問題的想法
- Better management 管理
- Different team organizations 組織
- Better languages & tools 語言和工具
- Uniform coding conventions 程式設計慣例
必須意識到：“軟體” ≠ 程式設計，它有自己的生命周期 (life cycle)。大型軟體系統的開發與其它工程項目如建造橋梁、制造飛機、輪船等的開發是同理的。
實踐證明：對軟體進行充分的測試
才能夠有效的保證軟體品質
對軟體産品進行充分測試，找出其中的缺陷(Bug),并進行修複(Fix)。
2.4 軟體缺陷--Bug
缺點（defect） 偏差 （variance）
謬誤（fault） 失敗 （failure）
問題（problem） 沖突（inconsistency）
錯誤（error ） 毛病 （incident ）
異常（anomy）
IEEE (1983) 729 軟體缺陷一個标準的定義：
- 從産品内部看，軟體缺陷是軟體産品開發或維護過程中所存在的錯誤、毛病等各種問題；
- 從外部看，軟體缺陷是系統所需要實作的某種功能的失效或違背。
軟體缺陷的主要類型/現象：
- 功能、特性沒有實作或部分實作
- 設計不合理，存在缺陷
- 實際結果和預期結果不一緻
- 運作出錯，包括運作中斷、系統崩潰、界面混亂
- 資料結果不正确、精度不夠
- 使用者不能接受的其他問題，如存取時間過長、界面不美觀
2.5 軟體缺陷的産生
- 技術問題
算法錯誤，文法錯誤，計算和精度問題，接口參數傳遞不比對
- 團隊工作
誤解、溝通不充分
- 軟體本身
文檔錯誤、使用者使用場合(user scenario)，
時間上不協調、或不一緻性所帶來的問題
系統的自我恢複或資料的異地備份、災難性恢複等問題
2.6 軟體缺陷構成
2.7 軟體缺陷在不同階段的分布
在真正的程式測試之前，通過審查、評審會可以發現更多的缺陷。
規格說明書的缺陷會在需求分析審查、設計、編碼、測試等過程中會逐漸發現，而不能在需求分析一個階段發現
2.8 缺陷成本
3. 軟體測試的基本方法
3.1 軟體測試的目的
軟體測試是為了發現錯誤而執行程式的過程
- 一個好的測試能夠在第一時間發現程式中存在的錯誤
- 一個好的測試是發現了至今尚未發現的錯誤的測試。
3.2 軟體測試一些誤區
- 誤區一：如果釋出出去的軟體有品質問題，都是軟體測試人員的錯
- 誤區二：軟體測試技術要求不高，至少比程式設計容易多了
- 誤區三：有時間就多測試一些，來不及就少測試一些
- 誤區四：軟體測試是測試人員的事，與開發人員無關
- 誤區五：根據軟體開發瀑布模型，軟體測試是開發後期的一個階段
3.3 軟體測試的原則
- 所有測試的标準都是建立在使用者需求之上。
- 軟體測試必須基于“品質第一”的思想去開展各項工作，當時間和品質沖突時，時間要服從品質。
- 事先定義好産品的品質标準，隻有有了品質标準，才能根據測試的結果，對産品的品質進行分析和評估。
- 軟體項目一啟動，軟體測試也就是開始，而不是等程式寫完，才開始進行測試。
- 窮舉測試是不可能的。甚至一個大小适度的程式，其路徑排列的數量也非常大，是以，在測試中不可能運作路徑的每一種組合。
- 第三方進行測試會更客觀，更有效。
- 軟體測試計劃是做好軟體測試工作的前提。
- 測試用例是設計出來的，不是寫出來的，是以要根據測試的目的，采用相應的方法去設計測試用例，進而提高測試的效率，更多地發現錯誤，提高程式的可靠性。
- 對發現錯誤較多的程式段，應進行更深入的測試。一般來說，一段程式中已發現的錯誤數越多，其中存在的錯誤機率也就越大。
- 重視文檔，妥善儲存一切測試過程文檔（測試計劃、測試用例、測試報告等）
- 應當把“盡早和不斷地測試”作為測試人員的座右銘
- 回歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象并不少見
- 測試應從“小規模”開始，逐漸轉向“大規模”。
- 不可将測試用例置之度外，排除随意性。
- 必須徹底檢查每一個測試結果。
- 一定要注意測試中的錯誤集中發生現象，這和程式員的程式設計水準和習慣有很大的關系
- 對測試錯誤結果一定要有一個确認的過程。
3.4 測試方法
- 黑盒子和白盒子
- 靜态的和動态的
- 文檔、代碼審查
- 資料輸入邊界條件法
- 等價劃分、資料流程圖
- 狀态變換圖
- 邏輯路徑法
3.4.1 黑盒子和白盒子
功能測試和資料驅動測試
結構測試和邏輯驅動測試
3.4.2 靜态的和動态的
3.4.3 自動測試和手動測試
3.5 驗證與确認（V&V）
Verification：Are we building the product right？
是否正确地構造了軟體？即是否正确地做事，驗證開發過程是否遵守已定義好的内容。驗證産品滿足規格設計說明書的一緻性
Validation： Are we building the right product? 是否構造了正是使用者所需要的軟體？即是否正在做正确的事。驗證産品所實作的功能是否滿足使用者的需求
4.軟體測試的分類與階段
4.1 生命周期如下圖：
4.2 軟體測試分類
4.3 軟體測試階段
4.3.1 測試階段（SDLC)
4.3.2 單元測試
單元測試的對象是程式系統中的最小單元---子產品或元件上，在編碼階段進行，針對每個子產品進行測試，主要通過白盒測試方法，從程式的内部結構出發設計測試用例，檢查程式子產品或元件的已實作的功能與定義的功能是否一緻、以及編碼中是否存在錯誤。多個子產品可以平行地、對立地測試，通常要編寫驅動子產品和樁子產品
單元測試一般由程式設計人員和測試人員共同完成
4.3.3 內建測試
內建測試，也稱組裝測試、聯合測試、子系統測試，在單元測試的基礎上，将子產品按照設計要求組裝起來同時進行測試，主要目标是發現與接口有關的子產品之間問題
兩種內建方式：一次性內建方式和增殖式內建方式。
4.3.4 功能測試
功能測試一般須在完成內建測試後進行，而且是針對應用系統進行測試。功能測試是基于産品功能說明書，是在已知産品所應具有的功能，從使用者角度來進行功能驗證，以确認每個功能是否都能正常使用
4.3.5 系統測試
系統測試是将軟體放在整個計算機環境下，包括軟硬體平台、某些支援軟體、資料和人員等，在實際運作環境下進行一系列的測試，包括恢複測試、安全測試、強度測試和性能測試等
4.3.6 驗收測試 &安裝測試
驗收測試的目的是向未來的使用者表明系統能夠像預定要求那樣工作，驗證軟體的功能和性能如同使用者所合理期待的那樣
安裝測試是指按照軟體産品安裝手冊或相應的文檔，在一個和使用者使用該産品完全一樣的環境中或相當于使用者使用環境中，進行一步一步的安裝操作性的測試
5. 軟體測試的工作範疇