GUI自動化測試系列一測試用例的設(shè)計(jì)及自動生成

GUI自動化測試系列一測試用例的設(shè)計(jì)及自動生成第1頁/共27頁目錄

Contents背景介紹測試用例生成技術(shù)使用方式02延時(shí)符第2頁/共27頁1自動化測試背景介紹延時(shí)符第3頁/共27頁延時(shí)符對于自動化測試，很多項(xiàng)目經(jīng)理甚至測試人員都有誤解，認(rèn)為自動化測試越多越好，在某種程度上說這種理解是正確的，但是我們更應(yīng)該對app自動化測試進(jìn)行分析和設(shè)計(jì)。各階段的自動化測試各有特點(diǎn)。自動化測試簡介第4頁/共27頁延時(shí)符自動化測試簡介雖然單元測試發(fā)現(xiàn)修改問題成本低，方便自動化，但是單元測試無法從全局觀的角度了解系統(tǒng)模塊間的交互，也無法通過方法、組件的組合幫助用戶完成業(yè)務(wù)目的，而基于GUI的測試描述的是從用戶角度出發(fā)的用戶使用場景，因此更容易闡述用戶的行為和業(yè)務(wù)需求?；贕UI的測試描述測試的層級更高，所以也就更接近于業(yè)務(wù)，而單元測試更接近于實(shí)現(xiàn)。不同層級的測試都很有必要，而我們要根據(jù)不同測試所處的層級和其特點(diǎn)來進(jìn)行測試設(shè)計(jì)第5頁/共27頁延時(shí)符GUI自動化測試設(shè)計(jì)基于用戶界面的自動化測試層級最高，需要準(zhǔn)備的測試環(huán)境和測試數(shù)據(jù)更復(fù)雜，運(yùn)行時(shí)間更長，所以我們應(yīng)該把其他測試層級能覆蓋的測試盡可能的推到更底層的測試層級。由于機(jī)器比較適合做簡單重復(fù)，但工作量大的工作，因此設(shè)計(jì)GUI自動化測試時(shí)，原則是盡可能編寫用戶旅程級別的測試用例，而對于一些復(fù)雜的反向功能測試用例，例如需要特定環(huán)境或復(fù)雜操作的測試應(yīng)該給手工測試執(zhí)行。否則維護(hù)成本過高。第6頁/共27頁延時(shí)符GUI自動化測試設(shè)計(jì)用戶旅程（UserJourney）是一個用戶體驗(yàn)設(shè)計(jì)的術(shù)語，指的是為達(dá)到某種特定目的，用戶所執(zhí)行的一系列操作的集合第7頁/共27頁延時(shí)符GUI自動化測試設(shè)計(jì)一個簡單的注冊功能，能想清楚有多少操作路徑嗎？全憑經(jīng)驗(yàn)覆蓋？有沒有更標(biāo)準(zhǔn)的方法？能不能有像爬蟲一樣的工具搜索出路徑？第8頁/共27頁2基于UML圖模型的測試用例自動生成技術(shù)延時(shí)符第9頁/共27頁功能測試用例自動生成技術(shù)幾十個頁面，內(nèi)容都差不多，全部都要寫用例，能不能自動化生成，自動執(zhí)行？第10頁/共27頁功能測試用例自動生成技術(shù)功能測試人員應(yīng)該把主要精力放在測試設(shè)計(jì)上，像一個設(shè)計(jì)師一樣工作！讓復(fù)制粘貼、碼字這樣的工作交給機(jī)器去做吧！第11頁/共27頁功能測試用例自動生成技術(shù)

軟件測試功能測試過程是將被測軟件系統(tǒng)看作一個黑盒，通過對它進(jìn)行一系列的操作、輸出，來查看被測系統(tǒng)是否能正常響應(yīng)和輸出。測試人員設(shè)計(jì)的測試用例即設(shè)計(jì)一系列的操作步驟和輸入來盡量完全覆蓋被測系統(tǒng)的功能路徑并確認(rèn)系統(tǒng)能合理的處理所有輸入。測試用例的生成結(jié)果依賴于所使用的模型。比如使用UML狀態(tài)圖模型時(shí)，根據(jù)一定的覆蓋準(zhǔn)則遍歷狀態(tài)間的遷移所獲得的轉(zhuǎn)換路徑就是測試路徑第12頁/共27頁UML活動圖主要包括活動狀態(tài)、對象、變遷、變遷條件、分支匯聚結(jié)點(diǎn)、決策節(jié)點(diǎn)、合并節(jié)點(diǎn)等基本元素，可以用于記錄單個操作或業(yè)務(wù)流程邏輯。測試場記是活動圖中的一個路徑序列，在活動圖上，從起始結(jié)點(diǎn)到終止節(jié)點(diǎn)任意可能的路徑，都能表示為待測軟件的一個測試場景，而活動圖可以看做是一種操作流程圖，節(jié)點(diǎn)間是有先后關(guān)系的，為了獲得活動圖中所有的測試路徑，必須通過圖的深度優(yōu)先算法來獲取所有流程路徑，通過這種方法能夠得到一個模塊的所有操作路徑覆蓋的測試用例集。

