測試物件依便利性與獨立性的取捨
『測試的時候你習慣用現有的東西改，還是每次都用新的？』
不管是在生活或工作上，任何人一定都有經歷過「驗證是否正確或可行」的這個流程，只是在測試專職人員的角色上需要著墨的更多。今天想跟大家分享一下對於軟體測試過程中，測試物件的準備會是怎麼進行的。所謂「工欲善其事，必先利其器」想必是大家都耳熟能詳的做事方法，除了妥善運用工具把事情做好之外，通常也想要用最短時間達到預期成果。所以在做測試工作的時候常會用固定的物件做些條件的調整來因應不同的情境(Scenario)。以下我會以自身在 AsiaYo 訂房平台擔任 QA 的例子，來分享一下自動測試在測試物件選用上的一些小小經驗。
通常測試之前會做一些測試規劃與準備驗證的案例，並將對應的測試環境與受測物件準備好，以 AsiaYo 訂房平台的例子來說，測試環境指的是內部封測的環境，通常做測試最好還是要區分測試專用環境，不要冒然在正式線上環境做測試，至於為什麼，相信不用多說也知道。但若只能在線上環境做測試，也不是說一定不行，只是要小心一點就是。至於測試物件，對於訂房平台來說指的就是旅宿與其底下供預訂的房間，以訂房流程的情境來說，會針對不同旅宿類型，底下房型可容納人數(是否含加人)，房價方案及促銷優惠條件…等，下去規劃測試案例，若今天是以手動方式執行測試，當然可以只用一間旅宿及房間每測過一個案例就調整對應條件設定再來執行下一個測試項目，只是對應起來可能會有很大部分的時間是在旅宿後台調整各項設定，真正執行測試步驟的時間相對可能還比較少。
今天如果是要把原本手動測試的案例轉為自動測試，在公司內部有完善的工具支援之下(指的是有相關的功能接口或套件，若要透過改 Database 方式，一樣請小心謹慎，弄髒環境要小心四周投射的目光)，大概準備測試物件的方法可以有三種:
- 跟手動測試差不多，先手動建一個空殼旅宿，後面要什麼就改什麼。
- 稍微聰明(省事一點)先歸納出測試大方向上會踩到哪幾種類別，可先手動建幾個對應旅宿出來，減少旅宿物件改動的工。
- 完全不想修改既有物件，要什麼就重頭建一個符合測試情境所需的旅宿房型。
備註：(1.) & (2.) 第一次是手動建，後續都透過程式改；(3.) 是完全透過程式處理。
以上三種方式都可以達到最後測試的目的，不過如同開頭所說，若要測試結果有達到目的外，也要測得快的話，在單一線程執行的情況下，可以預期前置作業越少的執行的效率會比較高，所以執行的時間效率大概可以預期第 (2) 種方式的結果會是最快能達到成果的。
以筆者自己的經驗早期在實作自動測試的時候，這邊以下單流程的 API Integration Test 為例，就是選用第 2 種方式，先針對下單流程規劃出幾間旅宿出來，如圖一所示的「歐透塔斯特」系列(名字是 Auto Test 的諧音)，先手動建好現有的幾個物件，後續再針對局部條件在執行測試的前置處理的時候調整，調整完才進入測試下單流程。以這樣的方式跑了段時間，後續隨著平台功能的新增也陸續對案例做了維護，雖然實作上還蠻快的，但久而久之慢慢也感受到一些缺點。
- 固定的測試物件其實就是 Hard Code 你的測試腳本，少了些變通，換個環境還要準備另一組。
- 隨著平台功能日漸增加，設置條件也越變豐富，所以測試的前置處理(Setup)與後置處理(Teardown)相對要做的事情變多了。
- 由於測試旅宿是多個測試腳本共用，如果案例一多，如果想加速平行多個執行序跑，旅宿條件各個腳本改來改去會造成衝突。
這個時候就會發現，每個測試案例之間沒有相依性是件多暢快的事。透過上面的一些經歷之後，後來就決定改用開頭說的第 3 種方式，全部的測試物件既然 API 可以建，那我就全部用 API 建。
修改之後可看上圖二，測試用的旅宿在執行測試腳本的當下會自己新建過(每間都是新上架)，可以說每個測試物件都是可用完即拋，且可在任何指定的環境執行。若要用多線程去跑測試也不會有衝突，可以縮短測試執行的時間。但相對的原本在第 2 種方式前置處理修改旅宿的方式，在第 3 種方式中變成要新增不同條件的旅宿，新增的動作會變得很頻繁使用，所以必須要設計共用元件的架構，不然可能會更累。以修改旅宿條件條件來說，可能只需要用到少數的 Update 功能 API，但完全新建的話就不只動到旅宿而已，還包含需要建立旅宿的 Owner 及上架條件。
已單修改旅宿條件為例會用到：
- Update Property API (因旅宿本身已上架，只需調整測試物件部分內容)
但是新建旅宿並上架的話會用到：
- Create Property Owner API (例: 建立旅宿主人)
- Create/Update Property API (例: 新增並調整旅宿內容)
- Update Property Online Status API (例: 調整旅宿上架狀態)
- Update Booking Status API (例: 調整旅宿底下房型的可售狀態及價格)
想要做到完全自動化，有些常用的 API 需要做成 Combo 技共用模組，方便後續的使用及維護，但相對開發的成本也會比較高。所以回到開頭的問句「測試的時候你習慣用現有的東西改，還是每次都用新的？」，並沒有要比較那個方法好，只是分享一下自己的經驗，若你問我是不是之後都會採用一定要堅持測試間的獨立性，我可能會說不一定，還是要看開發環境能給予的資源到什麼程度，以及產品的變動性高低，如果系統大資源廣且公司發展步調穩定的話，我是推薦做自動測試的時候要考慮的長遠一點；反之如果能給予的資源不多，且產品變動大(指存活時間不長)又想做自動測試，可以用比較簡單快速甚至半手動的方式也可以，主要的目的都是要減少重複性人力的工。
另外推薦若要做 API 的自動測試，想要簡單上手可以用 Postman + Newman 去做(理論上 Postman 的 Collection 設定好，就完成一半了，重點會在 Pre-request 及 Tests 區塊，前提是你要懂一些 JavaScript 的語法)。若想要有比較完整的框架，可以用 Python Unittest 或 Pytest 來實作，有提供測試前後處理的流程，會比自己刻單純些，且都支援 Html 的報告輸出，方便分享(交差)。
最後不免俗的廣告一下，如果你對 AsiaYo 訂房平台有興趣，想要打造一個對旅人更友善更貼心的訂房服務，歡迎跟我們一起努力創造更好的產品體驗。
相關職缺請見職缺連結！
