软件测试的概论
1. 什么是软件质量
是指满足用户需求的程度
A. 明确定义的功能和性能需求
B. 明确定义的开发标准和准则
C. 隐含要求的其他特性
2. 软件的组成
文档、数据和程序的集合。
3. 测试
Testing
引申：度量、检测。
4. 什么是软件测试？(有争议)
是对数据、文档和程序的一种度量和检测。
5. 软件测试和软件质量之间的关系是什么？
软件测试是为了提高软件质量而服务的，是保证软件质量的手段
6. 软件测试的目的是什么？
A. 验证 （软件是否正确的实现了用户的某一特定功能 （挑错））
B. 确认 （软件符合用户需求）
7. 软件测试的对象
文档、数据和程序
文档（需求规格说明书、概要设计说明书、详细设计说明书、用户手册（帮助文档）等等）
数据（还包括图片、视频等）
程序（源码、模块、部件、软件）
8. 软件测试的原则是什么？
A. 所有的测试活动都应以用户需求（软件需求规格说明书）为标准
B. 应尽早地和不断的进行软件测试 （和看病一个道理）
C. 完全测试是不可能的 （例如：计算器）
D. 应充分注意测试中的集群现象（第一个：2 . 8 定律 20%的错误有80个 80%错有20个）
E. 程序员应避免检查自己的程序
F. 尽量避免测试的随意性
9. 软件测试工程师的作用是什么？
尽可能早的发现软件缺陷，并确保其得以修复
10. 软件测试的衡量标准是什么？
多、快、好、省
11. 总结：
从最初的软件质量------引申出软件测试-------了解软件测试需要了解什么内容就是我们关心的了
软件质量------软件测试-------软件的组成------测试- ------对象------目的------原则------软件测试工程师------衡量标准
软件测试的基础
1. 软件生存周期模型
阶 段 基本任务 基本任务
问题定义 理解问题 生产电冰箱
可行性研究 理解工作范围 产值、产量、技术能力等
需求分析 定义用户要求 市场调研
概要设计 建立软件结构 主体设计
详细设计 各模块的功能实现 图纸设计
编码 编写程序 制造
测试 发现和排除错误 检验检测
维护 运行和管理 保质保修
2. 软件需求分析
需求是 用户对系统提出的要求，这种要求可能是原始的、笼统的，也可能是抽象的太细节化的
软件需求分析的主要目的是：在综合分析用户对系统提出的一组需求（基本功能、性能、数据等方面）的基础上，构建一个从抽象到具体的逻辑模型表达软件将要实现的需求。
并以“软件需求规格说明书”的形式作为本阶段工作地结果，为下一个阶段的软件设计提供设计的基础
3. 概要设计
又称总体设计，即确定系统的具体实现方案、给出软件的模块结构、编写总体设计说明书
4. 详细设计
又称过程设计，这一步的工作，就是要对系统的每个模块给出足够详细的过程性描述。这种描述不是程序的书写，而是用一些工具来表示每个模块，所以这种描述是不能够在计算机上运行的。
5. 什么是Bug？
Bug一词的原意是“臭虫”或“虫子”。现在泛指计算机硬件和软件中的缺陷或错误
6. 缺陷的特征：
1、软件未实现需求说明书要求的功能
2、软件出现了需求说明书指明不该出现的错误
3、软件实现了需求说明书未提到的功能
4、软件未实现需求说明书未明确提及但应该实现的目标
5、软件难以理解、不易使用、运行缓慢等。
7. 为什么会产生缺陷？
信息传递的错误
1、用户想要的
2、用户所说的
3、需求人员理解的
4、《系统需求规格说明书》
5、开发人员理解的
6、实际软件
实际软件与用户想要的有偏差。
8. 缺陷的分布：
第二个： 2 . 8 定律
（60%需求 20%设计 ） 8 . （15%编写 5%其他）2
9. 缺陷修复的成本
需求设计 < 设计阶段 < 编码阶段 < 支付阶段
10. 软件测试的模型：
什么是软件测试的模型：
测试模型是对测试工作活动的总结与归纳。
它告诉了我们在软件开发过程中，测试人员应该做什么、怎么做。
第一大关键问题
V模型：
最常见的测试模型：
下降的是开发过程各阶段 右边上升的是测试活动的各阶段
局限性
软件测试作为需求分析、概要设计、详细设计和编码之后的一个阶段，而前期需求 的问题要到测试活动的后期（验收测试）才会暴露出来。
W模型：
是V模型的一种发展
它强调了测试应该伴随着整个开发周期，与开发同步进行。
优点
试的不仅仅是程序，需求分析和概要设计同样需要测试
更符合“尽早地和不断地进行软件测试 ”的原则
H模型：
单元（模块）测试
针对软件设计中最小的单位进行正确性校验
集成测试
在单元测试的基础上，将程序模块进行有序的、递增的组装测试
11. 单元测试：
目标：
检验程序最小单元有无错误（类、文件、窗口、菜单、报表或一个存储过程）
·接口、数据结构、便捷、覆盖、逻辑
检验单元编码与设计是否吻合
依据：
详细设计，编码
方法：
白盒测试
测试执行人：
开发工程师
12. 软件测试的分类-按开发阶段分
验收测试：
系统（确认）测试: System Testing 测试两个或多个单元
是为了验证和确认系统是否达到了用户的原始目标。
检验组成整个系统的代码、以及系统的软硬件配合有无错误
代码实现的系统与用户需求是否吻合
检验系统的文档等各种是否完整、有效
模拟验收测试的要求，检查系统是否符合用户的验收标准
单元测试：Unit Testing 检查应用程序的小单元和模块
集成测试：Integration Testing 测试整个系统
系统测试：
性能测试：所有的活动都作为性能测试的一部分执行，且与白盒测试紧密联系。彻底检 查并监控系统，通过所有可能的输入和预期的输出结果来测量系统
可用性测试：检查输出结果和错误消息以判断其是否有意义、是否简单
开发界面时要考虑用户的教育背景和理解能力
GUI 测试：窗体测试、空间测试、菜单测试
图形用户界面是基础代码的前端，是用户和软件交互的工具
配置和安装测试：检查软件安装，这个流程也判断系统是否能在不同的平台上安装或卸载
恢复测试：有意使系统发生故障
如果系统自我恢复，将确认重新初始化和检查点机制是否正确
安全性测试：拒绝未经授权的访问
都是经过身份验证的用户
13. 验收测试：
又称交付测试，即当软件完成单元测试、集成测试、系统测试之后，我们依据软件需求规格说明书，对软件进行一次全面的测试，完成对软件整体质量的评估
1.有效性测试
是在模拟的环境运用黑盒测试的方法，验证软件是否满足需求规格说明书列出的需求。
2.软件配置复查
保证软件配置的所有成分都齐全，各方面的质量都符合要求，文档内容与程序完全一致。
α测试：先在公司内部的环境上运行，由公司员工先试用，提出反馈意见和发现缺陷。
β测试：让少数用户或者公司合作伙伴使用，提出反馈意见和发现缺陷。（微软和QQ）
正式验收：用户根据验收测试报告独立完成或者在测试人员指导下完成。
14. 软件测试的分类-按测试实施者分：
开发方测试
开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求。
用户测试
用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。
第三方测试
介于开发方和用户之间的测试组织的测试。
15. 软件测试的分类-按测试技术分：
白盒测试
通过对程序内部结构的分析、检测来寻找问题。
黑盒测试
通过软件的外部表现来发现其缺陷和错误。
灰盒测试
结合了以上两种测试方法。
16. 测试分类
测试策略
黑盒测试 白盒测试
手动测试 自动测试
静态测试 动态测试
总结：
第一章了解到了软件测试的概论 那么这章了解到了软件测试的基础
首先了解到得是软件生存周期模型，在了解软件生存周期模型上，了解到了什么是软件需求设计，概要设计，详细设计等
软件测试？我们要发现的是什么？
我们要发现的Bug。
在了解Bug之后，必须要了解为什么会有Bug？它的特征是什么？分布？修复的成本
那么我们怎么样能更加好的测试呢？
由此引出了模型（V模型 、 W 模型 、 H 模型）
软件测试的分类
软件生存周期---软件需求分析---概要设计---详细设计
Bug---为什么会产生---特征是什么---怎么分布的---修复的成本
模型---V模型---W模型---H模型
软件测试的分类---按开发阶段分（验收测试、系统（确认）测试、集成测试、单元测试）---按实施者分（开发方测试、用户测试、第三方测试）---按技术分（黑盒测试、白盒测试、灰盒测试）---测试策略（黑盒测试、白盒测试 --- 手动测试、自动测试 --- 静态测试、动态测试）
软件测试功能测试用例设计
1. 测试用例的定义：
测试用例就是记下我们要进行什么测试，进行测试的具体步骤，以及测试执行是否正确的标准
测试用例是一个包含输入和预期输出并与实际输出有关的标志
解决要测什么、怎么测和如何测的问题
所有的预期输出缺一不可
2. 测试用例的用途和目的：
执行测试，发现缺陷
重新执行测试，重现缺陷
管理测试过程
回归测试，验证缺陷是否修复
使测试更加方便的执行
提高测试效率
便于进行回归测试
使测试过程更方便管理
3. 影响测试用例测试的主要因素
需求目标
用户实际使用场景
软件功能需求规格说明书
测试的方法
测试的对象
4. 测试用例的编写原则：
准确性：测试用例的设计确实符合测试需求，并且必须准确地说明测试的内容
简洁性：测试用例的设计中必须包含完成测试必要的步骤、要素，不需要加入多余的、可有 可无的步骤、要素
可重用性：测试用例的设计要求测试是可控的，它能够使任何人在任何时间进行测试都能获 得同样的结果
适用性：测试用例对于当前的测试环境和测试者而言是可以执行的
纯净性：不会因为执行该测试用例而影响其它测试用例的执行，用例中应说明如何将应用系 统恢复到最初状态，而不影响后续测试的进行。
5. 测试用例的编写有三种主要格式：
Step-by-step （按步骤）
Matrix （矩阵表）
Automated script （自动化脚本）
前两种是测试用例最基本的格式，最后一种是自动执行前两种测试用例的软件脚本。
6. 测试用例设计的方法：
黑盒测试方法：
1） 等价类划分法
2） 边界值分析法
3） 场景法
4） 错误推测法
5） 因果图法
6） 判定表驱动法
7） 正交试验设计法
8） 功能图法
白盒测试：
1）语句覆盖
2）判定覆盖
3）条件覆盖
4）判定/条件覆盖
5）路径覆盖
7. 编写有效的测试用例
使用合理的语言：
测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测 试用例的输入和预期输出
避免含义混淆，方法：在操作步骤中采用动词+名词的结构，动词总是测试人员要 做得事情，名词总是测试人员操作的对象、事物
制定命名规则，同一种事物只有一种名称
使用模版：
编写测试用例更方便
提高测试用例的组织性
提供了标准
格式统一美观
有助于测试人员寻找信息
能够包括很多有关测试过程的选项
使用克隆：
模仿某个测试用例来写别的测试用例
某些用户手册中的步骤、文字也可以被克隆
保存以前写过的测试用例，以便以后进行克隆
Matrixes测试用例也可以克隆，特别是在表结构相同的情况下，只需要改变一些列 的名称和值就可以
测试用例的依赖关系：
具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用 例
考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积 的。应尽量避免这种情况，以免让测试变得繁琐
保持测试用例依赖关系的正确性和一致性
以一种合理的顺序来安排测试用例的顺序
8. 测试用例示例
1.测试用例标识
2.测试步骤
3.输入
4.预期输出
5.实际输出
6.特殊过程的要求
7.与其他测试用例的依赖关系
8.环境要求
8.1 硬件
8.2 软件
8.3 其他
9. 测试模板包含的内容
项目名称 程序版本
测试坏境
编制人 编制时间
功能名称
功能特性
测试目的
预制条件
参考信息 特殊规程说明
用例编号 测试步骤 边界值 输入数据 预期结果 测试结果
总结：为什么有测试用例？怎么样把它做到最好
从测试用例的定义到怎么编写一个好的测试用例
定义---用途和目的---编写原则---影响因素---编写格式---方法---有效的测试用例---测试用例的模板
最主要的是理解 ------ 方法
软件测试功能测试用例设计（黑盒测试 等价类方法）
1. 测试用例：预期输入不同就写一个测试用例
2. 黑盒测试
内部实现不可见 关注的只有输入和输出 （这两个条件是否满足需求）
3. 黑盒测试发现的常见错误
A. 功能不正确或遗漏
B. 界面错误
C. 数据库访问错误
D. 性能错误
4. 黑盒测试的特点
从理论上来讲，黑盒测试只有采取 穷举输入 测试，把所有可能的输入都作为测试情况考虑，才能查出所有的错误
实际上测试情况是无穷多的，完全测试是不可能的。
如何解决
把黑盒测试加以分类
1、节约测试实施的时间和资源
2、避免盲目测试、提高测试效率
3、使测试的实施重点突出、目的更明确
5. 分类
1、等价类划分法
2、边界值分析法
3、错误推测法
4、因果图法
5、判定表驱动法
6、正交试验设计法
7、功能图法（把软件分解为相对独立的功能单元
8、场景法
结合一起使用
6. 等价类划分
讲程序的输入域分成若干部分，然后从每个部分中选取少数代表性数据作为测试数据
特点：代表性数据在测试活动中的作用等价于这一类中其他的数据
分类：有效和无效等价类
有效等价类：
对于程序的需求说明来说是合理的，有意义的输入数据所构成的集合
利用它可以检验程序是否实现了预期的功能和性能
无效等价类：
对于程序的需求说明来说是不合理的，没有意义的输入数据所构成的集合
利用它可以检验程序对于无效数据的处理能力
7. 划分等价类的方法：
A . 在输入条件规定了取值范围的情况下，则可以确立以个有效等价类和两个无效等价类
如：输入值是学生成绩，范围是 0~100 有效： 0 <=成绩<=100 无效：成绩<0 成绩>100
B . 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效 等价类和一个无效等价类；
如：填写验证码
C . 在输入条件是一个布尔量（true和false）的情况下,可确定一个有效等价类和一个无效等价类。
如：我同意条款才能执行下一步 QQ安装
D . 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n 个有效等价类和一个无效等价类。
如：密码查询问题 默认的“请选择密码查询问题”是无效等价类
E . 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等 价类（从不同角度违反规则）；
如：申请邮箱号码
F：在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划 分为更小的等价类。（细分）
如：数据 ： 数值 和 非数值 / 数值：非服数值 和 负实数 / 数值： 字母 和 空格
8. 等价类划分的特点和注意事项
等价类的特点
测试内容相同
如果等价类中的一个测试能够捕获一个缺陷，那么选择该等价类中的其他测试也能 捕获该缺陷
如果等价类中的一个测试不能够捕获一个缺陷，那么选择该等价类中的其他测试也 不能捕获该缺陷
两类划成一类，结果？
一类划成两类，结果？
注意
考虑无效等价类
仔细划分
9. 怎么设计测试用例
1)为每一个等价类规定一个唯一的编号；
2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步， 直到所有的有效等价类都被覆盖为止；
3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到 所有的无效等价类都被覆盖为止。
黑盒测试（边界值分析法）
1. 边界值分析法
对程序输入或输出的边界值进行分析和测试，是对等价类划分法的一种补充。
2. 边界值分析法的特点：
1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、尺寸、空间等。
相应地，以上类型的边界值应该在：最大/最小、首位/末位、最短/最长、 空/满等情况下。
3. 边界值方法小结
输入或输出的边界最容易产生错误
确定边界值的方法
对取值范围进行界定
对取值个数进行界定
有序集合
分析规格说明，找出其他边界条件
隐含的边界值
2的乘方
ASCII表
4. 边界值分析法的使用
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个 范围边界的值作为测试输入数据。
如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件， 其邮，其费计算公式为:货物重量*费率=邮费”。
有效等价类边界值(10、10.01、50、49.99)
无效等价类边界值（9.99、50.01）
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作 为测试数据。
比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。
3)将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
问题:某程序的规格说明要求计算出“每月保险金扣除额为0至1165.25元”，如何取其测 试数据?
有效等价类边界值（0.00、0.01、1165.24、1165.25）
无效等价类边界值（-0.01、1165.26）
4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个 元素作为测试用例。
5)分析规格说明,找出其它可能的边界条件。
黑盒测试（功能图法、错误推测法、场景分析法）
1. 功能图法
就是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。
功能图模型由状态迁移图和逻辑功能模型组成。
例如：Windows的屏幕保护程序测试（有密码保护功能）
2. 错误推测法
是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例
错误推测法本身不是一种测试技术，而是一种可以应用到所有测试技术中产生更加有效 的测试的一种技能。
3. 错误推测法基本思想
列举出程序中所有可能有的错误和容易发生错误的特殊情况来设计测试用例
例如:
以前测试时曾出现过错误的地方，包括单元测试、集成测试、系统测试、前几次回 归测试
输入数据的问题，如是否可为空，是否可以有特殊字符，是否可以小于0、等于0 等等
一些问题的范围或边界
4. 场景分析法的定义
用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束 遍历其中所有基本流和备选流。
5. 为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同 一事件不同的触发顺序和处理结果形成事件流。
这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情 景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。
6. 场景分析法实例
上图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用 例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个 特定条件下执行，然后重新加入基本流中（如备选流 1 和 3）；也可能起源于另一个备 选流（如备选流 2），或者终止用例而不再重新加入到某个流（如备选流 2 和 4）。
场景分析法实例
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将 基本流和备选流结合起来，可以确定以下用例场景：
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。
7. 测试用例
7. 生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。
每个场景写一个测试用例
总结：
选择测试用例的综合策略
首先进行等价类的划分，包括输入条件和输出条件的等价类划分
在任何情况下都必须使用边界值分析方法
可以使用错误推测法追加一些测试用例
对照程序逻辑，检查已设计的测试用例的逻辑覆盖程度
如果程序的功能说明中含有输入条件的组合情况，则一开始就选用因果图法和判定表驱动法
对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
功能图法也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据
对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合运用各种测试方法
白盒测试
在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特征的情况下，在程序接口进行测试，他只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能够适当地接受输入数据产生正确的输出信息。
通常情况下使用工具测试
1. 白盒测试方法：
语句覆盖：使程序中每个语句至少执行一次
语句覆盖是最弱的逻辑覆盖
判定覆盖：使每个判定的真假分支都至少执行一次
判定覆盖仍是弱的逻辑覆盖
条件覆盖：使每个判定的每个条件的可能取值至少执行一次
条件覆盖不一定包含判定覆盖
判定覆盖也不一定包含条件覆盖
判定/条件覆盖：选取足够多的测试用例，使判断中的每个条件的所有可能取值至 少执一次，同时每个判断本身的所有可能判断结果至少执行一次.
能同时满足判定、条件两种覆盖标准。
路径覆盖：（想到与场景法）最好的一种
2. 白盒测试的基本技术：
1、语句分析和语法分析
2、静态错误分析
类型和单位分析
引用分析
表达式分析
接口分析
3、程序插桩技术
方法简介
断言语句
3. 白盒测试的方法：
1、代码检查法
代码检查方式（桌面检测、代码审查、走查）
代码检查项目
编码规范
代码检查规则
缺陷检查表
2、静态结构分析法
3、静态质量度量法
4、逻辑覆盖法
语句覆盖（SC）
判断覆盖（DC）
条件覆盖（CC）
条件判定组合覆盖（CDC）
多条件覆盖（MCC）
修正条件判定覆盖（ＭＣＤＣ）
５、基本路劲覆盖法
程序的控制流程图
程序环路复杂性
基本路径测试步骤
６、其他白盒测试方法
域测试
符号测试
Ｚ路径覆盖
程序异变
测试的执行
1. 测试团队在项目中的位置
测试团队的基本职责
1、尽早地发现软件系统中的问题；
2、督促和协助开发人员尽快地解决程序中的缺陷；
3、帮助项目管理人员制定合理的开发计划；
4、对缺陷进行跟踪、分析和分类总结；
5、促进程序编写的规范性、易读性、可维护性等；
6、帮助改善开发流程、提高产品效率。
协助 > 督促
测试团队的定位
1、以开发为核心，测试只是开发队伍中的一部分。
2、以项目经理为核心，开发小组和测试小组并存。
3、测试人员独立于项目之外，三足鼎立
2. 第二大关键问题
测试工作流程：（和H模型一样）
3. 测试环境
什么是测试环境
测试环境是软件+硬件+网络
硬件：pc（品牌和兼容）、笔记本、服务器、各种PDA
软件：指软件运行的操作系统
网络：针对C/S和B/S结构的软件（局域网（速度）、互联网）
4. 测试环境的要求
1、真实（尽量模拟用户真实的使用环境）
2、干净无毒
3、独立（测试环境和开发环境相互独立）
5. 环境对测试用例的影响
C/S模式的客户端软件（如腾讯QQ）着重要考虑操作系统、网络协议、通讯端口 和防火墙的影响
B/S模式的Web应用则主要考虑的是浏览器、SSL协议、API等的影响，而操作系 统对Web应用影响较小或者几乎没有。
SSL协议：网络安全协议 API：应用程序编程接口
6. 测试环境优化
测试用例的环境组合不能简单地叠加起来。试图进行完全组合的测试是不可能的。
操作系统（12种）
浏览器 （9种）
防火墙 （6种）
等等
7. 操作系统的市场份额
Win xp > win7 > win > 其他
8. 浏览器的市场份额
IE（55%）> Mozilla（20%）> Firefox（15%） >其他（10%）
9. 用户界面和适用性测试
软件的用户界面（user interface UI）
Windows 95、Windows98、Windows 20##、Windows XP、Windows Vista
10. 用户界面测试的要素
1、符合标准和规范
不同的界面元素在不同的场合适用。
例如：Windows界面的提示信息分为系统提示 （i 白色符号）、警告信息 （！ 黄 色呼号）和严重警告信息 （x 红色符号）
2、直观性
例如：Google的初始界面
3、一致性（使用的术语、字体、界面的元素风格是否一致）
4、灵活性
软件用不同的选项来满足不同用户的喜好和需求，用不同的方式来完成相同的功能
例如：计算器
5、舒适性
例如：登陆QQ后会弹出一个腾讯迷你首页
6、正确性（窗口没有完全显示、文字不对齐、文字拼写错误、密码输入没有*屏蔽）
7、实用性
例如：日期的输入 可以直接选择日期
11.
功能测试执行
1. 软件测试项目要素
1、用户
2、目标
3、范围
4、工期
5、项目类型
6、软件平台
7、开发工具和语言
2. 项目的测试需求和任务
确定软件功能测试需求
确定非功能性的系统测试需求
l 容错处理
l 兼容性要求
l 配置要求
l 性能要求
l 安全性要求
l 可靠性
l 易用性
l 日志文件
3. 功能测试
功能测试：
用于测试应用系统的功能需求的黑盒测试方法。
这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工 作(自然他能用于测试的各个阶段)。
运行系统，查看其功能是否正常实现，是否满足需求。对于需求没有涵盖，但功能 实现上不合理的地方(从用户角度考虑)与项目经理沟通，进行系统完善。
参考
参考《需求分析》、《规格说明书》、《测试计划》、《测试用例》等文档
多与开发人员、用户及其他项目相关人员沟通
4. 功能测试－控件操作
文本框测试：从输入数据的内容，长度，类型，格式等几个方面来考虑
按钮测试：
按钮功能是否实现
提示信息是否正确
对于不符合业务背景的输入数据是否有相应的处理
单选框测试：
单选按钮是否同时只能选中一个
各单选按钮功能是否能正确完成
是否有默认被选中的选项
up-down控件＋文本框组合测试：
上下箭头的控制
边界值的测试
默认值的测试
非法输入字符的测试
组合列表框测试：
条目内容的检查
条目功能的是否实现
列表框中是否能输入数据
复选框测试：
多个复选框可以同时选中。
多个复选框可以被部分选中。
多个复选框可以都不被选中。例如，即不选轮廓，也不选阴影字体
逐一执行每个复选框的功能。
每个复选框都可能有三种状态：选中、未选中和部分选中。
列表框测试：
条目内容正确。
逐一执行列表框中每个条目的功能。
列表框内容多要使用滚动条。
列表框允许多选时，要分别检查按Shift选中条目、按Ctrl选中条目和直 接用鼠标选中多项条目。
滚动条控件：
滚动条是否能拖动
滚动条拖动时屏幕刷新情况
滚动条拖动时显示信息的显示
滚动条的上下按钮是否可用
各种控件的组合使用：
控件间的相互作用
Tab键的顺序
热键的使用
回车键和ESC键的使用
控件组合后功能的实现
5. 文件操作：
打开文件：
打开在任意位置的文件
以各种方式打开文件
打开任意格式的文件
打开文件对话框中的各按钮
保存文件：
在任意位置保存文件
以各种方式保存文件
保存任意格式的文件
保存文件对话框中的各按钮
关闭文件：
正常关闭文件，系统提供确认信息。
通过菜单或窗口按钮关闭。
非正常关闭。
打印文件：
本地打印和网络打印是否能完成
打印界面的各属性的设置
打印界面的各按钮功能是否能实现
6. 编辑操作：
编辑操作需要测试些什么
查找、搜寻中考虑输入的内容和长度
替换中考虑输入的内容和长度
编辑操作窗体的功能测试
7. 插入操作：
需要测试些什么？
8. 复制操作：
复制操作需要测试些什么？
9. 鼠标操作：
如何进行测试
左右键操作是否能完成
单击、双击、三击是否能完成
拖放、滚轮等功能是否能完成
移动、点击的速度
10. 窗体界面测试：
窗体大小
移动窗体
缩放窗体
显示分辨率
状态栏
工具栏
错误信息
父窗口
子窗口
11. 控件界面测试检查列表
控件 测试内容 是否通过
1 控件摆放对齐，间隔要一致，没有重叠区域
2 无错别字
3 无中英文混合
4 控件的字体和大小都要一致
5 控件被现实完整不被剪切或重叠现象
6 文字无全角和半角混合使用
12. 菜单界面测试：
1. 点击菜单可以正常工作，并与实际执行内容一致。例如点击菜单查找，而进入 的窗口却是打开文件窗口。
2. 错别字。例如“恢复取消”写成了“灰复取消”
3. 快捷键重复。例如“取消”和“设置只读”操作的快捷键都是Ctrl+Z，当用快 捷键操作时，其中一个操作就会无效。
4. 热键重复。例如“粘贴”和“查找前一个”操作的热键都是P。
5. 快捷键和热键操作有效。逐一测试每个快捷键和热键，都可以执行正确操作。
6. 菜单的字体和字号一致。不同窗体内的菜单的字体和字号要保持一致
7. 中英文混合。个别菜单文字仍为英文，整个菜单中英文混合。
8. 菜单和语境相关。例如，用不同权限的用户登录一个应用程序，管理员可以看见并使用 所有菜单功能，不同级别的用户可以看见不同级别的菜单并使用不同级别的功能。
9. 菜单设置为灰色。如图11-9右侧菜单，是关于表格的菜单，因为还没有创建表格，所以 “合并单元格”等项和当前进行的操作无关，被置为灰色无法使用。
10. 鼠标右键快捷菜单。点击鼠标右键，若出现快捷菜单，测试内容同上。
11. 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
12. 常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的 系统有所取舍。
13. 下拉菜单要根据菜单选项的含义进行分组，并且按照一定的规则进行排列，用横线隔开。
14. 菜单深度一般要求最多控制在三层以内。如果菜单选项较多，应该采用加长菜单的长度而 减少深度的原则排列。
15. 菜单前的图标不宜太大，与字高保持一致最好。
主菜单数目不应太多，最好为单排布置。
13. 特殊属性检查清单
14. 界面设计总体原则
界面的长宽比例
按钮的大小
背景的搭配
颜色的搭配
界面大小应该符合美学观点，感觉协调舒适，能吸引用户的注意力。
1. 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2. 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
3. 按钮的大小要与界面的大小和空间相协调。
4. 放置完控件后界面不应有很大的空缺位置。
5. 字体的大小要与界面的大小比例协调, 通常使用宋体，字号为9-12，很少使用 超过12号的字体。
6. 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。 常用色考虑使用Windows界面色调。
7. 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要 求的地方。
15. 文档测试：
哪些文档需要测试：
联机帮助
用户手册
ReadMe文件
包装文字和图形
市场宣传材料
授权/注册登记表/用户许可协议
标签
指南、向导
16. 联机帮助和用户手册之间的区别
·联机帮助 1）帮助手册，帮助用户解决问题 2）按F1 以.chm的格式显示帮助文档
·用户手册 1）具体告诉你每个功能 2）以文档的形式提交给用户
17. 自序文件：修改了哪些功能 、 新增了哪些功能
18. ReadMe文件：包括程序的基本信息；若有升级版的程序，还需包括新增和修改功能的简介
19. 指南、向导：通常捆绑在联机帮助系统中，用户可以提出问题，然后由软件一步步指引完成任务，例如，微软Office中的助手。
20. 标签：可能出现在媒体、包装盒或者打印材料上。例如，软盘或光盘表面的标签，包括软件名称、版本号、支持语言、版权信息、安装序列号等，都需要检查，保证无错误
21. 如何对文档进行测试
1）确认文档中指出的站点
2）确认文档中的链接正确
3）按照提示操作，完成内容
4）确认内容正确，没有错别字，标点符号使用正确。
5）确认格式、排版正确。
对于联机帮助的测试和功能测试内容相类似
1）确认目录中的内容完整，没有遗漏。
2）功能说明与系统的实际功能一致。
3）逐一点击帮助目录，检查帮助内容显示正确，标题和目录一致。
4）确认文档中的链接内容正确。
5）确认文档中热点显示正确。
6）按照提示操作，完成内容。
7）确认内容正确，没有错别字，标点符号使用正确。
8）确认格式、排版正确。
9）确认帮助窗口中的所有图标和菜单正确。
10）关键词搜索正确。
11）回车键，Tab键，热键的使用。
12）界面测试，测试内容详见第13章“设计功能和界面测试用例”。
13）帮助要有即时针对性，在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。
对用户手册的测试：
用户手册的测试内容与联机帮助相类似，因为是印刷的文档，所以少了软件功能方面的测试。
确认内容正确，没有错别字，标点符号使用正确。
确认格式、排版正确。
确认给出的示例正确。
确保拷屏和实际产品一致，不是来源于已修改过的版本。
确保所有信息真实正确和实际产品功能一致。包括开发者，服务电话，公司地址等服务信息也必须是最新 的。
22. 联机帮助测试检查列表
23. 文档测试检查单
1）术语：用户是否理解；是否需要定义；是否标准、前后一致
2）标题：是否合适，是否和实际产品一致
3）内容：功能描述正确、清晰
4）逐步执行：确保所有信息真实正确和实际产品功能一致；检查搜索的正确性；检查 网站URL能否正确链接
5）图表和拷屏：图表准确；拷屏版本一致；图表标题正确
6）示例：对文档中示例要载入并使用，保证其可以正确执行
7）错别字：无错别字，标点符号正确
8）排版：排版正确，风格一致
24. 安装测试
安装测试需要测试哪些？
安装测试
运行测试
卸载测试
安装测试需要测试些什么？
1. 关注各种不同的安装组合，无论是典型安装还是自定义安装或者其他安装类型 都要一一测试，我们的最终目标就是所有组合都能安装成功。
2. 安装退出之后，确认应用程序可以正确启动、运行。
3. 在安装之前备份注册表，安装之后，察看注册表中是否有多余的垃圾信息。
4. 卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需 检验系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。
5. 安装完成之后，可以在简单的使用之后再执行卸载操作，有的系统在使用之后 会发生变化，变得不可卸载。
6. 对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测 试是否会出现问题。
7. 至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题， 尤其是系统级的产品。
8. 考察安装该系统是否对其他的应用程序造成影响，特别是Windows操作系统， 经常会出现此类的问题。
其中第7，8条是在安装测试中引出的兼容性的问题，我们将在第19章“兼容性和易用性测试”中具体讲解。其余的1至6条让我们以office的安装为例来说明。
25. 典型安装
确认点击所有包含“上一步”按钮的对话框中的“返回”按钮都可以回到上一个安装界面。
确认点击“取消”按钮，安装程序不直接退出，而是弹出对话框与用户确认是否中止安装。
确认点击“关闭”图标，安装程序不直接退出，而是弹出对话框与用户确认是否中止安装。
点击“许可协议”中的“不接受”按钮，按“下一步”，安装程序弹出对话框与用户确认是否中止安装。
在安装过程中以点击“取消”按钮或点击“关闭”图标中断安装，程序自动删除已安装的文件。
输入用户信息，包括用户名、缩写、单位等。注意测试输入字符的长度，输入字符为空值和默认值的情况。
确认在每个窗口点击“帮助”按钮，弹出相应的关于该窗口功能的帮助。
安装界面上的文字描述正确，符合要求且语言通顺，无错别字。
界面测试
文档测试
回车键，Tab键，快捷键的使用。
安装过程突然中断。例如，安装过程中掉电。
安装介质满。例如，在剩余空间只剩100M的硬盘上安装MSOffice2000。
安装介质损坏或介质忙。
26. 用户自定义安装
选择“自定义安装”，指定新的安装路径。点击浏览键选择安装路径，或者直接输 入安装路径，可尝试输入正确的或不存在的路径。同时注意检查磁盘可用空间 显示是否正确。
选择要安装的功能。选择要安装的功能，以及各种不同的安装方式，如从本机运行， 在首次使用时安装，不安装等。同时注意检查选取不同功能时说明的变化，文 件大小的变化和有效磁盘空间的大小。
其他测试内容同典型安装
27. 安装测试通用检查列表
28. 如何进行运行测试
1. 确认安装的软件都可以正常的打开和关闭，常用功能可以使用。例如，Office2000 典型安装后应该包括Word，Excel，PowerPoint，Access，Outlook等，它们都可以 正常打开关闭。
2. 确认软件安装的目录和安装的内容都正确，没有遗漏或增加。例如，自定义安 装Office工具中的公式编辑器，安装完毕后可以在程序中使用公式编辑器；自定义 把Office安装到d:\office下，安装完毕后检查安装路径是否正确。
3. 把安装之后的注册表与安装之前备份的注册表做比较，检查是否有多余的垃圾 信息。
4. 如果安装的是正式版或升级版的软件，要确认没有时间锁。例如，通过更改时 间分别进行三个月、半年、一年的测试，检查程序能否运行。如果安装的是限时版 或试用版的软件，要确认软件超过时间就不可以运行。例如，将系统时间调整到使 用期限以外（一天、十天、一月、三月、一年），重新启动软件，确认软件不能够 使用，并弹出提示信息对话框提示用户使用期限已到，关闭提示信息对话框后，软 件自动退出。
5. 对于多语言的软件要确认产品的字符编码。例如，简体中文版的程序显示的必 须是简体中文，而不能是繁体中文。
6. 确认产品信息与实际版本一致。例如，点击“关于”菜单，弹出版本信息对话 框，确认产品名称，版本与实际版本一致。
检查开始菜单、桌面快捷方式或快速启动图标的名称正确，无错别字，可以正确打 开相应程序。
29. 卸载测试需要测试些什么
在Windows环境中，卸载程序通常有两种方式，一是运行程序提供的卸载程序，二是 在“控制面板”的“添加/删除程序”中找到要删除的程序，然后点击“删除”按钮进 行卸载。无论使用哪种方式，以下内容都是我们在卸载测试的时候要测试到的内容：
1. 卸载后，注册表中有关的注册信息是否都被删除。
2. 所有的文件全部删除
3. 在卸载过程中，卸载界面上的按钮功能是否都能实现。
4. 是否支持回车键，Tab键，快捷键的使用。
5. 卸载正在使用的程序。
6. 卸载过程中突然中断。
卸载过程中介质处于忙碌状态。
30. 卸载测试通用检查列表
安装完成之后，先简单使用一些功能，然后再执行卸载操作
卸载完成后检查注册表中有关的注册信息是否被删除
卸载完成后检查系统是否把所有的文件全部删除，安装时创建的目录文件夹、开始菜单、 桌面快捷方式和快速启动图标是否被删除
执行卸载步骤，按功能测试方法确认功能是否正确
取消或关闭卸载过程，程序不被删除，仍然可以使用
按界面和易用性测试规则，检查卸载中的所有界面
按文档测试规则，检查卸载中的所有文档（帮助）
卸载正在使用的程序
突然中断卸载过程
卸载过程中介质处于忙碌状态
31. 加密测试
加密测试需要测试些什么？
序列号的测试
解密文件的测试
加密狗的测试
32. 如何进行加密测试？
软件加密
1. 在安装或运行时提示输入正确序列号，程序可以正常安装或运行。
2. 在安装或运行时提示输入错误序列号，程序不可以安装或运行。
3. 按要求执行解密操作，检验程序可以正常运行。
4. 不执行解密操作，程序不可以运行。
硬件加密
1. 安装加密狗后，检查程序可以正常安装或运行。
2. 不安装加密狗，程序给出提示不能安装或运行。
3. 在安装或运行的过程中，拔掉加密狗，程序给出提示并退出安装或运行过程。
4. 插入同一软件不同版本的一组加密狗，检查程序仍然可以正常安装或运行。
5. 插入一组加密狗包括被测软件的加密狗和其他软件的加密狗，检查程序仍然可 以正常安装或运行。
把加密狗同其他设备连接在一起，检查程序是否仍可以正常安装或运行。例如，在并口 上插入加密狗，然后再连接上打印机。
33. 加密测试通用检查列表
软件加密
在安装或运行时提示输入正确序列号，程序可以正常安装或运行。
在安装或运行时提示输入错误序列号，程序不可以安装或运行。
按要求执行解密操作，检验程序可以正常运行。
不执行解密操作，程序不可以运行。
硬件加密
安装加密狗后，检查程序可以正常安装或运行。
不安装加密狗，程序给出提示不能安装或运行。
在安装或运行的过程中，拔掉加密狗，程序给出提示并退出安装或运行过程。
插入同一软件不同版本的一组加密狗，检查程序仍然可以正常安装或运行。
34. 设计兼容性测试用例
兼容性测试
如何解决这些问题
测试平台兼容
操作系统
应用程序
数据共享兼容
版本兼容（向前、向后兼容）
数据格式兼容
剪贴板
标准和规范
35. 兼容性－平台
测试平台兼容
操作系统
应用程序
36. 兼容性－数据共享兼容
数据共享兼容
版本兼容（向前、向后兼容）
数据格式兼容（导入、导出和转换）
剪贴板（考虑格式兼容）
DDE（动态数据交换）和OLE（对象链接嵌入）
Windows的DDE机制基于Windows的消息机制。两个Windows应用程序通过相互之间传递DDE消息进行DDE会话(Conversation)，从而完成数据的请求、应答、传输。这两个应用程序分别称为服务器(Server)和客户(Client)。服务器是数据的提供者，客户是数据的请求和接受者。
对象链接和嵌入(Object Linking and Embeding)是一组服务功能，它提供了一种用源于不同应用程序的信息创建复合文档的强有力方法。 对象可以是几乎所有的信息类型，如文字、位图、矢量图形，甚至于声音注解和录像剪辑等。
37.
缺陷报告
1. 缺陷的属性
属性名称 描述
缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识
缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源(Source) 缺陷来源指引起缺陷的起因。
缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。
2. 缺陷的状态
3. 缺陷的等级
缺陷严重等级 描述
严重缺陷 （Critical） 不能执行正常工作功能或重要功能。或者危及人身安全
较大缺陷 （Major） 严重地影响系统要求或基本功能的实现，且没有办法更正。
（重新安装或重新启动该软件不属于更正办法）
较小缺陷（Minor）
轻微缺陷 （Cosmetic） 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
其他缺陷 （Other） 其它错误
4. 解决的优先级
解决优先级 描述
立即解决 缺陷必须被立即解决。
高优先级 缺陷严重需要优先考虑
正常排队 缺陷需要正常排队等待修复或列入软件发布清单。
不紧急 缺陷可以在方便时被纠正。
5. 缺陷的类型
缺陷类型 描述
F-功能 如逻辑,指针,循环,递归,功能等缺陷
G-语法 拼写、标点符号、打字
A-赋值 如声明、重复命名，作用域
I-接口 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷
B-联编打包 由于配置库、变更管理或版本控制引起的错误
D-文档 需求、设计类文档
U-用户接口 人机交互特性：屏幕格式，确认用户输入，功能有效性
P-性能 不满足系统可测量的属性值，如：执行时间，事务处理速率等
N-标准 不符合各种标准的要求，如编码标准、设计符号等
E-环境 设计、编译、其他支持系统问题
6. 缺陷报告的详细描述
1、步骤
2、期望的结果
3、实际发生的结果
4、测试环境
5、截图和系统错误日志等
7. 缺陷报告状态流程图
（第三大关键问题）
8.
软件测试策略应用
1. C/S 和 B/S 之间的区别
C/S又称Client/Server或客户/服务器模式。
a) 服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或 SQL Server。
b) 客户端需要安装专用的客户端软件。
c) 如：网络游戏、各类资源管理系统。
B/Ｓ是Brower/Server的缩写，
d) 客户机上只要安装一个浏览器（Browser），如Internet Explorer
e) 服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。
f) 浏览器通过Ｗeb Server 同数据库进行数据交互。
g) 多数交费系统、网上银行等。
.（B/S架构）以浏览器为基础的应用程序的优缺点：
· 易于安装：可以用于许多桌上型计算机，并且和客户计算机的操作平台无关。大多数计算机已经默认安装有浏览器软件（有些应用系统需要基于IE浏览器，或者需要安装java虚拟机，在此暂且忽略不及）。
·易于部署与维护：只需要在服务器端进行部署和维护工作。
·必须在线工作：工作效率和网络是否延迟有关。
·不能充分利用客户端计算机的资源：只能通过有限的HTML语言来呈现用户界面，没有利用客户端计算机的计算处理能力。只能利用浏览器的打印功能来打印资料，不适用于企业的报表打印。
·网络传输量大：由于客户端不能保存状态数据，因此必须在客户端和服务器之间传输用户界面内容以及所需的数据。
·安全性较低。对于服务器来说可以通过防火墙软件来过滤数据，因为所有传输内容都是基于HTTP端口。但很难对数据进行加密和签名以保证在传输过程中的完整性。（HTTPS似乎并不能解决问题）
·适合电子商务或不要求严格控制客户端的应用程序。
2.（C/S架构）丰富型客户端应用程序的优缺点：
·充分利用客户端计算机的资源：可以为用户提供丰富的界面元素，可以存取本机磁盘与本机应用程序接口 (API)，执行速度较快。
·网络传输量较小：只需在客户端和服务器之间传输数据。
·安全性较高。可以方便的在客户端和服务器执行加密和解密操作，同时也可以通过Web Service来消除传统的应用程序诸如防火墙和HTTP的障碍。
·安装、部署和维护工作较为繁琐：对客户端计算机在操作平台和附加软件上有一定的限制和要求。
·可以离线工作：前提是本地必须有缓存数据的能力，这涉及到与服务器数据同步的问题。
·适合企业内部应用程序。
C/S 与 B/S 区别：
Client/Server是建立在局域网的基础上的.Browser/Server是建立在广域网的基础上的.
１．硬件环境不同:
C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务.
B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理.
有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行
２．对安全要求不同
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息.
B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群.
３．对程序架构不同
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.
B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S
结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 20## Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.
４．软件重用不同
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子
５．系统维护不同
系统维护是软件生存周期中,开销大, -------重要
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.
６．处理问题不同
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统
B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.
７．用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.
８．信息流不同
C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低
B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更象交易中心
2. C/S结构软件系统的测试
易用性测试
了解用户需求、使用习惯
了解通用或市场占有大的同类软件
服务器端的测试
专门测试，对某些组件和服务要重点测试
对部署的web services进行专门的功能验证测试
性能测试
较多用户并发
较大容量数据
安全性测试
权限及权限级别验证
安装测试
3. B/S功能测试
链接测试
链接是页面切换和引导用户到不同功能页面的主要途径。链接测试主要验证链接页面是否存在、目链接的地是否正确。
是否有孤立页面
表单测试
表单信息提交的完整性
缺省值（默认值）
Cookies测试
检查cookies是否正常工作
Cookies中的相关信息是否加密
兼容性测试
不同浏览器
相同浏览器不同版本
并发访问测试
数据库测试
4. B/S界面测试
最终用户
界面（网页）的设计策略
页面元素的协调性：位置、颜色、大小
页面风格的统一性
用户在界面上操作的便利性
界面动态操作测试：分辨率、缩放
5. 插件不算客户端
网页游戏：B/S 由PHP编写的
同步：双向的
上传
下载
单机版游戏
6. 应用服务器、数据库服务器
C/S测试主要有：文档，安装，运行，卸载，容错，安全性，兼容性，可靠性，易用性等等。
B/S测试主要有：链接，表单，cookies,开发语言，数据库，界面，性能，易用性，兼容性，安全性
其实说白了就是：对这个软件所进行功能测试和非功能测试 在测试的过程中注重集成测试