# NTU Software Testing Notes
###### tags: `NTU_ST` `Software Testing`
**All content in this presentation is refer to [Pro. Farn Wang Website](http://cc.ee.ntu.edu.tw/~farn/courses/ST/2021.Spring/)**

:::spoiler Click to open TOC
[TOC]
:::

# 2.5 Graph Coverage for Specifications
## Design Spec.
* What is design specification?
* 描述軟體應該有的行為(可見或不可見都有可能)
* What is different between requirement and specification
* requirement: 顧客端 / specification: 技術端
* Sequence就是一連串的行為和狀態->script
* Testing就是在看script有發生該發生的事情
* Two types of description are used in this chapter
* **Sequencing constraints**
* **State behavior**

## Sequencing constraints
* Constraint有可能是document的一些潛規則或是method上順序的限制，e.g. stack data structure在沒有push前不能pop
* Queue Example: precondiction就是這個例子的sequence constraint
* File ADT Example
* ADT: Abstract Data Type其實就是早期的class
* sequence constraint about example
1. 寫之前要先打開file
2. 關閉之前要先打開file
3. 在close file之後除非再open file，不然不可以write file
4. close file前一定要write file，不然就浪費這個procedure
* Static Checking: 先不跑test input，先針對畫出來的graph做checking
* [1, 3, 4, 6]就是這個instance的open到close之間沒有任何的write procedure
* Edge[1, 3]和Edge[3, 4]可能有共同變數在控制file的read、write，讓file不會經過Edge-Pair[1, 3, 4]->實際上會不會發生還是要看中間的邏輯
* Testing的目的是要找出所有可能會違反test constraint或其他條件使software不正常運作

* Test Requirements for FileADT
1. 有write但沒open
2. 有close但沒open
3. close當中再包含write
4. close-open中無任何write
* 如果program的設計與邏輯都正確，所有test requirements都**不可執行**

## State behavior
* FSM: finite state machine(有限狀態機)是個用來描述軟體狀態在執行時變換的圖
* FSM不太適合用在狀態很多的program
* **Nodes**: States / **Edges**: Transitions
* FSM Example
* 上圖是指海上熱帶氣旋和颱風之間的關係
* 列在FSM的變數，都是會影響state轉換的variable
* Application
* **Embedded** System and control software
* **Abstract data types**
* **Compiler** and operating systems
* **Web** application
* **Language** for describing FSM
* UML Statecharts: 比較複雜，因為state中還可以再包state
* Automata: 和FSM最相關
* State tables(SCR)
* Petri nets: 和FSM有很多差異
* Annotations on FSM
* **Precondition**是trigger action的前置條件
* 實際**trigger action**的是triggering event
* Coverage FSM
* **Node Coverage**:執行每個state
* **Edge Coverage**:執行每個transition
* **Edge-Pair Coverage**:執行每個transition-pair
* **Data flow**
* How to derive FSM?
* 由一些document可以幫助tester更快的建立FSM，e.g. system requirement, transition table, UML model
1. **Combining** control flow graphs(CFGs)
* **不是準確描述系統的FSM**，因為CFG只是把流程connect在一起，但沒辦法表現出caller和callee之間的關係
* 以CFG而言，可以建立如上圖(分開的狀態)，但是第6, 8, 10都可能呼叫change time method，而return時又要返回6, 8, 10的哪一個呢?相關的資訊並不會被記錄在node中
2. Using the **software structures**
* 以method當作一個node
3. Modeling **state variables**
* 只要有state variable就有機會可以實踐這個方法
* 
* 
* 因為watch, stopwatch和alarm這三者互相獨立，所以只需要9種狀態
* 
5. Using implicit or explicit **specifications**
* Explicit requirement
* Using intuition and experience when no explicit requirement
* Summary-Tradeoffs in Applying Graph Coverage Criteria to FSMs
* **Pros**
* 在實作**之前**就可以先設計testing
* 分析FSMs比分析source code容易很多
* **Cons**
* 一些實施決策沒有辦法在FSM中建構出模型->複雜的program(有太多的狀態)
* 由於推導FSM時會有一些主觀性質，造成結果存在一些差異
* 測試必須“映射”到程序的實際輸入，出現在FSM中的名稱可能與程序中的名稱不同

# 2.6 Graph Coverage for Use Cases
* UML Use Cases: 就是各式的結構、圖形、邏輯等整合在一起，讓學界及業界在開發同一份project可以更無縫的整合，支援的IDE有Visual Studio->由diagram產生C#、Java等template或是反過來也可以
* Pros: 節省開發時間(原本是畫出diagram後還要依照requirement再寫出程式->2倍時間)，且如果implement時發現有東西要修改，大部分的programmer都會直接修改code而忽略修改diagram，到最後design和implementation做的事情就會越來越遠，不利於公司的QA
* Graph in UML - supporting many dagram styles
* Structure diagram
* component diagram
* class diagram
* Behavior diagram
* activity diagrams
* use case diagrams
* statecharts
* Interaction diagram
* sequences diagram
* communication diagram
* Use Case: 系統操作的各種情境，或者說使用案例
* Use Case Example
* 人的symbol代表一個role
* 橢圓形的內容就是Use Cases
* Elaboration: 利用附屬文件產生更詳細的model
* **Use Case Name**
* **Summary**: 對於project整體的總結
* **Actor**
* **Precondition**
* **Description**: 正常操作的細節
* **Alternatives**: 步驟出現例外情況(catch & exception)
* **Postcondition**: 當use case結束之後，應該有的狀態是甚麼
* Use Case to Activity Diagrams: activity diagram約等於CFG，就是從user requirement中操作的step
* Covering Activity Graphs
* **Node Coverage**
* **Edge Coverage**
* **Scenario Testing**
* Summary of Use Case Testing
* Use cases定義在**requirement** level
* Very **high level**
* UML **Activity Diagrams**在圖中encode use cases
* 圖通常具有相當**簡單的結構**
* **Requirement-based** testing可以使用graph coverage
* 直接用手做
* Specified path coverage對這些圖有意義