Eric Hu's Weblog : Test

Internationalization Testing Reference

zheyehu — Tue, 30 Jun 2009 23:59:00 GMT

之前曾經簡單的介紹過 Internationalization Testing. 大致講了一下 Globalization, Localizability 和 Localization 有什麼不一樣. 如果要實際對軟體做完整的國際化測試, 我建議先從這篇 MSDN 上的文章開始: Testing for World-Readiness Overview. 這篇文章裏針對測試順序及內容都有較詳細的說明.

大致上, 國際化測試的先後順序是 Globalization -> Localizability -> Localization, 而這三者的執行時期可以有部分互相重疊以期儘早執行所有測試工作. 這樣的測試順序是因為配合軟體 Localization 的程序. 大體上要把一個軟體 Localize 成為數種不同的語言版本, 首先要知道有那些字串是需要被翻譯的, 所以理想上要達到近乎 Code Complete 的階段才能開始進行 Localization 的工作. 所以 Localization 測試會最慢開始. 至於 Globalization 測試和 Localizability 測試則可以在更早的階段開始. 測試員甚至可以參與 Code Review, 或進行 WhiteBox testing 來及早發現程式碼本身對 Globalization 和 Localizability 的支援的瑕疵. 這些都可以在遠早於 Code Complete 的階段就開始執行. 另一個決定這樣測試順序的原因是如果軟體被設定成只能執行在某種特定語言的環境, 就根本不用考慮 Localize 成其它語言的狀況, 自然也不用考慮 Localizability 的問題了. 所以 Globalization 總是第一個開始執行的國際化測試工作.

User Scenarios and Test Case

zheyehu — Tue, 30 Jun 2009 20:52:00 GMT

軟體測試工程師和軟體品質有直接的關係. 但在我前幾篇的文章中一直重複述說軟體測試工程師的工作其實沒辦法直接確保品質. 也就是說, 測試和品保基本上並不相同. 簡單說, 測試結果顯示軟體的功能和規格相符, 達到發行團隊設定的可發行標準, 並不表示軟體的品質符合客戶的期待. 一個品質好的產品, 並不一定說亳無瑕疵, 而一個瑕疵不多的產品, 也不一定品質就很好. 一個產品如果沒辦法讓客戶覺得好用, 愛用, 就算沒有什麼 BUG, 客戶一樣不會覺得這是一個品質好的產品.

所以我們回頭看軟體測試最基本的測試案例, Test Case, 其實也就不一定能確保一個產品達到高品質的水準. 重點還在於使用者情節, User Sceanrio, 的收集和設定. 這就有賴和客戶有最直接接觸的PM們的努力了.

所以, Test Case 的撰寫, 除了根據技術規格書, 還會仰賴PM們設定的 User Scenario. 如果 User Scenario 一開始的設定就有問題, 那測試工作做的再好, Test Case 寫的再詳細, 也沒辦法保證客戶會滿意產品的品質.

Test Complete?

zheyehu — Fri, 12 Jun 2009 00:18:00 GMT

很多人應該都有聽過 "code compelete". 在 Wikipedia 上, "Code complete" 可以是軟體開發周期的一個階段, 指的是開發團隊同意不再增加全新的程式碼到這個發行版本; 或者是有名的軟體開發書: Code Complete. (目前出到第二版).

那對測試而言, 有沒有 "Test Complete" 這個階段? 我的答案是 Yes or No. 測試團隊要簽核 (sign-off), 軟體才能發行給客戶, 而要簽核, 一定必需要完成某種程度的測試工作, 發行團隊才能根據測試團隊的簽核來評估軟體品質是否達到發行的目標. 所以在軟體發行前, 有很多測試工作必需要 "Complete". 但是完成這些工作, 是不是就是 "Test Complete"? 嚴格來說並不是, 測試工作還是可以繼續進行. 除非發行團隊已經決定不再有下一個版本, 也不會有後續的 Service 的工作, 但就算如此, 也不代表測試就 "Complete", 只是不再做了. 不再做不一定是 "Complete".

看到這裏, 格友或許會問, 那軟體發行後, 還需要進行什麼測試工作? 我認為要看情況. 例如, 我們可能要做 Visaul Studio 2008 在 Windows 7 上的相容性測試. Visaul Studio 2008 是已發行的軟體, 但當發行時並沒有 Windows 7 可供測試所以現在我們要進行相容性測試. 當然, 也有一種可能性是測試發行前沒有被包含的案例, 例如發行後客戶回報的使用性問題或缺失.

