时间回到2012年中，我去的时候三个开发工程师已经实施过几个月了，但是据说效果特别不好。我就是那个他们期待带来奇迹的家伙，然而我当时是一脸懵逼。但是我做了一件至今我仍然觉得很英明的决定，那就是我和我的团队坐在一起，测试人员、我、测试平台的开发工程师，三个脑袋对着这个屏幕，大家一起做测试。
那个测试工程师是个话痨，这也是为啥我选了他。他的嘴特别快，手也特别快，我必须经常性的打断他的操作，问他为啥要这么干。平时半个小时做完的工作他干了两个小时；然后我亲自操作，他俩观摩指导，又来了一遍。
接着，我骚扰了这个团队的每个测试工程师，我成功的发现，原来每个人都有自己的独门技巧。每个人的测试习惯、测试用例、操作方式都不一样，这也导致测试的深度完全不同，有些人的质量很高效率特别低，有的人效率高质量差；有的人靠直觉，有的人靠逻辑；有的人按部就班应付事，有的人认真但是很憋屈。
在一个月之后我们有了成果，终于做出了第二个版本。这个东西的设计思路是基准测试：
- 将一个XML文件里的测试数据传给本次要发布的程序版本
- 这个程序会调用指定数据源完成数据提取、转换和上传
- 将程序上传的这个结果文件与基准（上个版本保存好的结果文件）进行比对
- 使用SQL或者其他方式访问制定数据源，确认这些差异是符合我们的要求的，测试通过
- 将最新生成的结果保存成新的基准。
这个设计思路很不错，我也是第一次学习了基准测试。这个测试方法的好处是，我不需要一个详细的需求说明文档告诉我针对每一种数据程序应该是个什么反应，我只需要知道转换规则，然后通过与基准比较出来的差异去抽样，就可以获得很不错的测试效果。
但是在新的测试工具推广半个月后，我发现大家都不爱用这个工具。我发现了几个问题：
- 有些测试工程师会忘记保存基准，导致下一个人去执行的时候发现，基准是错误的。他需要很费力的重新运行。
- 有时候程序会出bug，而当测试人员发现问题的时候，他们倾向于直接手工执行，而不是上报这个问题。
- 程序只能与基准比较，而当我们要确认一些问题的时候，这个工具就不能用了。
- 这种基准测试会遗漏一些缺陷，导致测试人员不敢信任它通过的结果。
当时的开发经理甚至说出这样的话，“自动化测试只能作为辅助使用，归根结底你们还是要用手工再执行一遍，如果都能用工具自动化了，要你们干什么？”
这可能代表了当时团队所有人的心声，我也遇到了我管理测试团队最大的一次信任危机。我们真的只能使用手工的方式执行测试吗？
当然不是。那四个问题是我和我的团队沟通时他们告诉我的，这里边有程序的问题，有人的问题，有流程的问题。现在想来，自己还是低估了困难。当时的测试工作压力很大，看似同样的任务，事实上有很多隐藏的工作，工作量差异巨大。我的方法很笨拙，我观察到团队都不爱干的活，我就拿来自己干。无论加班到几点，我都要弄清楚，到底这个工作麻烦在哪儿？
经过一个月的深入调查，我发现，最主要的原因是当时的测试方法和测试流程都没有经过完善的设计，测试水平太低。靠自动化来推动流程改革是不可能的，只有我才能推动测试流程改革。
我们当时做的事情是ETL的测试。其中，提取和上传没有逻辑，只有转换才是需要重点验证的焦点。我们有Mapping表，指明了数据源中的字段与标准文件中字段的对应关系和转换逻辑。但是，一个转换逻辑应当由相应的测试数据来验证，而当时我们使用的数据库是从客户那里拿来的真实数据，对于很多特殊逻辑是无法覆盖的。
比如，我们有一个逻辑，要求用户的姓和名不能都为空。那么，至少应当存在四种数据，有姓有名、有姓无名、有名无姓和无名无姓。但是我们的数据源里不一定有这种数据，如果逻辑写错了，我们根本发现不了。到了生产环境，遇到了这种数据，程序执行就出错了。
用测试的语言说，这是由于数据多样性不足以覆盖需求导致的测试覆盖率不足。
解决的方法是改变测试用例编写流程。我要求：
- 每个测试人员针对Mapping文件提取出所有的逻辑作为测试点，列上编号。
- 针对每个测试点设计测试用例
- 针对每个测试用例，找到至少一个测试数据（如果没有就修改一条）
这样，我确保每一个需求都被完善的覆盖，经过测试团队修改过的数据库变成标准库，所有的测试都只有在这些标准数据库执行过，才能通过。
同时，我给测试工具开发团队定了目标，必须让每一个测试人员都爱上你的工具。他们蹲守在测试人员身边，陪着他们一点一点跑通，随时给与指导。他们完善这个工具，让他们自动上传、读取基准文件，在虚拟机上接受本地传递的配置文件，将测试报告自动发送给群组邮箱。这个功能实现后，我要求每个测试人员至少同时处理三个任务。
到了2013年中，测试团队的测试效率提升了至少5倍，同时我们的缺陷发现率呈现了井喷式增长，开发团队修改了自己的流程，他们的代码评审开始使用我们的用例、工具和测试数据。
这次的经历带给我什么样的启迪和感悟呢？我认为至少有三条：
- 测试工具的自动化并非银弹，它需要团队配合、流程配合才能成功；
- 自动化工具的开发者必须了解测试人员的痛点，将力气用在刀刃上，不能闭门造车；
- 自动化工具对团队内部和外部来说都是新鲜事物，我们需要花费大量的力气让大家接受它。
第二次杨帆