TechDays 2011隨堂筆記0914

【開發人員應做的測試】

1. 要落實UnitTest很花功夫，可能要多耗費1.5倍的時間，要實現不容易，除非老闆很有決心，不過這種老板通常也沒人受得了
2. 測試的難度: 愈多人參與難度愈高!
3. 利用Visual Studio 2010 Ultimate進行網頁整合測試
   * Web Peformance Test功能
   * 可使用IE測試錄製器錄下所有瀏覽操作，做為後續測試依據
   * 驗證規則: 可以指定執行時間上限、檢查<title>或特定HTML標籤、HTTP Status Code...
   * 提供CSV當作資料來源，指定測試各步驟的URL及測試參數
   * 擷取規則: 將一張網頁的內容擷取出來做為後續輸入參數，存入預先宣告的參數，供隨後使用
   * Binding語法: {{DataSource1.Report#csv.URL}}
4. 負載測試
   應在開發過程中反覆執行，儘早發現問題，愈早發現成本愈低，並以找出最大瓶頸為首要工作
   VS Ultimate版本: 使用Controller控制多個Agent聯合攻搫，產生可觀的負載 。實務進行時，可能需要Lab Management，用100個VM跑100個Browser
   "考慮時間"(怪翻譯?): 發出Request後的等待，調節產生的負載大小
   Smoke Test: 買電器回來先插一下電看會不會冒煙，初步測試
   測試混合設定: 多個測試一起進行，並可設定比例。ex: 查詢75%、新增25%
   網路混合: 模擬網路Delay
   瀏覽器混合: 若Web針對不同瀏覽器丟回不同內容，可用此模擬真實環境
   可蒐集Server的效能Counter，但太忙時可能會收不回來
   支援用SQL Profiler追蹤SQL執行狀況，可統計不同指令的執行次數。
   啟用TestAgent才能產生夠大的壓力，不然只會用一顆CPU模擬250個User。(每1000User要加買License，現已改為吃到飽，實務上有8,000人的模擬需求)
5. 測試本身對效能也會造成影響: 例如: IntelliTrace會讓執行變慢
6. 另一個測試工具: Test Runner，測試結果存成XML
7. 自動程式UI測試
   * 可以吃Test Runner的存檔
   * <input type=”password”>的輸入會加密才放進變數裡，測試時會解密
   * 錄製->Gen Code
   * Feature Pack 2 - 提供Editor，GUI修改.uitest，存檔後GenCode
   * 錄製過程可以截圖存成圖檔，供事後比對或存查
   * 錄製結果會識別Control/Element，而非座標軸。WebForm通常會有Unique Id，但WinForm就不一定
8. 節約資源: 善用using (…) {  } / Window.close() 以免耗用過多CPU/RAM
9. (如意算盤)教導非開發人員使用VS2010投入測試工作

【BoF自動化測試實戰經驗分享】

1. 為什麼需要測試? 測試為開發者帶來信心! 減少面對改變的恐懼~~~
2. 系統整合出錯，責任屬該? 測試結果可以保護自己
3. 改了程式，其他會不會壞掉? 讓測試來回答
4. 交付程式時，透過測試來證明品質
5. 其他模組尚未完備時，透過測試驗證自己程式是否正確(會用到IoC、Mocking技巧)
6. Case: 有些茶包只在真實環境才會現身，故理想的狀況最好有獨立的測試環境，便於模擬出錯情境(即便如此仍未必可重現)
7. 程式撰寫 vs 測試 投入的時間? 實務上測試反而花比較多時間，但傳統上預估時程時，大部分資源被保留給Coding
8. Bug愈晚修，成本愈高... 透過自動測試用較低成本、較短時間得到測試結果，可提早發現Bug
9. 實現自動測試需要可觀的成本，如何說服管理者? 撰寫測試程式的成本是可預估可控制的，會收斂的，與後期處理Bug的成本相比很划算
10. SEARCH: Setup, Execution, Analysis, Reporting, Cleanup, Help
    Setup/Cleanup通常是比較困難的部分
11. 困難點: 如何實現允許測試被無限多次反覆執行(例如: 要解決PK重複問題->切出獨立資料庫[需要MIS/DBA的協助]/Snapshot技術)
12. 實務面常面臨的挑戰:
    * 開發時程未保留實做自動測試的時間
    * PM短視近利
    * 開發團隊抗拒改變
    * 缺乏測試環境
    * 缺少測試資料及測試腳本
13. 測試建立後，維護人員是最主要的受益者(註: 換句話說，寫測試程式是良心志業)
14. 突破困境:
    * 找不到時間點做測試(一行Code也抽出來寫測試程式，有開始就有進展)
    * 程式無測試性->沒有測試就不能重構->沒有重構就沒有可測試性
    (先用"黑箱整合測試"輔助，確保整體的Input/Output正確，再一小塊一小塊拆出小單位進行測試、修正、重構)
15. 自動測試常見的杯具
    耗費了可觀時間建立了測試，但...
    * 維護者不看測試結果、不寫測試程式
    * 破窗理論: 棄守第一個堅持後，之後就會一路墮落到底
16. Production Code與測試專案是生命共同體
17. 血淚教訓，變法者常不得善終: 既得利益者反撲、人性抗拒改變 ==> 別試圖變法，漸進式改革
18. 文化 = 多數人的價值觀 => 想辦法讓自己成為多數人(自古以來，人多欺負人少乃天經地義之事)
19. 整合測試 vs 單位測試 => 黑箱，只看輸入輸出 vs 白箱，要遍及程式邏輯
20. 怎麼開始?
    * 版本控管
    * 排除程式相依性
    * 建立第一個測試專案及第一個單元測試
    * 建立第一個可執行的自動測試
    * 爭取主管同意與支持
    * 找一個可控制風險的小專案，找到不知江湖險惡的熱血青年，嘗試第一個落實自動測試的專案
21. 寫測試程式常見的錯誤:
    * Hard-Coding路徑
    * 複雜度過高
    * 看到結果時，無法一眼了解問題所在
    * 誤報: 對的程式報錯、壞的程式報對
    * 龜速測試: 沒將單位測試跟整合測試分開，單位測試求快求輕，執行頻率高，若混了整合測試，將會很痛苦