测试架构:IT架构和应用程序的端到端测试

就在不久的前工业标准测试实战(针对 C/S 架构质量问题而发展起来)仍聚焦于客户端前端功能测试或者服务器端后端可伸缩性测试和性能测试这种"工作上分离"主要是缘于传统 C/S(客户端/服务器)架构比当前多层架构和分布式环境相对简单事实在标准 C/S 架构中问题要么发生在客户端要么就发生在服务器端
引言
就在不久的前工业标准测试实战(针对 C/S 架构质量问题而发展起来)仍聚焦于客户端前端功能测试或者服务器端后端可伸缩性测试和性能测试这种"工作上分离"主要是缘于传统 C/S(客户端/服务器)架构比当前多层架构和分布式环境相对简单事实在标准 C/S 架构中问题要么发生在客户端要么就发生在服务器端

今天典型计算环境是种复杂异构混合环境其组件和代码来自遗留系统、自主开发或第 3方或者是标准组件和代码(图示 1)随着 Web 发展架构复杂性进步增加通常在个或多个后端数据库和面向用户表示层的间会有个内容层该内容层可以提供来自多个服务内容(其中这些服务集中在表示层中)也可能包含些原来存在于传统 C/S 架构前端上业务逻辑

这种复杂度增加和遗留系统集成和尖端技术开发交织起来使软件Software及系统问题(包括功能和可扩展性及性能问题)描述、分析和定位成为软件Software系统开发和发布过程中主要挑战此外随着 SOAP/XML(简单对象访问协议/可扩展性标记语言)成为标准数据传输格式XML 数据内容问题对于 .NET 平台和 J2EE 平台变得越来越重要简单说正是现在架构和计算环境复杂性导致了原来面向 C/S 测试模式遭到淘汰

图1:现在典型多层架构


总体质量策略
很显然种新有效质量强化策略对成功软件Software开发和部署是必须最有效策略是将环境中单个组件测试和环境整体测试结合起来在这种策略中组件级和系统级测试都必须包含功能测试来确保数据完整性还要包含可伸缩性和性能测试来确保区别系统负荷下可接受响应时间

在评估性能和可伸缩性方面这些并行分析模式能够帮助您发现系统架构优势和缺陷并在解决和性能和可伸缩性有关问题时确定必须检查哪些组件和此类似功能测试策略(即全部数据完整性验证)正显得越来越关键现在数据可能是从分散数据源派生而来通过评估组件内外数据完整性(包括处理过程中任何功能性数据转换)测试人员可以定位每个潜在并使系统集成和缺陷隔离成为标准开发过程部分端到端架构测试(End to End Architecture Testing)指是这样种概念它测试计算环境中所有访问点并在组件级和系统级测试中将功能测试和性能测试整合在起(见图2)

从某种意义上来说端到端架构测试实质上是种"灰盒"测试种集合了白盒测试和黑盒测试长处测试思路方法在白盒测试中测试员能够访问底层系统组件并对其有足够了解尽管白盒测试能够提供非常详细和有价值结果但在检测集成和系统性能问题方面却有些"力不从心"和此相反黑盒测试需要很少或者完全不需要对系统内部工作机制了解而将注意力集中在终端用户上――确保用户能够及时得到正确结果黑盒测试通常并不能指明问题原因也不能保证某段代码已经被执行并且高效运行而且也不包含任何内存泄漏和类似问题通过将白盒测试和黑盒测试进行"技术嫁接"端到端架构测试真正实现了取长补短

图2:端到端架构测试包含所有访问点功能测试及性能测试


对可伸缩性测试和性能测试来说访问点包括硬件、操作系统、应用数据库和网络对功能测试来说访问点包括前端客户端中间层内容源和后台数据库明白了这些术语"架构"所定义就是在环境中组件的间以及组件和用户的间是如何进行交互单纯从组件来看优点和缺陷取决于将它们组织在起特定架构正是种架构将如何响应作用于它命令这种不确定性使我们需要进行端到端架构测试

为了有效实现端到端架构测试RTTS 成功开发了基于风险测试自动化思路方法The Test Automation Process(测试自动化过程TAP)建立在多年成功测试实战基础的上利用了最佳自动测试工具这是个迭代测试思路方法包括 5个阶段:

项目评估
测试计划创建和改进
测试用例编写
测试自动化、执行和跟踪
测试结果评估
端到端架构测试所要求单项功能和性能测试是在"测试自动化、执行和跟踪"阶段进行如图 3所示这个阶段被不断重复而相应测试也在每次迭代过程中得到精化

图 3:端到端测试 RTTS 测试自动化过程(TAP)


组件级测试
很显然首先必须开发单个组件然后才能将它们"装配"成功能系统组件可以进行早期测试所以在 TAP 中端到端测试是从组件测试开始在组件测试中随着环境建立适当测试也分别实施于各个区别单个组件上功能测试和性能测试在组件测试阶段都相当有价值它们帮助诊断了在整个环境构建前和构建中各种缺陷

