自动化测试中的AW的分类

Posted 2023-05-05

自动化测试中的AW的分类如下：

1、代码对象：一般为用C++、Delphi、VB、VFP、PB以及NetForm等技术开发的桌面程序；

2、Java对象：一般为用Swing、SWT等技术开发的桌面程序；

3、IE网页对象：一般性的网站，比如大的门户类网站；

4、Flex对象：网页的内容是用Flex开发。

自动化测试原则

自动化测试通常分UI自动化测试、接口自动化测试、性能自动化测试，甚至暴力测试等，有非编码工具，也有编码的框架。自动化测试原则是执行自动化测试，需要了解其的一些原则和前置条件。前置条件是当系统的功能或者接口稳定时，进行该环节测试。

同学们要注意功能、业务尽量覆盖回归测试，至少保证核心业务功能能自动化测试，自动化测试必须以不能影响功能测试作为前提，自动化测试必须在系统或者业务流程文档后开展，该点与前提条件相同。

参考技术A

自动化测试中的AW的分类：

1、代码对象：一般为用C++、Delphi、VB、VFP、PB以及NetForm等技术开发的桌面程序。

2、IE网页对象：一般性的网站，比如大的门户类网站。

3、Java对象：一般为用Swing、SWT等技术开发的桌面程序。

4、Flex对象：网页的内容是用Flex开发的。

测试过程分析

创建AW的主要原因是要解决自动化测试，用例有的时候非常多，一旦AW设计有问题，要修改的，要不影响到用例的自动化测试步骤的修改。

AW不暴露底层实现的细节，比如访问web的自动化，要是使用windows的power shell来封装实现，在AW层面就不应该暴露power shell的东西，因为竟来可能发现selenium2替换AW的底层实现会更好的话，大量的自动化用例是不需要更改的。

自动化在集成测试中的应用（案例分析）

案例介绍

软件测试在软件开发周期中的重要性毋庸置疑，但如何最大化实现测试的投入产出是个值得研究的问题。如今，测试分类及测试手段越来越丰富，测试工具及测试框架也日渐成熟。

SAP测试团队致力于尽早介入开发过程中并监控各个测试环节，尽快发现并解决风险。为了解决前后端测试的依赖性以及提高后端逻辑的质量，我们将自动化应用于集成测试中，并实现前后端独立的集成测试。

一、问题的提出

为了提高测试的效率，测试团队在测试过程中引入了自动化测试，将其应用在了验收测试、性能测试、压力测试、代码扫描等方面。性能测试、压力测试及代码扫描等主要依靠工具完成，所耗费的工作量不大。

相比较而言，验收测试的自动化投入较大，我们采用基于Thucydides的web自动化测试框架来模拟用户操作，实现系统的验收及回归测试。测试人员需要编写大量的测试脚本，而且需要根据页面的变化及时更新，所以测试脚本的编写及运行对产品的稳定性要求较高。

敏捷开发的模式使得我们的开发周期较短而且需求变化大，这都增加了实现验收测试自动化的难度。此外，由于自动化验收测试的脚本开发投入较大，所以其测试覆盖的范围较小并且很难测试异常流程。单纯依靠自动化验收测试很难发现软件后端逻辑所存在的问题，因此要用黑盒测试及单元测试来保证后端逻辑的正确性。

最初，我们希望通过加大单元测试的比例来保证逻辑的正确性，提高软件质量，减少测试人员黑盒测试工作量。但由于敏捷开发周期短、任务重，开发人员的单元测试的完成度较差，代码覆盖率较低，无法保证逻辑的正确性及稳定性。

因此，我们希望测试团队能够寻求一种方法保证产品逻辑的正确性，来弥补自动化验收测试的不足。

二、解决思路

我们自动化测试扩展至端到端的集成测试，并降低集成测试的颗粒度，代替开发团队的单元测试。

在实践中我们发现，集成测试对于软件质量的影响非常大。

因为通常多数bug并不来源于程序本身，而是通过外部输入的数据所引起的。在开发团队进行单元测试的过程中，开发人员往往依靠自己设定一些简单测试数据来检验程序是否会按照预期的方式运行。这些数据较真实数据差距很大，且异常数据的覆盖率较低，所以很难发现真正的问题。

