自动补足算法是什么_智能对话系统中的自动化测试

自动化测试这个词在项目中经常会提及到，许多人对它的了解都存在一定的偏差。

例如我经常就遇到产品或研发的同学讨论了一个新的方案或功能，随口就来一句测试这边自动化跑一下吧，这种时候就比较尴尬，自动化主要是对已有功能进行回归，新功能如果它能自己测试，那还要人干嘛？

现实是这样，别人怎么理解我们管不了，但测试人员自己还是得明确自动化的适用范围。

另外，现在许多公司招聘信息里面都要求自动化测试，明确提到各种测试工具。难免给人造成一种错觉，认为自动化测试就是这些工具或框架的使用。在一些大型的公司，由于业务复杂，这些常用的工具根本无法满足需求，通常都会自己进行开发，以满足项目的需要。因此，个人认为自动化测试是使用技术手段，将我们手工测试的工作用机器来帮我们执行的一个活动，不应该仅仅只局限于某个工具或框架的使用。

好了，言归正题，在前面的文章里，我们讨论了智能对话系统的测试点，其中提及到了自动化测试，这里我们继续讨论一下智能对话系统中自动化测试该如何开展(偏业务工程侧，算法侧的测试主要是大批量的测试语料过模型，比较简单，就不再详细描述了)。

PS：大家可以打开今日头条app，在上方搜索栏中输入“智能对话系统该如何测试”，就能找到上一期内容。

待测对象分析

开展自动化测试之前，首先得明确我们的测试对象，明确自己做自动化测试的收益点，避免大投入少产出的情况。

智能对话产品通常会分为C端和服务端。C端就是我们普通用户所接触到的客户端，展现的形式有多种(PC，M，语音等等)，这个层面(界面，UI)一般不建议进行自动化,维护成本比较高，收益较低。

智能对话系统的核心在服务端的处理，服务端与C端一般都是通过接口交互，因此我们只需要梳理交互协议，模拟C端发送的请求即可，而不需要真正的去C端进行操作。

模拟C端请求，是基于整个应答流程的测试，主要是从场景的维度对应用之间的协同工作进行验证，所处的层级比较高，对于一些内部精细的逻辑很难触发到。我们还需要更细粒度的验证。

从前一期的文章(参考：智能对话系统该如何测试)中我们知道，服务端是以微服务化的方式由多个不同功能模块的子应用构成的。因此，在粒度的划分上，我们也只到应用级别，再细就是单元测试了。

我们对待测对象进行分析后，决定以2种维度来进行自动化：<1>基于原子级别的基本功能测试 <2>基于业务场景的流程测试

工具选型

在明确了测试对象后，接下来就是对测试工具的选型。

通常而言，工具的选型，在满足功能的情况下，都是自己熟悉什么就选什么，即使别人不同意，也要说服别人同意；如果说服不了别人，那么就被别人说服。

前面说的有点粗暴，但确实挺具有操作性的。

言归正传，我们在选择工具的时候，其实更多的还是要根据自己的需求来决定。

从上图中可以看到，对话的整个流程虽然是链式调用的，但是最终答案的返回却是异步的。举个例子简单来的说，网关层调用会话管理层后，会话管理层会立即返回结果给网关层，但这个结果并不是最终答案，而仅仅只是一个接口调用成功的标识。真正的答案也许还在分析处理中，因为分析对话需要一定的时间，出于并发或性能的考虑，架构师把整个流程都设计成了异步的方式(这点我们不必关注)，当真正的答案生成的时候，再将答案推回给网关服务，再由网关服务把答案给下游。

上面只是一个举例，经过对会话流程的简单分析，我们发现由于整体架构采用异步消息的方式，一些常用的测试工具发送请求过去，根本拿不到预期答案。

因此，我们可以在测试工具与服务端之间加一层中间服务，他暴露给测试工具的是一个同步接口，接受来自测试工具的测试请求，将数据发送给后端服务，我们与后端服务进行约定，测试请求的结果全部都转发到中间服务，再由中间服务把结果返回给测试工具。

这样就能解决异步消息的问题。既然我们都已经完成了发送请求，接受消息的工作，那我们为什么还需要使用别的测试工具呢？直接使用中间服务进行测试不就完了吗？

是的，其实这个过程我们就已经完成了一个简单的测试工具了，只是它不是通用的，是我们这个项目定制化的工具。

用例参数化

在中间服务的代码里直接构造一个请求发送出去，在接收到测试结果后，做一个检查点就已经完成了一个自动化用例。我们的测试框架雏形就已经搭建好了，只是他非常简陋，测试用例和工具完全耦合在一起，不便于维护和使用。

这个时候，我们自然就会想到，将用例和工具分开。我们规定好用例的书写格式，以参数化的形式开放出去，例如可以在excel里面用我们规定好的格式去写用例的参数，验证点和逻辑，在测试平台服务里增加一个解析excel的功能，把excel里面的用例参数和逻辑解析出来,组装好请求发送到服务端。这样就实现了测试数据和工具的分离，这也就是我们常用的数据驱动模式。

易用性的提升

到现在，我们这套工具完全可以在测试小组内推广并运行起来，只是它可能需要一些学习成本，对于用例的管理方面还比较弱，如果有条件我们甚至可以在现有的基础上对易用性进行一些升级。例如，将用例的存储放到数据库，给用例增加一个可视化的管理操作界面；通过数据库的管理，能方便的查询修改用例；可以将用例自由组合形成测试任务；用例运行后做出漂亮的测试报告；用例运行时记录日志便于排查问题等等，这些功能都是可以挖掘的，它不是必须的，但可以给人一种蜕变的感觉，从一个发请求的工具蜕变成一个易于操作的测试平台。

