随着企业集成解决方案的出现,验证每个系统组件的可操作性变得前所未有地重要。在对已经投入生产应用的系统进行故障排除时,操作团队面对着各种各样的挑战:
要测试跨越多个物理节点和位置的分布式系统组件的可操作性,通常需要每一方团队的联合工作。
系统组件可以使用不同的技术来实现,并部署在不同的软件和操作系统平台上。组建一个熟练的操作团队,其成员位于不同的位置,并具备完整的必需技能集,这是富有挑战性的任务。
对生产环境的访问通常同时受到物理和过程约束的限制。这些限制没有为生产环境中的问题诊断提供足够的权限。
要验证总体系统对服务级别协议的遵从性和验证目标服务质量,将要求解决方案为提供此类措施做好准备。
与解决方案的基础实施部分不同,单独使用系统管理工具无法在功能级别验证自定义应用程序的这些方面。解决方案提供商必须提供某种方法,以测量和报告其系统组件的操作和功能方面。
除了面对所有这些挑战,操作团队通常还不止负责一个系统。为了简化其工作,需要将操作团队与系统的细节隔离,以便他们能够集中于一般操作任务。开发团队可以提供某种方法,用于通过遵循一组与组件内部细节无关的已定义的说明,从而以“黑盒”方式测试系统组件的可操作性。
嵌入测试组件
注意:为方便学习,我们定义了如下所示的术语。
功能组件 交付系统功能。
测试组件 只是为了增强系统的可测试性而引入的。
将测试组件嵌入在其他功能性系统组件中,只是为了使整个系统在部署期间(甚至在投入运行之后)可测试。图 1 显示了测试组件与其对应的功能组件之间的关系。
图 1. 将测试组件嵌入其他系统组件
测试组件将在系统范围的测试场景执行过程中进行调用。除了使用系统的功能组件的功能使用者外,嵌入的测试组件还将具有自己的使用者。
图 2 显示每个组件具有两个接口:一个提供系统功能,另一个提供系统可测试性。取决于测试组件如何公开其接口,可以将测试客户机实现为:
一组 API 调用——如果将测试接口公开为 API
命令——如果将测试接口公开为一个命令行工具
图 2. 通过其功能和测试接口使用组件
对于由您的系统使用的外部操作组件,例如新闻 Feeds 和支付网关,您也许无法在那些组件端添加测试组件。但是,您仍然可以在自己的系统中添加测试客户机,以验证那些外部系统的可操作性。在这种情况下,测试客户机的测试可以基于外部组件的功能接口,或基于可由测试客户机访问的外部系统上的某个基础设施资源。