一般提到优化，很多人都可以说n种角度。但是我个人觉得，针对我们这种内部使用量不高的接口测试平台来说，很多方面/角度 的重要程度都需要转变思想，比如我们现在这个半成品级别的测试平台，你觉得当前最紧急的优化是哪方面？是易用性，容错性， 还是 超多并发的负载均衡？
如果让我来说，这三点的重要和紧迫程度是这样：
容错性 > 易用性 > 性能效率
毕竟在想大规模使用的前提下，这个东西得先能用，好用，获得最开始的用户的认可，才能继续推广。
当然以上三点只是我举例说明，实际可优化的点很多，而且重要紧迫程度每个用户/每个开发者/每个公司/每个领导 都会有不同的看法。我这里只列举一些对内部测试平台的优化点，大家有空就想想办法具体优化。
- 容错性-主要是尽可能的避免服务器出现报错
- 易排查-出了错误之后，使用者和开发者可以很好的排查错误原因
- 易学性-使用一个平台最大的障碍其实是额外的学习成本
- 易操作-根据不同实际情况要调整改进常用功能的便利程度
- 易迭代-代码注释分层逻辑这些要尽可能清晰以便快速迭代新功能
- 稳定性-项目持续稳定运行不会几天不用就挂了,考虑服务器/垃圾/内存
- 易替换-平台的部分功能借鉴了主流工具能够替换很重要
- 易恢复-重启服务/部署服务很简单，自动/一键完成
- 可靠性-毕竟测试用的工具本身有bug太没说服力了
- 准确性-很多数据的计算统计不能有偏差且精度适当
- 保密安全-项目内会包含很多接口/用户数据/公司机密/敏感数据
- 效率性-尽可能的优化算法/架构来减少执行用例的时间
- 吸引性-界面简洁/大方/美观/时尚
- 负载力-对并发/长时间持续等场景能维持稳定性能级别
这里只是列举了一些，当然还会有其他的。
所以首先就要开始针对多用例运行这个模块的容错性进行优化了。
我们的目的是找出所有能引起服务器报错的地方，这就需要我们测试的头脑了。也就是说我们之前完成开发人员的工作，现在应该进入到测试阶段了。这就是测试开发 这个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。
所以教程中不会详细的对所有优化点进行优化，然后一句一句的代码去写，那样的话本模块永远都完结不了了。所以这里到底能优化到何种程度全看各位能力了。
