接口测试平台-84: 多接口之 优化章节水漫天

 本节课会对多用例模块进行最后的优化等，内容不多。本教程基本都是最浅显和基础的一期产品，后续能优化到什么程度，全看各位的造诣了。

 

提到优化，很多人都说n种角度。但个人觉得，针对这种内部使用量不高的接口测试平台来说，很多方面/角度 的重要程度都需要转变思想，如现在这个半成品级别的测试平台，当前最紧急是易用性，容错性， 还是 超多并发的负载均衡？

这里认为：容错性 > 易用性 > 性能效率。毕竟在想大规模使用的前提下，这个东西得先能用，好用，获得最开始的用户的认可，才能继续推广。

当然以上三点只是举例说明，实际可优化的点很多，而且重要紧迫程度每个用户/每个开发者/每个公司/每个领导 都会有不同的看法。这里只列举一些对内部测试平台的优化点，大家有空就想想办法具体优化。

1. 容错性-主要是尽可能的避免服务器出现报错

2. 易排查-出了错误之后，使用者和开发者可以很好的排查错误原因

3. 易学性-使用一个平台最大的障碍其实是额外的学习成本

4. 易操作-根据不同实际情况要调整改进常用功能的便利程度

5. 易迭代-代码注释分层逻辑这些要尽可能清晰以便快速迭代新功能

6. 稳定性-项目持续稳定运行不会几天不用就挂了,考虑服务器/垃圾/内存

7. 易替换-平台的部分功能借鉴了主流工具能够替换很重要

8. 易恢复-重启服务/部署服务很简单，自动/一键完成

9. 可靠性-毕竟测试用的工具本身有bug太没说服力了

10. 准确性-很多数据的计算统计不能有偏差且精度适当

11. 保密安全-项目内会包含很多接口/用户数据/公司机密/敏感数据

12. 效率性-尽可能的优化算法/架构来减少执行用例的时间

13. 吸引性-界面简洁/大方/美观/时尚

14. 负载力-对并发/长时间持续等场景能维持稳定性能级别

这里只是列举了一些，当然还会有其他的。

 

1. 容错性优化：针对多用例运行进行

目的是找出所有能引起服务器报错的地方，这就需要测试的头脑了。也就是说之前完成开发人员的工作，现在应该进入到测试阶段了。这就是测试开发 这个title本身的意义之一：能自己开发并且自己进行全面测试。

那么要如何发现这些地方呢？可以从三个角度来想，一个黑盒，一个灰盒，一个白盒。

黑盒思维：在页面上看到这么多输入和设计，如果全部输入正确数据那么运行没有问题，但是如果其中某些输入不按照规则来呢？引起服务器报错的话 就要进行优化修复了。

灰盒思维：运行这个大用例，中间需要经过很多函数：

首先是前端的js函数：

然后是view层的py函数

然后它又调用了run函数：

然后是

然后是

然后是

最后生成报告是

整个链路是如此复杂。

灰盒测试要考虑的就是他们直接的数据里传输，假如某一个函数传出的数据有问题，它对下游函数的影响会怎样。而且这个出问题的函数具体是谁呢？这些都要去用灰盒思想去测试，注意，这灰盒思想是集成测试阶段的主要测试手段

之前很多同学以为的：灰盒测试=接口测试=http测试  是错误的，真实情况是：灰盒测试>接口测试>http测试。它们都是向后包含的关系。

 

最后是：白盒思想：直接去看各个阶段的函数，去看它们内部的逻辑关系，分支，判定。

然后去根据五种逻辑覆盖率去设计数据进行单元测试，不过这里要求的技术难度很高，绝大部分测试同学都没有受过正规的白盒测试训练，很难去熟练快速的覆盖完全。所以这里推荐大家直接用性价比最高的路径法，进行覆盖测试。就比如这个demo函数，你可以新建个py文件，然后直接调用这个demo函数，给它传参数你要设计下，能让它把所有分支都走一遍并且表现符合预期即可。虽然并不是特别全面覆盖，但是性价比最高，你用10%的用例成本覆盖了至少50%的场景。

然后不算完，最初和最终的目的并不是测试，而是优化，提高它的容错性。所以你还要尽可能的看代码想bug，这就和11种黑盒用例设计方法中的错误猜测法有异曲同工之妙。

比如说这个demo函数，当前结构图是这样的：

在这个结构中，至少要设计mock和非mock俩种step测试。

举例，假如从数据库提取的step数据有问题，应该提取后进行简单检查 ，如果检查出现问题，那么就不继续往下走代码以免引起服务器报错，出问题直接return并且输出一句：此step数据xxx字段出现问题，请修复后再运行用例 ！

不比直接报错然后满报告都是报错英文信息好一些么。

 

进行替换操作的时候，有很多地方使用了eval，这个函数即危险又容易报错，所以是不是可以换成ast.literal_eval

具体使用方式见文章：https://blog.csdn.net/qq_22795513/article/details/105580397?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522160687552719726891144193%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=160687552719726891144193&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_v1~rank_blog_v1-1-105580397.pc_v1_rank_blog_v1&utm_term=eval

 

诸如此类的优化工作量可以非常之大甚至是无限的，一个容错性中的一个功能中的一个函数中的一小段代码，就可以扯一整天。曾经有个后台rd说，一个月的任务排期，他2天就开发好了，剩下28天优化和修复bug。

所以教程中不会详细的对所有优化点进行优化，然后一句一句的代码去写，那样的话本模块永远都完结不了了。所以这里到底能优化到何种程度全看各位能力了。

关于具体优化手段，黑白灰三种角度，以后会拿出一个完整的功能作为例子，单独用一大段章节进行详细优化教程。