簡單說, 對 Developer 而言, 在這個發行版本中, 所有的程式碼總有寫完的時候, 但對 Tester 而言, 就算測試工作已經讓我們有足夠的信心 Sign Off, 也還是很有可能必需再繼續做測試, 而且幾乎不可能宣稱所有可做的測試都 "Complete". 舉個簡單的例子, 一個使用者介面上有顯示生日日期的BOX, 有接受, 取消, 兩個按鍵, 還有三個Radio Button 可以選擇國曆, 陰曆, 或西元. 這樣會有多少種日期表現形式的選擇? 還要考慮閏年, 陰曆的閏月, 等等. 隨便一年都有上千個不同的日子可以測 (365 X 3). 當然真的執行測試工作時一定會將所以資料分門別類, 用各種手段來涵蓋各種可能性, 例如 Equivalence Partitioning Testing, Combinatorial Analysis, Boundary Testing...等等, 不會真的把 365 天每天都拿來測一遍, 但我們可以從上面這個簡單的例子中看到, 一個簡單的軟體要處理的使用者案例數目就很大了, 更遑論那些很複雜的專案和商業軟體.

所以當下次客戶回報 Bug 時, 先不要急著找 Tester 算帳, 重點先看是不是整個 Engineering Process 有問題, 為什麼產生這樣的漏洞, 規格文件有沒有涵蓋這樣的使用者案例, 然後做出持續改進才能真正解決問題.

For Newbies - Part II

zheyehu — Wed, 10 Jun 2009 09:24:00 GMT

之前寫過一篇給新手想選擇軟體測試工程師的文章. 對軟體測試工程師的工作做了一點很簡單的介紹希望能破除一些誤解多讓一些有志之士加入軟體測試的行列, 但內容有點過於簡單, 所以再補一篇. 不過這次我想直接介紹軟體測試界的大師, James Whittaker, 的文章 -- Testing sucks!

嗯, 好吧, 那就表示測試很無聊? 所以不要做測試工程師了...如果你有這樣的結論, 那你一定沒有真的點過去好好拜讀大師的文章, 老師在講你沒有在聽...其實 Dr. James Whittaker 是一個很愛開玩笑的人, 他下這個標題只是要引起讀者的注意而已. 他真正的意思是, 執行 Test Cases, 報告 Bug, 其實是測試工作中最無趣的部分, 而測試工程師應該把大部分的時間和精力放在有趣的部分 -- "strategy, deciding what to test and how to combine multiple features and environmental consideration in a single test". 我強力推薦大家點上面的連結過去細讀.

不過比較另人難過的是, 大師最近離開微軟公司了, 所以他在 MSDN 上的部落格也不會再更新了. 他的新書付梓了, 希望能早日拜讀他的新書.

Bug and Tester’s Responsibility

zheyehu — Mon, 08 Jun 2009 18:45:00 GMT

近幾年陸續看到一種新的”軟體測試外包”方式: 外包給社群的測試工程師測試. 簡單的說, 就是有一些公司, 提供一個平台仲介全世界的測試工程師社群和需要測試服務的客戶. 由客戶提出測試的需求, 讓測試工程師自己選擇要不要接這個CASE, 計價方式是算BUG 和TEST SCRIPT 的數量.

這就出現幾個有趣的問題: BUG 有重要的和不重要的. 不重要可以不修的BUG, 或不能在這個專案時程內修掉且不影響專案發行的BUG, 客戶要付錢嗎? 如果要, 要算多少錢? SHIPSTOPPER 和這種”可忽略”的BUG的價錢是否相同? 如果沒有找到 BUG, 也沒有提供新的 TEST SCRIPT, 客戶就不用付錢. 但就算測試工程師真的找不到 BUG (或沒有一定要修的 BUG), 難道就表示這個測試工程師沒有做好工作所以不可以有收入?

要討論這些問題, 首先要想一下所謂 Software Test Engineer, 或更廣泛的稱呼, Software Tester, 的工作職責是什麼. 這些提供測試社群平台的公司宣稱利用這種平台, 客戶甚至可以完全不用有自己的測試團隊 (我這裏指的”自己的測試團隊”, 包括自己公司的正式員工, 和自己外包給專門提供測試服務的公司或個人, 但不包括這種測試社群的服務), 但這真的可行嗎?

