程序猿测试媛之友谊的小船升华成巨轮

本文作者通过“流程平台自动化测试实践”的现身说法，介绍了测试人员如何简单高效完成开发测试任务，内容精悍，值得一读。

首先，让我们看一则有关“开发与测试”的小漫画来迅速了解本文前半部分内容：

1传统测试累不累？

在企业级应用中，流程服务的测试一直面临诸多的问题，诸如：

— 系统内部任何一个微小的变化，要上线测试；

— 外部关联系统变化，引起的业务验证测试；

— 如果流程作为一个公共的服务，一旦服务升级，所有业务系统都会有影响，所有业务系统全部都要验证。

这些都会给测试造成巨大的工作量，不仅消耗过多的时间，还无法很好的保证质量。当这些问题投射到云环境与分布式架构中，所面临的复杂度与解决难度的升级不言而喻。

如上图所示，在基于微服务架构的数字化企业云平台中，流程是一类重要的微服务。我们正在尝试将流程微服务的测试自动化，并由DevOps平台高效的验证微服务的改变是否影响原先的业务，从而提供高质量的上线保障，让测试人员告别那些让人生无可恋的重复性操作。

2自动测试行不行？

基于微服务的自动化测试的本质是通过数据的录制记录既有的测试过程，并通过案例固化过程中的全部测试数据，最终通过对案例的调用回放完成流程微服务测试的自动化。

• 数据录制

流程微服务的自动化测试并非完全脱离手工测试，这里的自动化是建立初次手工测试的基础上的。第一次手工测试会在数据库中记录下所有的测试信息，我们将收集这些信息录制形成测试数据文件，根据每条流程实例录制一个测试数据文件。每个文件中包含：该流程实例运行过程中的所有相应请求/相应报文，该流程实例运行过程中的上下文变化，该流程实例的流转路径（活动+连线），该流程实例包含的子流程实例。

• 案例生成

在流程微服务的自动化测试里，我们会根据实际的接口调用来设计多个组件，这些组件放置于一个测试组件微服务中提供给测试人员使用，每个简单的组件都对应一个接口的请求报文。这就犹如搭积木，每个积木是一个简单的接口报文，多个积木搭在一起形成一个房子，即多个接口报文固定调用形成一个复杂组件。多个房子、花坛、汽车形成一个小镇，即多个简单组件和复杂组件结合在一起生成的最终一个“流程实例的自动化测试”案例。

有了之前收集的数据文件，就是根据每个数据文件，选择积木的问题了，再根据数据文件给每个组件添加必要的参数，这样就形成了测试案例。在案例生成的过程中测试人员不需要编写任何代码！

• 调度回放

我们将统一测试平台门户设计为一类领域系统，可以上传我们的测试案例部署，选择案例点击执行即可。每个案例的运行其实就是相应手工测试的一次回放。案例执行完成会形成详细的测试报告，包含了成功、错误、异常的详细信息，案例统计图，以及案例执行时间。清晰明了地达成便捷测试。

3交互通信怎么办？

流程微服务有时也会和其他微服务之间通信，往往测试环境中无法与其他微服务直接交互，这时候我们为了模拟流程微服务引擎与其他微服务交互过程，提供了一个服务挡板功能，服务挡板也是设计中的数字化企业云平台的一类领域系统，由api mock提供挡板能力，即用服务挡板替代生产上的微服务。（未来我们会详细介绍api mock相对于传统mock的优势）

当自动化测试进行到其他微服务交互时，流程微服务引擎向挡板发起请求，挡板响应请求，并动态拼写回调报文，当所有的回调报文完成之后，挡板通知测试引擎，测试引擎向流程引擎发送回调报文。

4验证条件靠谱么？

对于测试案例，不仅需要模拟流程流转的服务接口过程，还需要验证流转过程中的参数正确性，所以需要验证组件来完成参数的确认。

• 对比服务接口返回报文信息是否一致；

• 一个活动完成后循环等待后继活动是否激活；

• 一个活动完成后对比当前后继活动与历史测试数据中后继活动是否一致；

• 一个活动激活后对比当前活动产生的连线是否与历史测试数据中连线信息一致；

• 每当一个可能引起上下文改变的服务接口完成后，对比当前流程实例与历史测试数据中的上下文是否一致。

开发人员小A、小B、小C：流程/资源/外部服务改动啦！就要上线啊！今晚加班赶紧测一下吧！

测试人员：so easy！轻轻一点执行，测试结束报告自动发送给每个成员！下班啦~\(≧▽≦)/~啦啦啦~~~~

关于作者

叶婉婷

现任普元信息SOA产品部开发工程师，为普元新一代数字化企业云平台开发团队一员。在过去的两年参与流程平台项目，主要负责Eclipse插件开发及自动化测试平台开发。爱好：旅游、电影、美食、游泳。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信账号。