可能大家会觉得，这么做会花费太多的精力不划算。这个就因人而异了，如果你做的这个东西只是当前这个项目使用，只有2个月左右的生命周期，后续也不打算再扩展这一套，那么的却不需要花这么多精力去做这些。

但我们的项目会持续几年，而且希望在每个迭代的周期中，让整个项目组的人员都自发的参与维护自动化用例，使自动化成为质量检测的一个必要环节，从这样的角度来看，我们觉得对易用性的提升，会有更大的收益。

当然，整个测试平台并不需要一开始就全部规划好，完全可以从上面描述的一个小工具开始，当有需要的时候再慢慢补足就行了。

构建策略

基于上面基础设施的建立，我们可以形成不同粒度的测试用例。根据使用目的，挑选出对应用例形成测试任务。在需要的时候直接运行任务，能快速的帮我们进行测试。

当然，我们也可以建立一些定时构建措施，定期让他自己运行，我们只需要关注结果就好。

定时构建也比较简单，可以自己在测试平台做定时任务；也可以从测试平台开放一个任务运行的接口出去，借助一些外部定时任务的工具定期触发接口(例如：jenkins)。

任务运行结束后，可以根据公司资源的情况执行结果反馈。发邮件，发短信或其他通知措施都可以。

这里说说我常用的定时构建策略：

我们有线上和自动化测试2套环境，采用了心跳监控和定时构建2种策略。

心跳监控

从用例集中抽取出最核心最重要的几个用例(不需要太多)，每隔N分钟对线上环境进行一次检查，如果连续M次失败，则告警通知。这么做的目的是为了监控线上核心服务是否正常，连续N次失败才告警主要是为了增加告警的准确率，避免由于临时网络波动等原因所造成的误告警。

定期全量构建

每隔一段实践都会对线上和测试环境进行全量构建。对于线上环境的构建，主要也是起监控作用；对于测试环境的构建就是当前迭代功能是否正常的实时晴雨表。研发提测前需要自己使用测试工具对当前提测的内容编写自动化用例并调试通过(自动化工具是否易用非常关键)，同时保证历史用例不会出问题；而测试人员在拿到版本的时候，能保提测的主要功能是正确的，只需要进行一些查漏补足即可，对于一些改动不大的需求，我们一般都是让研发自测，自测的交付件就是自动化测试用例。

我所接触到的公司，大部分情况下测试资源都是非常有限的，完全依赖测试来保障质量不一定现实，所以在能力范围内，尽可能的推动整个项目组对质量进行重视，让测试人员的精力投入到更重要的地方，收益才是比较大的。

数据隔离

我们上面的构建策略，会定期的向正式环境发送测试请求，如果没有进行特殊处理的话，就会影响到运营定期的数据统计。因此，在对线上环境进行监控的时候，需要结合项目情况，做到数据隔离。我们的做法比较简单，和研发在协议中约定好带上特殊字段的

请求都是测试请求，在数据统计的时候排除掉这些请求即可。

问题排查

当一个用例运行失败后，我们该怎么进行排查呢？最简单直接的方式就是拿着我们保留的日志关键字信息让研发去排查。后端服务一连串十多个应用，研发人员逐步排查起来也是非常头疼的。

那么能不能用什么手段快速的帮助我们进行问题定位呢？我们目前主要采用了以下2种方式进行问题定位。

粗细粒度用例关联

上面我们将测试用例分成了粗细2个维度来进行验证。在设计这2种用例的时候，其实我们可以刻意把他们进行关联。例如粗粒度的用例(场景用例)在应答流程中会顺序经历A-B-C-D-E 5个应用，我们做细粒度用例的时候

(对B，C，D，E进行单独测试 )，各个应用的入参就保持和粗粒度相同场景的入参一致。当场景用例失败的时候，我们就可以顺序把各个细粒度的用例执行一遍，这样哪个环节出错就能一目了然。

这样做，无疑会增加我们测试设计和用例编写的难度。

快照对比

简单来说就是在用例执行成功的时候，我们获取关键应用的中间数据，做一份快照保存起来；当用例执行失败的时候，获取失败情况下的快照，与成功的快照进行对比，从而判断出到底是哪个环节存在问题。

这种方式，使用起来比较方便，但是对工具的要求就比较高，最主要的难点在于如何获取到中间数据。这个就需要对项目整体架构和代码实现方式有比较清楚的了解，甚至需要研发进行配合。

我所经历的项目中，为了运营统计分析的需要，会在各关键节点中进行数据埋点，埋点的时候会采用MQ异步的方式将数据汇总到大数据平台。因此，我们只要去消费埋点的MQ就可以采集到中间过程数据，从而形成数据快照。

上面介绍了一大堆的文字，都仅仅只涉及到自动化测试中的一些关键点，还远远不够深入，许多问题要自己去实践才能发现。文章虽然写的是智能对话系统的自动化测试方案，也没有用到一些特别牛X的工具和技术，本质上与其他常规测试方法差异不大。无论是哪种类型的测试，在基本思想上都应该殊途同归。

关于自动化的做法，各个项目的实现方式都可能不一样，不能迷信某个工具，也不能生拉硬套的照搬别人的方法，适合自己的才是最好的。