功能測試用例自動生成技術(shù)第13頁/共27頁UML活動圖向測試用例的轉(zhuǎn)換

一個典型的測試用例結(jié)構(gòu)主要包含以下部分：1、測試操作步驟；2、測試數(shù)據(jù)；3、期望結(jié)果。4、測試場景。

場景就是順序化的、確定化的系統(tǒng)執(zhí)行軌跡，測試場景是多個測試操作步驟的序列?？梢园鸦顒庸?jié)點(diǎn)作為測試用例的一個操作步驟，同時(shí)測試用例中的期望結(jié)果可以看作是一個需要驗(yàn)證的狀態(tài)，因此在活動圖中可以給用一個狀態(tài)結(jié)點(diǎn)作為測試用例的期望結(jié)果。在一個活動圖中從初始節(jié)點(diǎn)通過活轉(zhuǎn)換、分支、匯合最終達(dá)到活動終點(diǎn)，這些不同的路徑序列可以組成多個測試場景?；顒愚D(zhuǎn)換第14頁/共27頁UML活動圖向測試用例的轉(zhuǎn)換

通過UML活動圖能夠條理化的推演出所有操作，甚至能夠找出需求沒有明確說明的步驟。通過深度優(yōu)先算法遍歷所有路徑，生成的路徑遠(yuǎn)遠(yuǎn)高過人工編寫用例。最終生成的測試用例覆蓋度高于通常的人工編寫測試用例方式，并且自動導(dǎo)出到excel，減小了工作量。通過圖形化的方式描述測試場景，方便評審，比閱讀文字測試用例效率高對于樣式類似的頁面，方便復(fù)用第15頁/共27頁一個簡單的鍵盤輸入功能的例子第16頁/共27頁實(shí)現(xiàn)方法業(yè)內(nèi)通用的UML設(shè)計(jì)工具Rationalrose在畫完UML圖后會生成一個MDL文件，該文件是一種ASCⅡ碼文件內(nèi)容可以以文本文件的形式讀取程序讀取UML文件中的節(jié)點(diǎn)和轉(zhuǎn)換信息抽象成有向圖數(shù)據(jù)結(jié)構(gòu)通過有向圖深度優(yōu)先算法遍歷所有操作路徑導(dǎo)出到excel文件中做為測試用例第17頁/共27頁轉(zhuǎn)換過程（一）第18頁/共27頁轉(zhuǎn)換過程（二）第19頁/共27頁生成的測試用例示例第20頁/共27頁3使用方式延時(shí)符第21頁/共27頁在Rationalrose中新建一個活動圖第22頁/共27頁狀態(tài)圖的畫法在各節(jié)點(diǎn)的名稱上寫入步驟，打開app作為初始節(jié)點(diǎn)，以流程圖的方式推演操作，以活動轉(zhuǎn)換箭頭連接各節(jié)點(diǎn)，在需要驗(yàn)證結(jié)果的時(shí)候創(chuàng)建狀態(tài)節(jié)點(diǎn)，狀態(tài)節(jié)點(diǎn)名稱為期望結(jié)果活動節(jié)點(diǎn)狀態(tài)節(jié)點(diǎn)第23頁/共27頁狀態(tài)圖的畫法在畫完需求上說的場景后，檢查各節(jié)點(diǎn)是否可以有互通路徑第24頁/共27頁自動化測試用例生成的擴(kuò)展這種方式最后會生成很多路徑的測試用例，這些用例適合自動化執(zhí)行，生成可自動化執(zhí)行的用例的方法是：在狀態(tài)轉(zhuǎn)換的