我的軟件測試之旅:(12)機(jī)遇——測試自動化培訓(xùn)師和教練
測試自動化小組嘗試過另一款芬蘭同事開發(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)鏈接:
我的軟件測試之旅:(2)轉(zhuǎn)變——作為專職測試人員
我的軟件測試之旅:(6)跳轉(zhuǎn)——追逐新鮮事物的探險者
我的軟件測試之旅:(8)困難——沒有現(xiàn)成的測試工具
posted on 2012-08-13 09:11 順其自然EVO 閱讀(193) 評論(0) 編輯 收藏 所屬分類: 測試學(xué)習(xí)專欄