個體經濟學上有一個很重要的效用理論稱作＂邊際效用( Marginal Utility, MU)＂ 是一種探討如何在能找尋最大收益點的時機行動的一個理論。也因為邊際效用強調什麼時候進行資料生產可以獲得最大報酬，所以可以用在生活上很多當我們某一生產資源有限時該如何安排生產優先順序，最常見的有限生產資源就是＂時間＂，對每個人來說時間就是有限的，所以在有限的時間裡安排做什麼事可以獲得最大滿足與成果，就是我們常常面臨的問題。
這樣的問題，最簡單的解決原則就是：”從施最小力而可獲得最大收益的事情著手”，這個原則的背後原理就是＂邊際效用(MU)＂，但更精確地說，其根據的應該是”邊際效用遞減法則”。
所謂邊際效用遞減法則就是：＂當我們從事一件能帶給我們快樂或是滿足或生產成果的任務時，其滿足或成就程度會隨著我們重覆進行相同任務愈多次而慢慢遞減，直到沒有任何正面效用或效用為負為止。＂
舉個例子就是我很喜歡吃湯圓，如果一個下午我只喝一碗，那這一碗鐵定是最好喝的，然後再喝第二碗，那第二碗應該還是很好喝，只是沒有第一碗好喝，那如果後面繼續喝第三碗、第四碗、第五六七碗，每喝下一碗我就會愈覺得膩，也就是沒剛開始喝好喝，最後我會在某一碗停下不喝了，因為完全喝膩了，這時候湯圓對我的邊際效用完全是零！而如果我繼續喝喝到吐的話，那邊際效用此時就是負的，因為不但喝了不會開心，反而有害自身。
邊際效用遞減最重要的例子就是＂水＂，地球上水資源對人類最重要，也是最為豐富的資源之一，但是卻是最沒有經濟價值的(因為便宜)，這是因為水太多了導致邊際效用遞減到接近零的狀態！反而像黃金這類沒什麼實際用途的資源卻因為稀缺性而邊際效用很高，因而人人搶著要(因為可以換很多錢)。
由上可知，邊際效用大小的時機點是在一開始某一資源量還不多的時候，不管是湯圓或水，只有一碗湯圓可喝時或缺水時，我們才會覺得湯圓很好喝以及覺得水非常的珍貴。但當時間一久，有一堆湯圓及水取之不盡時，反而我們不會想再繼續享用他們，所以邊際效用最大的點就在尚未開始遞減時，也就是某個有限資源剛開始被消耗時。
好的，現在我們把邊際效用遞減應用到測試的場景上，這是我最近工作在思考的問題：因為我們產品只有兩個QA，但是每一個版本的迴歸測試至少已經累積到1000條 Test Case，重點是我們是新產品，根本沒時間和人力做自動化測試，在這種情況下每一次迴歸測試時間自然相當有限，那該如何決定Test Case 的優先測試順序？
過去最直男的策略就是：從第一條測到最後一條，但你知道的，這樣能保證迴歸測試百分之百涵蓋，但其實沒有時間這樣做！另外的策略就是挑重點測，但是這又很害怕沒測到的地方會出問題，那到底有什麼方法可以保證回歸測試的測試品質維持高檔位而又能在有限時間下完成呢？答案就是：＂邊際效用遞減法則＂。
在這邊，時間就是我們有限的資源，所以讓每一秒的測試都能盡可能獲得最大邊際效用直到在時間邊際效用為零之前完成迴歸測試就是最佳的執行策略！那現在的問題就是：如何讓每一秒的測試所獲得的邊際效用總合起來的總效用達到最高？
答案就是：從最可能出問題或變動最大的功能的Test Case 開始測，然後有剩餘時間則依次安排測試其他較穩定或變動不大的功能的Test Case，直到所有測試時間用完為止，而最後可能會留下部份Test Case 沒有做迴歸，但這部份Test Case 則是最不可能出問題也最穩定或完全沒改動到的功能案例，測試它們的邊際效用為0，在沒測試的狀態下，由於總效用與有測試時是一樣的，所以還是可以達成迴歸測試任務完成的結果。
比方產品release有10個功能模組，如果有2個是新開發模組，3個功能變動模組，3個核心業務模組，2個基本未變更模組(如：登入功能)。那測試時按照邊際效用遞減法則，就必須首先測試 新開發模組，然後是功能變動模組，因為這兩個部份等於變動最多，最容易出問題的模組，接著才是核心業務模組，但核心業務模組應該針對基本核心功能做測試以及過往常出現bug的問題點做驗證即可，剩下有時間才是測試其他模組和功能。
這邊邊際效用最大的必定是核心模組功能接受測試之前的時間部份，而後面的問題點少或未變更的基本模組功能的測試就根本沒產生多少邊際效用，也就是說：我們已經完整執行迴歸測試了，因為我們有信心會出問題的部份都有做到迴歸，而未迴歸到的Test Case，基本上也可以保證不會出問題或至少不會影響使用者對產品的使用體驗！
這就是邊際效用理論應用到有限測試時間時的分析，或許我們應該思考怎樣的測試方法不但能保證產品品質同時又能達成迴歸測試的目的，而邊際效用理論則在這方面給了QA一個不錯的方向！
2022年7月15日星期五
留言列表
