小攻城師的戰場筆記

這天第一個 section 要談的是測試概論與單元測試。雖然 VS 2005 & 2008 也都有測試的功能，但 VS 2010 增加了更多測試類型。

---------------------現場對話實錄的分隔線---------------------

「一般如果沒有專職的測試人員，都由誰來做測試？」
『PM!』
「對，因為這個時間點他最閒。XD
　那如果 PM 不測，會由誰來測？」
『User!』
「這最正確，台灣都是客戶用一用有問題寄信給你，
　那誰最不適合做測試？」
『工程師自己！』
「不錯嘛，妳很熟啊。」
『因為我就是 PM。XD』

「那剛剛那位 PM，妳們什麼時候開始測試？」
『程式寫完以後呀，我收到建構就開始測。』
「那你們開發的時間大概多久？」
『有一個禮拜也有一個月的耶。』
「那假設你們開發一個月，妳們大概會開發多久？」
『開發大約兩週，然後測試一週，沒問題就給客戶。』

---------------------對話結束的分隔線---------------------


上面的對話中隱藏了一個問題：一開始 developer 都挑簡單的 bug 修，但影響到核心的 bug 怕一改下去全都要改，所以都不動。

此外，有些 bug 不太容易透過自動測試測出問題來，比方說某政府機關網站，因為使用了 open source 的 CMS，版位與內容是流水號，有人就刻意使用不同的版位套用了其他版位中的內容，使得標題區塊與內容區塊看起來牛頭不對馬嘴。像這種問題用自動化程式很難測出，但專業的測試人員看到網址有 query string，就會手動去調整；顯然這個機關的網站在開發時，沒有配置專職的測試人員。

（我個人認為有配置也沒什麼用，因為回到上面講的──developer 都會挑簡單的 bug 改，這種東西測出來以後說不定 PM & developer 也一起睜一隻眼閉一隻眼。）



「如果測試測到問題以後，developer 修正了，那接下來會？」
『全部重測啊！』

問題來了：如果有 4000 個 test case，人家改一行你就重測一次，如果不是同一個平台或語系（假設要測 IE6~IE9 好了），實務上不太可能全部重測。所以在大型的測試流程會做 smoke test：先把基本的流程都測過，沒問題的話才進入下一階段的測試，不會做全面測試。

測試如果在期末才做測試報告，這種測試報告都是假的，因為已無法完整測試、徹底修復；屆時安全、效能、壓力、功能都無法確保。



有些大型系統，若將內容上線後才發現錯誤，損失就很大，所以很在意資訊系統的正確度。講師舉例來說：有一個賣票系統，在測試時只測了 login，沒有測完整的商業邏輯，以至於後端整個鎖死就掛點了。

測試案例應該要能夠累積、收集、整合。並且要弄清楚，到底測試案例應該怎樣才有代表性？比方說，每次 SQL server 升級時，都會辦一個舊版與新版相容的一日營，會請各家廠商帶自己的系統的錄製過來，其中有一家提供了一份很大的錄製檔，一執行就掛了，細看內容是一大堆重複的 insert。事實上，相容性是要把所有功能都執行一遍，而不是把一個功能執行很多遍，因此應該對每一個功能都列舉一兩個代表例，而不是針對一個功能，把所有想到的可能值都塞進去試玩看看。

（這讓我想到做水果的甜度檢測時把每一個蘋果都拿起來咬一口的故事……）



在 Visual Studio 設定測試：solution items -> "*.testsettings"，預設在 local.testsettings 是什麼都不測試的。

涵蓋程式行與區塊可以以視覺化的方式觀察出涵蓋率：如果測試的對象是原始碼，可以顯示出涵蓋的行數；如果測試的是 dll，則會顯示為測試的區塊；預設配色下，測試有涵蓋到的部分是淺藍色的、未涵蓋的部分是橘紅色的。

雖然不可能每一次都全部重測，但週期性的全部重測仍是必要的。

