自动化测试设计实例－某广告系统自动化测试设计

来源：互联网发布：软件培训机构大学生编辑：程序博客网时间：2024/05/16 19:32

1 自动化测试框架

1.1 测试流程

1.1.1 测试流程图

自动化测试包括系统的安装和配置、模拟器的安装和配置、公用测试数据的准备、测试数据和配置的更新以及自动化测试脚本。如下图：

1.1.2 测试流程说明

系统测试准备：系统的安装和配置、模拟器的安装和配置、公用测试数据的准备这些动作，是自动化测试开始的前提，在自动化测试过程中的一次性行为。在系统测试中，公共的测试数据可以供整个系统使用，这些数据在系统安装配置完成后使用自动化测试脚本创建，创建好后存放在XML文件中。使用XML存放的好处是数据的复用。

功能测试类：同属某功能的测试用例放在同一个JAVA测试类中，该测试类从XML文件中读取公共测试数据并验证测试数据的合法性，如果测试数据合法则使用这些测试数据，否则创建一套新的公用测试数据并将这套公共测试数据存放到XML文件中供其它测试类使用。同时，创建适合这个功能测试类使用的测试数据，并配置适合该功能测试类的配置参数。

测试用例：如果某个测试用例需要某些特殊的测试配置和数据，在具体的某个测试用例开始的时候进行，在准备好数据后，获取当前测试数据的状态和设置预期结果，然后执行测试步骤，当所有的测试步骤都测试完成后检查测试结果。最后，一定要恢复测试环境，如果公共测试数据或配置被修改，一定要在测试用例结束的时候恢复。

1.2 测试结构

自动化测试框架由Data, Action, Verification, Cases和Util组成。如下图：

1.2.1 Data

主要用于存放公共测试数据的定义，比如要创建的公用测试数据的定义，创建测试数据的Action在创建数据的时候从Data定义文件中读取输入，然后创建符合测试要求的测试数据。

也用于存放数据结构的定义，比如，短消息的结构体定义或某测试对象的属性定义。

Data中还会有常量定义，常量在整个系统中全局使用。

1.2.2 Action

在测试过程中需要进行的任何操作，比如：配置、创建数据、测试步骤等。

1.2.3 Verification

在测试完成后，对测试结果进行验证的类和方法。比如：检查接收到的广告内容是否正确。

1.2.4 Cases

测试用例存放目录，相关功能的测试用例放在同一测试子目录中，同一功能的测试用例放在同一个测试类中。

1.2.5 Util

主要是用于存放工具类。

1.3 命名规则

1.3.1 包（Package）

· Allother letters are lowercase

· E.g.pushcampaign

1.3.2 类（Class）

· Thefirst letter of every word is capital, all other letters lowercase

· Theclass including test cases should end with XXXTest.java, or else should beXXX.java

· Forexample: PushCampaignTest.java

1.3.3 变量（Variable）

· Thefirst letter of the first word is lowercase.

· Thefirst letter of the every word except the first word is capital.

· Allother letters are lowercase.

· Forexample: dailyBudget.

1.3.4 常量（Constant）

· Allletters are capital

· Thename should be meaningful

· Thename of different words should be joined by “_”

· Thename should start with “DEFAULT”

· Forexample: DEFAULT_COUNTRY

1.4 基本原则

自动化测试的基本原则：

· Reliable

· Readable

· Extensible

· Maintainable

· Practicable

· Repeatable

2 Data

2.1 测试数据

测试数据可分为三种：公用测试数据、功能类测试数据和用例测试数据三种。

2.1.1 公用测试数据(Common Test Data)

公用测试数据是测试系统中所有测试用例都能使用的数据，在自动化测试用例开始运行前首先创建一套供所有测试用例使用的公用测试数据，这些数据可以包括：

· ServiceProvider

· Publisher

· PublisherPricing Agreement

· Site

· Inventories(One inventory for one channel)

· AdSales

· AdSales Pricing Agreement

· MediaAgency

· MediaAgency Pricing Agreement

· Campaign(One campaign for one campaign type)

· Consumer

公用数据应存放在XML文件中供所有测试类使用，测试类在测试开始前先从XML文件中读取测试数据，并验证测试数据的合法性，如果测试数据非法则需要重新创建并保存到XML文件中。

公用测试数据的创建流程：

· 根据数据定义文件创建公用测试数据(createCommonTestData)

· 保存公用数据到XML文件中(storeCommonTestDataToFile)

在测试类中使用公用数据的流程：

· 从XML文件中读取公用测试数据(readCommonTestDataFromFile)

