3.1 一般任务
我们可以从现有的测试的书籍中找到足够的信息，了解测试经理的一般任务。但为了帮助需要在云计算环境下工作的测试人员，我们将在本节中介绍以下活动。
- 风险分析。
- 与供应商就测试达成一致。
- 设置和执行端到端测试。
- 提供建议。
3.1.1 风险分析
"无风险，不测试。"不管是什么项目，测试经理首先需要考虑风险。测试投入属于测试业务中的成本部分，测试所覆盖的风险（通过风险覆盖可以降低产品应用问题导致的纠错成本）则属于收益范畴。风险分析通常构成测试经理采用的所有测试方法的基础。本书的第4章将提供各种各样的方法来消除风险。风险与我们选择的云计算的特征、服务模型和实施模型直接相关。用第4章提到的测试方法可以构建我们的测试策略。对于测试经理角色的扩展职责，我们有可以在选型过程中使用的方法，也有可以在实施和生产过程中使用的方法。
（产品）风险分析是测试经理的必备武器之一（见表3-1）。测试经理需要与不同的干系人讨论信息系统（在本书的场景中，是某种基于服务的解决方案）可能发生的失效，以及它们带来的影响。可能性高、影响显著的失效是高风险，需要较多的测试介入。另一方面，如果失效的可能性小，影响也小，则不需要过多的测试。
表3-1 风险分析表实例
首先，需要列出各种主要的风险。在风险收集过程中，一些人的参与至关重要，包括那些清楚向云端迁移时"哪里会出错"，以及可以判断"出错后会导致什么影响"的人。
接下来，需要将风险分析到足够详细的程度。应用传统的产品风险分析技术可以比较容易地达成这一结果。具体怎么做呢？首先，和项目组成员一起，将风险进一步拆分--例如，功能可以被拆分成哪些？有哪些安全方面的风险？就功能而言，可以基于不同业务过程进行拆分。为了完成拆分，可以要求有经验的用户提供输入。就安全性而言，需要借助更面向技术的人员。为了衡量失效的影响，需要转换到实际的场景视角：修复问题的开销有多大？会损失多少收入？单据有多长时间不能发送？诸如此类。基于详细的风险分析，测试经理可以制定测试计划，为高风险任务分配较多的测试资源，为低风险任务分配较少的测试资源。
有不少测试文献关注产品风险分析过程，并应用该过程开发测试策略。
3.1.2 获取供应商信息及与供应商达成一致
选型阶段之后是实施阶段和生产阶段。在这两个阶段，许多测试活动需要来自供应商的信息与支持才能被成功实施。测试经理需要考虑服务规格（测试的基础）、测试环境和记录问题的原则。如果供应商的标准条款中没有提供完整的这些信息，那就需要和供应商签署额外的协议。测试经理需要检查协议条款，确保签署了我们需要的协议。然而，情况并不总是这样，因为大的服务供应商不大会为小客户修改他们的条款。
针对供应商和其他资源的检查表
测试经理需要根据情况注意以下这些问题。
- 哪里可以找到接口规范？
- 哪里可以找到参考手册？
- 问题如何记录？
- 客户如何得知已记录问题的解决进度？
- 对解决（严重）问题的速度提供什么样的承诺？
- 对可用性（包括度量数据）提供什么样的承诺？
- 对性能（包括度量数据）提供什么样的承诺？
- 对安全性（包括各种指标的协议）提供什么样的担保？
- 是否有可用的测试环境以及如何使用？
- 当服务有变化时，如何通知客户？
- 当文档有变化时，如何通知客户？
- 当服务的测试结果变化时，如何通知客户？
- 如何配置监控及记录设备？
附加条款
由于以上的检查并不能完全覆盖各种可能性，所以需要附加的协议。有一些从未被标准化的部分，比如服务的可定制性和服务接口。以下是几个需要考虑的问题的示例。
- 定期的供应商服务评估与审查（例如，供应商在何种程度上满足了对性能等其他方面的承诺等）。
- 由供应商提供的模拟服务（Mock Services）。
- 对供应商执行审计（安全或过程质量方面）。
- 支持服务的实施。
尽量避免在法律合同内强制所有内容：客户应该从正常服务受益，而不是从惩罚条款中受益。
本文选自《云服务测试》第三章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
相关阅读：
