51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2635|回复: 0

[讨论] 如何在敏捷的世界中,实现高效的自动化测试?

[复制链接]

该用户从未签到

发表于 2018-5-29 16:57:55 | 显示全部楼层 |阅读模式
敏捷中的自动化非常关键

程序中每新添加一种功能,应该尽可能保证新添内容不会对原有功能产生影响。由于Sprint的持续时间
较短,有时系统只需执行其中的一小部分程序,就能够完成功能的实现。此时,自动化循环测试就派上
用场了。

毋庸置疑,自动化的引入和发展,肯定是要花费一些经历和时间的。但从长远来看,在初期就对自动化
测试进行投资,肯定是有回报的。

在敏捷中如何自动化?

无论何时,关于在何时引入自动化的问题,大多数人的第一反应都是——在进行"烟雾测试"或"回归测试
"的时候。

不可否认,自动化对于二者来说的确是最佳选择。但如果要拿自动化测试的结构来讲,这些测试仅仅
是我们讨论的这座自动化金字塔的顶层。

除了顶层,我们还有更重要的服务层和单元层。

那么,除了烟雾测试和回归测试之外,还有什么环节,可以考虑用自动化来实现?

# 1)当进行构建和部署时

在传统环境中,团队往往会设置固定的时间频率来进行构建,可以是每周、每两周甚至是每月。原因
很简单,这是部署必需的时间。

当然,这种方法也存在着一些问题。团队在发现并确定问题和缺陷后,只能等到设置好的时间段到来
以后,才能够进行修改并完成新功能的实现。而在这期间,常常会因为一些小问题的出现,拖延整个
进度。

当然这里还存在着另外一个原因——如果测试人员在完成该测试以后,才发现其中的问题和缺陷,往往
会导致这些问题根本无法记录和解决。因为此时程序员已经开始下一阶段测试工作,为了不能耽误工
作计划的实施,几乎没有人会回头去解决原来应用程序的错误和问题。

构建和部署是重复且乏味的工作。有时测试人员可能会需要花费几个小时来完成仅仅一个构建的部署,
这会大大增加测试的时间,并会对最终的反馈结果有着巨大的影响。

作为一个重复且如此耗时的任务,引入自动化,在此时成为了一个不错的选择。

自动化构建部署的一些优点是:

· 不会出现错误

(如:将文件复制到错误位置等人为错误)

· Bug特性一旦确定就可以立即进行测试

· 测试人员将会有更多的时间来进行其他测试

· 工作效率提高,生产效率更快

· 可以更快地得到的反馈结果

# 2)当执行单元测试、组件测试时

单元测试和组建测试构成了金字塔的最低层,因此二者都必须十分稳固才行。此时,自动化测试能够
帮助测试者解决这个问题。

开发团队应共同努力,将此类测试中的大部分都纳入到本层,并将其投入到自动化生产中,以得到最
优结果。

# 3)当执行API 、Web服务测试时

Web服务是请求和响应二者之间,交换信息间的介质,且不涉及底层体系结构。简单来讲,web服务
测试通常要做的事,就是给出请求并验证响应。

实现测试web服务,需要编写程序调用web服务方法,来验证其返回值。将所有的测试数据放在一个e
xcel表中,读取并将其作为一整个参数进行传递,就能够验证其结果。

这种特殊的测试是金字塔中层的一部分。大多数功能测试都可以被纳入到这个层当中。

利用自动化解决在该层中出现的问题,可以让中层变得更加稳定,并保证该测试过程不会拖整个周期
的后腿。

# 4)当执行后GUI的测试时

无论UI发生了什么变化,GUI的测试功能总能保持不变。即使更改一些UI元素,该特性也不会改变。

大多测试用例都是用表格进行编写的,除此之外,还可以用代码片段来编写。引用自动化测试后,系
统接收来自表格上的输入,将会立即产生结果并给出输出反馈。这为运行这些测试并获得预期结果,
提供了更广阔的空间和平台。

# 5)当执行非功能性测试时

