【開發人員應做的測試】

  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路徑
    * 複雜度過高
    * 看到結果時,無法一眼了解問題所在
    * 誤報: 對的程式報錯、壞的程式報對
    * 龜速測試: 沒將單位測試跟整合測試分開,單位測試求快求輕,執行頻率高,若混了整合測試,將會很痛苦

Comments

# by dave

這篇好幾句說中我之前情況(茶) 有測試,你才會對自已寫的東西有信心。 (這跟待過製造業思維非常相近)

# by 91

我濕了,黑大整理的重點摘要,比我講的還好...我這週末也會花時間,把一些我想講而沒講的,再補上去。 感謝黑大鎮守在教室後方,講得不是挺順的,希望不會浪費到你太多時間 XD

# by Jeffrey

to 91, 您太謙虛了。講得很好,聽得出都是親身實戰的血淚經驗,不是開嘴砲打高空,你一定沒注意到我在台下頻頻點頭如搗蒜 :P,受益頗多。不過,我還是覺得,"實踐自動測試"還真的是對毅力、人性的嚴峻考驗,是很不簡單(甚至可遇不可求)的成就哩,能聽到你的經驗分享很棒!

Post a comment