· 校验公用测试数据的合法性：存在于系统并且状态正常(verifyCommonTestData)，如果数据非法则重新创建。

使用公用数据的好处是避免重复创建测试数据，节省自动化测试的时间。而存放测试数据到XML的好处是一方面可以重复使用这些测试，另一方面是遇到问题的时候可以方便地使用保存在XML的测试数据进行问题跟踪。

公用测试数据不建议修改，如果非要修改，一定要记得恢复。

2.1.2 功能类测试数据(Functionality Test Data)

同一功能的测试用例放在同一测试类中，当公用测试数据满足不了这个测试类并且某些测试数据又可以供这个测试类的大部分测试用例使用时，在测试用例开始运行前创建功能类测试数据。

2.1.3 用例测试数据(Case Test Data)

某些测试用例需要特殊的测试数据，而且这些测试数据只适合于某个测试用例，则在这个测试用例测试前准备该测试用例的测试数据。

每个与广告投递相关的测试用例，都创建一个唯一的用户，这样做的好处是方便计费日志的检查，并且，当用例运行失败的时候，唯一的用户ID也方便定位出错的原因。

2.2 测试数据常量化

公用测试数据应该用常量定义，这些常量在创建数据、使用数据、校验测试结果的时候可以使用。这样可以避免测试数据写死在测试用例中，当某个值被改变或参数被删除的时候，所带来的维护工作量。

比如，每个广告投递一次需要1元，定义常量CAMPAIGN_DELIVERY_COST=1，那么在数据创建的时候可以使用CAMPAIGN_DELIVERY_COST这个常量，并且在检查这个广告投递成功后是否扣除1元也可以使用这个常量。

2.3 测试数据结构体

测试数据或测试对象定义测试结构体，供Action/Verification/Cases使用，比如：Publisher或Campaign这些测试数据根据它们的属性构成测试数据结构体；又如：短信广告内容这些被测试检查对象也根据他们的属性组成测试对象数据结构体。

3 Action

Action，顾名思义，就是在测试的过程中所作的任何操作。Action在自动化测试中可分为所有或某些测试类都可以使用的公用Action和某类或某个测试用例使用功能类Action两种，而这两种Action又可以分为原子Action和组合Action。

Primitive Action就是一个不可被分割的简单操作，而Composite action则是由若干个Primitive Action组成的操作，如果某几个Primitive Action会被两个以上的地方使用，那么这几个动作应该封装成一个Composite Action。

3.1 公用测试操作(Common Action)

以下这些测试动作是全局使用的：

· getCampaignBudgetImpressionClicks

· getInventory

· getChannel

· optinConsumersByWebservice

以下这些测试动作，适合于所有PUSH广告相关的测试，包括push campaign, survey campaign, incentive reward campaign和direct market campaign等与PUSH相关的测试场景：

· configurePushEnvironment

· receiveSmsAd/ receiveMmsAd

· returnSmsAdResponse/ returnMmsAdResponse

· sendSmsAdDeliveryReport/ sendMmsAdDeliveryReport

· receiveSmsAdDeliveryReportResponse/ receiveMmsAdDeliveryReportResponse

· sendSmsMo/ sendMmsMo

· receiveSmsMoResponse/ receiveMmsMoResponse

这些Action都是一些原子操作，这些原子操作将会被每类广告的Action根据每类广告的业务逻辑调用组成复合操作。

3.2 功能类测试操作(Functionality Action)

每类广告的测试场景所使用到的测试动作将放到对应的目录下。

3.2.1 PullCampaign

Pull Campaign的广告测试场景中，将会有这些Primitive Action：

· fetchPullAd

· fetchPullAdContent

· clickPullAd

· sendPullAdDeliveryReport

· sendActionReport

· fetchRingBackAd

· sendRingBackAdDeliveryReport

Pull Campaign的广告测试场景中，将会有这些由Primitive Action组合成的Composite Action：

· fetchPullAdAndCheckReponse

· clickPullAdAndCheckResponse

· sendPullAdDeliveryReportAndCheckResponse

· sendActionReportAndCheckResponse

· fetchRingBackAdAndCheckResponse

· sendRingBackAdDeliveryReportAndCheckResponse

3.2.2 PushCampaign

在PUSH CAMPAIGN 广告测试场景中，将会调用公用的Primitive Action组合成这些被测试用例调用的CompositeAction：

· receivePushAdAndCheckMessage

· clickPushAdAndCheckResponse

· receivePushAdButReturnFailResponse

