軟體測試原理

資料出處：軟體工程聯盟網站

Learning Objective

• 瞭解軟體測試的角色及其困難與限制
• 瞭解測試的原理以及其理論基礎
• 能區別軟體驗證所用的各種方法
• 能使用黑箱及白箱測試技術來產生測試案例
• 能使用靜態軟體驗證技術
• 能夠定義軟體測試流程

Testing Basics

How to Obtain Software Quality ?

• Quality management 品質管理
• which actions contribute and how to quality
  1. Well organized software process 妥善歸劃組織的軟體發展過程
  2. Requirements management 需求管理
  3. Design 設計
  4. Traceability 可追蹤性
  5. configuration management 組態管理
• Testing, validation, verification 測試、產品驗證、製程驗證
• Well educated people 受良好教育的人員
• Appropriate techniques and tools 適當的技術與工具
• And then: How to check that quality goals are satisfied ? 如何檢查品質目標是被滿足的？

軟體的主要特性或困難之一，就是軟體開發過程中的「不可見性」。換句話說，你不知道你所作的，是否與預期的目的一致。既然如此，要如何管理軟體的開發呢？答案是透過品質管理。通常的作法，是先做品管規劃，確認哪些行動對增加軟體品質有益，以及如何產生效益。在實行上，則透過組織完善的軟體流程規範，如需求管理、良好的設計、變更追蹤、配置管理（configuration management）等等，來執行品管計畫。此外，教育良好的員工，適當的技術和工具，也是不可少的。

What Software Testing is … ?

• Checking programs against specifications 檢查程式是否與規格有異
• Finding bugs in programs 找出程式中的臭蟲
• Determining user acceptability 決定使用者的接受度
• Insuring that a system is ready for use 確保一個系統是可以使用的
• Showing that a program performs correctly 證明一個程式執行是正確的
• Demonstrating that errors are not present 證明錯誤是不存在的
• Understanding the limits of performance 了解效能的限制
• Learning what a system is not able to do 學習一個系統不能乒的事
• Evaluating the capabilities of a system 評估一個系統的相容性

Researchers’ Definitions

• Testing is the process of executing a program or system with the intent of finding errors. (Myers) 測試的意圖是為了發現程式或系統執行時的各項錯誤。
• Testing is the process of establishing confidence that a program or system does what it supposed to. (Hetzel) 用來建立一個程式或系統是否照著寫所應該做的方式在進行的的信心之過程。
• Testing is obviously concerned with errors, faults, failures and incidents. A test is the act of exercising software with test cases with an objective of 1) finding failure 2) demonstrate correct execution (Jorgensen ) 測試關心錯誤、致命性錯誤、失常和意外狀況，一個測試是為了找出失誤並展示正確的執行，所進行的各項測試案例之演練。

Testing Scope

• Depending on the target, testing could be used in either of the following way
• 驗證（verification） 檢驗某個階段的產品發展是否符合其早先的規範，亦即建造正確的產品。
• 確認（validation） 檢驗某個開發完成的系統是否符合用戶的需求，亦即建造對的產品。

Testing Objective

• Which objective of testing a program is true 那個測試程式的目的是真的？
• To show that this program is correct? 證明程式是正確的？
• To find errors in this program? 找出這個程式裏的錯誤？ The first goal is not achievable in general and will not lead to effective testing 一般來說，第一個目的是做不到的，而且會導致無效率的測試。
• The second is not easily achieved either 第2個目標也不是容易地獲得。
• Today, the purpose of most testing is to measuring quality 今天，大部份的測試是去測量品質

Specification Vs. Programs

Test Coverage*

If there are specified behaviors for which there are no test cases, the testing is incomplete 如果有指定的行為，而其中沒有測試案例，那測試就是不完整的。

• If there are test cases that correspond to unspecified behaviors 如果當中有測試針對未指定的行為
• Either such test cases are unwarranted, or 要不是測試案例是不保證的，就是 specification is deficient 規格不是完備的
• It also implies that testers should participate in specification and design reviews 意謂著測試者應該參與規格與設計檢驗

Classification of Testing

There are three dimensions of classification

1. By means 工具
   Testing by machine (DYNAMIC testing) 動態測式 Testing by human (STATIC testing) 靜態測試
2. By target 對象
   Testing outside FUNCTION (black box) 黑箱 Testing inside STRUCTURE (white box) 白箱
3. By granularity 層級
   • UNIT level 單元層級
   • INTEGRATION level 整合層級
   • SYSTEM level 系統層級

Functional Testing

Structural Testing

Levels of Testing

• Unit testing: testing of code unit (subprogram, module, subsystem)

  • Usually requires use of test drivers

• Integration testing: testing of interfaces between integrated units

  • Incremental or “big bang”
• System testing: testing complete system for satisfaction of requirements

When to Use What

• Few set of guidelines available 沒有太多的指導時
• A possible approach could be 一個可能的方法是
  • Perform static testing as earlier as the project has generated the first deliverables 儘早地在專案產第一個產出前執行靜態測試
  • Prepare functional test cases as part of the specification to check its completeness and consistency; the test cases could be used later after units and/or the system is available. 準備功能性測試案例以作為規格文件的一個部份，以便檢視一致性與完整性，這些測試案例可以在單元或系統可用時被用上。
  • Prepare structural test cases as part of implementation/code phase. 結構性測試案例可以作為實作或程式階段的一個部份。
  • Unit, integration and system testing are performed in order but depending on the integration strategy 單元、整合和系統測試被循序地執行，只是必須根據整合策略。

Error, Fault, &Failure

• 錯誤（Error） 錯誤是人造成的。它的另一個同義詞是「失誤」（mistake）。人們在撰寫程式時，經常由於思慮不周，或者因為不小心，以致於出現了錯誤。錯誤傾向於繁殖；例如，一個與需求有關的錯誤，會在設計時被放大，然後進一步延續到編碼。
• 缺陷（Fault） 缺陷是錯誤的結果。更準確的說，缺陷是錯誤的外顯，存在於表達之中，例如文字紀錄、系統分析圖、結構設計圖、原始碼等等。「瑕疵」（defect）是它的同義詞；「臭蟲」也是。缺陷可能不容易發現，尤其是缺漏了什麼，某些東西應該存在但是卻不見了。反之，不該存在的東西卻出現了，比較容易偵測。
• 故障（Failure） 當程式執行到缺陷的位置時，故障發生。根據這樣的定義，不是所有的缺陷都會表現出故障的行為，因為故障只發生在可執行的程式碼中。其他如缺漏型的缺陷，則不在執行時才發生。或更進一步，有些缺陷只在某個特定時間才發生故障。例如，米開朗基羅病毒，在其他的日子表現完全正常，直到米開朗基羅的生日（3月6日）。
• 事件（Incident） 不是所有的故障，都有明顯的症狀或一眼可以看出。事件是故障所產生的症狀，讓用戶警覺到故障的發生。

Test Assertion & Test Case

• Test Assertion (or Test Requirement) 測試斷言
  • A statement of behavior, action, or condition that can be measured or tested. It is derived from the specification‘s requirements and provides a normative foundation from which test cases can be built 一個行為、動作或條件的敘述是可以被測量或測試的，衍生自規格的需求，並提供一個規範的基礎來建立測試案例。
• Test case
  • A triplet [I, S, O] where I is input data, S is state of system at which data will be input, and O is the expected output每個測試案例都有一個代號與測試目的（說明其程式應有的行為）。測試案例可以用三個變數來表示，其中I代表資料輸入， S是當時系統的狀態，O則是期望的產出。
  • A test case corresponds to a test purpose, which in turn maps back to the assertion(s), and finally the spec

Test Purpose & Test Suite

• Test Purpose
  • An explanation of why the test was written, and must map directly to one or more test assertions 解釋測試的理由，並且必須直接對應到一個或多個測試斷定。
• Test Suite
  • The set of all test cases (common definition) 所有測試案例的組合
  • A set of documents and tools providing tool developers with an objective methodology to verify the level of conformance of an implementation for a given standard (definition from W3C) 文件、工具組合

Example

• To test following code

  If (x>y) max = x; else max = x;
  

• This test suite {(x=3, y=2); (x=2, y=3)} is good

• But this one {(x=3, y=2); (x=4, y=3); (x=5, y = 1)} is bad

Test Case Examples

• All tests must be traceable to customer requirements.

• All tests must specify the expected results.