目录：

• 1、软件测试中，CS架构的系统和BS架构的系统，如何分别进行测试？
• 2、有哪些开源的自动化功能测试工具？ 要能测CS架构的程序的哦，需要一个工具来自动完成填表单的工作。。
• 3、CS所需要的工具
• 4、cs结构（客户端）软件测试要点，需要写成PPT给开发看的，让开发避免低级错误！在线等！！！
• 5、cs结构的客户端与服务端的通讯协议一般是怎样的
• 6、CS架构应用使用loadrunner如何进行性能测试

软件测试中，CS架构的系统和BS架构的系统，如何分别进行测试？

那个cs客户端渗透测试工具，CS是指浏览器和服务器cs客户端渗透测试工具，BS是指客户端和服务器。

1．硬件环境不同:

C/S 一般建立在专用cs客户端渗透测试工具的 *** 上, 小范围里的 *** 环境, 局域网之间再通过专门服务器提供连接和数据交换服务.

B/S 建立在广域网之上的, 不必是专门的 *** 硬件环境,例与 *** 上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行

2．对安全要求不同

C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可 *** 息.

B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群.

3．对程序架构不同

C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.

B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持 *** 的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.

4．软件重用不同

C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.

B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子

5．系统维护不同

系统维护是软件生存周期中,开销大, -------重要

C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统

B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.

6．处理问题不同

C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统

B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.

7．用户接口不同

C/S 多是建立的Window平台上,表现 *** 有限,对程序员普遍要求较高

B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.

8．信息流不同

C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低

B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心

了解其特性之外，cs客户端渗透测试工具我觉得测试就不是问题了。

有哪些开源的自动化功能测试工具？ 要能测CS架构的程序的哦，需要一个工具来自动完成填表单的工作。。

hi

1、首先我想知道你的C/S架构的软件程序编程语言是什么cs客户端渗透测试工具？是C++、Java还是啥cs客户端渗透测试工具？

2、是java的话，我推荐你使用开源测试工具abbot，它包括录制功能，它的测试用例是用XML写的，但是我建议你可以根据自己的需求进行aboot的修改，可以修改为直接调用其底层的对象识别API，然后上层自己拓建。至于。你想实现填表单工作

1）靠录制，然后加一个for循环，不过这要是用abbot的XML实现较麻烦，因为XML的逻辑实现不好，那你可以自己写一个XML解析函数，用一个程序自动化更新XML用例

3、是MC的程序的话，商用的很多都可以。个人觉得：你用C++自动化测试的话，更好能够自己去做一些自动化测试工具，是应用一些 *** 操作C++控件吗，这样的话，你可以找一些操作接口拓展自己的控件操作库，灵活而且复用性好， *** 有：

1）应用MSAA提供的接口，MSAA的全称是Microsoft Active Accessibility。这是类似DCOM技术。技术模型是这样的，UI程序可以暴露出一个Interface，方便另一个程序对其进行控制。 MSAA技术的初衷是为了方便残疾人使用Windows 程序。比如盲人看不到窗口，但是盲人可以通过一个USB读屏器连接到电脑上， 读屏器通过UI程序暴露出来的这个Interface，就可以获取程序信息，通过盲文或者其它形式传递给盲人。MSAA提供了如此方便的功能， UI自动化测试自然可以借用这项技术。MSAA暴露出来的Interface叫做 IAccessible。

2）每个windows窗口都有句柄，找到了窗口句柄我们就能够对其进行一系列操作。在找寻句柄的属性下，你可以用SPY C++进行识别。

4、.net程序的话，我记得VS2010自带的 CUIT工程就可以，其包含录制和回放API，蛮好的

有啥问题的话，可以发邮件我：test_sunny@hotmail.com（散步的SUN）

CS所需要的工具

反作弊工具:

sex客户端:

sex服务端:

c-d下载:

其他工具:

HLC(彩色喷图 *** 工具):

谢谢.

cs结构（客户端）软件测试要点，需要写成PPT给开发看的，让开发避免低级错误！在线等！！！

主要要说明几个方面

1功能性测试

1）功能正确性，检测标准为需求文档或者设计文档，主要检查是否存在功能缺失

2）流程正确性，正常流程、回退流程、分支流程是否能正常使用

3）功能可靠性，在错误、非法、空的情况系统是否能做出正确的响应（黑盒测试 *** 如边界值、等价类划分等，这个就不细说了）

4）流程可靠性，主要针对非需求、设计上有说明可能为非法流程的操作过程，这种情况在复杂流程系统中存在，经常出现单节点上有多个分支，或者存在交叉流程的系统中，或者分支流程中存在回退操作的，都有可能，具体情况需要具体分析了

5）数据正确性，如果C/S的系统的话可能涉及金融行业，钱算的对不对，算法的逻辑判断，这个需要结合功能正确性和可靠性一起进行测试的

2、对于性能要求的话，主要关注以下3个方面，时间特性（响应时间、传输时间等）、用户数情况（并发用户数、在线用户数等）、资源特性（服务器的CPU、内存、 *** 等使用情况、客户端的cpu情况、内存使用情况），这个需要团队在开发伊始就要注意的，主要集中在技术选型、开发框架、数据库设计方面

后面的内容需要团队的能力提升以后的事情了，不过现在可以让大家有相关意识，不用以后手忙脚乱

3、安全特性主要关注应用安全（包括功能性安全、权限安全等）、系统安全（软件是否存在安全后门等等类似）

4、兼容性关注不同的操作系统

5、易用性关注用户能否易于上手（这个可以扩展出去的内容）

有这几个方面，我想差不多够了，当然还有更细节的方面。

cs结构的客户端与服务端的通讯协议一般是怎样的