· receivePushAdButNotReturnResponse

· receivePushAdButReturnFailDeliveryReport

· receivePushAdButNotReturnDeliveryReport

· receiveMultiplePushAdAndCheckMessage

3.2.3 SurveyCampaign

在Survey Campaign广告测试场景中，将会调用公用的Primitive Action组合成这些被测试用例调用的CompositeAction：

· receiveSurveyAndReplyThenCheckMessage

· receiveSurveyButReplyInvalidFirstAnswer

· receiveSurveyButReturnFailedResponseForFirstQuestion

· receiveSurveyAndReplyButNotReturnResponseForLastQuestion

· receiveSurveyAndReplyButReturnFailedDeliveryReportForLastQuestion

· receiveSurveyButNotReplyAnyAnswer

4 Verification

Verification就是对测试结果的校验。Verification在自动化测试中可分为所有或某些测试类都可以使用的公用Verification和某类或某个测试用例使用功能类Verification两种，而这两种Verification又可以分为PrimitiveVerification和Composite Verification。

Primitive Verification就是一个不可被分割的简单操作，而Composite Verification则是由若干个Primitive Verification组成的操作，如果某几个Primitive Verification会被两个以上的地方使用，那么这几个动作应该封装成一个Composite Verification。

4.1 公用测试校验(Common Verification)

在测试完成后，不管是哪类型的广告，都需要校验广告一次花费的钱、交易日志等：

· checkCampaignBudgetImpressionClicks

· checkTransactionLog

· checkImpressionLog

· checkClickLog

· checkReportingData

对于PUSH相关的广告，还需要校验递送历史、检查短信或彩信内容：

· checkDeliveryHistory

· checkSmsMessage

· checkMmsMessage

4.2 功能类测试校验(Functionality Verification)

根据每类广告的测试场景的不同，相应的也会有不同的校验动作。

4.2.1 PullCampaign

Pull Campaign的广告测试场景中，会使用到这些Primitive Verification：

· checkFetchPullAdResponse

· checkClickPullAdResponse

· checkSendPullAdDeliveryReportResponse

· checkSendActionReportResponse

· checkFetchRingBackAdResponse

· checkSendRingBackAdDeliveryReportResponse

Pull Campaign的广告测试场景中，将会有这些Primitive Action & Primitive Verification组合成的CompositeVerification：

· fetchPullAdAndCheckReponse

· clickPullAdAndCheckResponse

· sendPullAdDeliveryReportAndCheckResponse

· sendActionReportAndCheckResponse

· fetchRingBackAdAndCheckResponse

· sendRingBackAdDeliveryReportAndCheckResponse

事实上，这是由Primitive Action & PrimitiveVerification组合的操作，原则上，动作应该和检验是分开的，但考虑到这个动作和校验之间的关系非常密切，并且每个原子动作的后面都跟一个原子校验的话，测试用例就会显得非常臃肿。

为了统一，所有由Primitive Action & PrimitiveVerification的组合都归类到Action中。

4.2.2 PushCampaign

在PUSH CAMPAIGN 广告测试场景中，将会调用公用的Primitive Verification：

· checkSmsMessage

- checkmsisdn and AD content

· checkMmsMessage

- checkmsisdn and AD content

· checkSmsAdDeliveryReportResponse/ checkMmsAdDeliveryReportResponse

· checkSmsMoResponse/ checkMmsMoResponse

和Pull Campaign的广告测试场景一样，在Push Campaign的测试场景中，也会有这些Primitive Action & PrimitiveVerification组合成的Composite Verification：

· receivePushAdAndCheckMessage

· clickPushAdAndCheckResponse

· receivePushAdButReturnFailResponse

· receivePushAdButNotReturnResponse

· receivePushAdButReturnFailDeliveryReport

· receivePushAdButNotReturnDeliveryReport

· receiveMultiplePushAdAndCheckMessage

同样地，在PUSH CAMPAIGN测试中，所有由Primitive Action & Primitive Verification的组合都归类到Action中。

4.2.3 SurveyCampaign

在Survey Campaign广告测试场景中，将会调用公用的Primitive Verification组合成这些被测试用例调用的Composite Verification：

· checkSurveyTransactionLog

和Pull Campaign的广告测试场景一样，在Push Campaign的测试场景中，也会有这些Primitive Action & PrimitiveVerification组合成的Composite Verification：

· receiveSurveyAndReplyThenCheckMessage

· receiveSurveyButReplyInvalidFirstAnswer

· receiveSurveyButReturnFailedResponseForFirstQuestion

