测试升级{ #testing-upgrades }¶

虽然 DHIS2 软件开发团队在发布之前会进行大量的功能、非功能和回归测试，但该平台的规模及其可配置性意味着并非每次发布都能对所有情况进行探索。因此，在升级生产实例之前，实施机构必须在测试环境中使用自己的数据，根据自己的关键方案对系统进行验证。

测试应在可用时间和预算范围内尽可能详尽。通常，这意味着要在一定程度上确定优先次序。为提高效率，主要的重点领域应包括：

• 特定于实施的定制：其他人可能无法测试的工具和功能。这可能包括定制应用程序和集成，以及高度配置的程序。
• 已知挑战：在实际环境中，不同规模的元数据和数据的核心应用场景大不相同。直观的例子包括分析生成或搜索注册人数。
• 关键工作流：一旦出现故障，会对目标实施产生严重运行影响的活动。这不仅包括考虑情景，还包括需要执行这些情景的各种用户角色。

应用程序测试清单{ #application-testing-checklist }¶

为了帮助确定优先场景和关键工作流程，可在 此处 获取升级模板清单。

本模板列出了平台的核心功能，旨在为您在升级过程中可能需要测试的项目提供指导。您需要根据自己实施的具体情况修改此模板，例如添加任何类型的自定义修改、应用程序、脚本或其他工具，以支持您的实施；或为您自己的实施开展任何不在清单模板内的具体活动。

为自己的实施工作制定这份清单的一个重要部分是关注当前正在使用的功能。这可能包括对最新版本不支持但仍在使用的应用程序进行详细测试，直到有足够的空间实施升级计划，或为一些即将取代以前功能的最新功能提供培训。

本检查表的目的是支持您在自己的测试阶段，在将版本升级部署到生产实例之前****在 DHIS2 中执行所有手动测试。

与特定用户核对{ #checks-with-specific-users }¶

方案确定后，一个重要的考虑因素是使用克隆用户进行测试，这些用户的用户角色和共享与现场部署的用户完全相同。

例如，如果您想在测试 Capture 应用程序的同时测试特定程序；虽然您可以使用具有管理权限的用户进行测试，但您****必须****确保将数据输入特定程序的数据录入用户也能进行测试。例如，如果您有一个疟疾跟踪程序以及该程序的特定数据录入用户，您可以通过克隆其中一个数据录入用户来测试采集应用程序，以该用户身份访问采集程序，并根据您的核对表模板完成采集应用程序中的各种检查。

有关如何在用户应用程序中克隆用户的说明，请参阅 此处

您应该考虑的使用特定克隆用户进行测试的大致分类包括

• **使用数据录入、采集应用程序或两者之一的**数据录入用户。您要重点关注
  • 如果他们能正确地将数据输入这些应用程序，而不会受到任何不必要的阻碍
  • 检查您在核对表中列出的与数据录入有关的所有功能是否按预期运行
  • 确保他们只能做他们应该做的事（即，如果在捕获中删除跟踪实体实例不是分配给他们的用户角色的权限，他们就不能这样做）
• **重点 "查看 "特定程序或程序集数据**的用户
  • 这些用户通常可以访问数据本身。这可以与数据录入角色结合，也可以不结合。
  • 检查他们是否可以访问他们应该访问的分析应用程序，以及这些应用程序中的功能是否能根据您的检查清单正确运行，同时使用该用户
  • 检查他们是否只能访问他们应该访问的数据
• 可以添加或编辑配置的管理员用户
  • 根据用户角色的设置，这些用户可以拥有多种权限。
  • 检查系统中每个管理员用户类型中的至少一个；根据他们拥有的权限，通过核对表确保所有功能在以这些用户类型登录时都能正常工作。

对于上述用户类型，您也可以根据程序的不同而有所变化。例如，单个用户可能可以查看一个或多个程序；不同用户在这些程序中可能有不同程度的访问权限。理想情况下，你需要检查每个程序用户，以确保共享、用户角色以及升级后的任何当前和更新功能都能按预期运行。

建立测试人员小组{ #establishing-a-group-of-tester }¶

虽然 DHIS2 核心团队一般总是需要使用克隆用户进行测试，但招募一小组能够支持测试的最终用户也是一种有益的补充。这些用户应在系统中扮演不同的角色，并能在测试环境中执行其典型任务，从而支持测试过程。

在持续发布环境下测试应用程序{ #testing-apps-under-continuous-release }¶

独立更新单个应用程序可被视为一般升级中的低风险子集。如果遇到问题，这些应用程序相对容易恢复，但在更新前仍应在单独的环境中进行测试；以确保已知的任何用户界面变化，以及实施中使用的关键方案仍受支持。

其他测试{ #other-testing }¶

除了在 DHIS2 内部测试面向用户的功能外，重要的是尽可能验证计划作业是否运行、集成是否继续工作以及性能是否下降。

预定工作{ #scheduled-jobs }¶

测试计划作业包括验证后台进程是否能在升级版本中成功运行。这包括以下测试 测试

• 资源表更新
• 预测器
• 分析生成
• 数据交换职位

这并不总是那么简单，尤其是分析生成（可能需要比测试环境更多的服务器资源）和数据交换（可能需要另一个测试环境来推送数据）。在某些情况下，简化测试可能是必要的（但不建议），例如只运行一年的分析。

集成{ #integrations }¶

集成通常是在本地开发的，因此测试尤为重要。这就需要为 DHIS2 与之共享数据或元数据的任何其他系统提供测试环境。

性能{ #performance }¶

性能测试也很重要，特别是要验证关键操作的性能没有下降。遗憾的是，这很难准确测量。

例如，测试环境通常不同于生产环境，无论是在基础设施方面，还是在缺乏活跃用户方面。如果基础架构是共享和/或虚拟化的，实际可用资源可能会随着时间的推移而变化，因此很难对结果进行比较。建议在同一环境中对不同版本进行比较，而不是在生产环境中的一个版本和测试环境中运行的另一个版本之间进行比较。最好也在测试环境中测量当前版本，然后进行升级、重新测试和比较。

虽然进行彻底的性能测试非常复杂，通常需要专门的技能和工具，但有些基本的东西还是可以比较容易地进行检查的：

• 应用程序/功能测试期间的预期性能
• 比较不同版本的分析运行时间
• 比较常见 API 请求的响应时间：
  • 创建新活动
  • 创建新注册
  • 搜索被追踪的实体
  • 导入包含汇总数据的文件
  • 分析请求

基本测量可在浏览器控制台中完成，但建议同时使用 Glowroot 或类似工具监控响应时间。

测试版测试{ #beta-testing }¶

测试版测试是指在软件发布之前对其进行测试。根据您的升级日程，可以利用测试阶段 "抢占先机"，在升级周期的早期开始测试。此外，您还可以向 DHIS2 开发团队提供有价值的反馈意见，帮助他们在发布前解决问题。

在测试阶段，DHIS2 开发团队会发布即将发布的候选版本。这些候选版本可以像真正的版本一样安装在测试环境中，并接受与任何升级相同的关键工作流程的测试。发现的问题可通过表格或电子邮件报告给 DHIS2 开发团队，作为测试活动的一部分。

请注意，测试期间报告的问题应属于以下类别。

1. 回归：这些问题在 DHIS2 先前的版本中是有效的，但在候选发布版本中被破坏了。

2. 新功能中的阻塞问题：这些问题会妨碍您使用新功能；如果这是您升级的主要原因之一，这可能会妨碍您升级。

重要的是，***不要***使用 beta 测试计划来报告 DHIS2 早期版本中已存在的问题，或之前已在问题管理系统 (Jira) 中报告过的问题。