跳转至
For the complete DHIS2 documentation index, see llms.txt.
安卓实现

测验

既然已经初步配置了DHIS 2服务器，并且已经在一个或多个设备中安装了该应用程序，则可以开始测试了。在计划测试时，您需要了解即将发布的版本。重要的是要成为[https://community.dhis2.org/](https://community.dhis2.org/）的社区成员并使用[JIRA]（http://jira.dhis2.org /），UiO使用的软件管理工具。这将使您了解计划在将来版本中发布的功能和错误修复方面的未解决问题。

我们建议与您的配置并行测试Android应用程序，以确保您在服务器中所做的更改能够正确反映并在应用程序中正常工作。这在配置程序规则期间尤其重要。除了逐步测试之外，在推出应用程序之前，还应进行其他类型的测试。

应当在较小的组内部进行一组初始测试，以确保正确完成配置，功能适当并且外观和感觉适当。作为测试初始阶段的一部分，您将执行内部测试，然后进行UAT（用户接受测试）测试。在本节的稍后部分，我们将详细说明这些类型的测试的含义以及如何进行测试。之后，您将进行现场测试和试点。在测试的这一阶段，您将与较大的组进行一组测试，以确保您的工作流，基础架构和体系结构正确。同样在本节的后面，我们将进一步详细介绍这些类型的测试以及如何进行测试。

下图显示了下一步实际上是迭代的，包括基于测试结果的新服务器配置。在准备进行扩展和推出之前，您很可能会进行几轮测试和重新配置。

测试 Android 应用的一般建议

在进入不同的测试阶段之前，我们将介绍一些可用于测试Android App的常规建议。通常，任何测试过程都可以归纳为以下步骤：

  1. 评论。第一步是访问[ https：//www.DHIS 2.org/android-documentation ]（https://www.dhis2.org/android-documentation），以查看有关应用程序本身的信息。该文档将为您提供有关测试原因和内容的信息。它可以帮助您确定该应用程序是否满足您的要求，该应用程序可以做什么和不可以做什么以及帮助您分析差异。它还应帮助您确定新功能和设置以及受支持的功能。

  2. 计划。在此步骤中，您需要通过了解自己实施的时间表来确定测试时间。在此计划阶段的一部分，您必须创建详细的需求列表，并将其分类为强制性（必须具备）或具有良好的需求。

  3. 设计。在此步骤中，您必须开发测试用例，决定测试交互的数量以及将用于测试的工具。

    • 测试工具示例 - Jira

    • 测试工具示例 - Excel

    • 每个测试用例应包括以下部分。要执行的测试的详细程度和内容将取决于用户的经验概况的水平。

      • 标识：周期号/ID、测试ID、版本、测试摘要。
      • 描述：详细信息、重现步骤
      • 状态报告：执行日期、执行者、预期结果与实际结果、执行状态报告 ID。

  4. 执行。在执行测试期间，请记住两个重要问题：

    • 元数据配置：验证网络上的程序设置，并查看文档以了解应用程序中功能的行为。这将有助于确定真正的错误，而不是由配置或不受支持的功能引起的问题。
    • 完成矩阵：根据您在计划阶段设计的截止日期检查进度。另外，请确保严格记录笔记，以便能够报告错误。
  5. 报告。您的报告必须具有三个重要特征
    • 报告的错误必须是可重现的
    • 信息必须是具体且信息丰富的
    • 报告必须区分事实和猜测 { .center width=80% }
    • 下表通过一些示例总结了良好的错误报告： { .center width=80% }

内部测试和 UAT 测试

您正在测试什么

您正在测试DHIS 2服务器配置和Android App本身。

你在找什么？

程序规则、表单、可视化 UI、指示器...错误、改进、新要求等。

怎么样？

各个组的测试方法和时间各不相同，但是它必须是迭代的，灵活的，并且必须在部署过程的早期阶段进行。您需要花费时间来决定谁将参加测试，制定测试计划并制定收集反馈的策略。有多种工具可用于报告和跟踪错误和问题。根据测试的复杂程度，您可以使用[trello]（https://trello.com/），[JIRA]（https://www.atlassian.com/software/jira）等。

为内部测试奠定正确的基础将提高测试过程的质量和效率。这些建议适用于您需要执行的任何不同测试。

UAT 测试

您正在测试什么 您正在测试系统配置（输入），视觉UI和图标，可用性和输出。您还可以在此阶段测试不同设备（智能手机，平板电脑，外部键盘，chromebook）的用户体验。

你在找什么？

先前项目中的调整和硬件问题。现在是开始确定对未来阶段有帮助的冠军的好时机。 UAT的主要目的是让来自不同背景的人员与配置相一致以执行现场测试。这个阶段的成功将决定进入下一阶段的现场测试

怎么样？

使用受控环境。查找很少接触该技术的用户，这些用户不一定要集成到工作实践中。您的用户可能是：1）健康领域的专家，2）现场人员，3）现场用户。

小组的规模将根据您要为其实现应用程序的项目类型而有所不同。 UAT测试小组的平均人数为5至10人。

在决定谁将参加您的测试时，请考虑所有不同类型的用户及其角色。考虑到这一点，请选择您的测试人员。您应该为测试人员提供正确的入门和指导。他们需要充分了解您将用于测试的方法，期望以及测试的总体目的和目标。如果可能的话，建议与一个或两个领导者组织测试会议，测试者可以互相帮助，并有可能提出问题并从领导者那里获得帮助。要考虑的另一个重要方面是测试数据。您的测试服务器中必须有足够的数据，才能测试不同的测试用例。

现场测试/试点{ #implementation_guide_testing_field }

您正在测试什么

  • 您正在测试SoP和工作流程。
  • 您正在测试您的基础架构/体系结构。
  • 您正在测试不同的设备。
  • 您正在测试培训程序和材料。

你在找什么？

  • 前项中的调整。
  • 所选设备是否适合工作空间和环境。
  • 评估您的解决方案
  • 确定冠军。

怎么样？

20-30个用户。建议2个月（提前计划！）。确定分布（位置）。不要选择最简单或最复杂的方法。保持简单，但挑战您的解决方案。

评估飞行员的考虑因素

您应该定义用于评估结果的指标，并确定试运行系统的策略。您可以并行使用当前系统和新系统几个月，也可以直接更换它。两种策略都有优缺点，您应该在进行试点之前与您的团队仔细分析它们。

并行使用当前系统和新系统的一些优点是：

  • 您可以证明在及时性或数据质量方面，新系统与旧系统相比有何改进，此参数取决于您特定项目的目的。
  • 如果某些功能按预期运行，则您具有以前的系统作为备份机制
  • 当用户比较两个结果时，可以建立对用户的信任。

一些缺点是：

  • 您正在设置一个双重报告机制，它会重复用户的时间和精力。 IT部门必须敏感地处理此问题，并在需要时准备潜在的支持人力资源，这一点很重要。
  • 用户倾向于并行比较两个系统的可能性可能是一把双刃剑，因为用户倾向于抵制变化。