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

我 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: 補充

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

相關文章：

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

我想說的是, 要做軟體自動化, 從頭就要跟 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, 所以不要亂寫一些沒用的東西, 很難趴

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

自動化測試導入

兩個時間點:

  • 新的案子, 剛開始. 最好是 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

延伸閱讀 (站內)

Comments

2014/05/09 19:33:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