· receiveSurveyAndReplyButNotReturnResponseForLastQuestion

· receiveSurveyAndReplyButReturnFailedDeliveryReportForLastQuestion

· receiveSurveyButNotReplyAnyAnswer

同样地，在Survey CAMPAIGN测试中，所有由Primitive Action & Primitive Verification的组合都归类到Action中。

5 Cases

5.1 测试用例实现策略

5.1.1 测试用例编写原则

· 测试用例应该具有清晰的结构，调用Data，Action或Verification组成一个完整测试用例。测试用例看到的就是一个业务流程，而这些业务流程的描述是由若干个Data，Action或Verification。

· 测试用例的注释应该遵循“Given…When…Then…Finally…”的原则，也就是：

- Givenfor preparation or pre-condition

- Whenfor test operation

- Thenfor test result verification

- Finallyfor test environment recover

· 测试用例按功能模块划分，具有相同功能的测试放到一个测试类中，而功能相关的测试类则放到同一个测试包中。

· 每个测试用例都必须是可读、可独立运行、可信赖的和可稳定运行的。在写测试用例的时候，需要连续运行测试类5次以上都成功才可以证明用例的稳定性。

· 每种类型的测试用例将会提供一个例子，供其他人写测试用例时参考。

5.1.2 测试用例组成流程图

以下是一个完整的测试用例的流程图：

5.2 PullCampaign

Pull Campaign的广告测试场景中，可以划分为广告流程测试场景和业务逻辑测试场景。

其中，广告业务流程测试场景有：

· WAPAdScenarioTest

· UssdAdScenarioTest

· PartialSmsAdScenarioTest

· NetworkAdScenarioTest

· HouseAdScenarioTest

· ApplicationAdScenarioTest

· RingBackAdScenarioTest

业务逻辑测试场景有：

· PullCampaignTargetingScenarioTest

· PullCampaignFilteringScenarioTest

· PullCampaignChargingScenarioTest

5.3 PushCampaign

在PUSH CAMPAIGN 广告测试场景中，业务流程测试用例有：

· PushCampaignSMSAdSigScenarioTest

· PushCampaignSMSAdIpxScenarioTest

· PushCampaignSMSAdHubScenarioTest

· PushCampaignMMSAdSigScenarioTest

· PushCampaignMMSAdIpxScenarioTest

· PushCampaignMMSAdHubScenarioTest

业务逻辑测试用例有：

· PushCampaignTargetingScenarioTest

· PushCampaignFilteringScenarioTest

· PushCampaignChargingScenarioTest

5.4 SurveyCampaign

在Survey Campaign广告测试场景中，业务流程测试场景有：

· SurveyCampaignSigScenarioTest

· SurveyCampaignHubScenarioTest

业务逻辑测试场景有：

· SurveyCampaignFilteringScenarioTest

· SurveyCampaignTargetingScenarioTest

6 Util

和所有的JAVA编码项目一样，在自动化测试框架中，Util主要用来存放一些工具类。

7 例子

这一章，我们一起来看一下已经实现的几个例子。

7.1 PullCampaign

以下是一个Pull Campaign自动化测试例子：

@Groups(Groups.MAJOR)

@Test

public void fetchWapBannerAdAndClickToSite() {

//Given weget the campaign original budget before fetching a WAP Ad

String[] oldTotalDelivered = getBudget(getCampaign());

//And opt inone consumer

consumers = multiGenerateMinimalConsumerData(getOperatorData().operatorId, 1);

optInConsumers(consumers, webServicesConsumerCreator);

//And get the inventory id

InventoryData inv = getInventoryByChannel(getChannel());

//And set theAd Type

setAdTypeParameter(AdTypeParameter.ADTYPE_BANNER);

//When fetcha WAP banner

fetchAd(consumers[0], inv.getInventoryId());

//And clickWAP banner

clickAd();

//Then checktransaction log

client.execute(new Wait(20));

int[] expectResponseCodes = { 2000, 4000 };

checkTransactionLog(consumers, expectResponseCodes, getChannel(), true);

//And checkimpression log

checkImpressionLog(consumers, true);

//And checkclick log

checkClickLog(consumers, true);

//And checkbudget

client.execute(new Wait(10));

checkBudget(oldTotalDelivered, inv.getInventoryId(), 1, false);

}

从这个例子，我们可以看到，测试用例呈现的是一个非常清晰的测试场景，它调用Action来完成测试步骤，调用Verification进行测试结果的检查。

7.2 PushCampaign

下面这个是Push Campaign自动化测试的例子：