如果你来这里是想找到一个关于ADT或ATC之类的帖子，我为使用误导性标签道歉。尽管我想在这篇博文中与大家分享的是关于测试的内容，但并不是关于SAP提供的任何工具或技术。相反，这是一个如何利用Atlassian的Confluence和JIRA来构建跟踪大型项目测试的工具的例子，例如，我们最近用EHP8和HANA-DB对NW7.50进行了大升级。

几年前，我们在MDMP系统环境中进行了一个大型Unicode转换项目，其中包含各种"有趣"的方面：几十种语言，包括中文和日语的双字节、代码页转换，表中的许多文本，其中内容的语言不一定适合语言键（如果有的话）。借助一些工具程序和大量的手工工作，我们建立了自己的词汇表，以便尽可能地为5的大爆炸转换做好准备（！）长周末的生产系统。

来源：XKCD–https://imgs.xkcd.com/comics/unicode.png

不用说，很多表格和流程都受到了影响，需要进行测试，不仅是在一个地方，而是在全球50多个国家。我们没有任何工具来帮助实现这一点，只是大量的单个Word文档，每个文档拼写出一个测试用例。对于更复杂的测试用例，这可以是像"打印任何类型的SD文档，并确保结果在您的语言中可读"这样简单的事情，需要一系列的活动，比如"从订单输入到交付文档的打印，再到发票，最后到FI过账"。每个文档都包含一些关于预期测试结果的信息，以及"测试成功"或"发现问题"的复选框。

这些文档被放入一个大zip文件中，并通过电子邮件发送给子公司，指示在测试系统中运行所描述的场景并报告结果。我相信你可以想象这是多么成功，我们收到的反馈是什么样的！在某些情况下，我们只收到一个zip文件，其中包含更新后的Word文档，但没有任何摘要，说明哪些有效，哪些无效。如果我们幸运的话，实际上有人填写了一个附带的Excel文件，但大多数情况下没有。基本上没有机会真正评估测试是如何工作的，我们必须依靠真实可信的IT格言"没有消息就是好消息"—如果真的出了问题，我们肯定会听到的！

Unicode项目成功上线后不久，我们就不得不开始计划进行一次大的系统升级，包括切换到另一个数据库和移动到另一个数据中心。我们很早就决定，我们需要一个更好的方法来组织测试，因为我们不想再次发送压缩的Word文档，几乎没有机会正确跟踪结果。我们没有像SolMan这样的工具，它（IIRC）确实支持测试。最终这个搜索结果出现在了我的办公桌上。

就在那时，我刚刚为我的一项涉及气候变化的业余活动设置了一些测试，我利用谷歌表格收集了关于新的/增强的网站功能的测试反馈。googleforms最妙的一点是，结果会自动显示在一个电子表格中，这样就可以进行适当的过滤，例如查找报告的问题。它还生成一些带有饼图和其他图形的仪表板。在内部使用googleforms不是一个选择，全球云购，但它让我知道了如何利用Confluence和JIRA来构建。

基于我们已经拥有的Word文档和测试用例描述，我创建了一个简化的模板，其中只包含测试用例ID、标题、模块的字段，应测试内容和预期测试结果的描述。在大多数情况下，这些描述应该是相当通用的，因此实际上是在一个较高的层次上，并且期望了解他们的常规任务和事务的关键用户能够实际执行大部分测试。例如，大数据局，云端云服务器，建议仅说明："为标准订单生成发票"，但不要提及任何特定的客户或物料编号，因为这些编号将根据实际进行测试的地点而有所不同，这既与进行测试的系统有关，也与进行测试的国家/销售组织有关。除了"应该测试什么"之外，还需要描述预期的测试结果，同样以一种相当通用的方式，比如"发票生成正确，财务数据发布正常"。

测试用例文档的示例

当我们的流程团队中的人员忙于创建文件时，我在Confluence建立了一个新的空间作为我们的测试存储库。我们从每个模块的一个文件列表开始，每个模块上载了相关的Word文档。后来，项目特定的文件列表被添加到混合中。在大多数情况下，文档的名称对应于测试用例ID（例如SD001或FI010），以便于识别并保持简短。合并中附加的Word文档的一个好处是，您可以在预览中打开它们，这样即使不是全部，也可以保留大部分格式。而且，预览链接是固定的，因此可以在其他地方使用它来指向文档，这是我们所想到的一个基本特性。

我们希望让关键用户的测试文档尽可能简单，因此JIRA项目只有五个主要状态："打开"、"进行中"、"已解决"、"问题解决"或"关闭"。下面是一个图形，显示了它的外观以及可能发生的状态变化：