其實市面上做接口測試的工具很多,爲啥挑這兩個來講解了,重點是真心好用。好了,廢話不多說,直接上乾貨。

相信有一定了解的人都知道這兩個工具應用最廣泛的就是接口測試,既然提到接口測試那我們不得不先普及下什麼是接口,接口測試又是啥?

我們常說的接口一般指下面兩種:

1、API:應用程序編程接口。程序間的接口

2、GUI:圖形用戶界面。人與程序的接口

我們這裏說的接口測試主要指API接口測試,API接口分類一般有如下幾種:

· HTTP接口

·Webservice接口

·RESTful接口

HTTP,RESTful接口走HTTP協議,通過路徑來區分調用的方法,請求報文入參有多種形式,返回報文一般爲json串,最常見的是get和post方法。

WebService接口是走soap協議,請求報文和返回報文都是xml格式。

而 Postman和SopaUI支持的接口類型如下:

因此,我們需要先辨別項目前後端是用何種接口交互再來選取相應的接口測試工具。

接口測試又是啥?

接口測試就是模擬客戶端向服務器發送請求報文,服務器接收請求報文後對相應的報文做處理並向客戶端返回應答,客戶端再接收應答然後對應答做一些校驗的過程。

下面我們分別介紹下如何用PostMan和SoapUI做接口 自動化測試。

A:Postman+Newman+Jenkins實現接口自動化測試

1.安裝Postman,編寫API接口測試用例

示例:豆瓣公開查找書籍接口

2.導出Collection(項目-接口用例),安裝NewMan,用NewManCommand運行Collection並輸出HTML報告。

C:\Users\Li.Shi\AppData\Roaming\npm\newmanrunC:\Users\Li.Shi\Desktop\PostMan\LiShiTest.postman_collection.json--reporterscli,json--reporterscli,html--reporter-html-exporthtmlOut.html

3.安裝部署Jenkins,其中Jenkins的配置如下:

至此,我們可完成基於postman和Jenkins的自動化接口測試。

B:SoapUI+UnitTest 實現接口自動化測試

1.安裝SoapUI,自行創建一個可運行的SoapUI的Project,得到項目XML文件.eg:DeviceReportService-soapui-project.xml

2.用VS(Visual Studio)創建一個Unit Test Project.添加reference,Check System, System.Configuration, System.Core, System.Data

3.添加app config文件,指定soapUI TestRunner.exe所在路徑.

4.添加SoapUIRunner公共類,通過新建Process去調用TestRunner.exe命令進而運行SoapUI的case.

using Microsoft.VisualStudio.TestTools.UnitTesting;

using System;

using System.Collections.Generic;

using System.Diagnostics;

using System.IO;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

namespace SoapUI

{

public class SoapUIRunner

{

public void RunSoapUItest(string soapProject,string testSuiteName,string testName,string report,string set)

{

const string fileName = "cmd.exe";

var soapProjectFileName = Path.GetFullPath(soapProject);

var arguments = string.Format("/C testrunner.bat -s\"{0}\" -c\"{1}\" \"{2}\" -r -a -f\"{3}\" -t\"{4}\" ", testSuiteName, testName, soapProjectFileName, report, set);

var soapHome = System.Configuration.ConfigurationManager.AppSettings["SoapUIHome"];

//start a process and hook up the in/output

var process = new Process

{

StartInfo = new ProcessStartInfo

{

FileName = fileName,

Arguments = arguments,

WorkingDirectory = soapHome,

Verb = "runas",

CreateNoWindow = true,

ErrorDialog = false,

RedirectStandardError= true,

RedirectStandardOutput = true,

UseShellExecute = false

},

EnableRaisingEvents = true

};

//pipe the output to console.writeline

process.OutputDataReceived += (sender, args) =>

Console.WriteLine(args.Data);

var errorBuilder = new StringBuilder();

//store the errors in a stringbuilder

process.ErrorDataReceived += (sender, args) =>

{

if (args != null && args.Data != null)

{

errorBuilder.AppendLine(args.Data);

}

};

process.Start();

process.BeginOutputReadLine();

process.BeginErrorReadLine();

//wait for soapUI to finish

process.WaitForExit();

//fail the test if anything fails

var errorMessage = errorBuilder.ToString();

if(!string.IsNullOrEmpty(errorMessage))

{

Assert.Fail("Test with name '{0}' failed. {1} {2}", testName, Environment.NewLine, errorMessage);

}

}

}

}

5.通過Unit Test調用SoapUI TestSuit, 進而可以運用bat命令集成運行TestCase. 做到接口的自動化測試。

{

[TestClass]

[DeploymentItem(@"soapUIFiles\DeviceReportService-soapui-project.xml", "TestData\\soapUIFiles")]

public class DeviceReport:SoapUIRunner

{

private string testCaseSuiteName = "BasicHttpBinding_DeviceReport TestSuite";

private string soapProjectFile= @"TestData\\soapUIFiles\\DeviceReportService-soapui-project.xml";

private string reportFile = @"C:\Users\" + Environment.UserName + "\\Desktop\\TestReport";

private String SoapUISettingsFile = @"TestData\\soapUIFiles\\soapui-settings.xml";

private TestContext testContext;

public TestContext TestContext

{

get { return this.testContext; }

set { this.testContext = value; }

}

[TestMethod]

[TestCategory("DeviceReport")]

public void Device_Report()

{

RunSoapUItest(soapProjectFile, testCaseSuiteName, "DeviceReport TestCase", reportFile, SoapUISettingsFile);

}

}

}

接下來我們對比下用方式A和B做接口自動化的區別:

1.從上面的實現來看,SoapUI自動化需要測試人員有一定的編碼能力,想比如Postman會對測試人員要求高些。

2.從兩種工具用例組織方式來看:

SoapUI的組織方式如下圖,最上層是WorkSpace,所以每個WorkSpace中可以打開多個Project,一個Project也可以在不同的WorkSpace中。

Project對應我們的測試項目,其中可添加WSDL、WADL資源、TestSuite以及MockService。

TestSuite對應我們的測試模塊,比如商戶中心,其中可以添加TestCase,TestCase對應我們對某個模塊的不同接口,比如訂單管理接口。而一個接口可以能需要多個Step完成,變量、數據源、請求等都是一個Step。

Postman功能上更簡單,組織方式也更輕量級,它主要針對的就是單個的HTTP請求。Collection就相當於是Project,而Collection中可以創建不定層級的Folders,可以自己組織TestSuite。每個Request可以當做是一個TestCase或者Step:

3.從長期的團隊協作來看:

SoapUI:本身一個project是一個xml文件,但是可以通過配置變成一系列文件夾,每個Case、每個Suite均是獨立的文件,這樣可通過svn/git/TFS進行團隊協作。支持性較好。

Postman:有團隊協作的功能,需要付費。

因此從項目支持的接口類型,不同集成測試需求和後期維護來考慮,我們可以根據上面幾點選擇適合自己項目的接口自動化工具。

查看原文 >>
相關文章