轉帖|行業資訊|編輯:龔雪|2016-05-04 16:41:45.000|閱讀 214 次
概述:敏捷宣言或其12條準則中沒有提到任何要團隊必須平衡測試自動化的工作以達到成功的說法。但是,如果你曾經做過任何形式的敏捷或適配性開發工作的話,你肯定知道他有多重要。敏捷促進了反饋循環更快進行。測試自動化,當有技能地去做,恰恰提供了這一點。重復地跑自動化測試用例給你的程序的質量提供了心臟的跳動,告知每個人當你從代碼庫向程序中添加或移除功能點時你程序的穩定性。對自動化的極樂世界是有一條路通往那里的。它將你導向你的團隊去建設有價值和可靠的自動化。不幸的是,它是設置在雙方中,其中的問題可能會將勇敢的努力變成一堆沮喪和白費力氣。學習怎樣避免將會在你實現測試自動化過程中擋路的幾個障礙的發生和出現。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
毫無疑問,測試自動化最有危險的隱患是缺乏視野。一個連貫的視野產生一幅詳細的地圖---某種脆弱的你的團隊可以開始剖析和理解的東西。沒有那幅共享的理解,團隊們經常在一個項目的生命周期里表現出漫無目的的情。盡管他們可能坐得很近,但是一個團隊可能跟下一個團隊的策略不同。其他團隊可能在做重復工作。另外一個可能完全在往錯誤的方向發展。更糟糕的是,團隊們可能在建造一些最終會被忽略或放棄的不可維護的東西。洞察力應當是簡單的并且清晰地闡述它的目標。主要的目標是去創建一個回歸套給予你的團隊信心當他們在重構程序的時候能夠發現缺陷。
重構舊的代碼沒有一個自動化安全網會是很危險的。它可能會有不可預見的質量后果,尤其是當處理那種過于復雜的不愿用手“摸”的代碼時。開發團隊和他們的產品擁有者需要有平靜的大腦讓他們無所顧忌地不用負面影響顧客體驗地重構程序。另外一個重要的目標是你的自動化測試套應當將你的測試人員從重復手工執行回歸用例中解放出來。這種解放會允許你的團隊將精力集中在更有深度的探索性測試中。如果你曾經多次手動跑過回歸測試,你就知道這最終是一個重復性的會麻木你的知覺和大腦的活動。
自由的測試人員是開心的測試人員,而開心的測試者會發現更好的缺陷。一個穩固的自動化策略應當將你對單元,功能(或服務)和UI測試的預期細節化。因為每一種類型都有其自己的成本和投資回報,對你團隊應當對每個類型貢獻多少時間具體化。馬克.科恩的自動化三角形象地呈現了每個測試類型的合理比率。不要低估一個有粘聚性的可實現的策略的價值。
它會成為你在專業,奉獻和團隊合作之旅中的技術指導。
我曾見過三家機構的團隊測試自動化配置。第一和最有毀壞性的是孤狼方式。創建和維護測試的責任降落在一個單一的個人,通常是團隊里最有技術能力的QA工程師。這個人跟其他每個人一樣對手動測試有額外的責任。孤狼方式中使用的自動化工具很可能是由管理層購買的。第三方工具產生錄制-回放自動化用例,且能快速地創建,但是那些測試通常本質脆弱。他們無法擺脫地將用戶界面元素綁定到測試邏輯上,因此保證任何在用戶界面上的小的變動意味著級聯的測試失敗。對這種等級的測試破壞意味著很多測試將不得不重新錄制,而沒有足夠的時間來解決這些問題因為有其他的測試責任。所以,用戶界面回放測試停留在一個失敗的狀態。
因為對結果缺乏信心,回歸測試套最終將會被暫停使用。該機構將會把用戶界面測試自動化與失敗關聯在一起。在不同方面讓團隊信服將會是一場費勁的戰爭。下一個方式是有一個小的,分離的自動化測試團隊與其他團隊分開的方式。簡單的團隊不會將他們最好的做法與組織剩下的人員社交分享。這些團隊也會發現隨著他們的測試數增加,維護工作變得不可持續。不是去開發新的自動化用例,他們去修復測試問題并且給框架打補丁。他們沒有這種網絡帶寬來創新或者將他們的知識和專業與其他團隊共享。甚至更危險的是,他們的分離可能導致在所有測試自動化工作上的一種域擁有感和微妙的不愿分享的情緒。給測試自動化支持的最有效率的方式是讓每個人都負起責任來。
在敏捷中,有一種成熟度標準來定義工作是否被認為是完成的。整個團隊同意而且為這個完成情況負責。一個例子是,團隊需要手工測試他們開發的功能。測試人員給精心安排所有的測試成員測試活動,包括開發人員。將測試自動化編織近你的完成度標準中是一種讓所有人對產品質量負責的好方式。非技術測試人員可以幫忙編寫前段測試用例,而開發人員或者測試“自動化人員”編寫實際的自動化代碼。目標是讓整個團隊感受到所有權。每個人分享開發,維護和修復測試的責任增加了測試的效率,移除了職員的平靜。它鼓勵合作和共享最好的做事方法。對自動化策略有一個統一的洞察和普遍存在的理解是使用這種團隊為基礎的方式的前提。
測試自動化對非技術的管理經理們是一個黑盒子。他們對它的理解是有限的,而他們對調查解決方法的時間幾乎是不存在的。市場上有產品生成可以提供最終測試自動化解決方案—銀彈。它的設想是非技術測試人員可以從理解使用該產品開始,然后快速不費力氣地建造一個健壯的自動化套。管理者們可能有一種感覺是因為沒有必要的特殊的培訓,軟件的成本是合理化的。營銷這類產品的網站生成要移除測試自動化的復雜性換之以一種直觀的用戶界面。別弄錯,測試自動化是復雜的。當心提防那些聲稱可以戲劇化簡化創建自動化測試的產品。
隨著專利測試數目的增加,團隊們變得跟自動化工具更加緊密地連接起來。如果你已經創建了成千上百個測試用例卻發現這個工具不能實現他承諾的功能怎么辦?對對成本有要求的機構,圍繞是撕還是替換的變動的討論會很困難因為已經投入的沉沒成本。關心設想的經理們不可能去承認失敗,而團隊被留在一遍無所選擇只能繼續講他們自己推往墻角。這需要有勇氣的領導力來承認在工具選擇流程上的錯誤。從一個技術角度來看,選擇一個第三方測試工具需要完全采用他們的架構。你想要一個增強嗎?提交一個功能請求,然后跟用戶庫的其他人排在一條線上。同時,你在非法訪問計算機測試系統
來讓他們工作。增加的技術債務將會導致廣泛的測試脆弱性。當脆弱測試越來越多時,維護他們的成本變得不可持續。如果你決定轉用另一個測試工具,沒有一個良好的退出策略。這不會像將你的測試用例從一個工具中到處然后導入到另一個中那么簡單。
那些對測試自動化直觀價值不熟悉的人嘗試從一些度量中收集獲取這種信息。他們將注意力放在數個編寫好的測試用例且注意自動化測試發現的缺陷數。而那些度量可能很有意思,他們只闡述了故事的一小部分。沒用自動化的測試團隊每次回歸測試用例手工運行時都會支付一輪循環成本。隨著代碼庫的增大,回歸測試集也會隨之增加。結果,那個循環成本繼續增加。一個有意義的度量是“我們使用自動化工具每周節約了多少人-時?”。隨著團隊可以執行更多探索性測試用例,他們可能發現更多測試缺陷。有多少缺陷是在使用探索性測試發現而使用手工運行回歸測試用例不可能發現的?這是個有趣的問題,但是不可能有答案。更困難的是分配一美元可以展示投資回報的價值。自動化帶來價值,但是據我的經驗很難衡量。
一個有著可靠的安全網的團隊很大膽。產品所有者可能不止會冒險還會允許團隊去對重構的代碼做更多冒險的活動。這種重構導致的結果可以增加產品質量,甚至它還能改善該程序的用戶體驗,然后可能增加登錄和轉變。更多的用戶就會帶來更多收入。而用這種假設的情形來決定投資回報率是不可能的。它強調了一個觀點---不是所有有價值的東西都容易去衡量。關注于錯誤的度量的領導者會激勵錯誤的事情。如果一個團隊將關鍵表現指數作為總測試數的話,隊員將會更可能會寫更多測試用例。總體測試數只代表自從引進測試自動化所走的距離;它并不告訴你離目的地有多近。而高測試總數并不等同于更好的覆蓋率;它只意味著團隊已經找到一種方式去游戲/測試系統。有意義的測試自動化度量的一個例子是手工回歸測試集被自動化的百分比。那給團隊成員一個對進度的理解。它也回答了那個還需要多少工夫才能完全自動化手工回歸測試的問題。
沒有一個合理合適的架構的框架的自動化是毫無價值的。框架這個詞包括所有支持性的幫助你的測試有價值的代碼。開發一個合適的框架構架需要時間。它是一個與你團隊的需求不斷演變的一個適應性的過程。總是有要加強的代碼,有要更新的組件和要執行的重構工作要去做。由于軟件開發的節奏的原因,編寫測試自動化的團隊迫切需要盡可能快地傳送價值。如果你的公司有沖刺評審,展示你所取得的進展。不要等到你的測試框架成熟到開始編寫測試用例;你可以使用現有的框架骨架來跑測試用例。
從價值的角度,你能做的最差的事是花費數軸來開發一個沒有任何測試進行的框架。一個沒有測試的框架-不管架構多么優雅,提供的價值微乎其微。結果,投資商可能
開始懷疑他們的投資。從一開始,你的焦點應當放在自動化手工冒煙測試上。使用如Jenkins這樣的工具,將這些測試用例的運行綁到一塊部署代碼上然后部署到你的測試環境上。你的下一個目標應當是自動化整個手工回歸測試集,從高價值的組件開始。類似于注冊,轉變,登錄,下單和支付的功能是高價值目標,需要被透徹測試。采用一種自動化策略后,至少在首次沖刺末尾承諾發送一小部分測試結果。通過展示你的測試結果在團隊附近某處的信息發射器(如掛在墻上的電視)最大化透明度。然后定期間隔地,反思你的進展然后做過程改正來增加測試程序集的價值。
任何團隊的自動化努力目標都是去創建有價值的測試用例。有價值的測試用例是穩定的,快速的,恰當關注的和易于維護的。這些測試類型是由已經長期自動化測試的團隊編寫的。隨著時間的推移,隊員們對什么該自動化,什么不該自動化有了理解。有經驗的測試團隊視自動化為一把扳手,而不是錘子。由于增加的維護成本和擴展的整體執行時間他們很小心地添加測試用例到程序中。當評價新功能是否能自動化,成功的團隊問自己,“這個果汁值得擠榨嗎?”這個測試被自動化更好還是留作手工測試更好?這個自動化太復雜、在我們的一個沖刺里給定的有限的時間里耗費時間編寫嗎?正在開發的功能做自動化已經飽和了嗎?自動化的執行依賴與某些我們無法控制的外部變動的代碼塊嗎?
如果對這些問題的任一個回答是是的話,找其他的去自動化吧。成功的團隊會快速刪掉不提供價值的測試。他們甚至更快速遞刪除那些沒有明顯原因就隨機失敗的測試。那些測試需要高維護成本。信息展示臺的觀察者可能視這些停留在失敗狀態的測試為不成比例的時間量。最終你的機構會成長為不再相信你的自動化測試,然后對其提供的任何價值打折扣。
一個成功的測試自動化,就像軟件開發,并不簡單。有很多重要的成本涉及到。有很多潛在的錯誤的轉變和錯誤的開始。要知道每個你編寫的有價值的自動化測試用例,
你的團隊變得更加解放。更重要的是,不要忘記授權成員做事。允許他們圍繞一個視野,提供給他們一個明晰的策略讓他們自我組織。給他們自由去探索新的技術,然后決
定他們想要擁抱的自動化工具。成為決定過程的一部分意味著他們會更多投資在他們自己的成功上。你的團隊可能剛剛發現了一個如果隱藏不被發現就會導致上百萬損失的缺陷。這種投資回報率怎樣?
原文轉載自:
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn