为了保证特殊人群能够顺利访问,不少国家均出台了相关标准。在某企业内部,根据标准制定了几十条检查点,为了验证程序是否遵循无障碍访问要求,测试人员需要借助相关工具进行测试分析和测试结果的管理。
回归测试是贯穿在整个测试的各个阶段的一个测试活动。它的目的是检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷。软件在测试或者其他活动中发现的缺陷经过修改后,都要进行回归测试的验证。在做回归测试的时候可以采用不同的策略。
回归(向后追溯)是软件系统的现实生活。即使之前是很好地工作的,但是不能确保它会在最近的“很小”的改变后也能工作。是的,模块设计和充分的系统架构可以减少这种问题的出现,但是不能完全消除。回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动,我们怎么进行充分的回归测试呢?我们怎么知道查找哪些方面?我们怎么减少出现问题的风险?
如何更高效地进行回归测试?看到这个问题,好多人觉得这是测试人员的事,其实我觉得如何更高效的进行回归测试应该是开发人员和测试人员共同的事。
回归测试是永远都需要的。但是我们在非常有限的时间里测试一个“很小”的改动,我们怎么进行充分的回归测试呢?我们怎么知道查找哪些方面?我们怎么减少出现问题的风险?
回归测试就是修改完bug之后对程序的新的一轮测试,据微软的统计,按照他们的经验,一般开发人员解决3~4个bug会衍生出一个新的bug,这就是必须作回归测试的原因。
在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。