由這種公司的商業模式, 我們可以簡單的認為, 如果所有測試真的可以透過這樣的方式完成, 那測試工程師的工作只有兩樣, 找 BUG 和寫 TEST SCRIPT, 頂多再加上一些 USABILITY 的建議. 但事實上, 我認為測試工作不只是這樣, 尤其是找 BUG 這件事在我看來, 根本是測試工程師執行工作後所必然得到的”結果”, 而不是測試工程師執行工作的”原因”或”動機”.

如果要用簡短幾句話來講測試工程師的工作, 大致上測試工程師要負責提供資料讓發行團隊評估發行軟體的風險, 決定發行軟體的功能是否達到計畫目標, 並且要利用工程方法改進軟體開發的全部過程, 減少缺失產生的可能性. 如此看來, 一個好的測試工程師, 應該要讓軟體經過精心設計和執行測試工程後, 使其”品質”達到或超過客戶的預期, 雖然從以上的工作內容, 測試工程師並未直接”確保品質”.

所以回頭看這種外包給社群的計價方式, 其實並沒有真的針對測試工程師的主要內容計價, 這樣的”測試”工作,其實和直接把軟體開放給部份客戶"試用"沒有太大的不同. 如果測試工程師只專注於找到更多的BUG來得到收入, 也並不能真正提升軟體的品質.

Internationalization Testing

zheyehu — Fri, 23 Jan 2009 03:00:00 GMT

在國際化全球化的趨勢下, 軟體產品也愈來愈重視軟體發行國際化的相容性. 簡單說, Internationalization (I18N) Testing 大致包含三個部分: 1. Globalization. 2. Localizability. 3. Localization

1. Globalization: 著重於軟體在各種語言上運行的相容性. 也就是說軟體不論在中文, 在英文, 在日文, 應該都要可以正確運作

2. Localizability: 軟體要真正打入各種不同語言文化的市場, 就要把軟體上的使用者界面, 各種錯誤訊息, 所有使用者看的到的字串都翻成當地的語言, 但把所有字串翻譯完後常會導致軟體不能正確運作, 最常見的狀況就是程式員把呼叫字串直接硬寫到CODE裏面, 如果這時把字串在UI上翻譯成不同的語言, 呼叫不到正確的字串就會導致軟體不能正確運作

3. Localization: 當翻譯完成, 真正組建"在地化"版本的軟體後, 還要經過完整的測試方能確保所有翻譯不會導致UI的問題, 翻譯的問題...等等

說這麼多, 舉個例子. 到某知名網路地圖上查從 "Taipei, Taiwn" 到 "Taichung, Taiwan" 的 driving direction, 會發現圖上會顯示從台北一路開到台"東"去, 而不是台中. 我知道沒圖沒真相但這個地圖不是微軟的 maps.live.com 所以恕我就不貼圖分享了. 反正大家應該都猜到我在那個網站上發現這個BUG. 希望沒有外國人真的因此從台北一路開到台東還沒吃到太陽餅.

像這樣的BUG, 我個人就會把它歸到 Localization. 因為很顯然, 因為某種不知那來的黑暗力量, 台中 (Taichung) 和台東 (Taitung) 的翻譯在這家公司的地圖資料庫裏搞混了. 對了, 忘了提, 打中文去找的話, 不會看到這個BUG.

還有, 如果你沒辦法 reproduce 這個BUG, 大概是他們在很短的時間內修好這個問題了. 聽說這種線上服務都更新的很快.

Why do you want to be a software tester? For newbies or who are considering to choose this career...

zheyehu — Tue, 20 Jan 2009 03:08:00 GMT

身為軟體測試工程師, 有時和台灣一些其它從事軟體業的朋友聊起軟體測試這一行在台灣的狀況, 感覺是每個人都覺得軟體測試很重要, 但實際上從事軟體測試的人員, 或說公司在招募軟體測試工程師時, 又多是招募一些剛入行比較缺乏工作經驗, 或技術能力要求相對較低的人員, 給的薪水也比其它軟體工程師低一些. 要是上一些入口網站搜尋"軟體測試", 有些人對軟體測試的了解還有軟體測試工程師的定位還真是另人搖頭, 例如"低階", "乏味"...等等負面的字眼, 大概會因此阻擋很多有理想有抱負的年輕人進入這個行業.

