寫在最前面 這個系列的主旨是要跟大家分享一下關於自動化測試框架的構建的一些心得。這幾年,做了一些自動化測試框架以及團隊的構建的工作。過程中遇到了很多這樣的同學,他們在學習了某一門語言和一些自動化測試的類庫或者工具之後,打算進一步的提高。我想這個系列也許會幫助到你,我們一起從各個維度來看一看自動化測試 ...
寫在最前面
這個系列的主旨是要跟大家分享一下關於自動化測試框架的構建的一些心得。這幾年,做了一些自動化測試框架以及團隊的構建的工作。過程中遇到了很多這樣的同學,他們在學習了某一門語言和一些自動化測試的類庫或者工具之後,打算進一步的提高。我想這個系列也許會幫助到你,我們一起從各個維度來看一看自動化測試框架的一些最佳實踐。本人能力有限,如果有什麼不正確的的地方還各位大牛指正。
聊聊自動化測試的初心
在開始具體的技術和理論之前,我們先來思考一下自動化測試的目的是什麼?我簡單的羅列了幾點:
- 替代手工測試中的重覆操作,讓測試人員把時間花在更有價值的地方
- 降低自動化測試用例編寫的技術門檻,即儘可能降低學習成本,提高工作效率
- 提高測試效率,在軟體開發生命周期的各個環節為質量保駕護航
- 精準的數據統計和分析,對產品質量和團隊效能提供數據支持
以上這幾點算是我們構建自動化測試的一些原因,在一開始聊這些是希望小伙伴們不要在構建框架的過程中時刻記得我們的宗旨。勿忘初心,方得始終嘛~~~(其實,很多失敗的自動化框架就是在實踐的過程中漸漸違背了上述的這些目標)
從一個測試用例開始
上來就談論技術選型,工具類庫的選擇,設計模式,生命周期這些概念也許會讓你迷茫。一個實實在在的測試用例也許是會是好的開始。希望能讓你先有一個感官的認識,後面的文章我們會一步步由淺入深的刨析這個Demo Case.
下麵這個Demo使用的是C#語言和單元測試xUnit.Net框架。如果對xUnit.Net還不是很熟悉的的同學,建議可以先看看我的另一個系列《玩轉xUnit.Net》,對於這個CASE而言瞭解單元測試的基本使用即可。
1 namespace AutoFramework.TestCase 2 { 3 public class TestSuite_Demo : TestBase 4 { 5 public TestSuite_Demo(TestContextFixture context, ServiceFixture service, DBFixture database) 6 : base(context, service, database) { } 7 8 [Fact(DisplayName = "TestCase.Demo001")] 9 public void Demo_Case_CreateCamp() 10 { 11 //-->Data preparation. 12 var userModel = ModelBuilder.ForJsonFile<UserModel>("DemoCase/TestData.json"); 13 14 //-->Test case exec way 01. 15 var signInPage = Router.GoTo<SignInPage>(); 16 var homePage = signInPage.SignIn("user-name", "pwd"); 17 var addUserPage = homePage.NavMenu.Select<AddUserPage>("User", "New"); 18 var userListPage = addUserPage.AddUser(userModel); 19 20 //-->Test case exec way 02. 21 /*You can custom this 'Workflow'*/ 22 var userListPage = Router.GoTo<SignInPage>() 23 .SignIn("user-name", "pwd") 24 .NavMenu.Select<AddUserPage>("User", "New") 25 .AddUser(userModel); 26 27 Assert.True(userListPage.IsExistUser(userModel.Name)); 28 29 30 //more 31 //this.Service.CallSomeService(someModel); 32 //this.Database.ExecSomeAction(someModel); 33 } 34 } 35 }
我在《Lesson 08 - Selenium For C# 之 PageFactory & 團隊構建》一文中,提到過自動化測試團隊的組成,而上面的Demo是基於一個成熟的框架(也就是這個系列文章所要帶你一步步構建的測試框架),所編寫的最頂層的測試用例。
首先思考一下這個問題,一個Web手工測試測試人員是如何來完成測試工作的:
- 測試用例執行前的數據準備
- 一個可以工作的瀏覽器,自由的導航到不同的頁面
- 在不同的頁面上進行的操作
- 檢查頁面上的測試點(Check Point)
- 檢查資料庫中的數據
- 檢查特定服務返回的數據
那麼,結合上面的測試用例Demo,我們來總結一下,將要實現的自動化測試框架應該為普通的用例編寫人員提供哪些的功能:
- 從外部文件中獲取測試數據的能力(ModelBuilder.ForJsonFile)
- 控制路由的對象Router,協助測試人員進行頁面導航以及PageObject對象的獲取。
- 用來描述頁面功能的PageObject對象。
- 調用系統服務的Service對象。
- 進行資料庫訪問的資料庫對象。
Note:當然,測試框架應當提供的功能遠不止這些。
讀到這裡,也許有些同學會有很多的疑問。Model是什麼?Router是如何實現的?PageObject應該如何封裝?Service 和 Database對象是怎麼實現的?等等... ... 這些問題也是這個系列的文章想要跟大家分享的,後面的文章我會逐一跟大家討論。在這裡我們還是把關註點放在這個case上面,在之前列出來的那些Router,PageObject,Model,Service對象和資料庫訪問對象都能正常工作的前提下,編寫自動化用例的人員是不是就可以很容易的完成測試用例的編寫?細心的同學也許已經發現了,這個case似乎沒有涉及到UI驅動的框架(比如:Selenium、Appnium、White...),我也沒有說這個自動化測試測試的是一個什麼樣的項目。但是,通過這段代碼:
//-->Test case exec way 01. var signInPage = Router.GoTo<SignInPage>(); var homePage = signInPage.SignIn("user-name", "pwd"); var addUserPage = homePage.NavMenu.Select<AddUserPage>("User", "New"); var userListPage = addUserPage.AddUser(userModel);
你是不是已經能大致的明白這個用例是做什麼的呢?
如果為你提供了所有對象的方法列表,你是不是也可以高效快速的完成其他的測試用例呢?回想一下我們構建自動化測試框架的初心。如果要測試人員可以像做手工測試一樣書寫自動化測試用例,是不是就做到了降低測試門檻的目的呢?這裡用到了自動化測試的一個常見的設計模式-PageObject。接下來的幾篇文章我們會針對這個模式進行講解。
看看我們將要構建的框架
任何一個框架都是一系列複雜組件的協作。我們將要一起構建的自動化測試框架會擁有下列的一些組件:
- 管理頁面路由的工具:Router
- 服務調用工具:ServiceInvoker
- 資料庫訪問工具:DataKeeper
- 針對PageObject模式
- Action封裝
- CheckPoint封裝
- Component封裝
- 異常處理工具
- 日誌管理工具
這一篇就先到這裡啦~~,自動化測試框架的構建是需要一定知識基礎和自動化測試經驗的。希望我們能在接下來的這段時間里一起提高,同樣也希望我的觀點對你有所啟發和幫助~~~
小北De系列文章:
《[小北De編程手記] : Selenium For C# 教程》
《[小北De編程手記]:玩轉 xUnit.Net》(未完成)
如果您認為這篇文章還不錯或者有所收穫,可以點擊右下角的【推薦】按鈕,因為你的支持是我繼續寫作,分享的最大動力! 作者:小北@North 來源:http://www.cnblogs.com/NorthAlan 聲明:本博客原創文字只代表本人工作中在某一時間內總結的觀點或結論,與本人所在單位沒有直接利益關係。非商業,未授權,貼子請以現狀保留,轉載時必須保留此段聲明,且在文章頁面明顯位置給出原文連接。