RMI是java语言本身提供cs客户端渗透测试工具的远程通讯协议,稳定高效,是EJBcs客户端渗透测试工具的基础.但它只能用于JAVA程序之间的通讯.Hessian和Burlap是caucho公司提供的开源协议,基于HTTP传输,服务端不用开防火墙端口.协议的规范公开,可以用于任意语言.Httpinvoker是SpringFramework提供的远程通讯协议,只能用于JAVA程序间的通讯,且服务端和客户端必须使用SpringFramework.Web service是连接异构系统或异构语言的首选协议,它使用SOAP形式通讯,可以用于任何语言,目前的许多开发工具对其的支持也很好.��测试结果显示,几种协议的通讯效率依次为cs客户端渗透测试工具：RMI Httpinvoker = Hessian Burlap web serviceRMI不愧是JAVA的首选远程调用协议,非常高效稳定,特别是在大数据量的情况下,与其他通讯协议的差距尤为明显.HttpInvoker使用java的序列化技术传输对象,与RMI在本质上是一致的.从效率上看,两者也相差无几,HttpInvoker与RMI的传输时间基本持平.Hessian在传输少量对象时,比RMI还要快速高效,但传输数据结构复杂的对象或大量数据对象时,较RMI要慢20%左右.Burlap仅在传输1条数据时速度尚可,通常情况下,它的毫时是RMI的3倍.Web Service的效率低下是众所周知的,平均来看,Web Service的通讯毫时是RMI的10倍.����二、结果分析1、直接调用直接调用的所有毫时都接近0,这说明程序处理几乎没有花费时间,记录的全部时间都是远程调用耗费的.2、RMI调用与设想的一样,RMI理所当然是最快的,在几乎所有的情况下,它的毫时都是最少的.特别是在数据结构复杂,数据量大的情况下,与其他协议的差距尤为明显.为cs客户端渗透测试工具了充分发挥RMI的性能,另外做了测试类,不使用Spring,用原始的RMI形式（继承UnicastRemoteObject对象）提供服务并远程调用,与Spring对POJO包装成的RMI进行效率比较.结果显示：两者基本持平,Spring提供的服务还稍快些.初步认为,这是因为Spring的 *** 和缓存机制比较强大,节省了对象重新获取的时间.3、Hessian调用caucho公司的resin服务器号称是最快的服务器,在java领域有一定的知名度.Hessian做为resin的组成部分,其设计也非常精简高效,实际运行情况也证明了这一点.平均来看,Hessian较RMI要慢20%左右,但这只是在数据量特别大,数据结构很复杂的情况下才能体现出来,中等或少量数据时,Hessian并不比RMI慢.Hessian的好处是精简高效,可以跨语言使用,而且协议规范公开,cs客户端渗透测试工具我们可以针对任意语言开发对其协议的实现.目前已有实现的语言有：java, c++, .net, python, ruby.还没有delphi的实现.另外,Hessian与WEB服务器结合非常好,借助WEB服务器的成熟功能,在处理大量用户并发访问时会有很大优势,在资源分配,线程排队,异常处理等方面都可以由成熟的WEB服务器保证.而RMI本身并不提供多线程的服务器.而且,RMI需要开防火墙端口,Hessian不用.4、Burlap调用Burlap与Hessian都是caucho公司的开源产品,只不过Hessian采用二进制的方式,而Burlap采用xml的格式.测试结果显示,Burlap在数据结构不复杂,数据量中等的情况下,效率还是可以接受的,但如果数据量大,效率会急剧下降.平均计算,Burlap的调用毫时是RMI的3倍.我认为,其效率低有两方面的原因,一个是XML数据描述内容太多,同样的数据结构,其传输量要大很多；另一方面,众所周知,对xml的解析是比较费资源的,特别对于大数据量情况下更是如此.5、HttpInvoker调用HttpInvoker是SpringFramework提供的JAVA远程调用 *** ,使用java的序列化机制处理对象的传输.从测试结果看,其效率还是可以的,与RMI基本持平.不过,它只能用于JAVA语言之间的通讯,而且,要求客户端和服务端都使用SPRING框架.另外,HttpInvoker 并没有经过实践的检验,目前还没有找到应用该协议的项目.6、web service调用������������ 本次测试选用了apache的AXIS组件作为WEB SERVICE的实现,AXIS在WEB SERVICE领域相对成熟老牌.为了仅测试数据传输和编码、解码的时间,客户端和服务端都使用了缓存,对象只需实例化一次.但是,测试结果显示,web service的效率还是要比其他通讯协议慢10倍.如果考虑到多个引用指向同一对象的传输情况,web service要落后更多.因为RMI,Hessian等协议都可以传递引用,而web service有多少个引用,就要复制多少份对象实体.Web service传输的冗余信息过多是其速度慢的原因之一,监控发现,同样的访问请求,描述相同的数据,web service返回的数据量是hessian协议的6.5倍.另外,WEB SERVICE的处理也很毫时,目前的xml解析器效率普遍不高,处理xml bean很毫资源.从测试结果看,异地调用比本地调用要快,也从侧面说明了其毫时主要用在编码和解码xml文件上.这比冗余信息更为严重,冗余信息占用的只是 *** 带宽,而每次调用的资源耗费直接影响到服务器的负载能力.（MS的工程师曾说过,用WEB SERVICE不能负载100个以上的并发用户.）测试过程中还发现,web service编码不甚方便,对非基本类型需要逐个注册序列化和反序列化类,很麻烦,生成stub更累,不如spring + RMI/hessian处理那么流畅简洁.

CS架构应用使用loadrunner如何进行性能测试

你确定你的服务端与服务端的交互只是socket协议吗？协议正确的话就可以录制了。不能录制的原因有很多,比如loadrunner本身的问题,版本破解汉化导致的问题等。

如果你会点编程技术,完全可以自己编写socket协议的脚本。