自动化实施的头脑风暴一
2013-11-19 15:22:57   来源:原创   评论:0 点击:

不管是搞性能测试 还是搞自动化测试,如果 测试人员闷着头自己搞,都属于“闹着玩”的。

a:自动化的价值?

s: 1 不要盲目上,上之前跟项目经理好好讨论下,要不要做,做那部分,价值几何,如何维护。
    2 一定要明确边界, 一定要让项目经理知道,自动化测试就是个辅助,不是万能的,只是为了提高效率
   3 只有在项目上创作价值,才有意义,否则一起都是玩,都是在浪费时间。

   4不管是搞性能测试 还是搞自动化测试,如果 测试人员闷着头自己搞,都属于“闹着玩”的。


a:自动化兼容性问题:ie可以,ff不可以?

s:不同浏览器间,脚本兼容问题,恰恰是每个自动化用例coder应该做的一项很重要的工作。

我们所遇到的,所理解的,自动化coder重要的工作并不是写测试脚本。

1.用例设计,动作设计,场景设计,异常校验设计。
2.按照理想化设计实现时的技术难点公关。
3.用例编写完毕后 浏览器兼容性 修正。系统兼容性修正。

经过我们实践发现,按照设计写代码,是所有工作里面花时间最少的,大部分时间花在 调试代码的正确性,还有兼容性。

所以,遇到FF能跑,CHROME 跑不了,很正常,其实是你这个脚本的工作还没做完呢,你自己想当然的以为脚本写完了工作就结束了。 

其实这里面就有个换位思考的事情了,大家都在喷开发,写完代码看都不看,也不自己测试下,就扔给测试人员。  现在的情况是你自己也是开发,你写完了也认为完成了,不想再测试,不想再调优。
 

a:是别人电话面试我了,然后我说做这方面,然后人家就不说话了。就game over
 

s:这么说,不要以为做底层接口就比坐UI NB,高端。

UI做强了更能说明问题,因为所见即所得。但UI做的好不好在于用例设计和实现,你能不能设计出行之有效的用例查找出所有BUG,以及你设计出来了很好的用例,但是你能不能实现它。

另外,就是对UI测试的定位和看法,它就是用来对产品功能进行回归验证的工具。


底层的测试与上层的业务场景相距较远,不能直观的反应业务问题。但是底层的测试可以更直接的根除很多问题。

但是,他们2个并不是能够相互替代的关系,应该是都需要做。互补的关系。


具体哪个为重,要看你们具体的业务产品特性。

如果页面UI很复杂,交互很多,那么应该多做做UI,因为底层给的东西都是对的,但页面加载以及重运算可能会出错。


如果页面很简单,主要是底层接口的逻辑处理和运算。那么就应该接口为重。

所以,具体情况具体分析。

 

招聘的一般都是人事,他们不懂这些。所以没必要计较这个。
技术领导说招个UI,他就会要你,技术领导说要个接口,可能就不要你,只能说你的技能对于他们的侧重不适合而已。

相关热词搜索:自动化,实施,头脑,价值

上一篇:使用SSH集成框架开发项目步骤
下一篇:自动化测试风暴二

分享到: 收藏
评论排行