为了提高软件质量，我们测试团队在已有的自动化测试的基础上，将验收测试的测试数据和测试用例进行扩展，利用QUnit框架实现后端服务的集成测试，加大对集成测试的自动化投入。

希望达到的验收测试、集成测试及单元测试的投入比例如下：

图1. 测试比重对比图

案例的目标如下：

（1）独立的前后端测试

（2）减少开发人员单元测试工作量

（3）模拟异常数据，提高测试覆盖率

三、实践过程

在最初的实践过程中，我们希望由开发团队实现自动化的集成测试，但从如下几个方面考虑后决定由测试团队实现。

（1）重复工作

测试团队在实现验收测试的过程中，已经完成了端到端的测试用例，并且准备了相应的测试数据。如果由开发团队开发集成测试，开发人员需要理解并改进已有的测试用例及测试数据，造成了部分重复工作。

（2）运行及分析时间长

集成测试往往运行时间较长，平均一个测试用例要花费几分钟的时间，通常一个敏捷开发周期至少有60到100个的测试用例，全部运行完成并分析结果需要较长的时间，开发人员在一个周期内开发任务较重，很难频繁监控并分析集成测试。

（3）沟通花费大

一般开发人员花费很短的时间就可以完成一个单元测试，但为了完成某一个逻辑的集成测试，可能涉及到多个开发人员的功能接口，所花费的沟通时间及编写测试脚本的时间较长，对于开发团队压力太大。

经过分析，我们决定由测试团队实现自动化的集成测试。

下面详细介绍具体的实施过程：

（1）独立的前后端测试环境

为什么要将前后端的集成测试分开呢？因为在实践中我们发现，通常在开发周期的后期，前后端开发人员才完成本周期的需求并完成联调，这时测试团队才可以得到一个可执行的产品，并进行测试脚本的开发工作。

因此，在一个敏捷开发周期结束时，集成测试以及验收测试的自动化脚本的开发都难以完成。为了不受前后台联调的限制，我们决定将前后端的集成测试分开，为测试脚本的开发和执行正确更多的时间。

我们将后端的remote service连接调用真实的remote serve。前端仿照remote service定义一致的mock service， mock service调用测试团队准备好的mock data，模拟remote server上的数据。

这样前端的集成测试便不会依赖于后端逻辑的开发进度，测试团队可以同步进行前端和后端的集成测试。Local mock data由测试人员提供并掌控，测试人员可根据测试用例的需要来修改local mock data。

图2. 独立的前后端测试环境

（2）基于Thucydides的前端自动化测试

在需求确定后，架构工程师根据需求定义remote service及mockservice。测试人员模拟remoteserver上的数据建造mockdata。

此时前端开发人员进行前端代码的编写，调用mockservice进行调试。测试人员利用Thucydides编写前端集成测试脚本，在前端集成测试中要注意如下几点：

①测试数据

测试数据的编写要以local mock data为基础，因为mock service调用的是mock data，所以此时系统的初始数据及各种操作的返回数据全来自于local mock data。

②配置文件

为了在之后的验收测试中重用前端自动化测试，在前端自动化测试的开发过程中，测试数据、测试环境、测试用户等最好抽象成变量，并将数据维护在外部文件中，便于修改及重用。

③测试目标

前端的集成测试的主要目的是检验响应的正确性，侧重检查前端页面操作，功能逻辑的正确性将放在后端集成测试中进行验证。因此前端的测试用例及测试数据多为正常流程的测试。

图3. 前端自动化测试

（3）基于QUnit的后端自动化测试

为了测试后端逻辑，我们将后端的ABAP方法抽象成为web service，利用QUnit进行后端逻辑的自动化测试。QUnit是jQuery团队开发的JavaScript单元测试工具，功能强大且使用简单。

目前所有的JQuery代码都使用QUnit进行测试，原生的JavaScript也可以使用QUnit。QUnit有很多优点，使用起来非常方便，界面美观并且测试功能完整。此外，QUnit非常简单，容易上手，不需要依赖其它任何软件包或框架，本身只有一个JS文件和CSS文件，只要能运行JS的地方就可以。

在remote service定义好后，后端人员进入开发阶段。但remote server的数据通常由第三方提供，存在滞后性，且我们不能完全了解和控制第三方数据。无法掌握数据给设计测试用例带来困难。