個人有幸在微軟當軟體測試工程師, 並沒有感受到這些不受尊重的負面字眼發生在我的工作中, 不過既然有如上的狀況出現, 雖然沒有正確的取樣數據, 但這在台灣應該還是常見的狀況. 如果不改善, 這對軟體產業在台灣的發展絕對會有不好的影響.

我個人有時也會被問到軟體測試工程師在做什麼, 以及我為什麼要從事軟體測試, 而不是當個 DEVELOPER 或 PM, 原因其實很簡單, 因為我認為測試軟體, 不但要看懂 DEVELOPER 的程式碼, 了解整個軟體架構的設計, 還要做出計畫, 和開發團隊溝通, 並在某種程度上了解客戶的需求(雖然我認為搞懂客戶的需求其實是 PM 的責任). 最後, 還要想盡辦法去預防 BUG, 調查分析發生 BUG 成因, 並提供測試報告給軟體發行團隊評估產品發行的風險, 簡言之, 一個好的軟體測試工程師, 需要了解所有(負責領域的)開發流程的技術和流程環節, 還要利用各式各樣的工程方法來降低軟體出錯的機率, 或找到軟體的錯誤, 這其實是很有挑戰性且樂趣一點也不少於其它角色的工作.

至於究竟一個稱職的軟體測試工程師需要那些技能, 或更簡單的講, 要如何做軟體測試, 如果不怕看英文的話, 不妨參考 Bj Rollinson 的給新手的書單. 如果想多了解微軟怎麼做軟體測試, 則可以參考 How We Test Software at Microsoft 這一本書.

What is the customer impact of this bug?

zheyehu — Tue, 06 Jan 2009 10:19:00 GMT

在我之前的 POST, Tester vs QA, 中有一小段文字是說, "tester 並不負責提供 user scenarios, 那是 pm (或 ba) 的事". 可是在個人的工作經驗中, 三不五時就會被問到, "這個 BUG 的 customer imapct 是什麼?" 言下之意, 是要我, 也就是報告 BUG 的 Tester, 回答或評估這個 BUG 對客戶的影響有多大.

說實話, 有時候我還真的可以回答這個問題, 但有一個先決條件, 就是我已經有 PM (或 BA) 交給我的使用案例 (Use Case) 或情節 (Scenario) 了, 而這個 BUG 就剛好會導致使用案例失敗, 那對客戶的影響很簡單, 就是這個案例或情節掛掉, 會導致客戶沒辦法這樣使用產品.

但大多時候, 事情不會這個剛好, 而且就算剛好是掛在已經有的 CASE 或 SCENARIO, 還是有很大的機會, 當我回答了上述的答案後, 會被繼續追問, 那客戶沒辦法這樣使用產品的影響有多大?

每當遇到這種事情, 只好嘆口氣, 耐著性子回答, 這個問題不是 TESTER 能回答的, 我的工作不是去直接面對客戶和他們討論他們的需求, 這些是 PM (或 BA) 的責任, 我的工作是按照你的規格, 你的使用案例, 設計測試案例, 並不是去評估這樣做對客戶的影響有多大的.

軟體測試工師很重要, 你要成功的發行軟體產品, 或成功上線, 一定要有好的測試團隊, 但軟體測試工程師在整個開發流程中所扮演的角色, 雖然相較放DEVELOPER 來說是較貼近客戶的那一方, 並不表示 TESTER 就能代替和客戶有直接接觸的 PM 去評估一個 BUG 對客戶的影響有多大. TESTER 只能根據規格, 和從別人交付的使用案例, 來告訴決策者產品有那些 BUGS 不符合規格, 或造成那些功能達不到設計的目標, 至於評估 BUG 對客戶的影響和對產品發行或上線的風險, 則要 PM 或整個決策群們要去傷腦筋評估了.

Tester vs QA

zheyehu — Wed, 11 Jun 2008 10:57:00 GMT

上一篇談 Tester 的職責是什麼, 這一篇談另一個觀念, Tester 不應該被叫做 QA (quality assurance), 因為基本上, Tester 沒辦法真的確保 "Quality".