组件测试中功能测试
组件级功能测试验证了每个组件所执行事务这包括了组件或系统所要求任何数据转换和组件所处理事务业务逻辑验证在应用功能开发中基础设施测试(infrastructure testing)验证并量化整个环境中数据流量并以这种方式来同时进行功能和性能测试数据完整性必须当数据在组件间传递时进行验证例如XML 测试在逐个事务地验证 XML 数据内容并在需要时验证正式 XML 结构(元数据结构)对组件测试来说诸如 IBM Rational Robot 这样自动可扩展测试工具可以大大减少用在 GUI 测试和非GUI组件功能测试上时间和精力Rational Robot 脚本语言支持对外部 COM DDLs 是非 GUI 对象测试理想工具此外Rational Suite TestStudio 和 Rational Team Test 所附带新 Web 和 Java 测试功能提供了测试 J2EE 架构和使用 java 语言来编写测试脚本附加功能



组件级可伸缩性测试和性能测试
和这些功能测试并行是组件级可伸缩性测试在环境中检验每个组件来确定其事务(或者说容量)限度旦有足够应用功能来创建业务相关事务事务特征测试(transcation characterization testing)就被用来确定业务事务中各个定量描述包括消耗带宽和后台 CPU 以及内存占用率资源测试(Resource testing)将这个概念扩展到多用户测试从而确定应用和子系统或模块中全部资源消耗最后配置测试(configuration testing)可以用来确定哪些硬件、操作系统、软件Software、网络、数据库或者其他配置上变更可以优化性能和功能测试样有效自动工具如 Rational Suite TestStudio 和 Rational Team Test 所提供那些工具可以极大地简化可伸缩性测试和性能测试在这种情况下创建、计划和驱动多用户测试以及监控资源利用率能力是有效且成功完成资源测试、事务特征测试和配置测试基础

系统级测试
系统 "装配"完成后对环境整体测试就可以开始了同样端到端架构测试需要对整个环境功能以及性能/可伸缩性进行验证

系统级功能测试
集成是首要考虑问题的集成测试 ( Integration Testing ) 从数据角度检查了整体系统是否完成了集成也就是说需要互相交互硬件或软件Software组件是否通讯正常？如果是那么在它们间传递数据是否正确呢？如果可以数据应当在系统组件传送中间阶段被访问和验证例如当数据被写到临时数据库中时或者数据在被目标组件处理的前已经存在于消息队列中时就应该对数据进行验证在这些组件边界对数据进行访问能够为数据完整性验证和数据问题描述提供个重要附加尺度如果在两个数据传输点的间检测出数据那么有缺陷组件必定是位于这两个传输点的间

系统级可伸缩性测试和性能测试
可以通过创建个测试来回答以下有关环境可伸缩性或者完成情况问题:在系统仍能维持可以接受响应时间下最多可以有多少用户同时访问它？

我高可用性架构是否可以按照设计那样工作？
在加入新应用或者对正在使用应用进行更新后会发生什么情况？
最初使用时系统应该如何配置以支持我们所期望用户数？6个月的后该如何配置呢？年的后呢？
　
我们只能得到部分功能－－设计是否合理？
这些问题答案可以通过定测试技术来获得, 包括可伸缩性/负载测试、性能测试、配置测试、并发测试、压力和容量测试、可靠性测试以及失败转移(failover)测试

在系统容量方面总体环境测试通常是从可伸缩性/负载测试开始这种测试思路方法逐渐增大目标环境上负载直到某些性能要求如最大响应时间达到极限或者特定资源被耗尽这些测试目在于确定事务处理和用户容量上限它们经常会和其他测试手段结合起来以优化系统性能

性能测试和可伸缩性/负载测试相关它通过测试特定业务场景来确定环境是否满足所设定负载和事务组合要求(图 4)

和组件级配置测试并行是系统级配置测试它提供了特定硬件和软件Software设置下权衡信息同时也提供了有效资源分配所需度量标准和其他信息

图 4:性能测试:系统具有特定用户负载时能够按照要求执行吗？


并发测试(concurrency testing)(图 5)剖析了当多个用户同时访问同段应用代码、同个模块或者数据库纪录时效果它鉴别并度量了系统加锁和死锁级别以及系统中单线程代码和加锁信号使用从技术角度讲并发测试可以归为种功能测试不过它常常和可伸缩性/负载测试配合使用它需要多用个户或者虚拟用户来驱动系统

图 5:并发测试能够识别死锁和其他并发访问问题


