软件测试 单机版软件（无server，使用sqlite或access）与网络软件的区别？测试侧重点？

我看到过一段关于这两个测试区别和侧重点分析，我觉得很有道理，以下是相关说明：

我们在日常功能测试工作中，常常依据测试对象和测试目标的不同分为四个级别的测试，单元测试、集成测试、系统测试和验收测试，但是往往忽略了被测应用系统架构。在测试过程中针对不同的系统架构，测试的侧重点也不同。下面以B/S结构和C/S结构的特殊应用系统为例，分析在功能测试中的区别。

我们谈到的web系统是指以Brower/Server的访问方式为主，包含客户端浏览器、web应用服务器、数据库服务器的软件系统。一般的B/S结构，都是多层架构的，有界面层、业务逻辑层、数据层。由于这种结构不需要客户端的安装，客户端主要通过浏览器来访问，因此客户端测试的重点是：客户端 *** 作系统（不同类型和版本）、客户端浏览器（不同类型和版本）以及客户端配置（cookie设置和分辨率设置）等测试。除客户端测试外，根据WEB系统常用技术还需要关注以下几个方面的测试：

（1）链接测试

（2）表单测试

（3）脚本测试

（4）ActiveX控件测试

C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。这种结构与B/S最显著的区别是需要安装客户端，通过客户端程序来访问应用系统，因此C/S客户端测试是重点，并且与B/S结构有所不同。

C/S客户端测试的重点有：

（1）客户端安装测试

安装手册的评估

安装的自动化程度

安装选项和设置得测试

安装过程的中断测试

安装顺序测试

多环境安装测试

安装的正确性测试

修复安装测试

卸载安装测试

（2）客户端升级测试

与变更相关的测试

变更内容的测试

与变更相关的测试

（3）客户端与服务器链接测试

（4）服务器端数据验证

（5）客户端可维护性测试

以上内容总结了B/S与C/S系统测试的不同点，唯实践使理论之树常青，我们可以在实际工作中积累总结出更多的不同的测试关注点。

　1、FireBird不是新手想象的那么弱，要想数据完整性好，速度快，连接数容量大，数据库大而不慢，还是FireBird是首选，用MSSQL是下策，至少目前MSSQL还达不到海量数据库标准，我的FireBird1.5和Interbase6完全胜任几百G的单数据库，应该是十万以上的连接数，当然，这个10万以上连接数是我服务器端程序来解决的，而十几个服务器端程序只用大概300多线程连数据库而已，客户的感觉一直就是查询真快。。。

根据经验，MSSQL的单数据库文件超过4G后，特别是含有各种索引，存储过程、触发器等复杂应用时，总会有些问题，做维护时很头痛的。当然，如果应用简单 ，记录数少，单记录尺寸大时，例如一般的信息管理数据，MSSQL还能支持大一点的数据库。若是记录数多，特别是读写密集型，如超市销售，省级销售网络，MSSQL基本玩完，硬撑是大幅增加维护成本，必须要上马FireBird了。

另外在大容量客户连接时，不管用什么数据库，千万不要用数据库原生的XML返回，XML是网络带宽杀手啊。最好用C的API返回记录集，再程序生成XML。

2、SQLite还是很鸡肋，真的不如全功能的嵌入式FireBird，网上的测试都是太简单，循环读写最简单的记录，我的测试是SQL语句只要稍复杂点，SQLite的速度可以说是慢，抛开复杂SQL语句不说，仅仅是循环插入BLOB字段，SQLite跟死了差不多，而Firebird依然是很欢快的。看来SQLite还是主要依赖 *** 作系统，还不能叫做数据库。

我以前每次做单机程序都会先选择SQLite，因为它能全编译进C++Builder，但每写一段时间都被迫换回Firebird，次次如此啊，真痛苦。最大的感觉是SQLite为什么总是那么不争气呢。。。

3、单单是为了速度的话，还是建议用BerkeleyDB，我做网络管理程序和数据库管理程序时，主程序都是用BerkeleyDB保存各种数据，它也能全编译进C++Builder，速度没得说。而服务器端数据库的用户信息、单位信息、产品型号标准等等变动少的表，我也是用BerkeleyDB做数据库的缓存表，一有客户端连接认证，直接查询发出即可，开发者更容易控制程序的运行稳定性，维护很少。

---