这种非功能测试技术主要涉及负载、性能和压力测试三个方面。市场上有各种各样的工具可以用来自动
化这些测试。

# 6)当进行数据比较时

许多测试会要求测试人员比较文本文件、CSV或excel文件的差别,从而进行数据的验证。

进行数据比较的过程有一个特点,就是可以比较内容相同但是格式不同的数据。当有两个来自不同的
地方但内容相似的文件时,就可以利用该特点进行测试来得到测试结果。

此时,也是可以应用自动化的。

# 7)当进行搜索时

从大量文件中搜索特定文件也是很麻烦的。例如,搜索日志文件的工作。如果此时考虑将其自动化,那
么将简化该工作的大部分内容。

# 8)当执行重复的任务时

任何与终端用户互动的任务,如果工作内容重复,都应该考虑投入到自动化当中。

自动化并不意味着有多么复杂的技术。它可以仅仅运用一个简单的VB或Java程序,就能够完美解决所
有问题。

从哪里开始?

这里没有要点,也没有一步一步的指导,来具体说明要在哪里开始自动化。

启动团队的自动化,要求测试员进行头脑风暴,并对其想要实现自动化的方面,进行深入的思考,考虑
其是否具备以上条件。

你可以先

识别重复的任务;

识别应用程序的复杂区域;

确定测试的难点所在;

如果在整个过程中都没有发现具体的、可以有运用到自动化的地方,那么这个测试过程很有可能是选择一
种多层的方法,对其中的每一个单元测试都需要进行自动化。

同时,测试人员的工作可以先从烟雾测试开始,然后进行回归测试。一旦团队找到了突破口,就可以逐
渐将其他的任务也进行自动化了。

一旦确定了需要完成自动化的范围,下一步的任务就是设计框架了。

记住,在敏捷测试中,框架是会随时变化的。不要在最开始就设计好了整个过程的框架。因为有时为了
设计和实现最小可行产品,测试过程中会不断地增加现有框架中的功能和特性。如果在初始阶段就设计
好了整个框架,这将为后续工作带来极大的困难和工作量。

想要自动化循环功能强大,还需应用良好的编码实践开发。

在敏捷的世界里,自动化还存在着挑战

· 决定测试套件、工具、框架和方法时,都需要一个恰当的策略。切记,千万不要过度计划。

· 不要为了快速交付,而在代码的质量上缩水。切记,技术负债也会存在于自动化之中。

· 大多数的团队往往不会遵循“整体团队运行方法”,他们会将整个编码和使用自动化方法的责任都留给
测试人员,这将大大增加测试人员的工作负担。

· 自动化功能测试比自动化UI更加困难。

在所有这些挑战中,最关键的一点,就是提高测试人员的技能水平。

测试人员所做的自动化编程测试工作几乎是整个团队工作的全部。

因此,不仅要完成实现任务,还要将自动化集成到CI中,这些都是很重要的。这就要求测试人员不断学
习新的技能、学习新的工具和技术来提高工作能力和水平,从而迎接挑战并战胜挑战。


总结一下著名的敏捷测试象限:

象限1是单元和组件测试,可以通过TDD方法实现自动化。

象限2讨论了功能测试,可以应用BDD方法来实现自动化。

象限3是唯一具有手动测试的范围。

象限4基本上讨论了利用一些工具就可以实现的测试,主要有负载测试、压力测试、卷测试和安全测试。

结论

除了烟雾测试和回归测试之外,还有很多自动化可以实施的范围。因此,我们必须摆脱自动化传统“牢
笼”思想的束缚。

而要加强以上提到的测试类型,将意味着要求敏捷测试人员的技能全面,而不仅仅是只局限于发现问题
的阶段。

测试人员需要更多的团队协作,去提高他们的编程、自动化技能水平。

在未来,自动化的测试将会越来越多。它将给测试人员带来更多的时间,去从事其他更复杂和更具挑
战性的工作。


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-28 20:58 , Processed in 0.063259 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表