測試自動化小組嘗試過另一款芬蘭同事開發(fā)的新型框架，名字叫做robotframework，如今已經(jīng)開源。這個框架本身使用Python語言開發(fā)完成，用來開發(fā)可接受性測試，是關(guān)鍵字驅(qū)動的測試自動化框架，支持多種測試用例的格式，我最喜歡的是使用表格的HTML文件格式。框架非常好用，各方評價都非常高，但是由于核心的開發(fā)者都在芬蘭，杭州本地需要有人能夠進(jìn)行培訓(xùn)、輔導(dǎo)，才有可能做到快速地推廣使用。于是測試自動化小組的同事參加了該框架的高級培訓(xùn)，以及如何進(jìn)行入門級培訓(xùn)的培訓(xùn)，然后向杭州研發(fā)中心的其他同事提供培訓(xùn)，幫助他們使用這個框架實現(xiàn)測試用例的腳本化。
測試框架的使用推廣很快，該產(chǎn)品線決定全面采用此框架來實現(xiàn)測試自動化，包括手工測試的用例也需要使用此框架來撰寫和管理。并且還專門成立了一個團(tuán)隊為產(chǎn)品線開發(fā)庫函數(shù)，封裝操作命令，以便于測試人員們可以不必?fù)?dān)心太多庫函數(shù)編程的問題，快速地實現(xiàn)測試用例的腳本化。
但是測試自動化并不只是將測試用例實現(xiàn)腳本化而已，它是一個復(fù)雜的活動，同樣包含測試用例的設(shè)計、測試方案的選擇、測試驗證手段的選擇等等步驟，而且還必須考慮到在自動化執(zhí)行的情況下，機(jī)器和被測對象的之間的交互方式和人不同，觀察被測對象反應(yīng)的方式也不同。更不用提到腳本本身也是一種代碼，而代碼如果質(zhì)量不高就會產(chǎn)生大量的技術(shù)債務(wù)。在缺乏編程經(jīng)驗的測試人員手中就更是一場災(zāi)難，他們會復(fù)制、粘貼現(xiàn)有的測試腳本，再做相應(yīng)的修改，重復(fù)的腳本片段或是無關(guān)腳本片段的殘留物可謂是司空見慣。測試人員也漸漸地從歡迎轉(zhuǎn)變到了叫苦連天的態(tài)度，抱怨他們需要花非常多的時間調(diào)試出錯的腳本，根本就沒有時間去進(jìn)行“真正的”測試。
為了能夠更好地推廣測試自動化，也為了能夠解決測試自動化所帶來的這些問題，管理層決定設(shè)立測試自動化教練的角色。我是被選定的兩位教練之一。我們所服務(wù)的對象不僅僅是參加過Scrum試點項目的那批人，還包括剛剛進(jìn)行敏捷轉(zhuǎn)型不久的數(shù)百人大組織。
在培訓(xùn)師和教練的工作中，我發(fā)現(xiàn)一些常見的問題：
● 不愿意花時間去熟悉工具：很多測試工作者參加完基礎(chǔ)培訓(xùn)之后就不再花時間去查看工具的相關(guān)文檔，不愿意去熟悉其操作技巧以及庫函數(shù)開發(fā)，連一些非常簡單的小技巧也不知道，開發(fā)出來的測試用例很臃腫，使用的測試操作往往要耗費很多的CPU或者內(nèi)存資源以及執(zhí)行時間。
● 不愿意去閱讀現(xiàn)有的用例：由于種種原因，一些測試用例本身就非常難讀懂，導(dǎo)致后續(xù)接手的測試人員不愿意花時間去理解用例的設(shè)計思路，或者是去理解其中的每一步操作，往往滿足于用例運行通過即可，用例失敗時也只是以修改后用例通過為目的。
● 需求和用例間斷裂的聯(lián)系：敏捷轉(zhuǎn)型給測試工作帶來了一系列的挑戰(zhàn)，首當(dāng)其沖的就是從需求到測試用例的整條線索如何延續(xù)。以往會比對軟件模塊的功能需求條目和測試用例，衡量測試的覆蓋率，而Scrum模式下開發(fā)的粒度是特性，無法沿用此做法。于是在此時，我們提出了Robot Case as Requirement的想法，也即利用robotframework測試用例本身描述性強(qiáng)的特點，來承載需求文檔的作用，而測試用例自身就是可執(zhí)行的自動化腳本。
● 測試工作者失去的歸屬感：在Scrum模式下，測試工作者散布于每一個跨職能特性團(tuán)隊中，很可能孤單一人，團(tuán)隊里最多也就2~3個做測試的。相比以往單獨的測試部門，大家沒有了歸屬感，也不知道該找誰問問題、在哪里獲取測試相關(guān)信息以及如何提高自身的測試能力。我們也為此成立了測試社區(qū)Test Community，定期聚會，邀請大家來分享自己的心得體會，互相學(xué)習(xí)提高，還有在線論壇供大家交流，社區(qū)已經(jīng)可以自我推動著持續(xù)發(fā)展壯大。
● 缺乏測試自動化理論知識：測試自動化（Test Automation）和自動化測試（Automated Test）其實是兩個不同的概念，測試自動化是包括測試計劃、測試用例設(shè)計、執(zhí)行、分析、報告各個階段在內(nèi)的一系列活動，而自動化測試可以看做是僅僅把測試用例的操作實現(xiàn)成腳本而已。缺乏測試自動化理論知識會累積測試技術(shù)債務(wù)，難以維護(hù)、脆弱易損的測試腳本就像是低質(zhì)量、漏洞百出的代碼，后期的維護(hù)、修復(fù)開銷遠(yuǎn)超過魯莽自動化所帶來的那一點點效益。
● 軟件本身低下的可測性：可測性可謂是測試自動化的關(guān)鍵，可測性不高的軟件本身就難以進(jìn)行測試，測試自動化則更加依賴軟件的可測性。機(jī)器不像是人，可以通過眼睛觀察多處信息，并且找到其中的聯(lián)系，或是在腦中進(jìn)行邏輯分析，從蛛絲馬跡間找到問題。測試自動化需要采取適合于機(jī)器的腳本執(zhí)行、信息收集、結(jié)果分析的測試方法，一定程度上這都依賴于軟件本身要提供準(zhǔn)確的、適量的信息。
● 測試工作者不熟悉Scrum：Scrum模式要求團(tuán)隊是跨職能特性團(tuán)隊，應(yīng)該著手培養(yǎng)出通才化專家（Generalizing Specialist），通過加強(qiáng)團(tuán)隊內(nèi)的交流，開發(fā)、測試以及其他職能人員通過合作和溝通互相學(xué)習(xí)，摸索出適應(yīng)迭代增量模式的工作方法。但多數(shù)測試工作者依然是按照類瀑布模式的方式工作，在Sprint前期空閑后期忙碌，來不及完成測試。當(dāng)然，這也和不了解測試自動化，或是可接受性測試驅(qū)動開發(fā)有關(guān)系。
相關(guān)鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發(fā)人員
我的軟件測試之旅：（2）轉(zhuǎn)變——作為專職測試人員
我的軟件測試之旅：（3）同期——加入測試自動化小組
我的軟件測試之旅：（4）并行——自動化回歸測試
我的軟件測試之旅：（5）難點——功能改進(jìn)的測試
我的軟件測試之旅：（6）跳轉(zhuǎn)——追逐新鮮事物的探險者
我的軟件測試之旅：（7）啟程——Scrum中的測試工作者
我的軟件測試之旅：（8）困難——沒有現(xiàn)成的測試工具
我的軟件測試之旅：（9）行動——簡化測試文檔和流程
我的軟件測試之旅：（10）貢獻(xiàn)——開發(fā)項流程
我的軟件測試之旅：（11）嘗試——Scrum Master