很多项目都有自己对应的自动化测试系统，你当前的系统体现出价值了吗？觉得有下列几种情况：
1、人力精力投入了，能经常发现代码更新引起的bugs；
2、人力精力投入了，偶尔能发现Bugs，不多，觉得投入与产出性价比不高；
3、没怎么发现问题，性价比低，甚至后期都没动力维护。
当然还可以从 用例覆盖率作为产入 发现bugs作为产出 作为维度来分析问题！
当然，自动化测试的启动都是奔向第一个目标，然后系统持续集成保持强壮性！
下面收集自动化测试过程中遇到的一些问题、方法思路
1、针对功能点写了很多用例，貌似没发现多少问题
应该思考的是，当前功能点是有经常改动维护的，不是一些已经成型很久都不动的功能点，对于前者如果写了很多用例但是没怎么发现问题，问题有可能出在哪里呢？
举个例子，该功能点经过评审后总结出需要写10个用例，并分出来了3个优先级高7个普通的，所以，最先入手并效果最明显的就是先搞定那3个用例
当然写用例要先看看实现起来困难不，一般是集中先写 优先级高+实现难度适中 的用例，其他的后续再补充。
也就是说用例的选型方法是值得斟酌的！
2、团队里面的反角色
有时候写了很多用例，难道要等到问题出现的那天才知道自己用例的质量如何？不是的，可以在团队里面使用反角色人物，经过他的破坏，能及时反馈到测试用例质量如何。
3、需求经常变，我们只能等到研发最后开发完再写用例
也就是说此刻测试的角色很被动，但是可以改善吗？
需求会变，但是主线应该不会变吧？你总可以先写主线的用例吧？然后及时跟进修改都行啊，连主线都改动很大那是需求方的工作有问题i啊！
既然主线还是比较明确的，先写用例，后续需求明确下来了，有稍微改动，你再更新下用例也行啊！
也就是说，要从被动转换到主动来进行。
原文：http://blog.csdn.net/linxuping/article/details/22816457