维护软件测试的策略 软件测试工具
上面描述的开发测试策略的技术，能够直接用于新开发的系统。一个很自然的问题是：对于一个以前已经开发完毕或测试过的系统，上面所描述的步骤在多大范围内仍然可以用于该系统的版本维护?
从测试策略的观点来看，版本维护主要的不同点在于故障几率。在维护的过程中，存在由于系统发生变化而gIA故障的风险。那些对系统行为的有意改变当然需要测试。但也有可能需要测试那些系统中没有变化的功能，它们在以前的版本中表现正常，而在新版本中由于其他变化的副作用而出现问题。这种现象称为回归。在版本维护中，绝大部分的测试工作是测试以前的功能是否仍然工作正常，这被称为回归测试。因为一且产品进入维护阶段，故障几率会发生改变，所以相关的风险也会发生改变。接下来将改变子系统的相对重要性：例如当开发一个全新的子系统时，由于其商业要求高，因而其重要性就高。在版本维护中，这个子系统没有发生改变，因此相关的风险就低，就可以将该子系统的重要性评定为低。
因此在开发测试策略时，通常将“子系统”的概念用“变更”来代替是有用的。这些变更通常是一组将实现的“变更需求”和一组需要解决的“已知缺陷”，要对每个变更需要对系统的哪些部分做修改，哪些部分会间接受到影响，哪些质量特性与之相关等进行分析。根据风险和预期进行的彻底测试，存在多种可能来测试每个变更：
一仅仅关注变更本身的有限测试；
一对变更的功能或部件的全面(再)测试；
一对变更的部件与其邻近部件的一致性和交互性的测试。
实现每一个变更，都会引起回归风险。回归测试是维护测试项目中的标准元素。通常要维护一组专门的测试用例来进行回归测试。根据风险和可用的测试预算．需要在执行完整的回归测试．还是测试那些最为相关的测试用例之间做出选择。测试工具可以非常有效地支持回归测试。当回归测试的绝大部分能够自动执行时，选择放弃哪些回归测试用例就不再必要了，因为无需多大努力就能够执行完整的回归测试。
决定按照变更需求而不是子系统来规划测试策略，在很大程度上依赖于变更的数量。当只有相对很少的变更时，通过将这些变更作为风险评估、计划和进度跟踪的基础，就能够更好地管理测试过程。当子系统由于实现许多变更而进行重大修改时。可以采用其最初开发时所用的方法来进行处理。通常人们更喜欢基于子系统来开发测试策略。如果一旦决定按照变更需求来规划测试策略，则下面的步骤就可用来开发测试策略：
1确定变更(要实现的变更需求和要解决的问题)；
2确定变更和回归的相对重要性；
3选择质量特性；
4确定质量特性的相对重要性；
5确定每个变更(回归)，质量特性联合体的相对重要性；
6确定可用的测试技术。
表7 7是从前两个步骤得出的—个矩阵例子。其他步骤和74节中描述的步骤类似。
表7 7变更和回归的相对重要性矩阵
变更，回归 相对重耍性(％)
文章来源于领测软件测试网 https://www.ltesting.net/