---

※ 引述《msc0953 (殺菌)》之銘言：
:: 測試，可分成手動測試和自動化測試。簡單來說，自動化測試就是把手動測試可以用程
: 式來代替。基本上，自動化測試不一定要使用 C++ 或是 Java，也可以使用一些腳本語
: 言，例如: Python, Javascript, 主要是測試有的時候要跑很久，當測試案例失敗後，
: 改程式碼可以很快地再跑一次測試。
: 推自動化測試要有老闆的支持，還要整個團隊對於產品的品質要有一定的要求。因為除了
: RD 要寫 Unit Test, Integrate Test, 還要有自動化的建置系統, 另外, RD 要寫出可被
: 測試的程式，QA 需要設計模組去驅動測試案例測試 RD 寫的程式，如果只是會看著測試
: 案例去測試 RD 寫出來的軟體，那替代性真的很高。
: 但是如果你有辦法看出測試案例上沒有的Bug，甚至可以給予 RD 沒想到解決方案，或是
: 能夠寫自動化測試處理原本要由人跑得的測試，那這就不是免洗的。這種QA非常靠經驗和
: 個人風格，也不是一般QA可以馬上達到的目標。
: 你可以朝向 QA Leader 的方向去走，主要是安排要怎樣測試軟體，測試範圍要怎樣開，那
: 些測試要做，先訓練自己組織的能力，也許再補充自己的專案知識，接PM的工作，也許會
: 比較適合。


針對自動化測試分享一些東西 ..


自動化測試的目的有幾個:

  - 減少人力成本, 資源有效利用
  - 找出潛在性問題
  - 找出效能問題
  - 執行回歸測試, 特別是維護階段, 或者客製化 (Custom Build) 的維護
  - 規劃的好, 有所謂認證的價值, 公信力.


不過大部分, 做到後來都不知道在幹嘛 ....
不過很多案子, 我看到的問題經常是:

  - 通常找不到什麼問題, 因為整個自動化程式都是問題
  - 自動化測試不是用來找測試的, 是用來維護的
  - Bug 都是自動化程式自己的問題, 沒有業績, 只有黑箱
  - 為了自動而自動
  - 沒有規劃, 所以不同的 QA/Tester 會用不同方式寫,
    C/Python/Perl/Java/Shell ... 大亂鬥, 接手的很過癮 ...
  - Test case 相依性太高, case 1 跑完後, case 2 就不能跑了,
    因為環境爛掉了, 偏偏後面還有 2000 個要跑,
    結果你已經下班了, 明天早上要給報告. 發現時已經是隔天進辦公室的時候了.
  - Test script 本身沒有 quality. 所以那 2000 個不知道怎麼來的.
  - 幾個 cycle/stage 之後, 自動化測試能跑就不錯了
  - 通常寫 autotest 的人, 不知道啥叫做 source control ....
  - 自動化測試好不容易可以跑了, 結果忘了換 build, 發現時已經是隔天早上.
  - Developer 通常不想因為需要配合自動化, 而幫 QA/Tester 在 Code 加東西/開洞,
    因為自己的東西都做不完了, 搞不好幫到最後變成自己的 orz ..
  - Developer 有時間/願意配合了, 不過找到可以開動的 lib 又是一個大問題
    (沒人維護了)
  - QA/Tester 通常也沒啥 Coding skill, 也不知道怎麼跟 Developer 提出需求
    而且 PM 也不知道那是做啥的, 所以 QA 就是找一些工具 (ex: selenium),
    錄一錄, 然後只能跑幾次 ... 或者常常不知道為啥突然不能動了.
  - GUI automation 看看就好, 不管是 Web/Window App/Mobile,
    因為那些重點都在 **自動**, 但不是在 **測試流程**,
    也不是在找問題, 製造的問題不少
  - 大部份的 test tools 都只是用來安裝用的
  - 自動化程式通常換一個環境就毀了
  - 沒有完整的報表/Log, 無法缺陷分析, 更別提和 Issue tracking system,
    or test management system 整合
  - 自動化測試工具本身的品質堪慮 ... .(ex: RFT, 我不知道現在有沒好一點)
  - 自動化測試不只是 test script 而已, 還包含自動部署, flow control/timer,
    rework/rerun mechanism, schedule and job contorl, status, report interface
    不過九成能動就不錯了, 剩下的都不知道是啥鬼.
  - 自動化測試仰賴 PM/Develoer 推動 CI 相關流程, 同時把產品界面定義清楚.
    產品界面就是 product name, version, revision, build type .... etc.
    一個還好, 當同時有十幾個時候, 就不好玩了.
  - 大部分自動化 '程式' 不會當作正式的 '程式', 所以九成九都是垃圾 code ...,
    放到 source control 會被排擠.
  - .... 不想列了 ...... orz.


