如何迎接下一代富网络应用测试？（10-07-12）（获奖名单已公布）
随着HTML5离我们越来越近，FLEX技术和Silverlight的普及，我们正在跨越传统的HTML技术，进入新一代的富网络应用，那么我们的测试技术需要有哪些突破来应对呢？谈谈你为此准备的方法，工具或手段。
本次奖项空缺
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
FLEX的测试的确比较难一点 占座位等待高手:victory:
Flash Bulider 4简介
Adobe® Flash® Builder™ 4（之前称为 Adobe Flex® Builder™）软件可以帮助软件开发人员使用开放源 Flex 框架快速开发跨平台富 Internet 应用程序 (RIA) 和内容。它包含对智能编码、调试及可视设计的支持，提供功能强大的测试工具，这些工具可以提高开发速度并创建出性能更高的应用程序。功能强大的测试工具（增强）（仅限高级版）
借助内存和性能概要分析器提高应用程序性能，它们可以监视和分析内存消耗情况以及 CPU 周期。还提供对 HP QuickTest Professional 等自动化功能测试工具的支持。 说说我的看法。
先谈谈可能出现的变化。
首先自动化测试会受到一定的冲击，手工测试比例会提高。然后随着技术和测试工具的成熟，自动化测试的比例会逐步回升。
其次测试难度和成本会上升，展现层的复杂化会导致测试复杂度的上升。同时测试分工也可能更细化，客户端和服务器端的测试可能会逐步分离。
最后测试工具也会重新洗牌，可能会出现一些新的竞争者，但是最后生存下来的测试工具会更少，市场份额会更高。
我们可以做的准备包括
增加对系统架构的了解，提升自己的视野。
更多的客户导向。
最重要的是积极学习新的协议，规范，利用业界技术升级的机会完成自己的跳跃式发展 楼上的说的很好
在适应新测试环境需要做的准备就是
了解新的应用技术，在新的应用技术上了解被开发的软件
然后成功的执行测试！
需要跟进准备的就是学习市场中重新涌现的新的测试工具！ 首先肯定是要学习新的测试框架啦 http://docs.flexunit.org/index.php?title=Main_Page
其次，我觉得真正的挑战是以下几点：
1. 测试的精确性（精确和准确的区别请参见wikipedia）
[*]特别是现在“集群”的在数据数方面的应用把并发查询的处理速度提升到了一个很恐怖的数量级上，且对并发数量越大越能体现出性能的优势。。。测试团队能否把并发的时间切片提升到毫秒上？
[*]是否可以利用云平台的来模拟用户？10个甚至1个虚拟用户用1个instance来取代原先的1个process来模拟一个用户？这样就能省掉操作系统做进程调度的时间，从而提升测试精度。
应对方案：亚马逊的EC2
2. 测试分析
[*]以前针对要分析的数据用个excel的数据透视表就能搞定，数据源也就几个。
[*]现在单数据源这块就横跨了好几个操作系统，加上应用本身的profiler，再分析前需要建立良好的分析模型和工具。
[*]然后分析数据量也大了n倍，1个小时就会生成近1千万行的测试数据。注意：这些数据是拿来计算的不是筛选的。
应对方案：建立分析型数据库和相关的数据库应用（用游标写实现标准时间间隔内数据库查询响应时间的中位数是悲剧。。。）
3. 性能模拟的等价代换
[*]一个在线服务支持几百万用户同时在线，我们真的要模拟这么多用户么？或者说我们有能力模拟这么多用户么？
应对方案：服务器端性能降级，画出等价公式。
3. 真实世界的QoS测试
[*]不知道大家用过google的Analytics没，前段时间看过我们对公司在facebook上的某游戏做过用户地域分析，发现大多数投诉游戏有质量问题的用户集中在网很“卡”的地区。即便游戏在release前做过大量QoS模拟的测试，实验室数据总归是跟真实情况有差距的。
应对方案：尽可能让你的测试脚本大众化，一个可以在jmeter上跑的测试用例要好过无数in-house工具上写的复杂脚本。因为像watchdog这样的网站，可以提供把你的脚本部署到分布在全世界各大地区的测试服务器上运行的服务（只支持免费且大众的test framework）。
5. 知识，技能，knowhow
记得在某网站上看到：测试是强大的，只是我们没有足够的能力去驾驭它。 采用自动化测试的手段。
EXT，Flex都已经做了。
Silverlight没有产品用，所以不知道。
HTML5没有产品用，所以没有做过。 个人认为测试工具的开发要跟上
QTP和LR的RIA插件要搞好啊，这些大厂商不搞好的话，自动化发展不了啊。
另外有个路子就是开源测试框架，用开源引擎管理自定义对象库了。这个是听某高人说的。 不太熟悉这方面，期待高人。 好难，没做过。 网络基础设施的日益完善为各类应用服务提供了良好的承载平台，各种接入方式（比如ADSL，Cable，光纤接入，Mobile）为用户提供了各种接入网络的途径，网络终端需要更多种类，更灵活，质量更好的应用服务。网络应用服务种类繁多，包含传统的标准应用，比如HTTP，FTP，DNS，Streaming等应用，更多更复杂，增长更快的是P2P应用和Messenger应用。传统的应用可以通过仪表很好的进行测试，对于层出不穷的P2P应用和Messenger应用需要提供更灵活可扩展的方案进行仿真。 本文提供了思博伦公司Avalanche3100对网络应用测试的业界领先方案。
2网络应用测试
网络应用测试包括对网络应用服务器的测试和对中间网络应用基础架构的测试。网络应用从协议实现方面包括传统标准应用和五花八门的非标准（没有具体规范）应用，如P2P和Messenger等。网络应用测试不单单是对单应用测试，还包括流量模型的测试，流量模型是对一定时间一定周期内网络流量的分布特征的抽象，反应各类应用在网络中的分布情况，流量模型的测试对于网络应用承载和检测设备测试非常关键。
3标准网络应用测试
标准网络应用测试主要包含基于Web的测试，DNS测试，流媒体测试，以及其他各类服务器（FTP，邮件，CIFS等）的测试。这些应用都会特定的标准对应，有具体的协议框架，承载内容会有变化，具体到实现，不同的服务器也会有特定的要求。此类应用的测试难点在于对于服务器的测试，比如基于Web的服务器，虽然应用基于HTTP，但是服务器比如Portal会对客户端的内容有严格的要求，如果仅仅支持HTTP其实不能说就可以测试Portal服务器，因为仪表需要提供Portal需要的请求才能完成和Portal的交互，否则测试无法进行。对于传统标准应用测试，下面举Portal测试为例说明思博伦Avalanche3100如何实现服务器的测试。
（1）Portal服务器测试
Portal是基于Web的认证系统（HTTP/HTTPS），主要提供个性化、单次登录、聚集各个信息源的内容，Portal是对信息的集成技术，可以很方便的为用户提供统一的界面和个性化的服务。
Portal虽然是基于Web的技术，登录Portal的过程虽然简单，但是Portal通常会提供一些会话信息给登录客户端，这些信息对客户端来说是动态变化的，需要提供给Portal以表明自己的会话合法性。测试的难点在于如何提供Portal需要的动态内容以保证Portal对用户的身份认证以及Portal通过认证对用户的控制。对于Portal的测试，仪表需要支持比如Cookie，SessionID等才能完成和Portal的交互。通过Avalanche3100可以完成任何和Portal动态交互的过程，以达到测试的目的。
（2）测试场景
如图1所示，Avalanche3100仿真登录的客户端，登录Portal，登录成功以后，点播电影《阿凡达》。
图1测试场景 登录的过程需要若干动态交互的过程，比如SessionID，Cookie以及ViewState等。Avalanche3100通过对动态内容的变量化来完成动态交互的目的，同时提供高性能的压力测试。Avalanche 3100也是性能测试仪表中惟一支持与Portal动态交互的仪表。
（3）P2P和Messenger测试 目前网络中的应用除了标准的应用外，还有几千种甚至更多流行的其他应用，比如P2P（BitTorrent，eDonkey，Kazaa，Gnutella）和Messenger（MSN，QQ，YahooMessenger，Skype，GTalk）应用，同时一些研究机构或者军方会有自己的专有协议或者定制应用。这些应用的测试是棘手的问题，主要在于这些应用不规范，不标准，种类繁多，协议变化快无法一一跟踪，以前仪表的方法是通过对单个会话的回放来仿真这些应用，这么做的问题在于无法根据应用变化随时进行修改，并且简单的单用户回放无法实现多用户多场景多流程的变化，与现网相去较远，并且这种回放无法对交互过程进行编辑甚至定制，所有过程千篇一律，对于DPI等测试效果很不佳。针对这种情况，Avalanche3100提供的SAPEE（ScaleableApplication Playback Emulation Environment）可以提供灵活的可扩展的方案，对所有基于TCP/UDP的非标准应用进行动态仿真，适应各类应用的版本升级和协议变化。
那么如何用SAPEE来实现P2P和Messenger呢？本文将以MSN为例对此进行介绍和说明。
使用SAPEE对MSN进行仿真，需要抓取MSN报文，MSN报文里面可以包含任意你需要的会话内容或者会话数。SAPEE会提供一个向导完成对MSN报文的导入，导入的过程可以提供一系列过滤条件来完成对报文的过滤。导入后，Avalanche会提供对这个报文的解析，具体参见图2。
图2导入后Avalanche提供对这个报文的解析 此例中的报文中包含4个MSN会话，生成的SAPEEMSN为播放列表（Playlist），其中4个MSN会话叫做流（Stream），点击任何一个Stream都可以看到这个Stream中包含的报文交互过程，以及各报文的详细内容。SAPEE与一般意义的回放不同在于，你可以对报文内容进行任意编辑和扩展，比如你添加你想要，也可以删除你不喜欢的，你可以对报文的任意字段变量化，比如MSNID或者MSN交互的内容。这样就可以对会话进行扩展，确保对MSN的仿真不是单用户行为的重复，而是千变万化。对于仿真P2P或者Messenger测试DPI/DFI来说，DUT可能会对特定字段更敏感，SAPEE可以提供LOOP和TIMER对特定流或者特定报文段进行LOOP或者处理延时评估，为测试提供更准确完备的结果。
4网络流量模型测试
网络中的应用是复杂多样的，但是网络流量其实也是有一定规律的，这些规律可以通过一定时间的观察和分析得出一个模型来描述，这就是流量模型。把流量模型搬到实验室用仪表进行实施就是流量模型的测试，流量模型对于测试网络基础架构非常重要，这类测试不仅仅是对网络设备的功能性或者指标的测试，更重要的是稳定性的测试，对网络后期运营有很多的指导意义。
图3是网络流量模型中各类应用的分布情况，各类分布以带宽为基准。 图3网络流量模型中各类应用的分布情况
模型显示，网络中基于Web的应用占有较大比例，同时非标准应用比如BitTorrent，MSN，GTalk等也占有40%左右的比例。
Avalanche3100可以根据各应用的分布情况来进行灵活配置，实现各类应用之间的比例关系，对于非标准应用通过SAPEE来进行仿真。图4是各标准协议的选择和配置。
:Q 验证回答。
我转的哦，大家可以看下。 图4各标准协议的选择和配置
SAPEE完成各类P2P，Messenger等的仿真，具体参见图5。
图5SAPEE完成各类P2P，Messenger等的仿真 通过Avalanche灵活的Load分配机制，完成各应用流量的混合，具体参见图6。
图6通过Avalanche灵活的Load分配机制，完成各应用流量的混合 5结束语
网络应用服务器测试，比如Portal服务器，需要支持动态交互过程，比如SessionID，DynamicLink和Cookie是必须的，通过Avalanche3100可以在高性能的情况下实现Portal服务器的测试。对于非标准协议支持，需要的是可扩展的解决方案，以便随时跟踪各类P2P和Messenger应用的发展变化，Avalanche SAPEE提供了一种灵活可扩展的方案。
非标准协议因不同场景会有不同的流程，其中交互过程也有动态的内容，SAPEE的动态变量可以实现内容的动态化，而不是简单的回放单个用户行为。流量模型（TrafficModel）是对现网一段时间流量的抽象，测试需要关注各类流量的分布和业务特征。Avalanche支持各种流量分布模型的构建和非标准协议的可扩展性仿真
富网络应用
JavaScript库，ICEfaces，AdobeFlash，微软Silverlight，现在还有HTML5，全球性的网络支配地位的竞争已经进入了崭新的时代 -- 一个富网络应用（简称RIA，中文也 有叫富互联网应用）的时代。详见 http://tech.qq.com/a/20100728/000341.htm 这个问题足够写篇论文了饿。。。。
页:
[1]
