簡介軟體系統測試(含系統測試報告書撰寫說明)

1. 蘇維宗, PMP
資訊工程學系
真理大學
1

2. 日期 版本 負責人 說明
9/7/2016 V1.0 蘇維宗 105年度科技部計畫版本
2

3. 成大資工郭淑美教授，”How to Develop Project Documents”
網路搜尋「Guru99 Software Testing」
Glenford J. Myers，”The Art of Software Testing”
3

4. 軟體系統測試簡介
 軟體測試的重要性
 軟體測試的原則
 軟體測試的型態
 軟體系統開發流程
 軟體系統測試模型
系統測試報告書撰寫說明
4

5. 5

6. 軟體測試是以有限的資源在遞交前找出錯誤的過程。
軟體測試的重要性?
6
1994年中華航空名古屋空難264死
(來源: http://tw.gigacircle.com/1095392-1)
1999年火星氣候探測車直接衝撞
火星表面解體損失8000萬英鎊
(來源: http://www.visionlearning.com/blog/2012/09/21/
tragedies-in-science-the-crash-of-the-mars-climate-orbiter/)

7. 測試只能證明軟體存在錯誤
測試無法證明軟體不存在錯誤
窮舉測試(Exhaustive Testing)在有限的資源下無法達成
多數錯誤出現在少數模組(Pareto Principle)
測試案例必須定期審視(Pesticide Paradox)
測試方式與軟體特性有關
越早測試越好
7

8. 測試應該由獨立第三方來進行(來源: 郭淑美教授投影片)
8

9. 所有的測試應該能夠被追溯到客戶需求(不多、不少、剛剛好)
9

10. 白箱測試(Programmer) 黑箱測試(Tester)
10

11. 功能性測試
 測試軟體是否符合其功能性需求，例如
 LO-001 使用者可以透過正確的帳號、密碼來登入系統
非功能性測試
 測試軟體是否符合其非功能性需求(效能測試、相容性測試、壓力
測試…)，例如
 LO-003 同時間支援至少1,000個使用者上線，且系統需在7秒內回應
11

12. 需求(Requirements)
設計(Design)
開發(Code)
測試(Test)
維護(Maintenance)
如何提早發現錯誤?
12
0
10
20
30
40
50
60
…
100
Requirements Design Code System Test Maintenance
Phase Error Found & Fixed
CosttoFix
$1
$5
$20
$50
$100+

13. CMMI流程領域
 驗證(Verification)
 The purpose of Verification is to assure that selected work
products meet their specified requirements
 確認(Validation)
 The product or product components are validated to ensure that
they are suitable for use in their intended operating environment.
例如，
 需求規格書、專案計畫、系統設計等工作產品都需要被驗證
13

14. 子系統整合
測試計畫書
系統整合
測試
系統接受
測試
子系統整合
測試
Service系統
維護
測試階段
分析階段
需求發展 系統規格書
系統接受
測試計畫書
系統整合
測試計畫書
系統設計 細部設計
設計階段
模組與
單元測試
開發階段
14

15. Banking System (BS 1.0)
 Login (LO 1.1)
 Balance (BA 1.2)
 Deposit (DE 1.3)
 Withdraw (WI 1.4)
 Transfer (TR 1.5)
15
Login
Balance
Deposit Withdraw Transfer

16. 測試單一軟體系統元件之運作是否正確
 Interface
 Local data structures
 Boundary condition
 Independent paths
 Error handling paths
建議利用工具進行自動化測試
 JUnit、CUnit、…
16
Balance
Method 1
Method 2
Method 3
…

17. 測試一組相關的軟體系統元件之運作是否正確
測試方法
 Big-Bang
 Incremental testing
 Top-down
 Bottom-up
 Sandwich
17

18. Big-Bang整合測試
缺點
 需要等所有模組開發完成
 需要花費時間
 不容易追蹤錯誤的原因
18
Test
BS 1.0
Test
LO 1.1
Test
BA 1.2
Test
DE 1.3
Test
WI 1.4
Test
TR 1.5

19. Incremental整合測試(整合順序與開發時程有關)
19
Login
Balance
Incremental Testing 1
Login
Balance
Deposi
Incremental Testing 2
Login
Balance
Deposit Withdraw
Incremental Testing 3
Login
Balance
Deposit Withdraw Transfer
Incremental Testing 4

20. Incremental整合測試(如果其他模組還沒開發完成)
20
Login
Balance
(Stub)
Deposit Withdraw Transfer
Top-Down Integration
Login
(Driver)
Balance
Deposit Withdraw Transfer
Bottom-Up Integration

21. 測試軟體系統在其指定的運行環境中之運作是否正確
 Alpha testing
 Beta testing
21
Developer Site User Site
Software
Developer Site User Site
Software

22. 22

23.  版本(Revision History)
 測試範圍(Scope of Testing)
 接受準則(Acceptance Criteria)
 測試環境(Testing Environment)
 測試時程、程序、與責任(Testing Schedule, Procedure, and Responsibility)
 測試案例(Test Cases)
 測試結果與分析(Test Result and Analysis)
 追溯表(Traceability Matrix)
23

24. 確保共用文件的正確性
24
修改日期 版本 文件狀態 描述 負責人
2010/10/31 0.1 Draft 整合測試案例 蘇維宗
2010/12/7 1.0 Release 新增效能測試案例 蘇維宗
… … … … …

25. 本文件主要是描述銀行系統(Banking System)內容將依據系統
需求規格書與系統設計文件，描述關於整合測試的相關計畫與
內容。在確認本系統整合前，必須先確認所有的設計之子系統
均能正確無誤的運作，因此著重於系統整合測試(Integration
Testing)與接受測試(Acceptance Testing)，並透過此文件之描
述與實踐，達到順利進行測試工作之目的。
25

26. 本測試計劃需要滿足下列的測試接受準則：
 本系統需要對所有列為必要(Critical、Important、Desirable)之需
求作完整測試。(註: 針對不同等級的測試可能會有不同的準則)
 測試程序需要依照本測試計畫所訂定的程序進行，所有測試結果
需要能符合預期測試結果方能接受。
 以測試案例為單位，當測試未通過時，需要進行該單元的測試，
其接受的準則與前一項規定相同。
26

27. 對於本系統進行系統測試的環境說明，請參考測試環境圖
27
Ethernet
Ethernet
BS 1.0Client
Ethernet
1 Gbps Switch
Database

28. 伺服器規格
 硬體規格
 At least 2 GHz processor
 At least 1GB RAM
 At least 600MB of free disk
space after OS has been
installed
 軟體規格
 Windows Server 2008 R2
 SQL Server 2012
客戶端規格
 硬體規格
 At least 1 GHz processor
 At least 1 GB of RAM
 軟體規格
 支援Chrome、Firefox、與IE
28

29.  根據專案執行規劃書計畫書，測試時程100年12月起至101年6月止，詳
細時程說明如下。
 時程
 各子系統之內部元件整合測試(100/5/1 ~ 101/5/11)
 系統功能測試(100/5/14 ~ 100/5/25)
 系統效能測試(101/5/28 ~ 101/5/31)
 查核點
 各子系統之內部元件整合測試(101/5/11)
 系統功能測試(100/5/31)
 系統效能測試(101/5/31)
29

30. Incremental整合測試(整合順序與開發時程有關)
30
Login
Balance
Incremental Testing 1
Login
Balance
Deposi
Incremental Testing 2
Login
Balance
Deposit Withdraw
Incremental Testing 3
Login
Balance
Deposit Withdraw Transfer
Incremental Testing 4

31. 人員職責分配
31
Testing Cases Personnel
FT1 吳孫銘、李尚恩(紀錄)
FT2 吳孫銘、李尚恩(紀錄)
FT3 吳孫銘、李尚恩(紀錄)
… …
PT1 吳孫銘、李尚恩(紀錄)
PT2 黃傑翔、高肇億(紀錄)
… …

32. 測試案例(以能涵蓋所有客戶需求為原則)
32
Identification
Name
Requirement number
Severity
Test data
Preconditions
Steps
Expected result
Post Conditions

33. 測試情境(需求/設計階段)
測試案例(設計/開發階段)
33
檢查登入功能是否正常
FT1
使用正確的帳號密碼登入後
會進入帳戶餘額畫面
FT2
使用錯誤的帳號密碼登入後
會顯示登入失敗
PT1
同時間能讓1,000個使用者登入，且
反應時間在7秒以內
…

34. 34
Identification FT1
Name 輸入正確的帳號密碼登入後進入帳戶餘額畫面
Requirement number LO-001, BA-001
Severity Critical
Test data
1. 帳號: user1, 密碼: pass1, 帳戶餘額: 1000
2. 帳號: user2, 密碼: pass2, 帳戶餘額:500
Preconditions 資料庫中必須包含兩筆帳號資料
Steps
1. 開啟網頁登入畫面
2. 輸入第1組帳號密碼進入帳戶餘額畫面並顯示餘額為1000
3. 登出
4. 輸入第2組帳號密碼進入帳戶餘額畫面並顯示餘額為500
5. 登出
Expected result 登入後能正確顯示帳戶餘額
Post Conditions 登入的日期時間必須被記錄

35. 功能測試
效能測試
35
Test Case Result (Pass / Fail) Comment
FT1 Pass
FT2 Fail 輸入空白帳號會導致系統錯誤
FT3 Pass
… …
Rate 95%
Test Case Expected Result Test Result Comment
PT1 1,000使用者同時上線 1,000使用者同時上線
PT2 10 seconds 3 ~ 12 seconds 當同時超過800人上線時可
能會超過10秒
… … …

36. 測試原則: 所有的測試應該能夠被追溯到客戶需求
36
Test Cases
Requirement
FT1 FT2 FT3 … PT1 PT2 PT3 …
LO-001 V …
LO-002 V …
LO-003 V V …
BA-001 V …
… … … … … … … … …

37. 需求變更
 LO-001 使用者可以透過正確的帳號、密碼、驗證碼來登入系統
37
Test Cases
Requirement
FT1 FT2 FT3 … PT1 PT2 PT3 …
LO-001 V …
LO-002 V …
LO-003 V V …
BA-001 V …
… … … … … … … … …

38. 38