现代软件工程实践需要高质量的思维方式。诸如单元测试、集成测试、系统测试之类的自动化测试，或者诸如安全性测试或性能测试之类的任何其他测试都在增加。但是随着越来越多的自动化测试，团队面临着一个复杂的挑战，即如何理解哪些自动化测试与哪些需求相关。SAP最近开放了持续跟踪监视器（CTM），零售大数据解决方案，它正好解决了这个问题。

遵循左移质量方法，商业大数据分析，在软件开发生命周期中应尽早考虑测试标准。在最佳情况下，productbacklog项（PBI）已经定义了如何测试新需求的明确度量。隐式地，这可以通过随后使用行为驱动开发（BDD）来实现，BDD支持PBI的自动化测试。明确地说，这可以通过坚持ready定义中的测试标准来实现。

敦促实现PBI的开发人员编写适当的自动化测试，云服务器 免费，以保护新的需求。在实现发布之后，需求和自动化测试之间的关系受到威胁。随着时间的推移，需求和覆盖它的自动化测试集之间的联系可能会被遗忘。随着时间的推移，一些测试可能会覆盖额外的需求，在最好的情况下，很难回忆起与特定需求相关的自动化测试信息。最坏的情况是，团队失去了这种关系。

缺少这种关系会在很多方面造成麻烦：如果自动化测试失败，互联网大数据，就无法判断哪些产品需求受到影响。仅仅在测试用例级别上监控产品质量，往往会淡出那些测试用例应该涵盖的原始需求。代码重构也将变得更加困难，因为更难理解重构的含义。保持需求、其自动测试用例和当前测试结果之间的联系，使团队能够在任何时候做出清晰的产品质量声明。

理解需求和当前质量之间的关系的需求既不是新的，也不是软件工程独有的。在ISO9001第8.5.2章"标识和可追溯性"中，谈到"[…]与[…]要求相关的输出状态…"，可以翻译为：您应跟踪（->我们产品的状态（->输出）要求

在SAP，在发布期间，每个产品都必须证明所有现有的和新的产品测试涵盖了需求，并且这些测试成功地执行了。在这方面，SAP团队使用术语"可追溯性"，将需求追溯到测试用例和测试结果。

产品需求（或PBI）存储在项目跟踪系统（如Atlassian Jira）中，测试代码保存在源代码版本控制系统（如git）中，测试结果生成在CI/CD系统（如Jenkins）中，云服务器平台，这使得保持这三个实体的链接非常麻烦。

帮助团队跟踪"需求""自动测试用例""测试结果"，SAP开源了一个称为连续跟踪监视器（CTM）的工具。CTM根据其相关产品要求检查来自您的连续交付管道的测试结果，并在您的任何要求因测试失败而受到影响时通知您。不要监视测试用例的运行状况，监视产品需求的运行状况！

有关如何在项目中使用CTM的更多信息，请查看CTM入门wiki。

Dirk是SAP的DevOps传道者和持续交付专家。

自2001年以来，Dirk在SAP担任各种角色，包括开发和运营。他与以前的团队"TwoGo by SAP"一起，在SAP建立了第一个持续交付实施，每天为客户提供价值。

在他目前的职位上，Dirk是SAP的云质量教练，专注于持续交付和DevOps实践。

Dirk经常在DevOps和持续交付国际会议上发言，他是苏黎世DevOpsDays的联合组织者。

联系方式：推特：@doergn领英：https://www.linkedin.com/in/dirk-lehmann-7712bb125/

我们已经采取了一切可能的措施，使这篇文章尽可能准确，但有时事情会漏洞百出。如果您发现任何错误或不一致，请告诉我们。