1. 軟體質量和軟體測試的含義

1.1 軟體質量的內涵

軟體質量是客戶滿意度的體現

質量是系統、部件或過程滿足

1. 明確需求
2. 客戶或使用者需要或期望的程度不同      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.  以檢測為重：產品製成之後進行檢測，只能判斷產品質量，不能提高產品質量。
2.  以過程管理為重：把質量的保證工作重點放在過程管理上，對製造過程 中的每一道工序都要進行質量控制。
3.  以新產品開發為重：在新產品的開發設計階段，採取強有力的措施來消滅由於設計原因而產生的質量隱患。

1.9.2  全面質量管理
TQM = Total Quality Management 全面質量管理

•   TQM是為了能夠在最經濟的水平上，並考慮到充分滿足使用者要求的條件下進行市場研究、設計、生產和服務，把企業內各部門研製質量、維持質量和提高質量的活動構成為一體的一種有效體系
•  TQM內容: 

1.   全員參與質量管理
2.  全過程質量管理。

•  TQM的4個關鍵要素:

1. 關注客戶
2. 過程改進
3. 質量的人性化因素
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  軟體測試的原則

1. 所有測試的標準都是建立在使用者需求之上。
2. 軟體測試必須基於“質量第一”的思想去開展各項工作，當時間和質量衝突時，時間要服從質量。
3. 事先定義好產品的質量標準，只有有了質量標準，才能根據測試的結果，對產品的質量進行分析和評估。
4. 軟體專案一啟動，軟體測試也就是開始，而不是等程式寫完，才開始進行測試。
5. 窮舉測試是不可能的。甚至一個大小適度的程式，其路徑排列的數量也非常大，因此，在測試中不可能執行路徑的每一種組合。 
6. 第三方進行測試會更客觀，更有效。
7. 軟體測試計劃是做好軟體測試工作的前提。
8. 測試用例是設計出來的，不是寫出來的，所以要根據測試的目的，採用相應的方法去設計測試用例，從而提高測試的效率，更多地發現錯誤，提高程式的可靠性。
9. 對發現錯誤較多的程式段，應進行更深入的測試。一般來說，一段程式中已發現的錯誤數越多，其中存在的錯誤概率也就越大。
10. 重視文件，妥善儲存一切測試過程文件（測試計劃、測試用例、測試報告等）
11.  應當把“儘早和不斷地測試”作為測試人員的座右銘
12.  迴歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現的現象並不少見
13.  測試應從“小規模”開始，逐步轉向“大規模”。
14.  不可將測試用例置之度外，排除隨意性。
15.  必須徹底檢查每一個測試結果。
16.  一定要注意測試中的錯誤集中發生現象，這和程式設計師的程式設計水平和習慣有很大的關係
17.  對測試錯誤結果一定要有一個確認的過程。

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.  軟體測試的工作範疇