敏捷腦圖用例實踐之路

原文在infoq已經發布,能夠直接閱讀:http://www.infoq.com/cn/articles/road-of-agile-mind-map-practice/web

傳統的黑盒測試用例比較繁雜,在實施敏捷的項目中會顯得水土不服,讓測試人員過分關注用例步驟的編寫、修改,甚至同一條用例通過多人執行獲得相同結果,讓人想到一個呼之欲出的廣告詞:一次編寫,多人運行相同結果,沒有思考的過程。在經歷過這些痛楚以後,對用例進行改革,以便快速響應開發的交付節奏,同時造成用例評審規範,讓開發、測試知己知彼,也增強開發自測的環節。本文主要講敏捷中腦圖用例的實踐。瀏覽器

1 轉型測試掉進傳統用例坑服務器

在《軟件測試轉型之路》(http://www.infoq.com/cn/articles/transformation-way-software-testing)中,經歷了沒法忘記的幾個月:天天高強度測試、反覆編寫、修改用例步驟,深入體會:框架

不寫測試用例或許測得更快,但毫不是一個測試人員的最佳素養,而如今的測試用例又過於繁雜,消耗了不少時間,怎麼辦呢?ide

先看看測試用例的定義:測試用例(Test Case)是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程序路徑或覈實是否知足某個特定需求。工具

還有測試用例編寫的通常原則:測試

? 測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。優化

? 測試數據應該選用少許、高效的測試數據進行儘量完備的測試。網站

按照定義和原則以及模板,實踐了三個月的備案系統,列舉一些簡單測試用例以下:ui

? 服務器、賬號信息

測試服務器地址:http://127.0.0.1/login.do

測試管理員帳號和密碼

管理員:admin

密碼:admin

? ICP備案信息錄入

測試數據參考:附錄-ICP信息錄入測試數據

步驟名稱 

描述 

預期結果 

實際結果

步驟 1

打開瀏覽器,登陸系統,點擊左側"ICP備案信息管理"-"信息錄入"

進入"信息錄入"頁面


步驟 2

填寫詳細信息,數據參考當天測試數據的:第一步 填寫ICP主體備案信息

點擊"下一步"

進入"第二步 填寫ICP備案網站信息"頁面


步驟 3

點擊底部,中間按鈕"添加網站"

進入"填寫ICP備案網站信息"


步驟 4

填寫詳細網站信息,

數據參考當天測試數據的:第二步 填寫ICP備案網站信息(要分清填寫的是測試數據幾)

 

點擊"提交"按鈕

返回"第二步 填寫ICP備案網站信息 ",而且看到剛剛填寫的網站


步驟 5

在剛剛的新增網站右側,點擊[添加接入]按鈕

進入[ICP網站接入信息]頁面


步驟 6

[ICP網站接入信息]頁面,填寫錄入信息,

數據參考當天測試數據的:ICP網站接入信息

(要分清填寫的是測試數據幾)

 

點擊[提交]按鈕

返回[ICP備案網站接入信息]頁面,一樣仍是看到剛剛新增的網站,代表成功


步驟 7

點擊底部按鈕"提交"

彈出對話框"信息錄入成功"


步驟 8

點擊"確認"按鈕,

從新進入"第一步 填寫ICP主體備案信息"




? ICP備案歷史信息查詢

步驟名稱 

描述 

預期結果 

實際結果

步驟 1

打開瀏覽器,管理員登陸系統,點擊左側[ICP備案信息管理]-[歷史記錄查詢]

進入[歷史記錄查詢]頁面


步驟 2

[歷史記錄查詢]-頁面,輸入查詢條件,點擊[開始搜索]按鈕

進入[歷史記錄]結果頁


步驟 3

[歷史記錄]結果頁,選中其中一條數據,點擊右側[詳細]

進入[歷史信息瀏覽]頁面


步驟 4

點擊[返回]按鈕

返回[歷史記錄]頁面



反思當時遇到的問題:

全部測試用例編寫完畢,都經歷了:第一次編寫後調試、發現問題從新修改步驟、再次調試發佈,過程至關繁瑣,並且當時測試人力不足,還得把這些用例分配給客服進行測試,客服按照測試用例也遇到很是多的問題:死機怎麼處理、瀏覽器掛了信息怎麼辦等等(實際上這裏有一些決策是客服沒法作得,對業務不熟悉、沒有測試經驗)。說實在的,不是專業測試人員,這個用例沒法執行下去了,就是每種狀況寫的不夠明細,誰能保證全部可能路徑都寫出來呢?不懂業務的測試人員,有執行測試用例的價值嗎?測試用例應當是有思考活動存在的。

另外,在excel編寫用例,不是永遠的辦法,後來把測試用例遷移到testlink上,確實比較方便,依然仍是傳統編寫步驟的方式:

wps330D.tmp

圖-1-Portal測試用例

這個階段,問題暴露愈來愈嚴重了:

一、測試用例裏面寫死了數據、業務步驟

不一樣測試人員都按照具體步驟來測試,就比如車載導航,變成「導航測試」了,若是須要測試其餘客戶、其餘業務呢?有些測試人員就再複製一個用例出來,形成用例氾濫。

二、測試用例依然沒有思考的過程

負責第一次編寫的測試人員有思考,但負責執行的測試人員,沒有再繼續跟開發交互測試過程,沒有更深刻的思考,而是僅僅按照用例執行,那這種效果等於走過場。

三、遇到十幾個、甚至幾十個步驟的功能,用例編寫耗時

例如:打開瀏覽器,輸入帳號密碼登陸,這些其實也是沒必要要展現的步驟,作測試就要熟悉業務,測試人員應當更加關注的是開發是否作了正確的功能,功能是否作了正確的事情,在一個測試、開發比例1:4(有些是1:10)的團隊裏面,測試人員的時間是有限的,不要陷入過度的步驟細節裏面去深究,要把重點思路放在運用哪些測試方法、如何組合更加有效覆蓋測試故事點。

例如簡潔的測試故事點:做爲主賬戶,輸入正確的用戶名和密碼登陸系統,以便可以查看當日的帶寬數據。

2 不進則退-倒騰敏捷腦圖用例

傳統的軟件交付測試,能夠簡單描述爲下圖所示:

wps333D.tmp

圖-2-傳統交付測試

開發人員完成任務以後,最後交付給測試人員,這種模式下,測試人員不能及早發現需求階段的缺陷、及時編寫測試用例,用例評審滯後,發現缺陷一樣也會滯後。而整個過程當中丟失最大的環節就是:溝通、反饋。在《全程軟件測試實踐:從需求到運營》中文:

http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational/也曾提過。

假若要是使用傳統的用例編寫,把測試團隊人員的思惟固化,這樣子下去不進則退,不利於團隊發展。鑑於此,建立了敏捷腦圖用例,有如下原則:

? 參與需求分析、記錄驗收要點

全程軟件測試,從需求階段開始參與,在sprint會議上對功能點進行評估,消除含混性的疑點,將明確的做爲驗收要點,做爲腦圖用例故事點的參考來源。

? 編寫腦圖用例,要與開發人員達成一致意見

開發過程當中,測試人員能夠根據原型圖設計腦圖用例(沒有實際系統,測試也能夠先行),與開發人員進行查漏補缺(也就是用例評審環節),主要是確認測試功能點、測試故事,以及測試數據的準備,這幾個方面不可能一開始就明確下來,要不斷溝通、挖掘、完善腦圖用例。

3 腦圖用例演化

這裏的重點主要講一下腦圖用例(推薦使用Xmind工具:http://www.xmind.net)的演化(測試故事點之後再作介紹),從第一個大版本和第二個大版本的考慮,其中的小版本忽略。

? 初版本腦圖用例

要點:

ü 所見所想

當時的想法很簡單,以需求爲思考出發點,把全部功能性、非功能性的列舉出來,而後再整理故事點。

wps333E.tmp

圖-3-腦圖用例模板v1.0

? 第二版本的腦圖用例

要點:

ü 增長風險考慮

ü 增長局部決策考慮

例如:一個輸入框(或者叫元素),測試人員應當針對這個元素,結合數據,會考慮使用哪些測試方法進行操做呢?

ü 增長全局決策考慮

例如:一個業務查詢操做,在web上操做,會觸發一系列元素(輸入框、查詢按鈕),這些應當如何組合、使用什麼策略呢?

ü 遵循:重構->測試->重構->測試,的原則

wps334F.tmp

圖-4-腦圖用例模板v2.0

腦圖的形式展示並非最重要問題,關鍵問題是:思考的出發點,這個要整個團隊參與討論,達成共識,才能傳承。

引出思考點,你們就能夠不斷補充腦圖,剛開始全部點多是零散的,甚至一點關係都沒有,這個時候就須要重構了,抽取相關點,下面會講講咱們用什麼方法來作。

4 腦圖用例實踐指引

腦圖編寫不是漫無目的去思考,正如探索式測試策略,並非指無目的去作即興測試,有原則指引很重要。團隊採用SMART原則進行腦圖用例實踐:

? Specific(具體的):測試須要一個具體的目標(甚至原型圖均可以),用來描述全景圖。

? Measurable(可度量的):有明確的度量能夠評估目標是否達成(也就是驗收條件做爲測試故事點的評判標準)。

? Achievable(可實現的):當前的目標應該是可實現的。這潛在地要求將一個大的目標分解爲多個小目標,每一個小目標也是具體的、可度量的。此外,跟蹤小目標的完成狀況也提供了總體進度的可度量性(一個業務操做會通過不少路徑,每一個路徑能夠單獨存在或者組合存在,須要切分測試)。

? Relevant(相關的):測試故事點從需求出發(包括功能性和非功能性),結合業務特性,以及相關上下文做爲切入點。

? Time-boxed(有時間限制的):爲每一輪腦圖用例的構建設定一個合理的時間窗口,例如在固定的時間窗口(一些人的專一度是45分鐘,一些是60分鐘,中排除不相關干擾、專一工做)。

腦圖用例編寫流程:

? 參與持續需求分析(不只僅是需求階段,開發階段的變化也須要及時捕獲)制定腦圖用例框架

? 將業務|功能測試目標分解成一系列測試任務,每一個測試任務有明確的時間限制和退出條件。

? 測試計劃以後,優先選擇一個測試任務,在一個測程內執行探索式測試,測程以45|60分鐘爲一輪,執行多輪。

? 反思當前的測試進展,並優化測試計劃。增長或刪除一些測試任務,以更加準確地反應測試對象。

實際案例:

團隊經過結對測試,摸索了一套腦圖思考方向,給予參考:

? 業務功能需求

以下圖所示,根據選定的頻道查詢在可選時間範圍內的帶寬數據

wps3350.tmp

圖-5-業務功能

因爲版面問題,這裏舉簡單的例子:

? 腦圖用例分析第一步

wps3360.tmp

圖-6-帶寬查詢用例v1.0

首先把業務需求分析結果填寫到目標中,而後分析功能(若是沒有系統,能夠只看原型圖),找到頁面的相關元素,逐個列入腦圖中,再爲每一個元素使用一些測試方法,例如:等價類、邊界值,進行局部決策,這樣子,全部元素的分析完畢,就進入第二步全局。

? 腦圖用例分析第二步

wps3361.tmp

圖-7-帶寬查詢用例v1.1

第二步繼續完善,進行全局分析以及列舉一些非功能性需求:

全局分析:

找到需求描述或者跟開發溝通代碼有限制條件的地方,而不是針對某個元素;

對不一樣元素組合有依賴關係的,也須要列出來

非功能性:

這個在文檔中可能沒有給出,須要根據經驗來評估,能夠參考團隊積累業務的測試經驗,通用的點:出錯的用戶體驗是否ok、查詢時間效率如何等等

風險:

儘量琢磨需求,挖掘風險,例如需求說:根據選定頻道,可是沒有說這個頻道不屬於客戶怎麼辦?這個就是思考的強大力量了。

? 腦圖用例分析第三步

wps3372.tmp

圖-8-帶寬查詢用例v1.2

第三步是最關鍵一步,產出測試故事點,根據風險、目標、要點分析得出,這裏舉了簡單例子,可使用關鍵路徑組合的方法來作。

固然,作完一二三步,也只是在第一個時間窗口而已(這個時候也能夠直接用於測試環境探索下,驗證一些關鍵思路,加強信心),後續還須要重構-測試,在下一個時間窗口,查漏補缺,不斷完善才能夠用於時間測試。

wps3373.tmp

圖-9-腦圖用例指引

5 關於富腦圖及輕腦圖用例

容許團隊成員在模板基礎上進行變化,以發揮更多的思惟空間,主要有兩種模式做爲參考:

? 富腦圖用例

我的認爲,大腦對於圖像的記憶,比文字更長久。富腦圖,注重以圖片、圖標、圖標、關聯關係等記憶爲主。

wps3384.tmp

圖-10-富腦圖示例

? 輕腦圖用例

注重以簡潔文字記憶爲主:

wps3385.tmp

圖-11-輕腦圖示例

團隊能夠在不一樣場景,選擇合適的模板來發揮、擴散測試的思惟點。

6 總結

傳統的用例編寫,團隊大概經歷了半年,就轉向敏捷腦圖用例,以後一直堅持了三年,期間也不斷完善用例的展示以及思考的出發點。其實,在整個開發、測試環節中,思考、溝通是最重要的環節,把產生的、達成共識的內容記錄下來,聚集在腦圖中展示,就能夠看到整個需求點測試的全景圖,而後再不斷細化成測試故事點,這徹底符合思惟擴散以及總結的模式,大腦也容易接受,並且能夠不斷重構->測試->重構->測試,不斷迭代下去。

固然,有些人會問:腦圖用例裏面的故事點怎麼保證人人都看懂,能作到100%覆蓋需求,bug爲0嗎?軟件測試不可能找到100%的bug,這是對測試的誤解,所以不建議實施腦圖用例的幾點:

一、抱着經過腦圖用例把需求覆蓋100%、bug爲0;

二、對業務不熟悉,看不到腦圖用例的故事點,由於它有時候比較隱晦;

三、團隊及主管沒有耐心;

四、經過外包作測試,須要詳細用例執行步驟、測試報告;

五、研發、測試沒有溝通,只有研發完成交付,測試才介入;

腦圖用例,不只對研發自身素質要求高,測試要求也高,不僅僅要有相關測試經驗,並且也要有相關開發經驗,能夠理解開發過程遇到的問題甚至有時候須要滲入到開發代碼中去排查。最後一張圖,展現了腦圖用例在Scrum框架中所處的位置,實際是貫穿整個從需求到運營階段:

wps33A5.tmp

圖-12-Scrum流程框架

相關文章
相關標籤/搜索