自動化測化測試：一定要先裝 TFS，才能使用 test manager，建立測試專案。測試人員要清楚描述自己的測試環境，developer 才能夠 build 相同環境、重現問題。

在使用 test manager 進行測試時，必須先連結到 TFS 建立一個 team project；一個 team project 上可以建置許多 test project。

測試案例可以在 Visual Studio 或 test Manager 新增，但其步驟無法直接在 Visual Studio 裡編輯，要在 Test Manager 才能設定。


在寫測試步驟時應該要寫每一個步驟的動作是什麼、期待的結果、實際的結果；要在 Test Manager 插入多筆步驟時，游標不可以停在 "動作" 的 cell 裡，要在外圍點一下（會顯示為選取該儲存格的虛線框），此時從 Excel 或他處複製多筆時才能夠一次貼上為多筆，否則會被貼進同一個儲存格之中。

在錄製網頁的測試時，如果不希望首頁或一些雜七雜八的東西被錄進去，可以先把環境設乾淨一點。最好不要讓雜七雜八的東西被錄進去，舉例而言，輸入帳號密碼 login 以後，瀏覽器問你要不要儲存密碼，如果你第一次有錄進去，那之後每一次重新播放這個錄製都會重播這個視窗，並且會等待你點選，以至於重播的內容就一直卡在那視窗上。

報表管理員大概每半小時收集一次資訊，所以測試完畢的結果要稍後才會送進去。



測試案例要寫到所有人都可以看得懂，並且寫得詳盡，比方說允入原則是怎樣的條件啦、怎樣才是正確結果啦，等等之類的。舉個講師在顧問案中看到的印度外包商來作為詳細與不詳細的例子，來比較一下：
    * 印度人的 test case: "開啟瀏覽器→在網址列輸入網址→按下 enter"...etc.，將所有動作盡可能拆解到最詳細，讓任何人都能在不會遺漏任何步驟的情況下重新執行一次。
    * 台灣人的 test case: "瀏覽這個網址"。沒了。

UI test 只支援 IE 7 up 還有 firefox 3，無法支援 chrome, safari 等瀏覽器。

規劃功能時要想像屆時如何測試；就算不能做 TDD，也最好有類似 TDD 的概念，在設計需求時順便思考如何測試。

有人形容 monkey test 是：「你給一千隻鍭子一人一台打字機，他們會寫出一本莎士比亞來。」自動測試想要給定亂數測試時，Visual Studio 的內建測試工具，可以讓我們定義邊界值後，所有的 input 在不斷隨意組合的情況下，把所有可能的情況都測完。

自動化最大的好處是可以迴歸測試、反覆執行。但自動化測試有盲點：我們通常不會去測試「測試程式碼」（比方 unit test 的 code），但測試程式碼本身可能就有 bug。



錄製會依照應用程式 process 執行的速度來運作，不會依照你實際錄製時的時間；例如，你等待了很久才輸入下一個儲存格，但是實際上在重播錄製內容時，test manager 會等到 UI process 運作完畢後立即進入下一個步驟，不會真的等候。如果希望系統在運作自動測試時可以等待一段時間可以在 CodeUI 裡增加 Playback.PlaybackSettings.DelayBetweenActions 這個設定。若是等一段時間無回應就想送出自動 time out 的訊號，則是設定 Playback.PlaybackSettings.WaitForReadyTimeOut。

Coude UI 會根據 *.uitest 的 XML 自動產生程式碼。如果直接手動改 *.uitest 的 *.vb，在補錄動作或移除動作時，剛才修改的 *.vb 又會被改回來，因為 Code UI 的 test code 是根據 *.uitest 的 XML 產生的，所以應該要透過 UI actions 編輯器去去修改 uitest XML。

自動測試無法完美錄製完整情形，例如：錄製計算機的使用，可以很正常地把所有步驟錄起來；但錄製在小畫家上繪製的曲線，它只存取頭尾的座標，所以曲線畫出來會變直線。



由於這兩天所講的課程中提到的東西，事實上在執行時需要太多 agent，若要一台主機就支援全部的工作，要在上頭同時裝 AD、裝 TFS 等等，記憶體至少要 8G（理想狀況下是 12 G 比較好），不然怕跑不動。

就胡老師顧問服務的公司沒有一間導入 unit test。所有的團隊開發，很難導入 unit test，因為要一群人做一件事情很容易意見分歧。



「網頁如果要求不能超過兩秒，那大家的技術會變很好，因為會有一秒的時間浪費在 IE，你的 DBA 要控制在 0.5 秒以內回應。 XD」

這時候有人問到如何調整網頁效能，胡老師的建議是：啟動 IIS 壓縮、viewstate on session (沒有 viewstate，減少回傳內容)。重點是，要讓測試環境變成可控制的，否則變因會太多，調整校能無法聚焦。



新增 Web 效能測試時要注意，若有啟動 IE 延伸安全的話，會無法錄製 AJAX（會出現「目前在 Internet Explorer 中已停用瀏覽器延伸...」的錯誤訊息），在不同的 OS，關閉 IE 延伸安全的方式都不同。

Web 效能測試是對網站送出 HTTP request，所以後端不一定要是 ASP.NET，也可以是 PHP 等其他語言撰寫的網站。

講師在錄製 google 的回應時，看到很多 HTTP 204 (No Content)，我拜了 Google 查到 josephj 寫的文章，看起來是一種 AJAX 的應用。
       


"回應URL的錯誤"：以今日範例而言，querystring 是帶一組具唯一性的訂單編號，因此前後兩次送出的 request 得到的回應會不相同，就會發出錯誤。若想忽略這個錯誤，可以把「預期的回應URL」刪除，或乾脆把這條 request 刪除。

在做測試時，可以設定各種檢證條件，例如：在幾秒內回應才OK、回應內容要包括特定文字...etc.

Web 效能測試也能 databind：先設定 data source，再把欄位指定為 data source 的特定欄位。data bind 也可以設定成特定格式，例如 NT$ {{DataSource1.Row.i}}，如果想要更進階的處理（例如，要為數字增加千分號），可以先把測試的 code 轉出來，或是把 data source 設定成一個 view（view 在欄位 select 時就將之設定成特定的格式）。



負載測試設計時要注意，必須要提出足夠大的壓力，但不要把自己操死、卻沒有得到壓測結果，例如：使用 Code UI 來測，光是 UI 的部分就把效能都耗光光了，根本沒有測到程式本身。為什麼不要用 UI？講師舉了個例子，在 SSMS 裡頭執行以下指令：

            set statistics io on
            set statistics time on
            select * from person.person
            select count(*) from person.person with(index(0))

在 MSSMS 下這樣的 SQL statement 做查詢，兩者的查詢成本是差不多的，但前者存取會花比較多的時間 (1647ms)、後者就只要 4ms，原因是因為前者要畫很多 grid 才能顯示資料結果，後者只畫一格而已，所以速度快很多。

「所以 UI 是很浪費的，你看好萊塢電影裡面用 3D 在破解密碼那種畫面都是假的，大概 99% 的效能都在畫 UI、只有 1% 在算密碼。XD」



在 msdn 可以下載 test controller，不過要注意一下，輸入 liscense 時要自己補 dash。

負載測試前要先有 Web 效能測試（因為負載測試是加入現有的 Web 效能測試來執行的），測試的報告會在「測試→管理測試控制器」。測試報告會存在一個系統建置的 DB，如果想調整儲存標的的話，也可以在[開啟和管理負載測試結果]調整 connection string。

Visual Studio 會在 Excel 裡安裝 Team Foundation Add-in，所以也可以從 Excel 的負載測試頁籤看負載測試報告。若執行了多個回合的負載測試，可以設定一個回合為基準、另一回合為比較，Excel 會藉由 Team Foundation Add-in 撈出來做比較。