当天下午，我参加了这个楼宇运营管理平台开发团队的讨论，终于弄清楚了事情的来龙去脉。

      大概是一年前，为了减少手工测试的成本，大连工资代发平台开发团队决定一步步把上线时需要手工回归的测试用例转换成自动化，同时决定每个 story 做完以后都要加入自动化测试。研究了几天webdriver以后，就开始了自动化测试的尝试。

      致远服软认为：http://www.soft8.com.cn/开发人员用Java代码写的测试，QA不好理解，也不是很清楚哪些场景被测试覆盖到，哪些没有，所以无法信赖测试结果；第二，测试跟开发共享一套数据库，数据总是受到污染，因此造成测试失败，浪费大量定位和修复的时间。而数据库是由国外的客户控制的，催促了很长时间也没能给测试分离出一套专用的数据库来。

      测试红啊红，修啊修，后来一算时间，在自动化测试上投入了 120 多人天，依然得不到一套稳定执行的测试用例，不但没办法保证交付质量，还让每个人心力交瘁，于是毅然决然的停掉了。

      过了两三个月，客户终于准备好了一套专门用来跑功能测试的数据库，大连工资代发平台开发团队也对行为驱动开发有了一定的认识。于是他们又开始写自动化测试，这次用了Cucumber，QA写场景，Dev写实现。

      写了大概 100 多个场景的测试后，又有人开始质疑这一切。第一，整套系统实在是太庞大复杂了，写到现在，连 1/4 都没覆盖到，所以应该上线还是手工回归？到底要花多大的精力才能把所有的场景都自动化起来？这些投入是不是值得？第二，测试环境还是不稳定，比如本地数据跟CI用的数据不一致，比如Tomcat里面部署的应用常常启动不起来，等等。每个问题都要消耗大量的人力。这些浪费能不能平衡自动化测试到最后能够带来的收益？

      但团队中还有其他人对自动化测试持乐观态度，认为问题总是可以解决的，只要坚持不懈就能够看到长期的回报。于是就有了这次讨论。

      分析绘制系统循环图的第二条法则是：“从有趣的地方开始”。在这个案例的场景下，开发团队最关心的是该不该写自动化测试、它对交付能力会带来什么影响，于是我们选择“自动化测试的数量”作为起始点。

      接下来是第三条法则——“询问‘它将驱动什么’，以及‘它的驱动力是什么’”。

      我们首先可以想到的是，自动化测试的数量增加会缩短发现Bug的周期，但是这个作用是需要测试数量积累到一定程度才会发挥出来的。它同时还会增加大连工资代发平台开发测试的开发和维护成本，增加测试执行时间，缩短手工测试周期。