软件测试培训之回归测试的基本过程及实践

网友投稿 833 2022-11-07

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

软件测试培训之回归测试的基本过程及实践

回归测试的基本过程

(1). 识别出软件中被修改的部分;

(2). 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。

(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。

(4). 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。

(5). 用T1执行修改后的软件。

第(2)和第(3)步测试验证修改是否破坏了现有的功能,第(4)和第(5)步测试验证 修改工作本身。

回归测试实践

在实际工作中,回归测试需要反复进行,当测试者一次又一次地完成相同的测试时,这些回归测试将变得非常令人厌烦,而在大多数回归测试需要手工完成的时候尤其如此,因此,需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略,自动测试工具应该是通用的和灵活的,以便满足达到不同回归测试目标的要求。

在测试软件时,应用多种测试技术是常见的。当测试一个修改了的软件时,测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。

回归测试并不减少对系统新功能和特征的测试需求,回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求。

回归测试是重复性较多的活动,容易使测试者感到疲劳和厌倦,降低测试效率,在实际工作中可以采用一些策略减轻这些问题。例如,安排新的测试者完成手工回归测试,分配更有经验的测试者开发新的测试用例,编写和调试自动测试脚本,做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下,鼓励测试者创造性地执行测试用例,变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。

在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。

在实际工作中,可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题,而同时也可以揭示编码在回归方面的错误。

上一篇:〖Kubernetes指南⑤〗Label快速入门
下一篇:K3S:轻量的Kubernetes -- 概览&部署指
相关文章

 发表评论

暂时没有评论,来抢沙发吧~