要么删除pol_sts字段上的索引，要么建立plan_code字段的索引，最不济就是建立这俩字段的组合索引，看起来很简单的事情，实际操作起来却有着这么多的顾虑，为什么为没人愿意去挑战系统运营的稳定性，拿这个做赌注付出的代价的确是很大的。对于他们的担忧，其实我解读出来的信息就是：
刚毕业那会，很幸运在神码融信的东亚银行核心项目做QTP的自动化测试试点和推广工作，真可谓是不舍昼夜的忙碌。早在那个时候，我就梦想着开发如果能够就一定可以建立标准的UI组件库，实现标准的拖拽式开发，不会随意命名一些组件；这样自动化脚本开发和维护就非常方便，很容易追得上甚至超过编码的进度。可惜这对我来说只是一个梦想，从未被实现，现如今在带领大家一起做Selenium/ WebDriver和WatiJ等工具的自动化测试脚本开发同样面临这种问题。很多页面组件没有id、name，coder们在修改的时候变动随意性也很大，实现方式五花八门，这样测试脚本的维护工作量也是非常大的，经常因为人力和工作量的比例不协调导致测试脚本维护不及时，运行稳定性不好。这样就意味着测试的投入需要增加而质量却不高，自动化的ROI呈指数曲线下降。有同事说：“测试自动化没有开发的帮忙就等于是测试自己在YY”。虽然有点夸张，但是意思很简单：如果coder如果故意不配合的话，自动化测试的确会因为可测性遭遇很多测试脚本开发技术实现上的问题，所以说低质量的应用代码能锻炼出自动化测试开发高手来，但是伴随着这种锻炼方法的是可耻的资源浪费。高智商的coder们想不清这么简单的问题么然不是，那他们为什么没有提供更具可测性的代码给tester呢/span>
接上文，我能想到的原因很简单：因为负责coding的和负责testing的不是同一群人，所以往往由于他们专心于“本职工作”而忽视了对对方工作进行深入的思考，他们忽视的是对自己造成什么样的间接影响，最终忽视的是自己交付给客户的代码的质量，也是自己的口碑。即便他们中有些人偶尔能想到这些，替对方多考虑一些，他们也无法打败流程的约束和更简单实用的诱惑，换句话说：选择短视，选择当下可见的便利；选择无条件服从流程规范，选择拒绝持续改进。
由于经历有限，所以我无法论证上面这5个层次是否需要逐步发展，也不知道从2或3直接跳入5会不会达到预期的效果，不过个人主观倾向于排斥这种做法，因为我认为双方在不具备主观能动性的情况下用什么模式去工作，结果都是一样的。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！