纯技术角度看自动化测试的迷思

转载 2007年09月24日 12:56:00
谈到自动化测试方面的误区,不少文章倾向于从人性、管理、职业规划等方面进行探讨。我这次专门从计划、设计、实现、维护等技术角度总结一下。

自动化的最终目标是什么?

很多人以为是像工业革命一样消灭手工劳动者,在这里等于手工测试人员。但是测试存在一个目前来看还算正确的、其他行业不多见的悖论:任何时候,你都不能准 确知道还有多少bug,就像警察不能准确知道还有多少贼一样。所以自动化的最终目标——目前来说——是解放尽量多的人手去进行更多的测试,除非有一种手段 能像《少数派报告》里面的预言少女一样预知所有的bug。因为永远有bug,有未知的bug,所以目前不存在能覆盖所有bug的手段,这意味着总需要人的 参与。现代化手段只是减少了而不是杜绝对人员的需求。所以如果认为自动化工作一做完就没活干,那你就大错特错了。正认为这些人闲下来,他们有空发现更难发 现的bug。这本来没什么大不了的,但是搁在计划阶段如果过分乐观,牛皮吹得太大的话,到后面就不容易圆回去了。因为按上面分析,自动化测试总有些地方是 力有不逮的,如果这些地方没有安排好人手时间,只要在这些地方出大问题,那你就玩完了。

能否/怎样自动验证?

这个问题每次复审测试计划的时候我都会问,针对每一个提出要实施自动化的地方。每个人、每个工具谈论自动化的时候都在说如何真实模拟用户使用产品的情况, 这很好,绝对需要关心。不过我得问一句:测试的最后结果是什么?如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话,你就漏掉了一大块:最起码还 得加上“产品能工作/不能工作“!所以模拟用户使用产品的各种情况,只是解决上述问题的第一部分;如何得出测试通过/不通过的最终结论,才是解决问题第二 部分的基础部分,还有详细缺陷描述、上下文数据收集等没做到呢!
所以让机器像人一样使用产品,并没有解决全部问题,剩下的事情还有多少,这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉,那简直就是在赌运气——有些时候自动验证是小菜一碟,但很多时候不是。
令事情恶化的是,自动验证了产品的一些指标,并不能反映产品的真实质量。有时验证过的指标通过了,其实其他地方暴露了问题却没有检查:比如说界面说没有查 询结果,这是期望的,实际上查询请求根本没有发过去,不去检查底下做了什么的话是发现不了这种bug的;有时验证过的指标不通过,其实只是个小问题,大问 题需要通过别的指标暴露出来的:比如说返回结果跟预期的不一致,实际上该有的都有,只是没有排好顺序而已,但是被标记成重要的测试用例没有通过,把开发人员搞个鸡飞狗跳。
这个话题深入下去,那就涉及到白箱测试策略、逻辑推演、嗅探和代码注入以及布景伪造(environment mockup)等领域,但我想强调的只是,如果考虑自动化测试,自动验证绝对不是可忽略的问题。

整合现有还是自力更生?

这个话题用于辩论赛是最好不过的,它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。
“现有的工具多少经过测试,质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛角尖,我们先关注几个问题:整个测试方案里面哪些部分是关 键,质量不好会导致致命后果的?这些部分有专人保证质量吗?出事的时候反应时间和修复效果如何?如果这些问题的答案是“我充分了解”或者“没问题”,那我 也同意这个观点(我敢打赌,回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案了)。
“整合现有的工具省时间和人力”。类似的几个问题:你能在这些工具中自由地调试产品的缺陷吗?整合方案能适应产品的演变吗?几个月后呢?几个版本后呢?有需要变动的话代价多少?(哗啦啦又跑掉一大队人了)
“自力更生好控制”。投入产出比如何?引用的技术可靠吗?如果你是开发者(之一),别人都觉得好控制吗?谁来测试你的自力更生成果?
“有些事情必须得自力更生“。剪裁现有工具难度如何?时间允许吗?
其实,纵观所有提出的问题,我想强调的一点是,自动化测试的开发跟产品开发一样,也是需要规划和管理的,回答这些问题也是自动化测试项目管理的一部分。

如何解决历史遗留问题?

