51Testing软件测试论坛

标题: 测试计划动态调整 [打印本页]

作者: 樱花季节 时间: 2011-1-13 10:36
标题: 测试计划动态调整
背景介绍
制定测试计划的目的，主要是明确测试背景、测试目的、风险分析、所需资源、任务安排和进度等。
即将需求和总体设计分解成可测试、应该测试、推迟测试和无法测试等范围，对每个范围制定测试的策略和方法，
制定发布程序和停止测试的标准，确定测试风险，准备测试所需要的环境和资源，制定测试进度和任务安排等。
因此，测试计划是对整个测试过程的组织、资源、原则等的规定和约束，是指导整个测试过程的导航灯。
文档编写的目的
在实际的项目中，常常会有需求、版本的变更，硬件设备或软件环境的不达标，资源的流失等情况出现。
这些变更不仅会影响到测试过程的正常进行，而且，如果处理不当，会造成极大的人力，物力和时间的浪费。
因此，针对各种情况的变更，需要在第一时间进行测试计划的调整，本文档对各种变更以及应对措施进行了收集，
希望能给读者相应的参考。
目录
Q1 项目计划的变更
Q2 需求的变更
Q3 提交测试版本的变更
Q4 测试资源的变更
Q5 测试计划的分步制定

Q1 项目计划的变更

项目计划的变更一般所涉及都是日程变更。当项目计划出现变更时，由于软件产品的发布期是既定的，因而不得不采取一些有效的方法，压缩执行测试的时间。
应对措施：
1.1 确定测试重点以及主次。先让重点部分优先测试。相对次要部分可以留给用户测试，即：用户体验测试
1.2 减少测试的阻力，例如降低测试计划中冒烟测试准入准则
1.3 变更测试策略：及时调整测试策略。可以采取分步提交测试，例如改成迭代方式增量测试
1.4 减少测试轮次：酌情减少回归测试的轮次。如增强开发单元测试粒度。控制上游代码质量。对于缺陷，进行局部回归而不是重新全部测试。

Q2 需求的变更

项目进行过程中最不可避免的就是需求的变更。在制定测试计划时，如果项目需求处于动态变化中，则需要在测试用例章节进行说明。在实际工作中，测试用例和测试数据往往没有进行区分，因而当需求发生变化时，设计的数据就作废了。
应对措施：
2.1 采用用例和数据分离设计方式。待需求确定后，再细化测试用例中对应表字段等元素。
2.2 制定一个变更周期的约定，定义变更的最大频度和重新测试的界限。
Q3 提交测试版本的变更

提交测试版本变更频繁，也能造成测试资源和时间的浪费。
对于测试产品版本的变更，除了部分是由于需求变更而造成的外，修改缺陷引发的问题或配置管理不严格也能造成版本变更。
应对措施：
3.1 规定项目更新不能多于每天三次，一个相对大的版本其变更不能每周多于1次。
3.2 紧急发布规定负责统一维护和同步更新测试环境
Q4 测试资源的变更

测试资源的变更是测试组内部测试资源不足或者与其他测试项目的测试时间冲突时，测试部门不能安排更多的人力和足够时间参与测试。
应对措施：
4.1 需要保证的资源还必须在测试计划中人力资源和测试环境一栏明确
4.2 资源流失应作为风险标示在项目中
Q5 测试计划的分步制定

对于规模比较大，涉及的资源非常多，周期比较长的项目的测试计划的制定。
应对措施：
5.1 可以采取分步制定测试计划的方案。
5.2 在项目需求评审阶段，测试计划可以是个大纲，标示出各个里程碑点。
5.3 在具体的开发设计中，针对各个模块进行测试计划的细化调整。

作者: menghang 时间: 2011-2-25 16:44

作者: msnshow 时间: 2011-2-25 21:33
没错，同意

5.1 可以采取分步制定测试计划的方案。
5.2 在项目需求评审阶段，测试计划可以是个大纲，标示出各个里程碑点。
5.3 在具体的开发设计中，针对各个模块进行测试计划的细化调整。

作者: sarajiang123 时间: 2016-7-12 17:10

作者: szc123qq 时间: 2020-3-27 16:59

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)