【问题标题】:How does test automation work with regression testing?测试自动化如何与回归测试一起工作?
【发布时间】:2016-11-08 21:30:50
【问题描述】:

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

【问题讨论】:

    标签: testing tdd


    【解决方案1】:

    回归测试意味着您测试系统是否仍然按照应有的方式运行,特别是它是否仍然正确地执行任何更改之前所做的一切。

    当您破坏软件中的功能时,大多数用户都会抱怨。所以你不会在发布之前绕过回归测试。这就留下了你如何做到这一点的问题。

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

    另一种选择是自动化测试:您仍然有一种测试脚本,但目前没有手动测试人员使用该脚本,而是由计算机代替。

    自动化测试的优势:

    • 它通常比手动测试更快。
    • 您无需雇佣测试人员、实习生或猴子。
    • 您无需担心人类会厌倦重复性工作、错过步骤或厌倦一遍又一遍地点击同一个旧程序。

    自动化测试的缺点:

    • 无法捕捉所有内容,尤其是某些 UI 方面可能难以自动化:人们会注意到重叠的文本或霓虹绿色文本上的粉红色,但 Selenium 很高兴如果它可以点击它。
    • 首先您需要编写测试,然后维护它们。如果您只是添加功能,维护还不错,但如果您重新构建用户界面,您可能需要调整所有测试(Page Objects 可能在这里派上用场)。但话又说回来,在这种情况下,您还必须重新编写所有手动测试。

    【讨论】:

      【解决方案2】:

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

      团队进入下一个 Sprint 2,它再次具有 5 个主要功能。当开发团队将功能移交给测试团队时,测试团队开始为 Sprint 1 编写自动化脚本。测试团队每天运行脚本以检查 Sprint 2 中正在开发的功能是否不要破坏 Sprint 1 先前工作和测试的功能。这只不过是自动化回归测试。

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

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

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

      【讨论】:

      • Scrum 与团队将一些东西交给测试团队?这听起来并不敏捷。
      【解决方案3】:

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

      下面是对 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 与上面的类似,旨在涵盖应用程序的功能和非功能方面。这可以确保在每次构建时都能捕获错误,从而提高最终产品的整体质量。虽然回归测试是软件 QA 过程的重要组成部分,但手动执行这些重复测试会带来许多挑战。手动测试可能乏味、耗时且不太准确。此外,每次构建都会增加测试用例的数量,因此回归测试套件也会增加。

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

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

      我希望这回答了你的问题。

      【讨论】:

        猜你喜欢
        • 2017-01-17
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2021-08-06
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多