折腾上个版本的自动化测试框架是新人最头疼的事情。但了解了一些事情之后,原先的事情就没那么令人头疼了。很多人忙于了解旧框架本身,其实世界一直在变,现在项目需要解决的问题才是关键。无论上个版本的东西多么辉煌,只有它适合现在的项目(的部分)才是有价值的。所以关于旧的自动化测试技术,了解什么能用得上,而不是了解它是什么,才是需要做的事情。就好像汽车修理工知道怎样拆旧车零件来修新车,并不需要他知道怎样造一辆出来或者知道怎样修好旧的那辆。
另一个极端是“旧的不好浪费,继续用“。“能用“这个结论是基于以前项目的情况的,现在能不能用,值不值得用得看现在的需求。人们要理发就是个很好的例子:总不能因为头发长出来要耗养分不好浪费,就一辈子都不剪吧?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1747560

===================================================

#   Architecturer 发表于2007-08-17 17:45:07  IP: 207.46.92.*
博主的思考很深刻,我只补充两点:

测试自动化不能从根本上代替测试人员,更无法保证产品的质量。那么自动化测试能做什么?产品的质量又是如何保证的?

自动化测试的主要应用范围是回归测试,也就是说测试曾经正常的功能在产品加入新功能或者有了bug fixing以后是不是依然能够工作。这是自动化测试的主要目的,而自动化测试的Case依然需要测试人员的智慧来编写,所以可以说自动化测试只是一个辅助性的工具。当然,在某些软件的压力测试上也需要自动化测试工具。

产品质量其实在设计之间就已经被决定了,这其中的决定因素就是团队本身的素质和团队成员在这个具体项目上的经验。测试只能帮助一个设计良好的产品不会因为小的bug而大幅度的降低可用性,而无法挽救一个设计就很差的产品成为优秀的产品。
 

个人角度认为自动化测试的学习步骤

软件自动化测试的学习步骤 大概步骤如下: 做好手工测试(了解各种测试的知识)-> 2. 学习编程语言-> 3. 学习Web基础(HTML,HTTP,CSS,DOM,Javascript...

另一个角度看软件测试

  • 2013年11月21日 14:20
  • 2.43MB
  • 下载

opencv图像识别技术在自动化测试中的应用

在自动化测试中,基于xpath、js选择器、css选择器进行元素定位及判定的技术已经比较成熟。在实际应用中,无论是web端还是移动端,仍有很多时候需要根据页面内容、页面中的图像进行定位及判定,这里介绍...
  • buaawp
  • buaawp
  • 2016年03月04日 17:15
  • 434

三类自动化测试技术学习

来源与极客学院视频教程。 TDD 测试驱动开发 根据测试用例,编写测试脚本,然后为了让测试脚本跑通而去开发代码。 代码自动化测试:多应用于测试服务端接口 界面自动化测试:使用一些工具去模仿...
  • zh26622
  • zh26622
  • 2015年11月20日 16:38
  • 174

浅析Android自动化测试基础技术(二)

在上面一篇文章中介绍了Android模拟点击按键的技术,但是对于自动化测试来说,使用坐标来编写执行脚本是很难维护的,所以需要一种更灵活的方式。 获取控件信息 通过Android sdk提供的工具,hi...

精通QTP-自动化测试技术领航 第2章2.2.9综合实例练习总结

1、浏览器  通过浏览器句柄来操作浏览器 oHwnd= Browser("51Testing软件测试网").GetROProperty("hwnd") '获取句柄 Browser("hwnd:= " ...
  • Tan37Lu
  • Tan37Lu
  • 2014年11月26日 19:46
  • 687

Windows GUI自动化测试技术的比较和展望

注意:这篇文章比较古老,仅供入门参考 http://www.51testing.com/html/16/n-170116.html   以前写过一篇跟UI自动化测试有关的技术,...

自动化测试技术QTP教程

  • 2017年10月31日 10:00
  • 9.64MB
  • 下载

基于图片驱动的C/S架构自动化测试技术 - Sikuli

前言 针对C/S架构的项目做自动化测试,我们可能最先考虑的是引入惠普的QTP工具,软件上的每一个空间都可以识别成唯一的元素定位,对这些元素按照测试用例进行操作,实现开发自动化测试脚本的目的。而对于非...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:纯技术角度看自动化测试的迷思
举报原因:
原因补充:

(最多只允许输入30个字)