很奇怪? 驚世駭俗? 推卸責任? 嗯, 當然不是啦, 上一篇才講過要追查到底才算盡忠職守, 怎麼這一篇突然說 Tester 不確保 Quality, 你可能會問, 那老闆雇用你幹嘛?

這個問題, 其實要從什麼是 "Quality" 談起. 為方便中文讀者, 我暫且把它稱為品質. 首先, 我們要先想一下, 到底是誰在決定產品的品質? 是 tester 嗎? 我今天執行一個 test pass, 有 99% 的 pass rate, 還有很好的 code coverage %, 就表示我的產品品質很高嗎? 假如事情有這麼簡單, 我們就一定不會聽到有人報怨微軟產品的品質了. "有人" 報怨產品的品質, 是因為 "有人" 使用產品的經驗不好而來, 不管這個不好的經驗, 是因為 bug, 還是產品本身的 design. 而這個 "有人", 就是 customer. 所以我們可以推論, 使用經驗決定品質, 而顧客決定使用經驗的好壞, 所以顧客才能決定產品的品質到底好不好, 不是 tester.

那既然 tester 無法決定產品的品質好不好, 要 tester 幹嘛? Tester 的職責, 是提供正確資訊, 來衡量產品發行的風險. 一個好的 tester 可以利用很好的工程技術, 提供正確的資訊, 給決策單位衡量產品發生後產生問題的風險, 而這個工程技術執行的愈好, 提供的資訊愈正確, 產品"壞掉"的機會就愈小, 如果這些利用工程技術做的測試, 能涵蓋愈多使用者使用的 scenarios, 那顧客遭遇到壞的使用者經驗的風險也愈小, 但縱然如此, 我們 tester 還是無法保證品質, 因為 engineering bug 並不一定等於 user experience bug, 而 design 更不等於 bug, tester 並不負責提供 user scenarios, 那是 pm (或 ba) 的事. 所以, tester 不是 qa, 因為我們不能 assure quality. 我們的工作, 是 provide information to measure risk. 各位 pm, 下次顧客抱怨產品品質不好的時候, 先不要急著怪 tester, 品質是一種感覺, 是沒辦法真正被量化測量的東西, 所以不妨想想真正讓顧客不滿的原因, 說不定是產品的設計根本和顧客的期望不一致也不一定.

本來幾年前我剛開始我 tester 的 career 的時候, 我也以為我是 "qa", 我的終極目標就是確保品質, 直到瞭解什麼是品質後, 想法才改變. 如果你對這個問題有興趣, 或完全不認同我說的, 以下提供兩篇不同的資深 testers 的文章給大家參考. 其實我也是聽了資深 tester, Bj Rollison, 的教誨後才改變想法的.

Testing and Quality by Alan Page

Testing is not responsible for quality by Bj Rollison

關於

A Software Tester is...

zheyehu — Wed, 11 Jun 2008 10:03:00 GMT

我是個 Software Tester , 但是我突然發現, 我的 BLOG 裏的 "Test" 這個類別裏的 Post 居然沒有很多, 所以我想我應該多談談 Software Testing.

最近看了一些其它高手的部落格, 還有根據我自己的經驗, 其實, Software Tester 和 CSI 沒什麼分別, 都要根據各種蛛絲馬跡, 找到線索, 抓到兇手, 再交給法官和其它執法人員 (Developer and PM) 決定要怎樣去制裁兇手(Fix Bug or...just ignore this bug). Alan Page 在他的部落格中畫了一個 Tester 處理 bug 的流程, 在找到 bug 後, 首先要去找可能產生 bug 的原因, 然後根據這個原因, 找看看有沒有類似的 bug, 或因為這個原因產生其它的 bug, 然後看看有沒有辦法防止同樣的問題再度產生, 或利用同樣的 pattern 找到新的 bug.

而分析一個看似簡單的 bug, 走一遍以上的流程, 找到真正的原因, 修掉這個 bug 則可能會非常的複雜, 在這篇 Anatomy of a Software Bug 中, 有一個很詳細的分析 bug 和修 bug 的故事, 雖然故事不是由 tester 寫的, 但也可以反映出一個看似簡單的 bug, 要修來可能是大費周章, 甚至要找到一個很好的 repro step, 都可能不是那麼的簡單, 更不用說要找出一個 pattern!

