不久前和某公司的测试同学做交流时，被问及了这样一个问题 -- 我们这边系统很庞大，每次感觉改的东西不是很多，但是怕出问题都得整体功能都过一遍，因为是金融系统，一次测试要做两周，有什么办法能降低我们的人力投入么。

挺有意思的一个提问，这里面能看到很多幽幽的怨念。

• 研发他们都是增量开发，之后为什么要全量测试
• 研发信誓旦旦的说只是改了一部分功能的代码，但还是担心牵一发动全身的事情发生。说句 “测试同学，你们简单测试一下”，但是还是多数测试同学不敢简单测试一下，然后硬着头皮把核心起码过一遍。

首先说一下，测试周期和测试投入是不是一回事儿。可以测试周期不变，但是投入变了，也可以测试投入变了，但是周期不变。当然我们通常希望的是投入和周期都能有所下降。

在这里，我个人认为可以有三个改善方向可以思考。当然了，我的强调一下，不代表就没有别的思路，也不代表我的思路就是最好的，我们是来做交流的，我负责抛砖，你们引玉。

第一个方向自然是做自动化测试。在代替人上，自动化是你应该首个就应该考虑的解决方案。虽然这位同学的潜意识是想问我如何减少测试用例，但是我不得不说，如果你的自动化替代率很高的前提下，你可以暂时不 care 是不是把 5000 条用例能减少到 1000 条，因为机器毕竟是人类速度的 N 个数量级倍，如果能足够快的速度执行完大量的自动化测试回归，那做精简这件事儿可能是不那么划算的。能交给机器做的事儿，作为人你不要去抢。

这位同学的背景是一个比较庞大且稳定的老系统，每次回归手工可能要两个人执行一周时间。在这类型的项目里，很显然自动化的施展余地会大很多，且收益也会大很多。一些新项目的自动化投入大产出大，通常原因是因为项目变更过快，老的接口设计动辄就废弃，或者动辄就做升级，自动化测试投入很难收回成本。而这种已经比较稳定的大型项目，接口设计还需要尽量遵循以前的规范（也可能没有什么规范，但是已经被系统之间的引用约束了），所以如果这种做一点升级优化就需要大面积回归的场景，配合高比例的自动化回归和辅之以一定规模的人工测试回归还是效果不错的。

那是不是新的、迭代比较快的项目就不可以快速引入自动化提升回归效率和降低投入了。答案当然是可以的，这就看你的自动化用例本身如何维护的了。如果你能利用文档做到参数的结构化，那么你可以利用文档自动转化和 update 测试用例，这对你的维护成本和撰写成本降低都会有很大的帮助。一旦这件事儿评估的结论是 -- 在开发测试阶段，投入的维护成本会小于执行使用成本，那你大胆的开展这部分工作吧。

第二个改善的思路，我个人的建议是做灰度测试。尤其是这种已经有较大体量的项目，我个人认为灰度测试是一个不错的选择。

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行 A/B testing，即让一部分用户继续用产品特性 A，一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

还是说下这位同学所说的项目背景，大型项目，做优化之后两个人测试一周多。既然我们的研发和测试同学都知道只是改了不多的内容，那是不是可以考虑做基本功能的确认之后，就发起灰度测试，利用小流量控制，将生产流量倒流给一部分用户，根据这部分用户的使用状况来评估。这样如果运行一周如果不出问题，那显然功能是好的，如果确实发现一些问题，那本身因为流量控制不会影响很多用户，通过问题反馈激励的方式也可以增加用户的参与感（其实更多的时候是让用户发现问题之后意识到是挖到了宝，而不是擦到了雷）。

在这一周的时间里，周期虽然没有下降，但是测试人员的人力投入会大幅度下降，测试人力的投入可能从一个 ST（系统测试）级别的测试下降到一个 SNT（准入）级别的测试，之后投入零碎时间关注问题反馈。这种方法使用于还有一个相对较长的验证周期，而且有足够量级的用户支撑你的灰度测试发布。

