# GenAI 時代下的測試三板斧 - 柯仁傑

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

## 📚 議程介紹

{%preview https://webconf.tw/agenda/27 %}

## ▼▼▼ 開始筆記 ▼▼▼

### 大綱
* GenAI真的懂軟體測試？
* 開立測試案例的提示工程
* 利用實例化需求讓生成有共識
* 利用探索性測試＋AI快速抓錯

### GenAI真的懂軟體測試？

生成式AI
讓機器產生複雜有結構的物件。
- 文章
- 影像
- 語音

來源：李宏毅 - [【生成式 AI 導論 2024】第1講：生成式 AI 是什麼？](https://www.youtube.com/watch?v=JGtqpQXfJis)
[【生成式人工智慧與機器學習導論2025】第１講：一堂課搞懂生成式人工智慧的原理](https://www.youtube.com/watch?v=TigfpYPJk1s)

LLM 模型怎樣生出來？
- 自督導式學習
- 督導式學習
- 增強式學習

定義非常多元
- Stress Testing
the art of testing->壓力測試涉及讓程序承受重負載或壓力。在短時間內遇到的資料量峰值。
widi->通常用於了解系統容量的上限。此類測試旨在確定系統在極端負載下的 表現

- Performance testing
the art of testing -> 目的是證明程式未達到其目標
wikipedia->效能測試通常是一種測試實踐，是一種集合名詞

網路上的資料
新手練習/不完整的答案/過時的作法.

GenAI 時代的測試錯覺

PM : AI 能幫忙測品質 => 可能只是加速錯誤的流動.
開發人員：AI 能自動測試 =>可能只是 Happy path 或 ret true
測試人員：AI 幫自動生 test case =>可能只是更多檢視確認

測試三板斧:
- 利用測試知識充實提示樣板
- 利用實例化需求加強協作與共識
- 利用探索性測試 人機協作彌補自動化的不足

### 開立測試案例的提示工程

- 你是軟體測試專家,擅長XXX領域.
- 請對功能XXX開立測試案例.
- 要有正向,反向,邊界值得案例
> 這些形容詞沒用啦，效果有限，你可以繼續燒你的token但其實幫助真的不大

- 輸出格式：標題、步驟、輸入、預期結果
> 還不錯? 但要想一想,
有這些格式是可以讓輸出比較固定，對自動化有幫助
>所有AI出來的東西都要容易review，不是生出來就很雜或敘述性的格式就超級難review的。
>重點在於要容易review，例如：表格
>Given-When-Then 的格式

- 輸入部分要有具體的值, 預期結果要真的能比對出是否通過.

#### 什麼是測試個案
- IEEE Std 829-1983
>用來描述測試時，所需要的*輸入*，*預期結果*，和一連串 *執行條件* 的一份文件

- 請用Equivalence Class Testing 方法開立

Non-Functional Test
易用性測試 Usability Testing
效能測試 Performance Testing
Security Testing
Stress Test

eeee
測試方法的關係.
黑箱測試（Black-box） - Equivalence Class Testing 為例:
切出partition 來做描述。

GenAI 不懂軟體測試.
只會分'有效'跟'無效'
看太多管顧公司的文章.
你自己要review , 即時如此, 還是要review
e.g. 有沒有早鳥票/早鳥票賣完.

Prompt 要靠 軟體測試知識+領域知識 才能下的好.

for testing : 問廣問深, 不同角度的風險(測試方法 = 從不同角度看同一個風險)

### 利用實例化需求讓生成有共識

吳恩達
需求分析 架構設計 細部設計 開發 測試 結案
但架構設計到開發中間的速度變快了

重點: 我們接下來應該做什麼

2 PM + 1 Dev
將來需要：
- 會寫程式碼的產品經理
-
什麼東西會是不變的？

SDD - Spec Kit
Constitution -> Specify -> plan -> tasks -> implement

<div style="color:red; font-size:42px;"> 但是以前你說看不懂 PM 寫的文件 !!??</div>

還少這一味: BDD / SBE (Spec by Example)

---

#### Specify.md 可能的內容 + 範例

##### Problem
>使用者想要以最便宜的票價搭乘高鐵，並希望在訂票時能知>道該車次是否有早鳥折扣，以及是否還有折扣名額。

##### Rules
> 早鳥優惠僅適用於「標準車廂對號座單程全票」。
> 折扣等級有三種，優先順序為：65 折 -> 8 折 -> 9 折。售完 65 折後才賣 8 折，8 折售完後才賣 9 折，9 折售完即恢復原價。
> 折扣票數量有限，若單筆訂購多張票，必須確認「剩餘早鳥優惠座位數 ≥ 要求張數」，才能套用優惠票價，否則可能部分或全部退回原價。
> 最晚折扣票販售至「乘車日 (含) 前 5 日」為止。

##### Examples
> 使用者查詢 2025-09-01 的某列車，並發現剩餘 65 折票 -> 系統顯示該列車票價為 65 折 -> 使用者訂票成功。
> 使用者查詢 2025-09-01 的某列車，但 65 折票已售完 -> 系統顯示 8 折票剩餘 -> 若使用者訂票 -> 系統套用 8 折票價。
> 使用者查詢某列車，但早鳥折扣票數已售完 (65 / 8 / 9 均售完) -> 系統標示為「原價票」並售出原價票。
> 使用者欲訂購兩張折扣票，但系統剩餘折扣票只剩一張 -> 系統應拒絕折扣票 (或提示折扣票不足) -> 或者退回整筆訂單至原價 (依團隊需求決定)。
> 使用者查詢距離乘車日 4 天內的車票 -> 系統不得提供任何早鳥折扣、僅顯示原價票。

---

99%的人都把心力集中在自動化.
(如何對齊開發與PM的需求??)
這樣充其量只是一個新的測試自動化啊!
不是在釐清需求
你終究只是寫給自己爽而已啊

你到底寫東西是要符合需求，還是只是寫給炫技，用一些根本看不懂但很潮的新技術？

釐清需求, 是要列出你不清楚的才要列.
實例化需求, 是要寫功能性的內容, 而不是UI/流程上的操作.

利用需求制定不變的基石, 這個是需求要所有人都有共識.

The State of Software Quality Report 2025
BDD/TDD 51%

### 利用探索性測試＋AI快速抓錯

Henrik: 1天的迭代.
2 week 迭代 -> 1天迭代.
不管週期多長, 就是沒時間測試.
> 不是沒時間, 是沒習慣.

AI會補你沒說的(腦補)
e.g. 日期合不合理這件事.
AI 會想跨日怎麼算? 可接受的format = ?
還是要review

AI也會跑測試 , 每次都說通過, 到底是真的還是假的.

測試不只是檢查. Checking / Exploring


40%~60% 的bug 不是從test case找到的.
> 代表那個 QA 會不斷質疑.
AI 會做QA這種質疑嗎? NO

---
聊天室
好難記.
>感謝筆記之神

SDD 會不會很燒token ?
> 燒啊 總比燒腦好ＸＤ
修bug 要重寫spec 再跑一次.

在我的電腦上沒問題

現在就是叫ＡＩ直接產範例 會好理解很多
ＡＩ搞不懂你的意思 大概人也搞不懂ＸＤ
被人說看不懂會生氣 被ＡＩ說看不懂就不會ＸＤ