测试除了关注传统的实现部分，还要渗透到选型和运营，这也是devops一直鼓励做的。
测试的主要内容有
- 风险分析
- 与供应商达成测试协议
- 设置和执行端到端测试。
- 提供建议
风险分析
供应商条检查
一般供应商条检查表
- 哪里可以找到接口规格？
- 哪里可以找到手册？
- 如何记录问题？
- 如何让客户了解记录问题的解决进度？
- 对解决(严重)问题的速度有什么保证？
- 对可用性的保证是什么（包括指标协议）？
- 对性能有什么保证（包括指标协议）？
- 安全性的保证是什么（包括指标协议）？
- 是否有可用的测试环境，如何使用？
- 如何通知客户服务的变化？
- 如何通知客户有关文档的变化？
- 如何告知客户服务变更的测试结果？
- 如何配置监控和日志设施？
附加条款
- 定期评价和审查供应商的服务(例如，供应商在多大程度上满足了对性能和其他方面的保证)
- 供应商提供的Mock服务
- 供应商审核（安全或操作质量）。
- 支持实施服务
尽量避免在法律合同中强制执行所有的内容。
端到端测试
E2E测试的概念与流程测试的概念很相似。有时也被称为技术流程或系统集成测试，它不外乎是对多个系统的系统测试。在E2E测试中，业务流程是最重要的。因此，E2E测试是以最终结果为出发点的最广泛的测试。系统集成测试和E2E测试的相似之处可能是显而易见的。区别在于流程没有得到充分支持的风险决定的。当组织、基础设施和流程更加复杂时，这种风险就会变得更大：谁能监督和评估流程、功能和技术基础设施之间的一致性？显而易见，E2E测试在云计算中更加重要，同时也增加了复杂性。
E2E测试不仅仅是系统集成。系统集成主要关注系统之间的接口。成功的系统集成是E2E测试的必要前提，因为系统需要交换信息。而E2E测试则是测试系统和业务流程的整体组合。可能出现的问题如下：
- 数据不一致(不同系统中的人有不同的地址)
- 对数据的错误(人为)解释(8-9-10是指什么日期)
- 在某一情况下是强制性的数据，而在另一情况下则不是。
- 时间和顺序问题(信息处理顺序错误)
E2E测试不限于功能。服务的许多非功能属性需要在E2E测试环境中进行评估，如性能和安全。因此，E2E测试结果在客户的IT环境和业务流程的背景下，对服务的验收起着重要作用。执行E2E测试提供了一个重要的副产品：获得的知识是描述和测试工作流程和所有附带文档的重要输入。
E2E测试的重点是多维度的测试。第一个是由使用IT环境的业务流程形成的，原则上不关注功能如何在不同的系统和服务上划分。这些业务流程构成了需要测试的最重要的基础。第二个维度是所谓的系统图：系统和服务以特定的方式连接起来，即信息流。隐含地，这也包括接口。这就是需要运行测试的物理世界。第三个维度是系统和服务在IT蓝图中的确切功能。
在准备E2E测试的过程中，需要对这三个维度都有所了解。这需要不同职能部门的投入：测试人员、技术专家和主题专家（如用户）。
从逻辑测试用例（例如，从分类树）到物理测试用例，是一项相当艰巨的工作，需要系统图，以及对功能细节的了解。其步骤如下。
- 描述E2E测试用例中的所有测试动作。例如，一个测试用例从某个系统开始，经过多个系统和服务后，在另一个系统中结束，并得到某个结果。
- 确定代表测试用例的数据（例如，分类树中的类的值）和E2E测试用例的预期结果。
- 确定E2E测试用例通过的所有系统和服务中需要的配置和基础数据。
- 描述测试用例在所有int上的预期中间结果。
在对测试环境、测试数据以及所有系统和服务的版本进行了采集之后，就可以执行测试用例了。容易出现的问题：
- 执行需要大量的时间（例如，业务流程要求下一步要在一天后执行）。
- 测试数据耗尽。当测试用例在途中卡住时，原有的数据就不能再使用，而且跨多个系统重置是非常困难的（这也是建立备份测试用例的原因）。
- 测试系统并不是都能及时使用（当及时知道这一点时，可以部署桩/驱动或模拟器）。
- 分析一个问题是困难的(问题发生在哪个系统或哪个服务中?)，需要技术视图和访问日志文件。
- 并非总能找到合适的人员来执行测试操作和分析结果。
- 供应商很难找到问题的答案。
- 没有人对所有系统有详细的了解。
完全自动化的测试执行使有效和持续的系统集成成为可能，但在实践中，这对许多人来说并不可行。然而，有许多辅助工具可以使E2E环境下的测试变得更容易。例如，有一些工具可以生成测试数据，有一些工具可以生成消息并对其进行分析，还有一些工具可以作为存根/驱动程序或模拟器使用。正确的接口规范对于正确使用所有这些工具尤为重要。
E2E回归测试的范围与要覆盖的风险有关。每一次变更，都需要进行E2E回归测试。然而，客户并不总是被供应商告知服务的变化。为了及时发现未通知的变更的影响，需要提高E2E回归测试的执行频率。由于这种较高的频率，自动化是无法避免的。
当测试结果不符合预期时，需要记录好问题。由于部分技术基础设施在云端，分析问题比软件在客户自有资源上运行时更加困难。专家不能随便跑到机房去，因为机房是虚拟的，是在云端的 "某处"。对于每一个问题，都要确定问题出在哪个组件中：在（虚拟）环境中，在平台中，等等。
在这种情况下，读取日志文件是可以还原的手段之一。日志数据需要配置在E2E过程中的战略位置，以便确定错误发生的位置。
测试经理确定测试服务的质量。这是在接口系统和业务流程的背景下进行的，并尽可能提供关于剩余风险的良好情况。这构成了发布建议的基础。
在选择过程中，出现了一个需要测试经理建议的明确时刻：选择某项服务（和服务供应商）的决定。测试经理需要及时准备好建议，并且必须知道谁是利益相关者。不能给出一个通用的准则，但往往采购部门在选择IT资源时有主导权。测试经理在选择过程中的任务是在对某项服务做出深思熟虑的决定后完成的，部分是基于交付的质量和风险信息。
在选择之后，接下来是一个实施过程，在这个过程中，配置和测试过程就会发生。与客户的软件在生产中实施时一样，测试经理将为服务的实施提供发布建议。在这种情况下，它是关于将服务投入生产的决定。这似乎与传统的测试流程类似，董事会根据测试经理的建议，部分地做出上线的决定。
当在持续E2E测试中发现问题时--例如，在测试更新后，测试经理需要通知组织，并且有人需要决定补救措施。这可能是实施一个变通方法，回滚变化，甚至选择另一个服务。在实践中，要找到责任人可能相当困难。在大型组织中，往往有不同的系统所有者，而对于云计算来说，有时会增加一个无法访问的供应商。
网友评论