这里又有人问呢，如果版本用户数很少呢？敢不敢发灰度，我只能说，你想发当然也可以，但是效果不好。另外，如果用户还没有那么多的时候，老板非要小步快跑上线，那你就牺牲一些质量好啦。不要死脑筋，上线出错对用户如果没有那么大，你是可以适当放弃质量上线观察的。关于测试经济学的概念，列为自行百度吧，我摘一段供大家了解。

随着信息技术的飞速发展，软件产业在国名经济中扮演着越来越重要的角色，各行各业对软件质量要求也越来越高，那么软件企业是不是为了保证产品的质量，测试人员就需要无限期的对软件产品测试下去呢？答案是否定的，从经济学的角度考虑就是确定需要完成多少测试，以及进行什么类型的测试。经济学所做的判断，确定了软件存在的缺陷是否可以接受，是否符合企业产品定义的质量标准。“太少的测试是犯罪，而太多的测试是浪费。” 对风险测试的过少，会造成软件的缺陷和系统的瘫痪；而对风险测试的过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于他们给系统造成的损失。

测试费用的有效性，可以用测试费用的质量曲线来，表示随着测试费用的增多，发现的去缺陷也会越多，两线先交的的地方是过多测试开始的地方，这时，发现缺陷的测试用超过了缺陷给系统造成的损失费用。

由于市场和软件研发成本的影响，软件测试不可能无限期的测试下去，软件测试最佳的发布日期通常是测试多伦后，在较长的时期发现不了缺陷或者发现和少的缺陷，但是该阶段消耗的研发成本日益增长的时候终止。

还有一个改善方向是做精准测试。精准测试现在业界有两个意思，一种指的是 14 年业界提出的 “穿线测试”，大概思路是如果通过降低白盒测试投入的同时又提升代码测试覆盖率,一些简单介绍如下。

黑盒和白盒各有优劣，采用二者相结合的方法，穿线测试实际上属于创新型的系统级白盒测试工具，是软件测试领域里面全新的学术流派。它先通过传统黑盒测试把基本的功能都测试一轮，覆盖率达到 70%，同时这个过程受到穿线测试工具的监控，并获取该阶段的测试结果数据；第二步，通过穿线测试得到的白盒结果，快速定位剩下 30% 的代码，进行针对性地增加测试用例，最终达到终极目标。经过很多客户的实践经验，这种方法对于覆盖率测试是最有效的，且测试时间最短。

对穿线测试基本概念想了解的，可以读一下：http://www.51testing.com/html/29/n-3641529.html

这里我们要提的是另外一层概念，是基于增量测试思路演变来的精准测试。主要目的是针对变更内容做评估，可以有针对性的对变更内容和关联内容展开测试，而不在没有影响的功能上做无畏的投入。

即便还比较粗犷的团队，可以将你们的代码 - 业务模块 - 用例设计一个映射关系，然后每次在修改内容之后 针对代码变更范围确定回归范围，这样不会每次都回归很多内容。

利用工具，能正反推模块和用例关系。正推模块变更需要关联的用例，反推可以通过用例评估对模块的覆盖。最开始可以基于人工基于经验做这个映射关系，更长远的还是需要上一些工具的。通过工具能评估组件和组件、模块和模块之前的引用关系，以及在用例执行时基于代码覆盖工具积累和模块的关联关系，在发起新的变更做测试时，能基于已经建立的映射关系给出参考回归的范围，并给出关联的测试用例，这里要强调下，要尽可能的利用工具在执行的时候反观对功能和代码的覆盖，比如你的用例虽然关联的新变更的模块，但是发现在用例执行的时候该模块有大量新代码没有被测试执行时覆盖，那要再有针对性的跟进该部分内容了。

以上，是我个人的建议的一些思路，具体如何实施就不长篇大论去写了，大家自行百度吧。