测试开发实践软件测试@IT·互联网

谈自动化测试

2018-04-07  本文已影响283人  严北

先写总结


正文

谈到自动化测试,有很多朋友对自动化测试不够理解,或是存在误解,导致工作方向不对,或是操作流程不够规范,导致陷入死胡同,不知道如何去做好,甚至不知道如何开展自动化测试。

功能测试过程

自动化测试实际上测的也是功能,只是将功能测试从手工转化为代码执行,因此自动化测试必须遵从功能测试的操作过程。

功能测试的基本工作包括:

  1. 分析功能点,创建测试用例;

  2. 执行测试用例;

  3. 输出测试结果/报告。

测试用例应当至少包括:

自动化测试

这里所说的自动化测试仅包括两个方面,一个是UI自动化测试,一个是接口自动化测试。二者都是对产品功能上的测试,也非白盒测试。

更有意义的自动化测试在于单元测试,但是单元测试一般需要有开发人员的配合,因此此处不谈。

手工测试即大部分人所说的“点点点”、“功能测试”,而自动化测试则是将这部分工作用代码实现的过程。

那么文章开头提到的误区在哪儿呢?

一是测试对象的选择

这里所说的测试对象,是指测试页面上直观的功能(UI),还是测试请求上的数据交互(接口)。

见到很多朋友,在尝试做自动化测试的时候,完全不对产品分析,直接选择了UI自动化测试,原因是网上大部分自动化测试所提到的,都是selenium/appium等使用。

首先要明白,测试是为产品服务,产品的特性决定了测试执行的方向。 UI测试并不适用于大部分未稳定的产品!

试想,当你所测试的产品正在研发初始阶段,页面仍在摸索阶段,可能今天一个页面是这些元素,明天这些元素名通用都改了名,或者干脆页面删掉重做了。那你作为测试该怎么办,前端开发时候能否顾及到通知测试,而测试是要让开发为你把修改了的元素、功能重写,还是你要付出重写一个新页面的测试脚本的精力?

相比之下,接口测试需要的维护成本是较低的。如果接口需要改动,通常是一些传值或响应内容的改动,在代码中只需要进行部分修改即可,而对UI测试时往往需要更多步骤。

但是接口测试也不是万能的,例如一个后端稳定,问题大部分出自前端的时候,做好页面测试是更有必要的。

通常来说,先做好对后端的测试(接口测试),再对前端测试(UI)是比较好的选择,但是一定要做更符合自己产品的测试。当后端稳定时,前端也会相对稳定,可以继续开展对前端的测试了,此时的维护成本就比过早介入UI自动化测试的成本来得低。

第二个误区是测试过程不够完善

有很大一部分刚开始做自动化测试的朋友都将“自动化测试”做成了“自动执行点击操作”。有什么区别呢?参照功能测试过程一节,测试不仅仅是执行过程,还包括结果判定,报告输出等等环节。很多人在做UI自动化测试时候,只考虑如何实现某个拟人过程,实现之后就认为这个功能点写完了,然后继续写下一个功能点。在执行过程需要人盯着,看看执行时候是否出错,试问这是“自动化”吗?

自动化测试一定要有断言,并且输出测试结果/报告,才能解放“人眼”,让测试脚本自己运行,运行完成后告诉你结果,并且能够让你快速准确地定位到问题所在。

不够完善还体现在测试用例设计上。测试用例是基本,否则手工测试都做不好谈何“自动化”?

有心的话,看懂开发代码,特别是判定条件,保证对每一个条件的覆盖,才能发现更多问题。测试用例设计得好,即使不开展自动化测试也能发现很多问题。自动化测试可以作为协助手段,帮助覆盖一些在前端无法或难实现的一些用例(例如一些条件需要遍历,用代码很容易实现,而手工可能需要操作很久)。

总结

自动化测试与手工测试相比有两个好处:

说到底,自动化测试是用于提升测试效率,并不是用于标榜自动化测试比手工测试优秀。如果你的自动化测试用例覆盖率低,说实话,如何编写测试用例更适合你学习,而非“如何完成某个点击操作”,“如何为某个输入框赋值”。

当你解决了“测试对象的选择”(怎么做自动化测试)和“测试过程不够完善”(怎么做好自动化测试)这两个问题,自动化测试的优势才能提现出来。

更重要的是要因地制宜,针对不同的测试产品采用不同的测试方法,用努力提高效率的心态去分析测试对象,选择测试工具,才能保证你在测试工作中的付出与收获能成正比。

上一篇下一篇

猜你喜欢

热点阅读