David Ko的學習之旅

測試程式架構的重要性: 看Commerical UI automation tool的演進

Mercury Business Process Testing：專注於業務需求的自動化測試
http://blog.joycode.com/oldsidney/articles/86763.aspx

當我在和同事談test automation時, 提到QA在做test automation時, 常常沒有 architecture design的觀念. 每次程式一有做修正或是需求改變時, 測試程式常常會改到翻掉.

像是在做UI測試時, 一開始的script都是直接描述UI的動作, 和UI的control 綁的很緊, 可以參照文章中第二代的自動化測試的script

set_windows( "Fight Reservation", 4);
edit_set ("Name:", "Candice Yun");
button_set("First", ON);
......

因此若是UI flow有改, 或是control有所修正(例如edit contorl 換成combo box), 這些script便都不能使用

軟體測試工具廠商便針對這種狀況做了一些改進: keyword driven test,但是這些還是不夠理想, 還是有很多地方會導致你的script要做修改.

因此最終現在改成 business process testing:

Login david, XXX
FillOrderDetailed PassengerName, FlightDate, FlyFrom, FlyTo, Tickets, Class, FlightNo

這樣的好處是, business process是比較不會因為UI flow or control變動而有所影響. 這樣你的script就不會三不五時就要大改. 沒有coding經驗的QA也比較容易上手, 並且你也可以拿它來和customer討論.

所以我要強調的是, test program的architecture design的重要. 你要知道會影響你程式變動的因素有哪些, 你就要在那裡做些設計. 就像UI測試的軟體工具廠商一樣, 不段改進工具的設計架構. 否則永遠只會得到測試自動化是沒有用的結論, 因為你的poor design導致測試程式根本不能用.