业务分析指南/系统测试与验收
测试的主要目的是确定和传达所测试系统的质量。测试通常由开发人员、质量保证测试人员、用户、培训师和/或业务分析师完成。在项目团队中，可以将资源分配给测试协调员角色。该角色负责监督和协调项目的测试范围。测试协调员的职责可能包括但不限于收集业务需求、定义测试策略、制定测试计划、执行测试、管理系统缺陷以及协助用户验收测试 (UAT)。
注意：虽然业务分析师可以执行测试、测试计划和测试用例的开发，但这些功能不会获得 IIBA CBAP 或 CCBA 证书的经验学分。请参阅 IIBA 手册中的认证要求，网址为 http://www.iiba.org。
单元测试是执行的第一个级别测试，用于验证特定代码单元是否按预期工作。通常由开发人员在开发代码时执行。
集成测试是执行的第二个级别测试，用于验证集成组件之间的接口是否按预期工作。通常在所有组件完全开发后由开发人员执行。
系统测试也称为端到端测试。它是执行的第三级别测试，用于验证系统是否满足定义的业务需求。它应该在系统完全集成并且所有集成测试成功完成之后执行（通常由质量保证测试人员或开发人员执行）。
验收测试也称为用户验收测试 (UAT)，是执行的最后级别测试。它由系统用户在系统测试成功完成之后执行。它是在系统所有权移交之前对需求的最终验证。
另请参阅：软件测试维基百科网站 - http://en.wikipedia.org/wiki/Software_testing
为了帮助进行测试协调，测试策略可能比较合适。测试策略向关键利益相关者（例如项目经理和技术负责人）传达整体测试方法。测试策略定义测试范围、要测试的系统、测试所需的资源、所需的测试类型、缺陷管理详细信息、测试任务和测试时间表。在业务需求最终确定后，应完成测试策略。建议确定一名测试协调员来监督测试策略的完成。然后，项目经理或技术负责人应批准它，以确保其准确性。如果范围、需求、时间表或资源发生变化，测试协调员应根据需要查看和更新测试策略。
另请参阅：测试策略维基百科网站 - http://en.wikipedia.org/wiki/Test_strategy
业务需求最终确定后，应定义测试用例。每个业务需求应至少由两个测试用例覆盖，一个正向测试用例和一个负向测试用例。测试用例定义测试人员确定系统是否按预期工作所需的信息。每个测试用例应包括
- 测试用例标识符
- 对正在测试的需求的引用
- 执行测试所需的条件
- 执行测试的步骤
- 输入测试数据
- 测试的预期结果
- 实际结果（测试完成后完成）
另请参阅：https://en.wikipedia.org/wiki/Test_case
测试计划是列出测试给定系统所需的所有测试用例的正式文档。测试计划有时用于描述测试策略。测试协调员将与技术负责人合作协调测试用例和测试计划的开发。
另请参阅：http://en.wikipedia.org/wiki/Test_plan
缺陷管理是管理系统缺陷的过程。它从识别缺陷开始，到修复并关闭缺陷结束。缺陷管理也称为缺陷跟踪。
缺陷可以定义为“应用程序组件的编码、逻辑或组装中的错误，导致程序运行故障或产生错误/意外结果”。它也被描述为“软件产品中不满足软件需求（如需求规范中所述）或最终用户期望的条件”。缺陷也称为错误。
来源：http://softwaretestingfundamentals.com/defect/
应记录有关缺陷的重要数据；请参见下表，该表显示了在记录缺陷时可以捕获的数据及其定义。
| 字段 | 描述 |
|---|---|
| 摘要 | 对缺陷的简短描述。 |
| 应用程序 | 受缺陷影响的特定应用程序。 |
| 发现环境 | 最初发现缺陷的环境。 |
| 测试类型 | 发现缺陷时执行的测试类型。 |
| 严重程度 | 由业务用户/所有者或测试人员确定的缺陷对业务的影响。 |
| 优先级 | 处理该应用程序的缺陷相对于该应用程序中存在的其他缺陷的优先级。 |
| 描述 | 对所有相关信息的详细描述，包括记录/事务示例。应描述何时以及如何检测到缺陷，以及结果是什么。还应说明预期结果应该是怎样的。 |