我想說的是, 要做軟體自動化, 從頭就要跟 developer 同步進行,
最好是 pair programming + TDD,
developer 提供對應的 config, component key,
然後能夠有不同的 build type (debug, release) ...

  - config 是未來自動部署時才有辦法設定在不同的環境;
  - component key 指的是自動化工具要取得 UI object 的識別,
    html 就是 id, iOS 是 label, andorid ... 我不想說了.
    不然自動化程式裡就是一堆 n 度空間的 array  ....
    然後 developer 隨便調一個 UI, 自動化程式從此自動消失.
  - PM 把 version role 定義好, CI 那邊才好串.
    阿不然今天 1.3.e-3425, 明天變成 0.1.ab0c-1 ... (不要懷疑, 我真的看過)
  - debug 可以讓程式或者 QA/Tester 調整一些參數, 增加測試的廣度與深度
  - developer 在 code 寫的 log = input of autotest,
    所以不要亂寫一些沒用的東西, 很難趴


# 自動化測試導入

兩個時間點:

  - 新的案子, 剛開始. 最好是 prototype 出來的時間



# 開發自動化工具 or Framework 的重點

市面上有很多工具, 不過很多都太過強調 '錄' 一些東西, 特別是 GUI 的,
錄 Web/錄手機/Window App ... 錄下來都不能看 ...
我覺得那只是行銷手法.

以下是我覺得 survey 一套自動化工具時的重點:

  - Config / Data-driven
  - Report
  - Log 分析 / Pattern
  - 圖形分析
  - Timing control
  - 測試流程
  - 找物件的 libraries 有完整的封裝 (GUI automation 常出現的問題)
  - 資源利用 / 分散式執行 (趕流行)
  - 提供 libraries 讓 QA/Tester 也可以參與寫 script / debug
  - 提供詳細的 debug 流程方法
  - 和 Issue Tracking System / Test Management 整合
  - lib 擴充性和文件產生工具
  - 工具自己要有品質 (某大公司的 RFT .... )


# 測試角色的定義

  - SDET:
    - 做過 developer 最好.
    - 寫自動化測試 Framework 或者研究老闆指定的工具
    - 寫 plugin (像是針對 JMeter 寫 plugin)
    - 維護/針對新功能提供 Libraries
    - Document / Sample Code
  - QA:
    - 寫 test spec
    - 利用自動化測試框架寫 test script / debug
    - 執行寫好的 test script, 跑 overnight
    - 回報/驗證爸個
  - Tester: 手動執行
    - 根據 QA 寫的 test spec 跑測試
    - 回報/驗證爸個

# 自動化測試在專案裡的執行注意事項

  - 寫 test script 本身也是一件 Coding 的工作,
    一樣要 design, coding, unit test, code review, source control ..
    要 Q (誰來 Q?)
  - 十個 test script 可以一個人執行, 不用 config 一樣可以正常上下班;
    2000 個 test script, 怎麼執行? config?
    維護? report? (400M 的 log 怎麼分析啊啊啊阿啊啊啊啊)
    這 2000 個要跑 20 次 (因為有 20 個客戶 QQ) ...
    其中一個客戶要求每個 case 再跑時, 同時要跑 db access, 增加 concurrent;
    另一個客戶說, 某一些 case 參數要調成 0800956956 ...
    去把 2000 test script 叫出來重寫嗎? 然後要 concurrenct 咧 ... 連 DB ...
    對了, 20 客戶有不同的 build, 要記得換 build.
    然後下一個 phase 就剩下 20 個可以跑, 因為改爛了 ...
    然後你就跑了.
    所以 config 的設計與彈性, 比你想像的還重要.
    鮮少 autotest tool 會加強這塊的.
  - test script 的內容重點在測試流程, 不是一堆找物件的 function ...
    那些東西應該是 lib 要寫好, SDET 要搞定的
    test script 重點是: 流程 驗證 記錄
  - 寫 test script 之前, 要充分了解 requirement / spec
    不過大部分 requirement / spec 都不充分 XDD
  - 自動化可以和手動測試同步進行最好.
  - 以前嚴重的 bug 要盡可能的放到 bucket, 有機會就自動化.
  - 如果有 TDD, 那麼就把自動化測試考慮進去吧 ~~
  - 如果是自行開發 test framework, 最好用 framework test self.
    保證 framework 本身以及 libaries 都是 qualify.
  - 文件 文件 文件
  - z>b

寫的有點怨念, 大概沒回到原 po 的問題 XDD

BTW: 有興趣去看看一本書叫做 How google tests software, 作者也有一些怨念 XD



--
   ::: 喝咖啡  聊音樂 :::
http://rickmidi.blogspot.com/


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.105.25
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1399479677.A.60D.html