你可能覺得真的嗎, 當 "Tester" 有這麼多事要做喔, 當然啊, 找到 bug 等於是證人的階段而已, 你覺得警察局會沒事雇用一堆人上街閒晃看有沒有刑案發生, 有的話就報警, 之後就不管了嗎? 之後還要繼續追查線索破案才算是盡忠職守, 對吧?

UI Automation Tesing?

zheyehu — Sun, 08 Jun 2008 02:21:00 GMT

做軟體測試的人, 大多會希望把所有的測試都自動化, 就算沒辦法全部 (事實上, 全部自動化在目前是不可能的...), 至少也要愈多自動化測試愈好, 畢竟, 自動化測試的好處很多, 使用得當, 絶對能大大幫助軟體測試人員的效率, 但相信大家也都發現, 在做 UI 的自動化測試, 還真是不容易. 而且常常達不到預期的效果, 為什麼會這樣? 可能的原因很多, 但 Bj (微軟公司裏一個相當資深優秀的軟體測試工程師), 在他的部落格裏這一篇, GUI Automation and ROI, 提出一個重要的觀點, UI 常會變動, 所以 Autoamtion 很難維護. 導致 COST 太高. 在這篇裏還有很多人回應了很多很有趣的觀點, 不妨一起參考.

A Story about How a "Test Case Issue" Turned to a "Product Bug"

zheyehu — Sun, 02 Dec 2007 03:39:00 GMT

剛在 MSDN 的 Tester Center 上讀到一篇有趣的文章, 大致上是敍述一個看起來是 Automation Testing 裏 Test Case 沒寫好產生的問題, 最後發現是真正嚴重的產品的 bug. 自己也曾 run 和分析 debug automation test case 所以頗有感同身受的感覺. 以下就是這篇文章的連結: Bug Story: Dig Deep

其實為了要有效率的完整測試軟體, 自動化的測試是有其必要的而且很有用的方法, 市面上也有不少提供測試者撰寫自動化測試的工具, 但其實寫軟體自動化測試的 Test Case 就和寫其它軟體產品沒什麼兩樣, 也就是說測試軟體的軟體本身, 一樣會有 bug, 一樣要經過一定的測試方法來確保品質, 要不然測試的 test case 本身就有問題, 那測試出來的結果也不會有什麼參考價值.

Tester Center on MSDN

zheyehu — Wed, 28 Nov 2007 07:54:00 GMT

不知您是否曾經想過要怎樣改進軟體品質, 或者您本身就是軟體測試工程師, 整天想著要如何才能更有效率的做測試? 您是否也好奇在微軟開發各式各樣軟體的時候是如何做測試的?

在 MSDN 上, 現在多了一個新的 Tester Center, 裏面有很多和軟體測試相關的有趣文章, 例如一些測試的觀念, practice, 或者測試工程師的工作內容等. 基本上這是一個和社群分享的資源中心, 讓所以的軟體測試工程師可以一起來分享. 我相信不只是軟體測試工程師對這裏的文章會有興趣, 對所有參與軟體開發的人員來說都會是很好的參考資料.

只是目前好像只有英文的內容: http://msdn2.microsoft.com/en-us/testing/default.aspx

還沒有看到有中文的文章. 希望以後會有中文的 Tester Center 或文章

Some known-issues of quality tools in Orcas beta1

zheyehu — Mon, 28 May 2007 07:15:00 GMT

雖然 Orcas beta1 並沒有中文版, 英文版在這個月初已經可以 download 了, 我相信應該已經開始有人 playing this beta, 所以分享一些 quality tools teams share 的 known issues 和 workarounds, 希望對遇到這些問題的人有些幫助:

Known-Issues and workarounds for Orcas (Beta1): ASP.NET

Known-Issues and workarounds for Orcas (Beta1): Inheritance

Known-Issues and workarounds for Orcas (Beta1): Device Projects

Unit Test in VS Pro

zheyehu — Mon, 23 Apr 2007 10:46:00 GMT

在 Orcas, 將 VS 2005 中只有 VSTS 才有的 unit test 放到 VS Pro 中了, 對於使用 VS Pro 開發程式的 developer, 往後做 unit test 就方便了.

但是 unit test 在 VS Pro 中和 VSTS 還是有許不同, 例如 test list 的管理就不在 VS Pro 中, 詳細的情形, 請參考下列的 blog:

Unit Testing Trickling into Pro