軟體自動化測試常見的問題

我 po 在 ptt Soft_Job 版的分享, 做一些重新整理, 原文在這裡.

註：這篇是我 2014 年寫的，文中描述的實際發生時間約是 2009 年 (快十年前 orz)，補充一些資訊在最後面。

本文 (2014/05/08)

以下保持原文的描述與格式。

自動化測試的目的

減少人力成本, 資源有效利用
找出潛在性問題, 提早發現 side effect, 維持產品品質穩定
找出效能問題
執行回歸測試, 特別是維護階段, 或者客製化 (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 有時間/願意配合了, 不過找到可以開洞的 third-party lib 又是一個大問題, 因為已經不能動 or 版本太舊了 (沒人維護了)
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.

會出現 garbage code 有很多原因:

歷史因素: 交接很多次了, 有時候為了滿足上面的要求, 暫時 改幾行. 這個 暫時 是怎麼一回事? 不要問, 很恐怖.
不知道 test framework life cycle: 把 code 裡的 init value 當 config 用, 所以也是 "暫時"
把 暫時 的 commit 了 …
為了某個特別的目的, 改掉整個流程 … (通常改的人不會知道影響有多大) 因為他自己可以跑就好, 這也是一種 “暫時” …
有在用 framework 寫產品的常會遇到, 某些時候一些寫法就是不正確, 但是大部份的 developer 不會去改 framework 的 source code, 因為他知道應該是自己使用錯誤, 或者對於 life cycle 不了解. 不過接 auto test 很多時候會直接跑去改 framework 的 code … 然後 … You know ….

2018/05/05: 補充

這段文字保留原文有很大的原因：因為十年來發現歷史不斷再重演，很多老闆真的很天真，不知道 自動化 的前提該要什麼，為了自動而自動。所以如果你是管理階層、有經驗的資深工程師，建議想想這些，因為出來混，是要還的。希望這些建議與經驗，可以讓大家少走一點冤枉路。

相關文章：

2017/11/12: 自動化帶來的問題

2017/08/30: 自動化 XXX 的陷阱

2018/03/20: 導入 CI/CD 的第一步

自動化測試流程上的的建議

我想說的是, 要做軟體自動化, 從頭就要跟 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 … (不要懷疑, 我真的看過)
- see Version Control
debug 可以讓程式或者 QA/Tester 調整一些參數, 增加測試的廣度與深度
developer 在 code 寫的 log = input of autotest, 所以不要亂寫一些沒用的東西, 很難趴

測試仰賴流程標準化 (SOP), 來亂的很難有品質, 相關參見：

協同合作系統建制與導入 - 以 Redmine 為例

Software Development Lifecycle

自動化測試導入

兩個時間點:

新的案子, 剛開始. 最好是 prototype 出來的時間
案子已經在維護了, 不會有新的需求進來, 但是會修 bug, 最重要是這個案子賺錢.

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

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

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

以下是我覺得 survey 或者自行開發一套自動化工具時的重點:

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

關於實作 Test Architecture and Framework 的一些想法，整理在 Designing Test Architecture and Framework 。

測試角色的定義

SDET (Software Developer Engineer in Test)
- 做過 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

補充

回復一些版友的問題:

推 Wolfken:重點在自動化測試要有多年coding經驗，一些沒多少經驗的 05/08 01:06
→ Wolfken:tester寫出來的當然問題百出，最好還有developer一起下來 05/08 01:07
→ Wolfken:幫忙弄架構跟寫一部分的code 05/08 01:07

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

→ umum29:現在開發的架構也越來越傾向測試優先阿如TDD 05/08 11:54

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

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

後記 (Updated: 2018/05/02)

這篇是我 2014 年寫的，文中描述的實際發生時間約是 2009-2011 年 (快十年前 orz) ….

隨著技術的快速發展，新的東西不斷出來，各式各樣的測試工具與平台如雨後春筍，相關的理論、學派、書也都在討論測試、討論持續整合、持續交付。後來我其實已經很少在看技術面的東西，今天跟測試 Team 同事聊了之後，發現實際的問題沒改變，也就是就是：十年前跟現在都是面對同樣的問題，問題就是：

讀了很多人推的書，但是上面寫的東西不是高大上、就是太理想、或者太空泛

不然就是沒人沒資源沒時間

自動化的技術跟現場需求對不上、跟不上

自動化程式本身的問題很多，最後手動最快

自動化測試這件事情，因為他『自動』的特性，和我後來做監控、部署 …. 本質性都有很高程度的類似，所以我可以有個參考基礎，然後延伸改變。。。

恩，突然覺得，十年前我有機會作文中描述的事情，還滿酷 XDD~~~ 因為能做這件事的公司，不太多。

補充 (updated: 2018/05/05)

底下這張圖來自 Coding Explained in 25 Profound Comics #21: When you want to automate everything，大概就是在說我想表達的意思：

When you want to automate everything

軟體自動化測試常見的問題

本文 (2014/05/08)

自動化測試的目的

實際遇到的問題 (血淋淋)

自動化測試流程上的的建議

自動化測試導入

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

測試角色的定義

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

補充

後記 (Updated: 2018/05/02)

補充 (updated: 2018/05/05)

延伸閱讀 (站內)

Comments

About

著作

演講

Facebook

AWS Certifications