前言

上周冒着大雨到唯品大学旁听了 2019 TesterHome 广州第一期沙龙。这期沙龙的三个主题自己的工作中都或多或少有接触到，受益良多。把自己的感想记录一下。

关于接口自动化

第一个主题是关于接口自动化测试的实践。正好过去半年自己的团队也正在做接口自动化相关的工作，也用 jenkins+pytest+allure 搭建起了一套每日运行的接口自动化框架，所以其中的收益和难点，自己也有遇到过。在听这段分享的过程中，其实也在对我们的框架搭建进行一个简单对比和工作回顾。

1.效率的提升：

分享中提到通过自动化测试，可以很大程度提升回归测试的效率。以往需要逐个功能点点点去进行回归测试，现在只需启动测试，然后等待一段时间即可看到完整的报告。这是生产力促进生成效率的体现，也是做自动化最大的价值所在。

2.关于全数据自动化校验：

分享中一个比较吸引我的点是全数据自动化校验的方案：

• 使用同一套参数先后发起两次请求，并对比其中返回值。将其中没有变化的参数，和有发生变化的参数分别保存起来，作为以后回归测试的验证模板。

正好我们的接口测试框架中也有做这部分的设计：

• 同一个接口，使用同一套参数分别请求生产环境和测试环境，并对比两个环境的返回值。如果返回值中不变的参数是符合预期的，则认为这个接口在测试环境与生产环境一致； 否则，说明测试环境的接口发生了变动。

这里共同的逻辑就是：假定生产环境的接口返回值是正确的（已通过了功能测试），并先后请求两次后，将对应的值进行对比后生成验证模板。

扩展： 如果接口文档设计比较完整，我们可以在开发之前就填写好对应的参数模板，直接作为开发阶段的测试用例进行执行，而无需根据生产环境的接口作为参考值。

3.对工作的启发

• 优化对返回值校验的方案。

- 造数平台及对外服务化：为整个研发团队提供服务。

关于引流压测

第二个主题是线上引流压测的实践。我们在日常工作中也会对部分功能进行压测，但和大厂的压测相比，差距明显：

1.数据真实性

我们日常工作中的测试数据，往往是模拟的单一假数据；线上引流，使用的是线上真实产生的数据。虽然经过了脱敏，但数据真实性、完整性、丰富度上，都比我们模拟构造的数据要强很多。

2.环境差异

我们日常的压测，通常是找一台内部的测试服务器来进行压测；而分享中提到了很多关于环境的模拟，如下游接口返回时间的模拟；redis 等服务的模拟预热；使用 mock 模拟下游服务等。环境越接近生产环境，测试结果的准确性也越高，参考的价值越大。

3.资源差异

大厂可以长期投入几个测试资源去持续开发、维护一套压测系统，而我们小团队只能在满足日常迭代开发的空闲时间里去做一些简单的研究和工作。其实听完这个分享后启发很大，有很多思路；但在目前的团队中，只能先挑重要的做起来，其余的还是有心无力。

4.对性能工作的启发

• 测试数据：使用更丰富、更完整的测试数据，尽量贴近生产场景
• 压测环境：用 mock 、预热等方式模拟更贴近生产的运行环境

关于云测平台

我们日常工作也有使用到云测平台：android 包升级之后，传到阿里云测上用免费的额度跑一遍，然后把对应的报告发给开发，检查一下对应日志是否有异常； 同时测试人员也简单看下报错、闪退、截图等。

但这个云测平台的分享，要解决的问题和大部分中小公司都不一样：真正意义上的云真机-- 不仅要是特定的机型，还需要有特定的运营商网络。

然后分享内容主要是关于如何克服各种难点的：网络、流畅度、音视频传输，等等。只能带着羡慕的眼光膜拜一下，一般的公司是没有这个成本资源做这些的。

或者什么时候可以对外开放，让我们这种小团队也能共享真正意义的云真机？

总的感想

1.小团队的大而广 vs 大团队的专而精

小团队由于资源有限，往往每个人都被迫要做到大而广：

• 测试业务覆盖面大
• 测试范围涉及度广
• 什么都要做，但是没有资源、精力做到精致

大团队：

• 允许投入专业团队、小组做专业的事情，例如上面的云测平台、引流压测平台
• 业务容错率更低、用户数量级更高，对于测试的精细度要求更高

2.效率优先

不管是小团队还是大团队，其实大家做的事情都是为了提高工作效率：

• 小团队优先做接口、UI 自动化，提升业务回归测试的效率
• 大团队可以开发出效率更高的工具供不同的业务部门使用，提升整个业务体系的效率

3.回归自动化测试的本质

在分享过程中，听到不少的问题：

• sql 注入属于接口测试吗？
• 收集到真机奔溃的日志有什么用？
• 在敏捷开发的模式下，如何推动自动化测试？

其实按我的理解，这三个主题，大家在做的都是回归测试的自动化（从接口、性能、兼容性等不同角度的自动化回归测试），因此都要回到回归测试和自动化测试的角度来解读：

• 回归测试的目的是验证原有功能是正确的，而不是为了找到新的 bug（期望找到新的 bug，还是要在功能测试、设计用例的时候下功夫）
• 自动化测试的范围要经过筛选，而不是直接全部功能测试用例的自动化实现（投入产出比和运行效率、维护成本）
• 自动化测试最终目的是提高效率，是加分项；不要因为要做自动化而忽视了常规的功能测试
• 测试工具没有最好，只有最适合自己。因此每个团队在全盘推广之前，还是要先做好试点和研究。

4.别埋头做，多抬头看

别闭门造车，多看看别人做的事情。很多你苦思不得其解的难题，说不定别人会给你启示，甚至已经为你提供了解决方案。

写在最后

这是第二次参加广州的测试沙龙分享了，每一次听完分享都能得到不一样的启发。

非常感谢主办方、各位讲师和各位志愿者的付出。感谢社区提供的平台，祝社区越办越好！