B/S测试与C/S测试之区别
我们在日常功能测试工作中，常常依据测试对象和测试目标的不同分为四个级别的测试，单元测试、集成测试、系统测试和验收测试，但是往往忽略了被测应用系统架构。

在测试过程中针对不同的系统架构，测试的侧重点也不同。

下面以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. 得到需求、功能设计、内部设计说书和其他必要的文档
ü 2. 得到预算和进度要求
ü 3. 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程(例如发行过程、变更过程、等等)
ü 4. 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
ü 5. 确定测试的步骤和方法──部件、集成、功能、系统、负载、可用性等各种测试
ü 6. 确定对测试环境的要求(硬件、软件、通信等)
ü7. 确定所需的测试用具(testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等
ü8. 确定对测试的输入数据的要求
ü9. 分配任务和任务负责人，以及所需的劳动力
ü10.设立大致的时间表、期限、和里程碑
ü11.确定输入环境的类别、边界值分析、错误类别
ü12.准备测试计划文件和对计划进行必要的回顾
ü13.准备白盒测试案例
ü14.对测试案例进行必要的回顾/调查/计划
ü15.准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，
建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
ü16.得到并安装软件版本民ü17.进行测试民ü18.评估和报告结果民ü19.跟踪问题/错误，并解决它民ü20.果有必要，重新进行测试民ü21.整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
三、有哪些测试
1、黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。

2、白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的
覆盖率。

3、单元测试——测试中的最小单位，测试特殊的功能或代码模块。

由于需要对内部
代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。

该测试的
容易程度同代码设计的好坏直接相关。

4、增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。

在程序
的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。

这类型测试可以有开发者或测试者完成
5、集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。

在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务
器断程序等等。

这类型测试典型的是于客户/服务器和分布式系统相关。

6、功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。

这类型测试应
当有测试人员来完成。

这并不意味着开发人员在发布版本之前就不需要检查他们的代
码。

7、端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行
测试。

例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交
互。

8、理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一
些主要的测试努力下表现的足够好并且可以接受。

例如：如果一个新软件每五分
钟当
机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理
智’状态，必须保证在当前状态下进行进一步测试。

9、回归测试——在软件或环境被修改后进行的再测试。

可能很难确定我们需要进行
多少的再测试，尤其接近到__________开发过程的末期。

自动测试工具可能会有很大的帮助。

10、可接受性测试——基于最终用户的规格进行的最后测试。

或者基于最终用户在一
定的时间范围内的测试。

11、负荷测试——在高负荷条件下进行的测试。

12、压力测试——该术语通常同负荷测试和性能测试是可交换的。

也可用于描述这样
一些测试，
如：在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测
试。

13、性能测试——该术语通常同负荷测试和压力测试是可交换的。

理想的性能测试是
定义在需求文档或QA测试计划中的。

14、安装和反安装测试——测试完全、部分或升级的安装/反安装过程
15、恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况
16、安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。

可
能需要复杂的测试技术。

17、兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。

18、ALPHA测试——在开发进行结束的时候进行的测试。

针对测试的结果可能还会进
行一些小的设计更改。

这类测试典型的是由用户进行的，而不是由开发者或测试人员
进行的。

19、BETA测试——在开发和测试已经全部结束后，并且在最终版本发布之前进行的
测试。

这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。

五、什么是测试计划
测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。

1、标题
2、确定软件的版本号
3、修订文档历史，包括作者、日期和批示
4、目录表
5、文档的目的和适合的读者群
6、测试的目的
7、软件产品概述
8、相关文档列表，例如：需求、设计文档、其他测试计划等
9、相关的标准或合法需求
10、可跟踪性需求
11、相关的命名规范和标识符规范
12、整个软件项目组织和人员/联系信息/责任
13、测试组织和人员/联系信息/责任
14、假设和依赖关系
15、项目风险信息
16、测试优先级和焦点
17、测试范围和限制
19、测试提纲——对测试过程的一个分解，通过测试类型、特点、功能性、过
程、系统、模块等
20、测试环境设置和配置问题
21、数据库设置需求
22、概述系统日志/错误日志/其他性能，有助于描述和汇报问题的屏幕捕获工具
等
23、有助于测试者跟踪问题根源的具体软硬件工具的论述
24、测试自动化的可能性和概述
25、使用的测试工具，包括版本、补丁等
26、使用的项目测试度量
27、报告需求和测试可传递性
28、软件入口和出口准则
29、初始的理性测试阶段和标准
30、测试终止和重新开始的标准
31、人员安排
32、测试地点
33、用到的测试外的组织，他们的目的、责任、可传递性、联系人和协作问题
34、相关的财产、分类、安全性和许可证问题
35、公开的一些问题
36、附录——词汇表、缩略语等
六、什么是测试用例
1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。