|
|
前面已经谈到,即使最简单的一个Web应用系统也会包括客户端、中间件、服务器等几部分,如果要设计一个大型的复杂应用,则可能包含数据库服务器、应用服务器、认证服务器等多个组成部分。在Web应用系统的设计阶段,测试的一个主要内容就是对Web设计从全面性、适合性、标准性等多方面进行检查。依据Web应用系统的架构,把对Web设计的测试分为总体架构设计的测试、客户端设计的测试、服务器端设计的测试三个部分。
|
|
|
|
Web应用系统中PC模型的复杂性呈指数增加,除了面临多个客户PC机所带来的测试挑战外,Web系统的服务端还涉及各种类型的硬件及操作系统、服务进程、服务器包和数据库等的软件组合。对总体设计的检查从以下几个方面进行。
|
|
|
|
瘦客户端与胖客户端是指部分应用程序和组件是否驻留在客户端。在瘦客户端系统中,客户端PC只作少量的处理,业务逻辑规则多数在服务器端执行。多数Web新闻站点、门户网站及用于信息发布的Web系统采用这种模式。这种模式适合于对客户端没有特殊要求、用户量庞大并且分散的Web应用系统。
|
|
|
胖客户端既运行应用程序的用户界面,又执行部分业务逻辑。此时,浏览器不仅要处理HTML等页面,还要执行Java applet和ActiveX控件等其他组件。一些银行客户系统、网络游戏、网上办公系统等Web应用系统采用这种模式。这种模式适合于对安全性要求较高、交互操作频繁或业务逻辑复杂的Web应用系统。胖客户端能减轻服务器端的处理强度,与服务器端之间有较强的交互能力,但需要在客户端安装一些应用程序或组件。
|
|
|
确定采用哪种模式,要由Web应用系统的具体需求决定。测试的任务就是验证设计中采用的模式是否符合系统需求。
|
|
|
|
根据业务需求,服务器端可能是一台简单的Web应用服务器,也可能是由中间件、数据库和安全服务器等组成的服务器群。在确定服务器端的组成部分时,需要考虑到成本、功能、安全性要求、容量要求、传输实时性等多个方面。对Web架构设计的测试除了要验证Web架构的组成部分是否满足上述需求外,还要检查各组成部分是否有搭配不兼容的地方。
|
|
|
|
服务器软件可能分布在若干个物理服务器单元上。如下表所示列出了服务器配置的几个例子。
|
|
|
|
|
这部分测试的重点是验证服务器端的配置和分布是否满足用户的功能、性能、成本等需求。
|
|
|
|
客户端设计主要是面向用户的,包括功能设置、信息组织结构设计和页面设计。对客户端设计的测试也将从这三方面进行。
|
|
|
|
Web应用系统的功能设置应尽量以企业内部工作的需求为主,取消或少设与工作无关的功能(如网上游戏、网上聊天等),以提高工作效率。常用的功能有以下几类。
|
|
|
|
此类功能为读者提供多种动、静态信息,如公共信息、同行业信息、企业内部管理信息、业务信息、信息搜索等。
|
|
|
|
此类功能主要提供企业内部通信、工作流控制等方面的功能,以实现企业办公自动化(实现无纸办公),如电子邮件、公文管理、内部论坛、会议日程安排、任务追踪、综合审批流程等。
|
|
|
|
企业内部网通过设立防火墙、代理服务器等接入Internet网,使员工享受Internet上提供的各种服务,扩大信息获取渠道,弥补Intranet站点上功能及信息的不足。
|
|
|
|
|
信息是Web应用系统,特别是Web站点的灵魂,信息发布是Web应用系统的一个重要功能。在进行Web应用系统设计时,要确保把需要发布的信息按功能、主题等分类,并以某种方式结构化相应的信息,使用户能直观、快捷地查到所需信息。信息组织结构设计主要有线性结构设计、分层结构设计和非线性结构设计三种。
|
|
|
线性结构信息的组织方式与一本书的组织方式相似,信息按顺序链接,一页紧接另一页。它限制用户不能以非顺序(即非线性)方式浏览内容,但可允许用户向前或向后搜索信息内容。
|
|
|
分层结构信息以树形方式组织信息,采用线性路径搜索方式浏览信息内容。它具有层次清楚、易于查找等特点,搜索路径只能向上或向下。
|
|
|
非线性结构信息按内容的关系链接信息,没有明显的结构。它允许用户随意地在信息中漫游。用户可在非线性结构中完全自由地改变信息浏览路径。
|
|
|
对信息组织结构设计的测试重点是验证设计模式是否适合信息的特点,能否使用户直观、快捷地浏览到所需信息。
|
|
|
|
页面是信息的载体,它直接体现Web站点的设计水平。一个好的页面因信息层次清晰而让用户一目了然;因设计巧妙、精致美观而让用户流连忘返;因恰当使用各种元素能完成许多功能而不显拥挤。对页面设计的测试可从以下几个方面进行:
|
|
|
|
. 在每个页面上是否设计友好的用户界面和直观的导航系统;
|
|
|
|
|
. 是否充分考虑了合适的页面布局技术,如层叠样式表、表格和帧结构等。
|
|
|
|
服务器端的设计包括众多的内容,而且都是非常重要的内容,例如数据库设计、安全系统设计等,这些设计会在很大程度上影响到Web应用系统的性能、安全性、可靠性等,因此要对这些设计进行严格的测试。下面分别讲述对容量规划、完全系统设计和数据库设计的测试。
|
|
|
|
大多数进程被划分为两类:输入输出限制(I/O-bound)和CPU限制(CPU-bound)。用于静态HTML的常常是I/O-bound,从硬盘检索文件的速度受到该速率的限制,同时文件从网络接口移出时受到该速度的限制。动态HTML的产生恰好相反,它常常是CPU-bound的,也就是说它用于产生页面的时间要比将页面移出网络接口的时间要长。CPU此时的作用很关键,特别是用CGI或Java Servlet来创建动态页面时尤其明显,并且大多数此类CPU处理是串操作。另一方面,依赖于数据库查询的动态内容常常受到数据库速度的限制,数据库又通常是I/O-bound的,因为它需要从硬盘上检索数据。容量规划就是把用户的需求量化成具体指标,作为Web设计的一个重要依据。
|
|
|
进行容量规划是非常必要和重要的,它和Web应用系统的性能是息息相关的。对容量规划的测试也非常必要,评价容量规划设计的关键在于:将所要求的延迟和带宽与该体系结构中每一环节的额定容量作一比较,每个组成部分都必须满足这些要求,其中还必须要考虑到系统各部分之间可能产生的内耗,以及对该体系的生命周期可能增加的负载。对容量规划的测试方法是,检查容量规划是否满足用户的需求,可以从以下几个方面进行检查。
|
|
|
|
点击率就是每秒HTTP的请求数,也叫每秒被访问的次数。从统计学的角度来看,服务器的负载是时间的函数,根据Web内容和用户群的分布,时间函数表现的曲线是不同的。对点击率的估算可采用80~20原理和UCML方法(参见本书负载压力测试部分内容),根据用户的需求估算容量规划中的点击率是测试的一个主要方法。
|
|
|
|
规划流量及延迟目标必须要考虑用户访问网络的能力及期望值,因此这部分测试就是对用户的情况进行分析,检查容量规划中确定的流量及延迟是否能达到用户的期望值。如果容量规划是以宽带接入的用户的标准进行设计的,那么这些指标对使用调制解调器上网的用户来说就不适用了,可能延迟时间会超过他们的接受范围。
|
|
|
在估算时还要注意Web应用系统设计中是否提供流媒体,流媒体需要连续传输,可能持续几分钟的时间,这和标准HTTP传输的连接时间有很大不同。另外,流媒体有不同的格式,例如音频和视频,它们的估算公式和标准也是不一样的。它们会占用大量带宽,对延迟时间有严格的要求。
|
|
|
|
服务器的内存是需要重点考虑的,经常是性能瓶颈所在。当内存不足时,有的进程会转移到硬盘上去运行,造成性能急剧下降。而且,一个缺少内存的系统常常表现出很高的CPU利用率,因为它需要不断地扫描内存,将内存中的页面移到磁盘上。估算所需的内存需要考虑几个方面:操作系统所需内存、Web高速缓存所需内存、CGI所需内存等。
|
|
|
|
安全是贯穿Web应用系统设计、运行、管理等全过程的一个非常重要的因素,需要从多方面考虑,才能制定出一个较为完善的安全策略,保证Web应用安全运行。因此,在对Web应用系统设计的测试中,对安全系统设计的测试是一个重要内容,一般从以下几个方面进行审核和评估。
|
|
|
①常识性安全策略。评估设计中对重要的部分是否采取了取消不必要的协议、严格控制写权限、取消服务器目录浏览属性、保留日志记录等安全措施。
|
|
|
②使用加密技术。为保证重要数据在网上传输过程中不被人窃听或修改,必须对数据进行加密,确保数据传输的安全性。加密的方法很多,如公共密钥加密、数字签名、链加密、文档加密、SSL和SHTTP等。审核采用的加密方式能否满足用户需求。
|
|
|
③构造防火墙。当Web应用系统与外部网络连接时,还必须构造防火墙,一般防火墙保护分为网络级、应用级和电路级等三种防方式。审核采用的防火墙方式和安全级别能否满足用户需求。
|
|
|
④构建网络防毒体系。病毒在网络中存储、传播、感染的途径多、速度快、方式各异,对Web系统的危害较大。因此,需要构建必要的网络防毒体系。验证网络防毒体系设计是否防护全面、多层次和全方位。
|
|
|
|
数据库设计是一个重要内容,对数据库设计的测试在本书的相关章节论述,这里不再赘述。
|
|
|