自动化测试思考 - 1关注过程

很多项目都有自己对应的自动化测试系统，你当前的系统体现出价值了吗？觉得有下列几种情况：

1、人力精力投入了，能经常发现代码更新引起的bugs；

2、人力精力投入了，偶尔能发现Bugs，不多，觉得投入与产出性价比不高；

3、没怎么发现问题，性价比低，甚至后期都没动力维护。

当然还可以从 用例覆盖率作为产入 发现bugs作为产出 作为维度来分析问题！

当然，自动化测试的启动都是奔向第一个目标，然后系统持续集成保持强壮性！

下面收集自动化测试过程中遇到的一些问题、方法思路

1、针对功能点写了很多用例，貌似没发现多少问题

应该思考的是，当前功能点是有经常改动维护的，不是一些已经成型很久都不动的功能点，对于前者如果写了很多用例但是没怎么发现问题，问题有可能出在哪里呢？

举个例子，该功能点经过评审后总结出需要写10个用例，并分出来了3个优先级高7个普通的，所以，最先入手并效果最明显的就是先搞定那3个用例

当然写用例要先看看实现起来困难不，一般是集中先写 优先级高+实现难度适中 的用例，其他的后续再补充。

也就是说用例的选型方法是值得斟酌的！

2、团队里面的反角色

有时候写了很多用例，难道要等到问题出现的那天才知道自己用例的质量如何？不是的，可以在团队里面使用反角色人物，经过他的破坏，能及时反馈到测试用例质量如何。

3、需求经常变，我们只能等到研发最后开发完再写用例

也就是说此刻测试的角色很被动，但是可以改善吗？

需求会变，但是主线应该不会变吧？你总可以先写主线的用例吧？然后及时跟进修改都行啊，连主线都改动很大那是需求方的工作有问题i啊！

既然主线还是比较明确的，先写用例，后续需求明确下来了，有稍微改动，你再更新下用例也行啊！

也就是说，要从被动转换到主动来进行。

4、纠结点，文档与robot用例如何加强关联

鱼与熊掌不能兼得啊，有了所谓的测试文档，评审后感觉像模像样，后续robot用例展开了，需求变更的时候就体会到如果文档和robot用例能有个强关联就好了，比如文档可以生成自动化用例等，目前还没有比较好的对策啊。

5、配置如何only

一般来说，比如robot用例的配置-resource，库的配置，shell脚本的配置  三者如何只公用一个配置的问题

6、追求易调试

目前使用robot-jenkins环境，发现进行dailybuild后，如果发现问题调试起来比较麻烦，所以从设计上讲，不仅仅是当前能写用例，还要讲究后续方便维护和调试，措施后续研究总结