软件测试需求的管理办法
在项目进行过程中，测试需求不是保持不变的，随着项目的进行，项目的“业务需求规格”、“软件需求规格”、“接口规范”、“设计规格”都有可能发生变化，对应的测试需求也可能发生变化；另外，测试策略、测试方法的调整也可能会导致测试需求的调整，需要采用规范的方法对测试需求进行管理，主要包括四个测试需求管理活动：需求评审、需求变更控制、需求跟踪和需求的一致性检查
测试需求评审
经过用户接受测试需求分析和导出过程后，将得到用户接受测试需求初稿。业务管理部门应组织相关的业务人员、技术人员、环境管理人员、测试人员和其他相关人员进行用户接受测试需求评审，确保达成一致意见。
同样，测试管理部门应组织相关的技术人员、环境管理人员、测试人员和其他相关人员对系统连接测试需求分析导出的系统连接测试需求，对系统集成测试需求分析导出的系统集成测试需求进行评审，确保系统连接测试需求和系统集成测试需求通过评审。
对于内部测试需求分析中导出的内部测试需求，应由开发中心质量控制部组织相关业务人员、开发项目组进行评审，确保达成一致意见。
当各类测试需求通过评审后，它们将被导入 MQC 中进行版本标识，并进行统一管理。
测试需求跟踪
测试需求的跟踪是通过建立测试需求与之来源、与之测试用例之间的双向跟踪关系来实现的。具体为：
• 建立用户接受测试需求与业务需求规格、与用户接受测试用例之间的双向跟踪关系；
• 建立系统集成测试需求与软件需求分析规格、与系统集成测试用例之间的双向跟踪关系；
• 建立（系统）连接测试需求与概要设计规格、与（系统）连接测试用例之间的双向跟踪关系；
• 建立单元测试需求与详细设计规格，与单元测试用例之间的双向跟踪关系；
• 建立内部测试需求与软件需求分析规格、与详细设计规格、与内部测试用例之间的双向跟踪关系。
当发生需求变更时，可以根据此双向跟踪关系分析变更影响范围。如针对一个业务功能的变更，可以分析出这个变更将影响到哪些软件需求功能，这些软件功能是否需要变更，相应的哪些设计模块、代码文件、测试需求、测试用例会受到影响，它们是否需要变更。
QC 可以管理测试需求与测试案例的双向跟踪关系，但是不能管理系统概要设计规格、系统详细设计规格、软件需求分析规格、业务需求规格与它们的测试需求之间的双向跟踪关系。这需要单独的需求管理工具，如 Telelogic Doors 或 IBM Rational RequesitePro 等需求管理工具，如果没有这些专业的需求管理工具，也可以使用 Excel 表格等方法手工进行管理。
测试需求变更控制
在测试需求的跟踪关系建立起来以后，可借此跟踪关系进行测试需求的变更控制。
对由于缺陷修复、系统功能增减、业务需求变更等原因导致的变更，应遵循规范的变更过程，使测试需求变更有序、可控、可管理。其变更的控制过程如下：
• 测试项目组需参与被测系统开发项目组的变更管理工作，针对在项目开发中引起的业务变更或系统功能变更或系统设计变更申请，测试项目组需要进行测试需求的变更影响性分析，判断这些变更是否会对相关测试需求产生影响。
• 如果会产生影响，测试项目组需要判断变更会影响到哪些测试需求，影响到哪些测试用例。
• 如果变更申请得批准，测试项目组需要变更测试需求及相应的测试用例，并形成新的测试需求版本（与变更后的相关开发文档版本保持一致）。
• 最后将新形成的测试需求提交给相关的主管部门，组织评审通过。
测试需求的一致性检查
• IT 业务管理部应指定人员定期检查用户接受测试需求与用户接受测试计划、用户接受测试策略和用户接受测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
• 测试管理部门应指定人员定期检查系统集成测试需求与系统集成测试计划、系统集成测试策略和系统集成测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
• 测试管理部门应指定人员定期检查系统连接测试需求与系统连接测试计划、系统连接测试策略和系统连接测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
• 测试经理应指定人员定期检查系统内部测试需求与系统内部测试计划、系统内部测试策略和系统内部测试方案的一致性，如果发现不一致，需要填写一致性检查报告。
• 测试经理针对一致性检查报告，确定不一致问题的纠正措施，并跟踪问题直至关闭。
文章来源于领测软件测试网 https://www.ltesting.net/
