ALM解释说 - 第2部分：测试

[#1]

Introduction

作为应用程序生命周期管理（ALM）的一部分，在测试方面没有快捷方式，但以下是在部署生产模型更改之前如何进行测试的指南，以最大程度地减少部署问题。作为利用ALM的决定的一部分，您应该创建“变更结构”并具有更改控制过程，如概述here。假设这已经到位，这里有一些技巧可以帮助最大程度地减少部署的不需要数据问题。

Create user stories and acceptance criteria

驾驶后的发展活动应具有与初始发展相同的重要性。作为其中的一部分，任何更改都应具有关联的user story,在那中验收标准。Acceptance criteria are the key to signing off a piece of development; it is the first part of testing known as ‘component’ or ‘functional’ testing. Functional testing should validate the work and prove out calculations (e.g. does the top-down value get allocated across all lower members correctly). However, depending on the level of complexity within the change, further testing may be necessary. More information on user stories and functional testing can be foundhere,as well as the训练课程。

Setting up the development and testing environments

Depending on the segregation of duties or customer requirements, the source data for the test model could be pointing to a QA environment or a production system. It is recommended that the开发模型始终用作来源for all test and production models. The advantages of this are as follows:

• 生产模型的来源保持恒定。没有混淆哪种模型是目标模型的来源。
• 使用一致的源可最大程度地减少破坏兼容性的机会
• 可以在使用后删除测试模型以保存使用的工作区
• It is possible to create multiple test models to validate different revision tag changes (e.g. one test model could be at ‘Revision 3’, another at ‘Revision 4’). Testing on ‘Revision 3’ may be complete, so, if desired, ‘Revision 3’ could be deployed, while testing on ‘Revision 4’ is progressing.
• 根据测试的范围，可能需要一个填充的数据集。如果是这种情况，则简单地将生产模型复制成为测试模型。

It is also recommended that the development and test environments are held within a separate workspace; this helps segregate responsibilities between developers and the business team (if that is required).

本文不会因为太多而贯穿所有测试协议，但是以下是如何检查更改前后的值的几个想法。

Create a variance model

This approach works well if you expect changes to the values in certain parts of the model or you need a detailed analysis of particular differences. This approach involves creating a brand new“variance” model通过新更改验证方差。该模型将是剪切版本或生产模型的“外壳”。仅当您同时访问测试和生产工作区时，此方法才有可能。

The detailed steps from above are as follows:

1. 确定您希望验证的细节级别（列表，模块和行项目）。例如，您可能需要验证年度总计，以获取收入/费用，每月或每周的总收入/费用订单项，或两者兼而有之。选择多少细节（行项目）以及您决定的结构级别（列表层次结构），将取决于您希望在验证过程中包含的细节级别。
2. 在测试工作区中，创建一个新的“方差”模型。
   1. Create the module(s) needed to validate data, using the level of detail identified in step 1, and repeat the following for each module identified.
   2. In each module, create a dimension or two line items that contain the “before” and “after” values. If you end up choosing the line items approach, create one additional line item that is simply a variance between the “before” and “after” line items.
   3. 从生产模型中创建一个适当地映射结构的导入到您在b）中创建的“之前”元素，然后重复每个模块。
   4. 运行C）中创建的所有导入。现在，您在“差异”模型中具有捕获的“之前”状态。
3. 采用生产模型的副本并将其导入到测试环境中。This creates a fully-populated test model, as well as providing a back-up of the data set.
4. Synchronize the proposed change from development to this test model. You now have the “after” state in the test model.
5. In the “variance” model:
   1. 对于每个模块，从上面的2C）和2d）重复该过程，以从测试模型中创建导入，以每个模块中的“售后”元素为目标。
   2. 穿过模块以比较之前和之后的值。

注意，一旦设置了“方差”模型，就不需要重复步骤2。如果您重复生产模型（步骤3），则无需重复步骤5A；您需要做的就是将导入源重新映射到新复制的测试模型中。这是在“设置”选项卡 - “源模型”中完成的。

Create a checksum module

This approach works if you are expecting no change to the overall values in the model.

笔记：如果要使用此方法，强烈建议将设置构建步骤（步骤1）包含在单独的修订标签中，并在开始在主要更改上开发之前进行同步。这是因为您可能需要修改更改并运行另一个同步。

详细步骤如下：

1. 在开发模型中：
   1. 与上面的过程类似，在高级别的开发模型中创建一个模块；甚至可能是单个值（例如，所有年份，所有渠道的总量）。
   2. Create three line items that contain “before” and “after” and the variance.
   3. 在“后”订单项中，创建一个公式以适当地提取值。
   4. Create an internal import to copy the values from ‘after’ to ‘before’.
   5. Save the changes as a revision tag.
2. In the test model:
   1. 同步从开发到此测试模型的校验和更改。
   2. 运行内部导入以设置“之前”状态。
   3. 检查校验和更改是否如预期。
3. Synchronize the change to the production model.
4. You can now proceed to make the changes in the development model.
   1. 一旦完成所需的更改，请在开发模型中设置修订标签。
   2. 采用生产模型的副本并将其导入到测试环境中。这创建了一个填充的测试模型。
5. In the test model:
   1. 运行内部导入以设置“之前”状态。
   2. 将更改与测试模型同步。
   3. 行项目将更新后的,你现在可以check this against the ‘before’ for any variance.

纠正问题

在上述两种情况下，如果数据尚未预期：

• 分析差异
• Identify the errors or issues with the proposed changes
• If the “issue” is a small change:
  • 纠正开发模型
  • 设置一个新的修订标签，并从上面重复测试过程
• 如果“问题”需要大量工作，则可以更快地消除开发的变化并重新开始。
  • 将开发模型还原回先前的修订标签（请参见下文）
  • 重复更改，并进行校正
  • 设置一个新的修订标签，并从上面重复测试过程

恢复修订

如上所述，如果测试结果不如预期，并且更正问题的更改级别是实质性的，那么重新启动可能会更快，而不是更改修订标签中包含的更改的元素。

1. In the development model, navigate to the History tab and review the historic changes. You should be able to find the point in which the previous revision tag was set (and the history id immediately before).
   
2. 将开发模型恢复到这一点；现在，在上一个修订标签中结晶的更改已备份
3. 根据所需的任何其他更改在测试中发现的问题
4. 设置新的修订标签
   
5. 如上所述遵循测试过程

Conclusion

为了重复开幕词，没有测试的快捷方式。测试水平和风险或错误的水平将取决于变化水平。另一个最佳实践to mention, in conclusion, is to set and test revisions regularly. This, coupled with a structured development program, should help minimize issues in deployment and drive efficiency in your ALM process.

See part three of the series to understand how to recover from the worst-case scenario— a synchronization has caused data loss.

[安德鲁蒂]

Great insight as ever@davidsmith呢

[David.Savarin]

Just reading this i was wondering if reverting a modem back to before a revision tag using the history log track sets the model back before the revision tag and hence erasing the revision tag from the model, hence making a model with accidental structural changes and revision tag compatible again

并不是说是为了了解历史日志和ID如何处理修订。

[戴维史密斯]

@David.Savarin

修订标签永远不会被删除 - 即使恢复模型历史记录也只会恢复结构。修订保持永久性 - 这就是为什么“回到未来”有效的原因！

David