压力测试(stress testing)(图 6)在系统达到饱和(指资源如 CPU、内存耗尽等情况)时来测试系统以判断其行为是否发生变更或者是否会对系统、应用和数据产生不利影响容量测试(volume testing)是和压力测试及可伸缩性测试相关联它可以确定整个系统能够处理事务容量通过压力和容量测试能够知道系统分别在处理突发访问量增加或进行持续大容量活动时所具有弹性这不包括那些内存泄漏或者队列溢出所引发失败

图 6:压力测试能够确定高容量使用时效应


旦应用环境开始工作并进行了性能优化可以在 75％到 90％环境利用率下进行项长期可靠性测试(reliability testing)用来发现任何和较长运行时间有关问题在应用了冗余和负载平衡环境中失败转移测试(failover testing)(图 7)分析理论上失败过程并测试和测量总体失败转移进程及其对终端用户影响本质上失败转移测试回答了这样个问题:"如果个特定组件运行失败用户还可不可以在最小中断下继续进行访问和处理？"

图 7:失败转移测试:如果组件X失败那么将发生什么情况呢？


最后如果在环境中使用了第 3方软件Software或者主机供应商及其他外部来源所提供组件那么 SLA(Service level Agreement服务水平协议)测试则可以用来确保双方合同规范标准中所规定终端用户响应时间以及流入和流出数据量个典型协议通常会指明在既定时间范围内活动容量和个特定最长响应时间

旦外部数据或软件Software到位后对这些来源进行持续监控是明智做法这样就可以在问题发生时快速采取补救措施将对终端用户影响降到最小

和组件级可伸缩性测试样Rational suite TestStudio、Rational TeamTest 和其他类似工具提供了些高级多用户测试能力它们可以用来高效进行上述大多数或者全部可伸缩性和性能测试

个实际例子
也许举个例子是介绍说明最好办法请考虑下面情况:



通过 eRetailer 构建个公共 Web 书店并在它内容层中使用了 4种由内容提供 Web 服务第种服务提供目录包括书名介绍语和作者第 2种服务提供所有产品当前库存信息第 3种是价格服务器它提供商品定价信息并根据购买者所在地提供运费和税费信息并完成交易最后种服务用来保存用户档案和历史购买纪录

表示层将用户通过 UI 图形界面输入请求转换成 XML 并发送给相应内容服务器接着响应 XML 就会通过表示层转换成 HTML 并服务于用户会话每种内容层服务都会根据需要更新其他服务(参见图 8)例如在用户历史购买纪录发生变更时价格服务器必须更新相应用户档案服务

图8:典型 eRetailer 应用访问点


对上述系统来说个端到端测试策略起点是分别对内容层每种服务同时应用功能测试和可伸缩性/负载测试XML 请求被提交给每种内容服务而相应响应 XML 文档则被捕获从而对它数据内容或者响应时间进行评估随着这些内容服务逐个集成到系统中通过向 Web 服务器提交事务功能测试和可伸缩性/负载测试也都可以在集成系统中进行事务可以贯穿整个站点进行验证不论是为功能测试(使用 SQL 查询)还是为可伸缩性/负载测试

在系统开发过程中应用于所有访问点单个测试可以被用来调协各个服务以便使其能够在整个系统中正常运作――无论从数据内容(功能性)还是性能方面(可伸缩性)来说当前端发现问题时(比如,通过浏览器)那些原来用来测试单个组件测试用例和数据可以帮助我们快速定位位置

网络建模优点
作为设计过程部分无论在硬件获取的前还是在最初测试阶段中为区别网络架构进行建模都可以扩大端到端测试优点它可以帮助设计更有效和低率网络在部署的前进行网络基础设施建模可以帮助指出性能瓶颈所在以及路由表和配置中此外在测试中获取应用事务物证可以输入到这种模型中用来识别和分离应用"chattiness" 和基础设施中潜在问题

结束语
端到端测试从个概括质量角度对计算环境进行测试和分析每个组件可伸缩性和功能性在开发阶段和前期质量评估中都进行了单个测试和集成测试这为开发有效性提供了诊断信息同时为系统发布提供了高度质量保证端到端测试为管理当今架构和分布式计算环境复杂性提供了个全面而可靠解决方案

当然在需要做大量测试和分析时端到端测试要求有相当专业技术和经验来组织、管理和实战但是从商业角度来说那些应用端到端测试组织能够得到应用软件Software、系统性能和可靠性上高度保证最终这些组织将获得质量提高所带来得种种好处:更好顾客关系较低运营成本和巨大收入增长

在过去 6年中RTTS 作为 IBM Rational 伙伴的开发并完善了自己端到端测试思路方法并和数以百计客户起努力确保了应用功能性、可靠性、可伸缩性和网络性能欢迎访问 RTTS 网站WebSite:www.rttsweb.com.

延伸阅读

• 2011-9-14-- 磁盘碎片整理程序,手机程序开发和测试关注点整理