因此，在后端逻辑的测试期间，remote service不再调用remote server而是调用之间准备好的mock data。这样，在测试过程中，测试人员就可以判断各个逻辑的返回值，方便编写测试用例。

图4. 后端自动化测试

在后端逻辑的集成测试中要注意如下几点：

①同步调用

在编写自动化测试用例时，如果想要降低复杂度，可以选择同步调用service。同步方式可以大大节约测试人员的工作投入。

②异常情况测试

在后端逻辑的集成测试中，测试人员要准备大量测试数据来实现正常和异常测试用例。异常测试数据主要用于测试参数异常以及元数据损坏。单纯的端到端测试很难模拟异常情况，因为前端页面对录入数据有判断，而且前端自动化测试若要模拟异常流程，其代码编写量很大。

后端逻辑的集成测试弥补了这一不足，高效的检测了后台逻辑对各种异常的处理情况。

元数据损坏可以通过修改mock data来重新初始化数据来模拟remote server上第三方数据损坏的情况。

③用户角色判断

前台集成测试中，可以利用不同测试账户模拟不同角色的用户行为。但后端逻辑测试中直接调用后端逻辑，所以需要定义不同实例来模拟各种角色。

（4）端到端的验收测试

在前后端集成测试都完成后，我们将进行端到端的集成测试。在第三步中，为了方便测试后端逻辑，remote service直接调用mock data，在端到端的测试中，我们将remote service连接到remote server获取真实数据。

图5. 端到端的验收测试

（5）持续集成

为了高效的监控测试结果，我们希望搭建持续集成环境。对于前端集成测试，我们利用Jenkins搭建Thucydides自动化测试工程的持续集成环境，并且为不同的测试环境分别定义构建周期。Jenkins提供了Thucydides的测试报告插件，方便查看测试报告。

但由于后端逻辑的自动化测试仅在每周测试阶段运行，我们编写了测试页面，手动运行。这也是今后可以改进的一点。

四、效果评价

我们的项目由JavaScript及ABAP共同完成，由于ABAP单元测试编写较为复杂且ABAP程序员工作量较大，所以过去ABAP单元测试覆盖率非常低，对于后端逻辑测试只能通过测试人员在前端手动测试。

经过一段时间的实践，我们发现这种自动化的集成测试的方法大大提高了我们的软件质量，并且几乎没有增加开发人员的额外工作量。

案例实施的关键因素如下：

（1）将原有的验收测试进行扩展，可以重用测试用例及测试数据。

（2）QUnit简单易学，前期学习投入较小。

（3）后端集成测试可以发现约80%的问题，降低了测试人员黑盒测试的投入。

同时，自动化的集成测试也给开发人员带来了便利，减少了单元测试的开发量，并且及时了解逻辑缺陷，尽早改进。自动化的集成测试也可用于后台逻辑的回归测试，帮助开发人员验证代码正确性。

集成测试成为了测试团队与开发团队沟通的一个很好渠道，开发人员不熟悉测试文档，但熟悉各个接口方法，所以开发人员通过查看集成测试的测试报告，可以方便快速的查看各个接口存在的问题。测试团队也通过集成测试更加了解了后台逻辑及参数定义，提高了测试的覆盖率。

目前，集成测试的结果已经成为了我们检验需求完成度的必要指标。

五、推广建议

集成测试需要深入了解产品代码结构及后台逻辑，所以建议在初期研究阶段，测试人员可以与开发团队共同探讨，寻求合适的测试框架及测试流程。为了更好的实现集成测试，可以选择测试团队较为熟悉的工具或者框架，提高测试开发效率。

此外，在框架选定后，可以利用一个或两个开发周期进行实践，若有问题，可以及时调整方案。

由于资源有限，我们为了节省投入，集成测试采用同步调用的方法编写测试脚本，运行时间较长，且无法测试并发响应。如果有能力可以尝试转化为异步调用，节约运行时间。

此外，集成测试中测试用例数量大，可以选择已有或者开发一个集成测试的测试报告应用，用于查看追踪集成测试结果。

分享嘉宾：梁璐

嘉宾简介：SAP中国研究院测试研发工程师

---

感谢关注top100case微信公共账号，我们致力于分享、解读有代表的技术创新/研发管理案例，帮助他人的项目或团队获得启示、成长。用案例启发思维，用案例激发行动，正如"他山之石，可以攻玉"。成为所有研发中心可用的案例智库！