系統設計與回歸測試
關於 從 #回歸測試 到 #系統設計方法 概念
#案例窮舉 #排列組合 #LeetCode
刷 leetcode 的時候
通常是透過 test cases 通過的完成度
代表是否完成一個題目
這背後其實代表一件事：
對一段邏輯 (不管叫演算法 / Function / Method)
先不管裡面的運算是怎麼算, 時間或空間複雜度,
首先要思考的是, 使用情境的 #排列組合
等於要有個方法可以 #窮舉 所有的情境
不然邏輯寫出來了
但不知道怎麼測
後面這個把測試案例列舉出來
是很多工程師做不到的
大部分只列得出 happy path ...
要展開其他排列組合 就比較少看到有人做得好
這就變成演算法寫的很好
但案例太少 只能淪為紙上自嗨
然後我隨便踩一下就炸了 XD
之前在引導同仁設計的時候
經常會用矩陣思考
步驟大概是
- 先列出幾個案例 A / B / C ... etc
- 從案例中找出找出相關的變因
- 從變因中分析出同類型的因素
- 依照變因, 定義 X 軸, Y 軸
- 把 案例 A / B / C 放到矩陣
- 展開 A / B / C 以外的案例
到這裡, 是才看清所有案例的 #可能性
當矩陣式 9 x 9
那就是有 81 種可能性
但是實際上真實情使用情境可能只會用到 1/3, 1/4 ... etc
其他的都只是邏輯的可能
但沒有實質意義
我這段分析方法過程
最難的就是定義 X / Y 軸
有時候過程會發現 有五六個軸
或者 X / Y 軸有 #子軸 XA / XB / XC ...; YA / YB / YC ...
這時候的排列組合的數量會非常驚人
但這就是實際上在 #設計分析 過程必要的
也就是我們要比使用者看到更多
然後透過業務需求
決定哪一些先做
哪一些後做
那一些不用做
這段過程通常會在 2 -> 5 一直循環
因為有時候 X / Y 會定義錯誤
然後重新排列組合
這讓我想起數學的矩陣運算 ...
我這個方法的例子
就是去年上市的 #薩爾達傳說 - #王國之類
遊戲中的各種道具 (武器 / 防具 / 物品)
都可以透過 #餘料建造 產生組合
而武器就是一個軸，彼此之間可以相互組合
假設武器的數量有 N 個，那就是有 N x N 個排列組合
道具還有防具 (M), 物品 (Q) 個
那麼排列組合就會有 N x M x Q 個
成法就是 餘料建造 這個功能
每個道具都還有 X 個角度可以轉
排列組合又更多了
這個數字則是開發團隊必須要測試過的
也就是實際上要執行的測試項目
上述都還沒討論
每個道具的物理與化學屬性
如何實作
會有這樣的思維
是以前在做測試計畫時
經常要思考的就是這個窮舉的方法
這個過程在 #回歸測試 (Regression Test)
需要知道的大盤
無法掌握 基本上就沒有辦法說這個回歸測試是足夠的
文章有列舉一些從 #整合測試 的角度來窮舉排列組合的複雜度
不要來 diss 裡面的公式對不對
我更多是想表達複雜度而已 XDDD
從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test
原始資料
- 發表時間：2024/09/20
- 原文連結