业务分析指南/系统测试和验收
测试的主要目的是确定和传达所测试系统的质量。测试通常由开发人员、质量保证测试人员、用户、培训师和/或业务分析师完成。在项目团队中，可以将资源分配给测试协调员角色。预计该角色将监督和协调项目的测试范围。测试协调员的职责可能包括但不限于收集业务需求、定义测试策略、开发测试计划、执行测试、管理系统缺陷以及促进用户验收测试 (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
缺陷管理是管理系统缺陷的过程。它从发现缺陷开始，到缺陷修复并关闭结束。缺陷管理也称为缺陷跟踪。
缺陷可以定义为“代码、逻辑或应用程序组件组装中的错误，导致程序故障或产生错误/意外结果”。它也被描述为“软件产品中不符合软件需求（如需求规范中所述）或最终用户期望的状况”。缺陷也称为 bug。
来源：http://softwaretestingfundamentals.com/defect/
应记录有关缺陷的重要数据；请查看以下图表，其中包含在记录缺陷时可以捕获的数据及其定义。
| 字段 | 描述 |
|---|---|
| 概要 | 缺陷的简要描述。 |
| 应用程序 | 受缺陷影响的具体应用程序。 |
| 发现环境 | 最初发现缺陷的环境。 |
| 测试类型 | 发现缺陷时执行的测试类型。 |
| 严重程度 | 缺陷对业务的影响，由业务用户/所有者或测试人员确定。 |
| 优先级 | 解决应用程序缺陷的优先级，与该应用程序存在的其他缺陷相关。 |
| 描述 | 对所有相关信息的详细描述，包括记录/事务示例。应描述缺陷的检测时间和方式，以及结果。还应说明预期结果应该是什么。 |