※ 引述《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 出來的時間
- 案子已經在維護了, 不會有新的需求進來, 但是會修 bug, 最重要是這個案子賺錢.

進行中的案子不要導入自動化, 除非時間很多.


# 開發自動化工具 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 叫出來重寫嗎? 然後要 concurrent 咧 ... 連 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

基本上 "自動化程式" 也是程式, 除了要有 Coding 能力,
更重要有 "分析能力", 因為往往 developer 產出的東西,
複雜度會比原本 requirement / spec 更複雜,
我的經驗, 做自動化程式最好就是 developer,
或者要 train developer 測試的基礎概念.


也不見得, DHH 說 TDD 已死 ...
see: http://www.ithome.com.tw/news/87245
TDD 表示: over my dead body

經驗告訴我, TDD 可以讓大家 (Developer/QA/PM) 思考,
產品的樣子應該是什麼, 但這不表示會抹煞工程師的創造力.


garbage code 有很多原因:

* 歷史因素: 交接很多次了, 有時候為了滿足上面的要求, "暫時" 改幾行.
這個 "暫時" 是怎麼一回事? 不要問, 很恐怖.
* 不知道 test framework life cycle: 把 code 裡的 init value
當 config 用, 所以也是 "暫時" ...
* 把 "暫時" 的 commit 了 ...
* 為了某個特別的目的, 改掉整個流程 ... (通常改的人不會知道影響有多大)
因為他自己可以跑就好, 這也是一種 "暫時" ...

有在用 framework 寫產品的常會遇到, 某些時候一些寫法就是不正確,
但是大部份的 developer 不會去改 framework 的 source code,
因為他知道應該是自己使用錯誤, 或者對於 life cycle 不了解.

不過接 auto test 很多時候會直接跑去改 framework 的 code ... 然後 ..
You know ....

※ 編輯: taliao (36.231.116.156), 05/08/2014 22:33:26