虽然B/S结构、J2EE架构愈来愈成为流行模式，但基于传统的C/S结构的应用程序还广泛地应用于各种行业。尤其是金融行业中的商业银行柜面－核心帐务系统等。一方面由于传统商业银行一般都有大量的字符终端等需要复用的设备，一方面也是因为他们存在大量密集的对实时性要求很高的高柜业务，使用传统的基于C/S结构或者C/S/S结构的应用效率更有保证。
C/S结构即CLIENT/SERVER结构。传统的C/S结构一般分为两层：客户端和服务器端。该结构的基本工作原理是，客户程序向数据服务器发送SQL请求，服务器返回数据和结果。客户端负责实现用户接口功能，同时封装了部分应用逻辑。服务器端的数据库服务器主要提供数据存储功能，也通过触发器和存储过程提供部分应用逻辑。
C/S/S结构即客户/应用服务器/数据库服务器三层结构，中间增加了应用服务器，通常实现应用逻辑，是连接客户与数据库服务器的桥梁。它响应用户发来的请求执行某种业务任务，并与数据库服务器打交道，技术实现上通常选用中间件产品，如BEA公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应用也属于这种三层或多层结构，这里不包括。）
三层或多层C/S结构与两层C/S结构相比，它的优势主要表现在：安全性加强、效率提高、易于维护、可伸缩性、可共享性、开放性好等。 1.2系统架构示意图
1.3CS/CSS系统架构中性能测试的特点 1.3.1CS/CSS系统架构的性能影响因素
由于CS/CSS系统的以下特性，测试工程师对一个CS/CSS系统实施性能测试具有很大的难度： *整个系统的各个部分使用多种操作系统，性能上有差别；
*整个系统架构的各个环节上使用多种数据库，同样在性能上有差别；
*应用是多个，分属多个种类，分布在不同设备上，包括自行开发的应用、第三方的应用； *系统中的设备、组件通过不同协议进行连接、通讯；
*系统的内部接口多，性能瓶颈多；而系统的整体性能往往取决于最差的部分；需要分别测试和联合测试
*系统的性能指标不光同应用系统架构有关，还和具体行业应用的业务模式有关； *采用此架构的行业应用往往是一个7×24小时系统；
*采用此架构的行业应用可能高柜业务多，这样会影响对性能度量项的选取和转换； *各个环节基本上以交换数据报文的方式通信，其格式经常会比较复杂。
因此这样的系统对于对测试工程师的知识的深度和广度都是一个考验。对于这样的系统，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。
1.3.2CS/CSS系统架构中性能测试的基本策略 1. 确定好测试工作范围
首先可以分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是用户最关心的，我们在测试之前就要通过一些设置把这些因素的影响调至最低。
另外，用户更关心整个系统中哪个环节的性能情况也会影响工作范围。如有的环节是全新系统，而有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全面一些。 2. 分析好客户的性能测试需求
客户是已经明确提出了性能指标，还是只提供了用户使用方式和历史交易流量数据，需要我们自己进行性能基准的计算？性能测试的目的是验证系统性能还是想确定目标系统的理想配置？是否还要使用测试结果预测在不同机型的处理能力？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。
3. 要作好性能测试的计划和方案
测试计划和方案中要注意测试需求分析阶段提出的问题的解决。 4. 确定的测试通过准则、性能测试的计划、结果要获得客户的认可
要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚至是性能测试过程，都要根据其重要程度，决定是否需要客户进行确认和签字。获得客户的认可是最重要的。
1.3.3CS/CSS系统中性能测量与性能探测 性能测量
1. 在性能测试开始前必须认真规划性能测量：
软件性能测量技术范围很广。可以包括日志、事件计数、事件持续时间、采样等性能测量技术。 *确定性能测量的策略：我们要测试什么？ *规划性能测试中使用什么样的测量工具。
学习WEB标准的朋友一般都是从学习CSS开始，为什么呢？因为CSS是一种很有意思的语言，它能让我们的网页千变万化。也许我们一开始的接触只是因为链接的样式修改，然后慢慢发现CSS的强大而又简单，于是我们用它来控制整个网页的布局、排版、色彩、图片等等工作。学习了CSS之后我们又会发现XHTML的结构更为重要，一个好的XHTML结构可以让CSS少费很多事。同时也会避免网页在不同浏览器之间的差异。于是又开始学习了XHTML代码，并且不断的去摸索着XHTML的结构的特点。会写CSS了，也懂得XHTML结构的重要性并能灵活应用的时候，是不是就可以了呢。也许这时我们就会发现其实样式的管理同样非常的重要。
大家也许都已经有了自己的管理方式，因为所要应用的网页类型的不同可能管理的思路也不一样，这里我只是把我的样式管理做一个整理。算是给大家提供一个可以参考与研究的范例，给对于没有形成自己的管理方式的朋友们提供一个参照范本。
我的样式管理是针对于单一项目、单一的风格体系的网站，一般这样的网站都是中小型的网站，风格是上一致的。对于大型网站，或是风格差异很大的'网站体系是不适用的。我们在做样式之前首先要想到样式的易维护性。一旦需要修改就必需要快速方便，修改工作的成本是很高的，所以我们要尽量避免这样的工作所占用时间的扩大。那我们就有必要把样式与结构代码分开。下面看一下我的目录分配方法：
其中，[images] 是存放xHTML中出现的图片，[jonStyle]我统称之为主题包，在样式包中包括了[CSS]、[img]、[js]分别存放CSS样式表、样式表中所引用的图片、网页中所用的JS。这里存放图片的[img]与外面的[images]虽然都是存放图片的，但是这里的图片的性质却是不一样的。[img]是CSS中所引用的图片，所有的图片的显示与否都与CSS样式有关，他的归属性是，[img]里的图片是归属于CSS的，而不是XHTML的。而CSS是不会引用[images]中的图片。[images]中的图片只归属于xHTML，xHTML也不要直接使用[img]中的图片。
这里把[js]也放在了[jonStyle]文件夹中也许会有人觉得不妥，我的考虑是这样的：行为与样式本都是使得这个XHTML的结构能多姿多彩。当我们需要更换皮肤的时候，也有可通这个行为也是需要更换的。比如：在第一套方案中，某个区块的内容是要上下滚动的，然而在第二套方案中，这个区块就需要左右滚动。那么这个行为也需要与样工一起更换。当然实际应用的时候不一定是这么简单理由。
基本上大的结构是这这样的。那么样式表的结构又是怎么样的呢？我是这样来划分的：样式包中有一个base.css（基本共用样式）module.css（模块样式）forms.css （表单样式）mend.css（补丁样式）print.css（打印样式）
其中base.css是一个基本的样式，也就是所有网页的共性样式，这个样式与module.css配合基本上可以显示正常的页面。表单的划分，也可以有利于对不同地方的表单的样式管理。WEB标准涉及兼容性，所以需要有样式补丁当然还有针对性的这里就不一一列举。最后一个的打印样式，是提供给打印设置使用的。
我通过这样的划分，在对于维护与网站的样工更新上，就显得非常的容易，基本上可以在不需要程序人员的参与下就可以完成对网站的皮肤的更换。如果一个网站同时具备很多个主题包，那么只要简单的在XHTML中更换主题包的名称就可以使用不同的样式。这与网站的程序相配合将可以做出非常好的，具有很强扩展性的应用网站来！
