测试自动化如何与回归测试一起使用?

时间:2016-11-08 21:30:51

标签: testing tdd

在进行回归测试时,我对测试自动化的概念(使用Selenium等)感到有些困惑。如果正在测试的系统不断变化,它如何影响测试用例?并且自动化是这种情况下的最佳方式吗?

3 个答案:

答案 0 :(得分:2)

回归测试意味着您要测试系统是否仍然按照应有的方式运行,特别是在任何更改之前它仍能正确完成所有操作。

当您破坏软件中的功能时,大多数用户会抱怨。因此,在发布之前,您不会进行回归测试。这就留下了你如何做的问题。

您可以手动测试。雇一群猴子,实习生,测试员或其他什么,让他们测试。为了让他们找到任何回归,他们需要知道要测试什么。因此,您需要测试脚本,告诉测试人员要测试哪些功能:单击哪个按钮以及输入的文本以及期望的结果。 (不幸的是,这部分排除了大多数猴子。)

替代方案是自动化测试:你仍然有一种测试脚本,但目前没有手动测试器可以使用脚本,但是计算机会这样做。

自动化测试的优点:

  • 它通常比手动测试更快。
  • 您不需要雇用测试员,实习生或猴子。
  • 你不必担心人类厌倦了重复的工作,错过了一步或厌倦了一遍又一遍地点击相同的旧程序。

自动化测试的缺点:

  • 不会抓住所有东西,特别是一些UI方面可能难以自动化:一个人会注意到重叠的文本或粉红色的霓虹绿色文本,但Selenium很高兴,如果它可以点击它。
  • 首先,您需要编写测试,然后进行维护。如果你只是添加功能,维护并不是很糟糕,但是如果你重构你的用户界面,你可能需要调整所有测试(Page Objects可能会派上用场)。但是,在这种情况下,你还必须重新编写所有手动测试。

答案 1 :(得分:0)

回归自动化测试工具是当今业界使用最广泛的工具。让我举个例子,考虑你的情景是“软件经历持续变化”。假设我们遵循基于Scrum的模型,其中软件将跨多个sprint开发。假设每个Sprint包含5个用户故事/功能。 Sprint 1经过开发,测试和交付。

团队转移到下一个Sprint 2,它又有5大功能。当时,开发团队将功能交给测试团队,测试团队开始为Sprint 1编写自动脚本。测试团队每天运行脚本说检查Sprint 2中正在开发的功能是否有效不要破坏Sprint 1之前的工作和测试功能。这只是自动化回归测试。

当然,这并不像听起来那么容易。自动化测试需要大量投资。投资不仅包括资金,还包括时间,培训费用,招聘专家等。

我参与了由大约组成的项目。 25个冲刺,数百个用户故事和项目跨越2年。只有2名测试人员在团队中,想象一下项目的困境是没有自动化测试套件。 同样,自动化不能完全取代手动测试,而是在很大程度上取代。自动化测试可以是功能性的,也可以是视觉回归测试。您可以很好地使用Selenium自动执行功能测试和任何其他可视化回归工具来检查CSS中断。

注意:并非每个项目都需要自动化。在考虑自动化任何项目时,您必须考虑 ROI(投资回报率)

答案 2 :(得分:0)

通常执行回归测试,以验证对系统进行的代码更改不会破坏现有代码,引入新的错误或更改系统功能。因此,每次将新功能部署到应用程序,添加新模块,更改系统配置,修复缺陷或进行更改以提高系统性能时,都应执行此操作。

以下是对Python中一些常用服务的简单回归测试。该脚本有助于捕获由于程序源代码中的更改而引起的错误。

    #!/usr/local/bin/python
import os, sys                            # get unix, python services 
from stat import ST_SIZE                  # or use os.path.getsize
from glob import glob                     # file name expansion
from os.path import exists                # file exists test
from time import time, ctime              # time functions

print 'RegTest start.' 
print 'user:', os.environ['USER']         # environment variables
print 'path:', os.getcwd(  )              # current directory
print 'time:', ctime(time(  )), '\n'
program = sys.argv[1]                     # two command-line args
testdir = sys.argv[2]

for test in glob(testdir + '/*.in'):      # for all matching input files
    if not exists('%s.out' % test):
        # no prior results
        os.system('%s < %s > %s.out 2>&1' % (program, test, test))
        print 'GENERATED:', test
    else: 
        # backup, run, compare
        os.rename(test + '.out', test + '.out.bkp')
        os.system('%s < %s > %s.out 2>&1' % (program, test, test))
        os.system('diff %s.out %s.out.bkp > %s.diffs' % ((test,)*3) )
        if os.stat(test + '.diffs')[ST_SIZE] == 0:
            print 'PASSED:', test 
            os.remove(test + '.diffs')
        else:
            print 'FAILED:', test, '(see %s.diffs)' % test

print 'RegTest done:', ctime(time(  ))

Regression tests与上面的类似,旨在涵盖应用程序的功能和非功能方面。这样可以确保每次构建都捕获到错误,从而提高了最终产品的整体质量。尽管回归测试是软件质量检查流程的重要组成部分,但是手动执行这些重复测试却面临许多挑战。手动测试可能很繁琐,耗时且准确性较低。此外,每次构建时测试用例的数量都会增加,回归测试套件也会增加。

解决上述挑战并维护一组强大且有凝聚力的回归测试脚本的简便方法是自动化。随着测试套件的增长,Test automation可以提高准确性并扩大回归测试的范围。

值得一提的是,即使使用自动化,您的回归测试也仅与测试脚本一样好。因此,您必须了解哪些事件触发了对改进和修改测试方案的需求。对于推送到您的代码库的每个更改,您都应该评估其影响并修改脚本,以确保所有受影响的代码路径都得到验证。

我希望这能回答您的问题。