最近，我们某个产品线的测试人员纳了闷了。随着自动化用例一批一批放到库里，全量执行的耗时长得越来越邪乎，长到要耗费两三天的时间了，甚至有的测试单执行耗时需要12小时。这速度，心里哇凉哇凉的！辛苦建起来的用例库，这样下去，很容易烂尾成摆设。
时间都花哪了？
先从测试平台上把最近三个月中有执行记录的测试单找出来。简单说下结构，每个测试单包括前置脚本、多个用例（组）的集合，后置脚本。同时，为了方便用户进行问题排查，测试平台有非常详尽的日志记录。可以通过这些记录解析出需要统计的时间数据。
从测试单的执行流程上，可以分为平台调度、执行前置脚本、执行用例(组)、执行后置脚本这四个阶段。对每次执行记录中的所有用例脚本和日志进行正则解析，获取各段的耗时时间。
图1 各测试单执行前置耗时和用例执行耗时的对比
图2 用例顺序执行耗时趋势
统计结果为：
前置脚本运行耗时与执行用例（组）耗时分别占总耗时的52%和48%。前者竟耗时这么久，不算不知道，一算吓一跳！
170多个测试单的用例（组）执行耗时中，其中4个耗时占了58%。它们的特点是用例组数量多，属于典型少数。
这4个测试单中，每个用例组的执行耗时随着执行次序的增加而增加，其中某测试单的第一个用例组执行耗时只有几秒，最后一个用例组执行耗时则达到了骇人的5分钟。这个结果耐人寻味。
显然，朝着降低前置执行耗时和这4个用例组执行耗时去努力，获得收益的可能性大。
针对结果1：前置脚本是用来准备测试环境的，按照同样的套路，找到该过程能提速的主要环节和因素，通过更改启动策略、缩小数据库等方式减少了70%的时间。
针对结果2和3：从现象判断是个缺陷，同样套路，排查平台处理每个用例执行的过程，发现了慢查询和列表检索耗时的原因，执行耗时降低了50%。
至此，并没有结束。解决了最短的木板后，原先的中板变成了短板。要是每个用例都能并行执行是个多美的事儿啊！我们要解决的问题就变成了追求理想型【见《麦肯锡问题分析与解决技巧》】，想办法尽量提升执行机分发并行度或者被测环境处理并行度，比如容器化。
综上，通过这个案例，归纳一下解决问题的过程。
1.发现现象
2.收集信息
3.对整体进行归类拆分，找出主要矛盾
4.分析原因，制定措施
5.如果需要，继续寻找优化方向
解决问题的能力，一方面体现在面对问题的好奇心上，一方面体现在一套有目标的行为步骤上。
