业务分析指南/系统测试和验收
测试的主要目的是确定和传达所测试系统的质量。测试通常由开发人员、质量保证测试人员、用户、培训师和/或业务分析师完成。在一个项目团队中，可能会有一个资源被分配到测试协调员角色。该角色预计将监督和协调项目的测试范围。测试协调员的职责可能包括但不限于收集业务需求、定义测试策略、开发测试计划、执行测试、管理系统缺陷以及协助用户验收测试 (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/
应记录有关缺陷的重要数据；请参见下面关于在记录缺陷时可以捕获的数据及其定义的图表。
| 字段 | 描述 |
|---|---|
| 摘要 | 缺陷的简短描述。 |
| 应用程序 | 受缺陷影响的特定应用程序。 |
| 发现环境 | 最初发现缺陷的环境。 |
| 测试类型 | 发现缺陷时执行的测试类型。 |
| 严重程度 | 由业务用户/所有者或测试人员确定的缺陷的业务影响。 |
| 优先级 | 解决应用程序缺陷的优先级，与该应用程序存在的其他缺陷相关。 |
| 描述 | 详细说明所有相关信息，包括记录/交易示例。应描述何时以及如何检测到缺陷，以及结果是什么。还应指出预期结果应该是什么。 |