一、 软件测试基本概念
1 bug的概念
bug类型：defect、fault、problem、error…
problem的来源：需求定义、设计、实现、支持系统、软件测试不足、草率的重构（几乎软件的生产过程中的每处都会出现各种各样的问题！）
bug来源百分比：规格说明书(55%)、设计阶段(25%)、代码阶段(15%)、其他(5%)【百分比留印象即可，按照时间顺序递减】
2 软件测试的定义
The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed
测试软件，尽早发现bug，并确保他们被修复
3 测试模型
3.1 V模型
近似瀑布模型,先开发再测试
V模型的缺陷：
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段。忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。
3.2 W模型
测试从需求阶段便开始,紧跟软件开发过程
对象不仅仅是程序，需求、设计和功能同样要测试
一旦有文档提供，就要及时确定测试的条件、编写测试用例
局限性：
1. 在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
2. 无法支持迭代、自发性以及变更调整。
3.3 H模型
1. 软件测试包括测试准备和测试执行,是一个独立流程,贯穿产品整个周期
2. 尽早准备，尽早执行
3. 不同层次的测试活动可以按照某个次序先后进行的，但也可能是反复的
3.4 X模型
边开发边集成测试，
单独的程序片段进行相互分离的编码和测试
探索性测试，这是不进行事先计划的特殊类型的测试
这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高
4 软件工程与软件测试的关系
总结：基本项目分析导出针对测试乃至系统/集成/单元的测试计划，这些计划最终用于指导v模型的测试过程。
5 软件测试的分类
按方法：黑盒测试、白盒测试
按目标/特性：功能测试、健壮性测试、性能测试、适用性测试、安全性测试、可靠性测试
静态测试：需求评审、概要设计评审、详细设计评审、代码检查
动态测试：单元测试、集成测试、系统测试、验收测试
6 测试与调试的区别
测试发展的初期,测试就是调试;而现在测试是一个系统化工程的概化念,有自己的生命周期,调试的范畴更小一些
调试不属于测试,是编码阶段的工作,由程序员完成;而测试由测试员或程序员完成
二、软件测试的现实
1 软件测试的9大公理
永远不可能完全测试一个程序;
测试是基于风险的实践;
测试无法说明bug就不再存在了;
当你找到越多的bug，那么程序里存在的bug就会越多;
杀虫剂悖论（pesticide paradox）的现象，即对软件进行越多的测试，那么该软件对软件测试人员的测试就越具有免疫力。
不是所有bug被找到后都会被修复;
很难说bug什么时候是真的bug
规格说明书永远不是最终版;
测试工程师不是项目中最受欢迎的成员;
软件测试是需要训练和技术的一个职业
2 软件测试的补充原则
必须基于“质量第一”
事先定义好产品的质量标准
第三方测试更客观、更有效
重视文档,妥善保存测试过程一切文档
3 谁来完成测试？
程序员应该避免测试自己的程序（心理学因素、思路受局限）
由其他人来完成测试工作会更有效、更成功。
这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。
开发者测试
对等测试
独立测试小组
独立测试机构
4 测试和QA
软件测试员（QC）：检测软件产品
找出缺陷，
评价软件质量
质量保证人员（QA）：检测软件过程
创建和加强促进软件开发并防止软件缺陷的标准、方法和过程。
5 SQA(Software Quality Assurance)
软件质量保证是通过对软件产品和活动有计划的进行评审和审计，来验证软件是否合乎标准的系统工程活动
5.1 SQA与软件测试的关系
SQA 是管理工作,审查对象是流程,强调以预防为主
测试是技术实施工作,测试对象是产品,主要是以事后检查(文档、程序)为主
SQA指导测试、监控测试,测试为SQA提供依据,是SQA的一个环节、一个手段
6 测试管理体系
测试规划（确定目标和策略）
测试设计（确定测试方案及用例）
测试实施（执行用例）
配置管理（测试配置管理）
资源管理（资源综合调配与管理）
测试管理（对以上过程综合管理）
7 组建测试队伍
7.1 任务
测试计划、测试用例设计、执行测试、评估测试结果、递交测试报告
7.2 责任
尽早发现问题，督促尽早解决，帮助制定合理的开发计划，分析、总结、跟踪问题，提高程序、文档的规范性、易读性、可维护性等
7.3 基本构成
测试组长：负责项目的管理、测试计划、任务安排等
环境配置人员：设置、配置和维护实验室的测试环境
测试设计人员/资深测试工程师：规格说明书、设计的审查，测试用例的设计，技术难题的解决，培训 和指导，实际测试任务的执行
一般(初级)测试工程师：执行测试用例和相关的测试任务
三、测试计划
1 测试策略
测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等）和方法，以确定合理的测试方案使得测试更有效。
2 测试计划的标准格式(IEEE)
Test plan identifier （测试计划标识)
Instruction (引言）
Test Items （定义或主题词)
Features to be tested （需要被测试的特性)
Features not to be tested (无需被测试的特性)
Approach (方法和途径）
Items pass/ fail criteria （测试通过、失败的标准)
Suspension criteria and resumption requirements （暂停的标准和再启动的要求)
Test deliverables (测试交付的内容)
Testing Tasks (测试任务）
Environmental needs （必备的环境)
Responsibilities (职责)
Staffing and training needs (人员和必需的培训)
Schedule (时间进度表)
Risk and contingencies (风险和相关费用）
Approvals （批准)
四、测试用例
1 定义
满足特定目的的测试数据、测试代码、测试规程的集合
是发现软件缺陷的最小测试执行单
有特殊的书写标准和基本原则
2 生成的基本准测
代表性：能够代表并覆盖各种输入数据、操作和环境设置等
可判定性：测试结果的正确性是可判定的
可再现性：对同样的测试用例,系统的执行结果应当是相同的
3 设计步骤
为测试需求确定测试用例
为测试用例确定输入输出
编写测试用例
评审测试用例
跟踪测试用例
4 作用
避免盲目测试；
估算测试工作量；
减少回归测试的复杂程度；
方便书写软件测试缺陷报告；
实施不同级别的测试
5 测试数据和测试用例的区别
测试数据：被用来测试系统的输入数据（输入）
测试用例：被测试系统的输入和根据规格说明书预测的该系统的输出（输入&输出）
五、测试用例设计（黑盒）
1 什么是黑盒测试？
1.1 概念
黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
1.2 主要测试
1.不正确或遗漏的功能;
2.接口、界面错误；
3.性能错误；
4.数据结构或外部数据访问错误；
5.初始化或终止条件错误等等。
1.3 优缺点
优点：
（1）有针对性地寻找问题，并且定位问题更准确;
（2）黑盒测试可以证明产品是否达到用户要求的功能，符合用户的工作要求;
（3）黑盒测试与软件如何实现无关，如果实现发生变化，黑盒测试用例仍然可用（可重用性，面向回归测试）;
（4）测试用例开发可以与软件开发同时进行，可节省软件开发时间，通过软件的用例就可以设计出大部分黑盒测试用例;
（5）能重复执行相同的动作，测试工作中最枯燥的部分可交由机器完成。
缺点：
（1）需要充分了解待测试软件产品所用到的各项技术，测试人员需要具有较多经验。
（2）测试用例数量较大
（3）测试用例可能产生很多冗余
（4）功能性测试的覆盖范围不可能达到100%
（5）在测试过程中很多是手工测试操作。
（6）测试人员要负责大量文档、报表的编制和整理工作。
1.4 简单过程
黑盒测试的实施过程
（1）测试计划阶段
（2）测试设计阶段
依据程序需求规格说明书或用户手册，按照一定规范化的方法进行软件功能划分和设计测试用例。
（3）测试执行阶段
按照设计的测试用例执行测试;
自由测试(作为测试用例测试的补充)。
（4）测试总结阶段
2 测试用例设计（黑盒）
2.1 等价类划分法
2.1.1 划分等价类
等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
无效等价类：无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。 对于具体的问题，无效等价类至少应有一个，也可能有多个。（有效类比即可）
2）划分等价类的标准：
完备测试、避免冗余
划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合
2.1.2 常用条件：
1.输入条件规定了取值范围或值的个数：一个有效等价类和两个无效等价类
如：输入值是学生成绩，范围是0～100
2.输入条件规定了输入值的集合或者“必须如何”：一个有效等价类和一个无效等价类
如 查询条件=9， 一个等于9，一个不等9
3.输入条件是一个布尔量：一个有效等价类和一个无效等价类
如 Yes or no
4.规定输入数据的一组值且对每一个输入值分别处理：N个有效等价类和一个无效等价类
例 输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
5.规定输入数据必须遵守的规则：一个有效等价类和N个无效等价类(从不同角度违反规则)
6.已划分的等价类中各个元素在程序中处理方式不同：划分为更小的等价类
2.2 边界值分析法
使等价类的每个边界都要作为测试条件，是等价类划分法的一个补充
2.2.1 基于边界值分析方法选择测试用例的原则
1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。
2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。
3）将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
例如，某程序的规格说明要求计算出“每月保险金扣除额为0至1165.25元”，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。
再如一程序属于情报检索系统，要求每次”最少显示1条、最多显示4条情报摘要”，这时我们应考虑的测试用例包括1和4，还应包括0和5等。
5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
7）分析规格说明,找出其它可能的边界条件。
2.3 错误推测法
通过经验和直觉推测出程序的错误所在
2.4 判定表驱动分析法
列出所有的条件桩和动作桩；
确定规则的个数。假如有n个条件桩,就有2^n种规则；
填入条件项；
填入动作项。得到原始判定表；
根据原始判定表的规则,设计测试用例,要求覆盖所有原始判定表的规则；
化简。
2.5 因果图法
2.5.1 4种因果关系
因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
Ci表示原因(cause)，通常置于图的左部；ei表示结果(effect)，通常在图的右部。ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
2.5.2 约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
（1）互斥（E-exclude）
含义：如果选只能选1个，但可以不选
（2）唯一（O-Only）
含义：必须选，且只能选1个
唯一与互斥的区别：唯一是必须要选一个；互斥是可以不选，如果选只能选一个
（3）包含（I-include）
含义：至少要选1个（可以多选但不能不选）
（4）要求（R-required）
含义：如果a=1，则要求b必须是1，反之如果a=0时，b的值无所谓
（5）屏蔽关系（M-masked）
含义：当a=1时，要求b必须为0；而当a=0时，b的值不一定
分析软件规格说明描述中,哪些是原因、结果,并给每个原因和结果赋予一个标识符
找出原因与结果之间、原因与原因之间对应的关系,画出因果图
把因果图转换为判定表
把判定表的每一列作为依据,设计测试用例
2.6 场景法
设计场景:根据用例的主事件流和备选事件流的组合给出不同场景
设计测试用例标准覆盖场景
根据测试用例标准给出具体的测试数据
六、白盒测试
1 什么是白盒测试？
白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。
1.1 白盒测试基本要求
o保证一个模块中的所有独立路径至少被执行一次；
o对所有的逻辑值均需要测试真、假两个分支；
o在上下边界及可操作范围内运行所有循环；
o检查内部数据结构以确保其有效性。
1.2 测试覆盖标准
o应用白盒法时，手头必须有程序的规格说明以及程序清单。
o白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。
o最彻底的白盒法是覆盖程序中的每一条路径，但是由于程序中一般含有循环，所以路径的数目极大，要执行每一条路径是不可能的，只能希望覆盖的程度尽可能高些。
2 控制流测试
2.1 逻辑分支覆盖法
为了衡量测试的覆盖程度，需要建立一些标准，目前常用的一些覆盖标准从低到高分别是
2.1.1 语句覆盖
每一个可执行语句至少执行一次
2.1.2 判定（分支）覆盖
程序中每个判断的取真分支和取假分支至少经历一次
2.1.3 条件覆盖
程序中每个判断的每个条件的可能取值至少执行一次
2.1.4 判定-条件覆盖
判定中每个条件的所有可能(真/假)至少出现一次，并且每个判定本身的判定结果(真/假)也至少出现一次
2.1.5 条件组合覆盖
每个判断的所有可能的条件取值组合至少执行一次
2.2 路径法
2.2.1 路径覆盖
保证程序中每条可能的路径都至少执行一次
2.2.2 基本(独立)路径测试法
1、定义
从入口到出口的路径,至少经历一个从未走过的边,这样形成的路径叫独立路径
2、步骤
画程序框图
画控制流图
计算环复杂度
确定基本路径集
设计测试用例
3、基本路径数
基本路径数=环复杂度=区域数=边数量-节点数量+2=判断节点数量+1
2 数据流测试
使用路径(du-Path)定义：是PATHS(P) 中的路径，使得对某个v∈V，存在定义和使用节点DEF(v,m)和USE(v,n)，使得m和n是该路径的最初和最终节点
数据流测试的策略：遍历所有使用路径
3 变异测试
变异算子：用来模拟典型的用户输入错误（如运算符或变量名使用错误等）以及强制使某些表达式满足一定的条件（如使表达式的值为0）
变异测试是一种对测试集的充分性进行评估的技术，以创建更有效的的测试集，不同于路径测试和数据流测试，没有测试数据的选择规则。
’
七、单元测试
1 概述
1.1 定义
单元测试是对软件基本组成单元进行的测试
* “单元”：明确的功能、规格定义，与其他部分明确的接口定义。
* 结构化程序设计：函数或子过程；
* 面向对象：类或类的方法；
* 一个菜单、屏幕显示界面或对话框等。
* 单元测试也称模块测试，这是针对最小的可测试软件元素-模块进行测试工作。
* 单元测试的依据是详细设计描述。
* 单元测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。
* 通常，我们使用白盒测试方法测试单元的内部结构，使用黑盒测试方法测试单元的功能和可观测的行为。
1.2 时机
一般在代码完成后由开发人员完成,QA人员辅助
1.3 单元的概念
有明确的功能、性能定义、接口定义的软件设计最小单位——模块
1.4 测试环境
模块不是独立的程序的时候，需要辅助测试模块：
* 驱动模块（Driver）：所测模块的主程序：它接收测试数据，把这些数据传递给所测试模块，最后再输出实测结果。当被测试模块能完成一定功能时，也可以不要驱动模块。
* 桩模块（Stub）：用来代替所测模块调用的子模块。
2 单元测试内容
局部数据结构、模块接口、出错处理、独立路径、边界条件
3 单元测试作用
在集成测试前保证最小代码单元的质量
4 单元测试策略
4.1 黑盒测试
等价类划分、边界值分析
4.2 动态白盒测试
逻辑覆盖、路径覆盖
4.3 静态白盒测试
在代码执行前仔细和方法性地检查软件设计、架构、代码
注意区分和动态白盒测试的区别：
动态白盒测试包括（逻辑覆盖、路径覆盖），静态白盒测试包括在代码执行前仔细检查软件
注意是通过检查和评审的方法！
* 静态测试可以手工进行，也可以借助软件工具自动进行
4.3.1 为什么需要静态测试？
* 静态测试的成效：最多能够识别软件所有缺陷中50-60%的缺陷
* 动态测试的成效：最多能够识别软件所有缺陷中40-50%的缺陷
* 识别缺陷的成本
* 需求阶段识别一个重要缺陷平均花费2-3小时；
* 设计阶段识别一个重要缺陷平均花费3-4小时；
* 代码评审阶段识别一个重要缺陷3-5小时；
* 动态测试识别一个重要缺陷平均花费15-25小时
4.3.1 非正式代码审查
同级审查：程序员和测试人员组成的非正式小组扮演审查者角色
走查：代码作者向程序员和测试人员组成的小组展示每一行代码的作用，审查者倾听，询问问题。
（代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的）
4.3.2 正式代码审查
一对一，严格审查，有文档，有规范
代码演示者不是代码的作者
其他参与者是检察员
有一个主持人确保规则遵循和会议顺利进行
会后要形成审查报告
4.4 极限编程(XP开发)之测试驱动开发(TDD)
先编写测试代码，再进行开发
先编写产品的框架，是指先编写类、方法空的实现
编译通过然后编写测试类，针对产品类的功能编写测试用例
然后编写产品类的代码，每写一个功能点都运行测试，随时补充测试用例
编写的测试代码以后需要修改的可能性比较小
5 代码审查清单
逻辑错误
计算错误
比较错误
控制流错误
子程序的参数错误
输入/输出错误
其他检查：如是否适合其他操作系统平台、是否国际化
6 单元测试的过程和文档管理
在详细设计阶段完成单元测试计划。—《单元测试计划》
建立单元测试环境,完成测试设计和开发。—《单元测试用例》
执行单元测试用例,并且详细记录测试结果。—《缺陷跟踪报告》
判定测试用例是否通过。
提交《单元测试报告》
7 单元测试工具
JUnit
Parasoft Jtest
Parasoft C++ Test
八、集成测试
1 集成的概念
把小的单元模块拼接、组合起来
2 集成测试的概念
将单元组装起来再进行测试，以检查这些单元之间的接口是否存在问题。如：数据丢失、模块间相互影响、组合后不能实现主功能等
2.1 集成测试划分为三个级别：
（1）模块内集成测试。
（2）子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
（3）子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。
3 集成测试的方法
* 静态测试技术——针对概要设计的测试
* 动态测试技术——灰盒测试
3.1 集成测试分为增量式和非增量式
非增量式：对所有模块进行个别的单元测试后，按照程序结构图将各模块连接起来，把连接后的程序当作一个整体进行测试。优点：
* ①方法简单
缺点
* ②允许多测试人员同时并行工作，人力物力资源利用率较高
* ①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高
* ②一旦集成后包含多种错误，难以纠正。
增量式：逐次将未曾集成测试的模块和已经集成测试的模块（或子系统）结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。
增量式集成测试又可以分为三种不同的方法：
（1）自顶向下增量式测试
（2）自底向上增量式测试
（3）三明治增量式测试（混合增量式测试）
* 优点：
* 较早地验证了主要控制和判断点；
* 按深度优先可以首先实现和验证一个完整的软件功能；
* 功能较早证实，带来信心；
* 只需一个驱动，减少驱动器开发的费用；
* 支持故障隔离。
* 缺点：
* 桩的开发量大；
* 底层验证被推迟；
* 底层组件测试不充分。
4 集成测试的目的
保证系统设计的完整性
保证组件之间适当的交互
运行简单的系统级别的测试
5 集成测试考虑以下问题
1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢
2.各个子功能组合起来，能否达到预期要求的父功能；
3.一个模块的功能是否会对另一个模块的功能产生不利的影响；
4.全局数据结构是否有问题
5.单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
6 软件集成测试前的准备
人员安排、测试计划、测试内容、集成策略、测试方法
7 增量式集成测试的策略
7.1 Top-down
7.1.1 定义
跟随自顶向下开发流程，从顶级模块开始，对低一级的模块编写桩模块
7.1.2 桩模块
用以模拟被测模块工作过程中的所调用的模块。桩模块由被测模块调用
7.1.3 优点
早期验证主要功能;
总是有一个顶层系统;
模块可以按照接口规范编写
7.1.4 缺点
性能问题延迟出现，桩模块编写成本高
7.1.5 适用范围
* 产品控制结构比较清晰和稳定；
* 高层接口变化较小；
* 底层接口未定义或经常可能被修改；
* 产口控制组件具有较大的技术风险，需要尽早被验证；
* 希望尽早能看到产品的系统功能行为。
7.2 Bottom-up
7.2.1 定义
从底层模块开始,对上一级的模块编写驱动模块
7.2.2 驱动模块
用以模拟被测模块的上级模块。启动被测模块,并打印出相应的结果
7.2.3 优点
原子函数得到更多测试，底层模块错误发现早，成本低
7.2.4 缺点
完整的系统到后期才能完全呈现出来，设计的错误很晚才会被发现
7.2.5 适用范围
* 适应于底层接口比较稳定；
* 高层接口变化比较频繁；
* 底层组件较早被完成。
7.3 混合策略（sandwich）
对软件结构中较上层使用自顶向下，较下层使用自底向上
* 优点：
* 集合了自顶向下和自底向上两种策略的优点
* 缺点：
* 中间层测试不充分
* 适用范围：
* 适应于大部分软件开发项目
7.5 Critical-First
优先集成最重要的组件，其他部分后期慢慢加上。优点：保证最重要的组件优先运行
九、系统测试
1 目的
获得一个作为整体的系统的完整性的信心
2 功能测试
2.1 概念
在集成测试结束之后，依据系统的需求规格说明书和产品功能说明书对系统的整体功能进行的全面测试，称为功能测试
2.2 目的和内容
程序安装、启动正常，有相应的提示框、错误提示等
系统的界面清晰、美观
菜单、按钮操作正常、灵活，能处理一些异常操作
能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等
数据的输出结果准确，格式清晰，可以保存和读取
功能逻辑清楚，符合使用者习惯
系统的各种状态按照业务流程而变化，并保持稳定
能配合多种硬件周边设备
软件升级后，能继续支持旧版本的数据与外部应用系统的接口有效
2.3 工具
QTP
2.4 回归测试
2.4.1 定义
对修正缺陷后的软件进行再次的测试，不仅测试被修复的软件缺陷是否已经解决，还要测试软件旧有的功能与非功能是否满足要求。
2.4.2 目的
2.4.3 方法
再测试全部用例
基于风险选择测试：测试关键的、重要的、可疑的，跳过非关键的、稳定的
基于操作剖面选择测试
再测试修改部分
2.5 冒烟测试
2.5.1 定义
每日Build建立后,对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率
2.5.2 目的
先通过最基本的测试,如果最基本的测试都有问题,就直接打回开发部了,减少测试部门时间的浪费
3 非功能测试
3.1 常用名词解释
响应时间
并发
3.2 分类
3.2.1 压力测试
1、定义
在一种需要反常数量、频率或资源的方式下，执行可重复的负载测试或强度测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。
2、压力估算
给出合理的压力估算值（结合峰值），给压力测试提供数据依据
根据峰值结合TPCC、TPCE、TPCH等指标，结合服务器的性能给出系统的硬件配置估算、给出硬件配置建议
3、稳定性压力测试（可靠性压力测试）
以合理的估算压力连续运行被测系统,检查系统运行时的稳定程度
采用7*24的方式让系统不间断运行
为了给出系统一个实际使用的指标和范围、使用边界条件
4、破坏性压力测试
持续不断地给被测系统增加压力，直到将被测系统压垮为止（让问题和薄弱环节快速暴露出来，找出瓶颈）。用来测试系统所能承受的最大压力。
采用破坏的手段，目的是为了找到系统的瓶颈
5、注意事项
问题的分析：日志文件、进程监控、查看运行参数、分解问题 累积效应：不要重启、不要归零、考虑累积情况
3.2.2 容量测试
通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下还能保持主要功能正常运行
还将确定测试对象在给定时间内能够持续处理的最大负载或工作量
通过压力测试的稳定性测试,可以得到容量值
3.2.3 性能测试
1、相关性能指标
客户端指标：
响应时间、并发数
服务器端指标：
processor time：服务器CPU占用率。一般平均达到70%
memory available Mbyte：
throughput(吞吐量)：
physics disk time：物理磁盘读写时间情况
2、性能测试定义
通过测试确定系统运行期间的性能表现与性能数据，得到如：CPU使用效率、运行速度、响应时间、占用系统资源等方面的系统数据，给出合理的系统配置
3、作用
确定在什么样的压力下系统达到最佳状态（稳定性压力测试），什么压力是系统的极限（破坏性压力测试）
根据性能指标确定实际的软硬件运行环境：如配置合理的CPU数、CPU的处理能力、内存量等等
4、目的
通过性能测试找出系统的性能瓶颈,解决问题，提升性能，并且给出性能指标数据，给出合理的环境 配置。最大限度满足用户需求，提升产品质量
5、性能合理的范围
服务器CPU的占有率:一般在85%以内
内存占有率:80%以内
6、工具:loadrunner、QALoad
3.2.4、安全测试
检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。
理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值，测试非法侵入者已无利可图。
3.2.5、容错测试
检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段
3.3 性能测试与瓶颈分析关键步骤
步骤一:性能测试与数据收集
步骤二:性能瓶颈分析
步骤三:性能调优解决方案
4 验收测试
4.1 定义
在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
4.2 过程和主要内容
4.2.1 前提
系统或软件产品已通过了系统测试的软件系统
4.2.2 测试内容
验证系统是否达到了用户需求规格说明书（可能包括项目或产品验收准则）中的要求，测试试图尽可能地发现软件中存留的缺陷，从而为软件进一步改善提供帮助，并保证系统或软件产品最终被用户接受
还需进行易用性测试、兼容性测试、安装测试、文档（如用户手册、操作手册等）测试等几个方面的内容
4.3 标准和注意事项
4.3.1 完成标准
完全执行了验收测试计划中的每个测试用例
在验收测试中发现的错误已经得到修改并且通过了测试或者经过评估留待下一版本中修改
完成软件验收测试报告
4.3.2 注意事项
必须编写正式的、单独的验收测试报告
验收测试必须在实际用户运行环境中进行
由用户和测试部门共同执行。如公司自开发产品，应由测试人员，产品设计部门，市场部门等共同进行
4.4 其他方法
4.4.1 α测试
α测试是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正
4.4.2 β测试
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善
4.5 用户界面和易用性测试
用户界面七要素:
符合标准和规范;
直观性;
一致性;
灵活性;
舒适性;
正确性;
实用性
易用性测试没有具体量化的指标,主观性较强
4.6 兼容性测试
4.6.1 定义
软件兼容性测试是指验证软件之间是否正确地交互和共享信息
4.6.2 包括
硬件兼容
软件之间兼容
数据之间兼容
4.6.3 向前和向后兼容
向后兼容是指可以使用软件的以前版本向前兼容指的是可以使用软件的未来版本
4.7 可安装性和可恢复性测试
系统软件安装
应用软件安装
服务器的安装
客户端的安装
产品升级安装
4.8 文档测试
软件文档已成为软件的一个重要组成部分,而且种类繁多,对文档的测试也变得必不可少
5 LoadRunner
1、Virtual User Generator
创建脚本
创建脚本,选择协议
录制脚本
编辑脚本
检查修改脚本是否有误
2、中央控制器(Controller)来调度虚拟用户
创建Scenario(一个测试用例),选择脚本
入股模拟多级测试,设置IP Spoofer
3、运行脚本
分析Scenario
4、分析测试结果
十、 软件测试环境
1 软件测试环境的作用
软件测试环境是软件测试实施的一个重要阶段，软件测试环境适合与否会严重影响测试结果的真实性和正确性。同时减少环境的变动对测试工作的不利影响
2 测试环境的要素
配置测试环境应该满足五个基本要素是：硬件、软件、网络环境、数据准备、测试工具。
3 测试环境的管理与维护
* 设置专门的测试环境管理员的角色
*明确测试环境管理所需的各种文档
*测试环境访问权限的管理
*测试环境的变更管理
十一、软件缺陷与测试报告
1 缺陷描述
软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分
缺陷：
o软件缺陷（Defect），常常又被叫做Bug。
o所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
1.1 报告缺陷
原则：
*尽快报告软件缺陷
*有效描述软件缺陷
短小
单一
明显和通用
再现软件缺陷
在报告软件缺陷时不做任何评价
补充的完善软件缺陷报告
1.2 如何有效描述缺陷-一个完整的实例
概要+再现步骤+隔离
概要：
Arial、Wingdings、Symbol字体会破坏新文件。
再现步骤：
1、启动编辑器，然后创建新文件
2、输入四行文本，重复输入“the quick for jumps over the lazy brown dog”
3、选中四行文本，然后选择下拉菜单，并选择Arial。
4、所有文件读被转换为控制字符、数字和其他明显的随机二进制数据。
5、重复三次，结果都一样。
隔离：
新建1.1.018；同样的测试用例在从1.1.007到1.1.017上都通过。对Wingdings和Symbol字体重复相同的步骤。
粗略估计是格式问题，保存文件，关闭编辑器并重新打开文件，但是数据仍然被破坏。
在改变字体前保存文件防止错误。对现存文件，错误不再发生。
只在Windows XP下发生，而不出现在Solaris，Mac或其他Windows系统
2 缺陷属性
缺陷标识;
缺陷类型;
缺陷严重程度;
缺陷优先级;
缺陷产生可能性;
缺陷状态;
缺陷起源;
缺陷来源;
缺陷原因
2.1 缺陷度量
2.1.1缺陷度量-缺陷消除率(DRE)
2.1.2缺陷度量-缺陷损耗
2.1.3缺陷度量-缺陷密度
Pareto分析
•以这种方式来进行更进一步的分析：以发生频率的降序形式（如功能性、可使用性等）来显示引发缺陷的原因。
3 缺陷生命周期
o主要状态有：
oOpen/New、Assigned、In Progress、Resloved、Rejected、Reopen、Tested/Closed
oBug状态走向：
oOpen - Closed
oOpen - Rejected - Closed
oOpen - Assigned - In Progress - Resolved - Closed
oOpen - Assigned - In Progress - Resolved - Reopen … Closed
oOpen - Assigned - Rejected - Closed
4 软件缺陷跟踪系统
主要包含缺陷管理功能和统计功能
常见免费缺陷管理工具：Mantis,Bugzilla
付费缺陷管理工具：Testdirector,JIRA
5 测试报告与缺陷报告的区别
缺陷报告：描述清楚缺陷，是测试过程的结果
测试报告：是分析与总结，是阶段性的总结
二者关系：缺陷报告为测试报告提供数据与依据，测试报告是缺陷报告的总结
十三、配置管理与软件维护
1 配置管理
1.1 定义
软件配置管理，是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性
配置管理是对工作成果的一种有效保护
1.2 配置项
1.2.1 定义
软件配置管理的对象是软件配置项，它们是在软件工程过程中产生的信息项
SCM从应用层次上可以从低到高分为三级：
版本控制
以开发者为中心
过程驱动
1.2.2 包括
与合同、过程、计划和产品有关的文档和数据
源代码、目标代码和可执行代码
相关产品，包括软件工具、库内的可利用软件、外购软件及用户提供的软件
1.2.3 命名/编号
软件的每个组件/部件的标识必须唯一，以便于用该标识符来跟踪和报告软件配置项的状态
1.3 基线
–基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。
–基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。
–通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
1.3 版本
1.3.1 定义
版本是某一配置项的已标识了的实例
也可以说，不可变的源对象经质量检查合格后所形成的新的相对稳定的格局（配置）称为软件版本
通常软件对象的版本组呈树形结构
1.3.2 版本控制
版本控制就是管理在整个软件生存周期中建立起来的某一配置项的不同版本
1.3.3 版本管理
要求：
能够根据用户的不同需求，提供不同的版本的软件配置项以配置不同的系统
保存软件配置项的老版本，以便能够对以后出现的问题作调查
能够根据各种版本的软件配置来配置生成开发项目版本的一个新版本
能够支持多个软件开发人员同时对一个软件配置项进行操作与处理
将各软件配置项的各种版本进行高效存储
1.4 配置控制组/委员会
配置控制组/委员会是指一组负责评估和审批配置项变更的人员，以确保所有的变更都是经过审核的
1.5 变更管理
变更管理是软件配置管理的一个要素，由评估、协调、批准或不批准以及对正式构造配置标识的配置 项实施变更等活动组成。
变更管理更多的是指变更的管理流程、人员按照一定的流程和制度去执行变更的过程控制
1.6 配置管理过程
制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等
配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置 库。配置管理员定期维护配置库，例如清除垃圾文件、备份配置库等
版本控制
版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可 以快速准确地查找到配置项的任何版本
变更控制
在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意 修改而导致混乱
配置审核
为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期 审核配置管理工作
1.7 相关培训
管理员培训
开发人员培训
管理流程培训
1.8 常用工具
SVN
GIT
2 软件维护
2.1 定义
软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程
2.2 原因
改正程序中的错误和缺陷
改进设计以适应新的软、硬件环境
增加新的应用范围
2.3 类型
改正性维护
在软件交付使用后，因开发阶段的问题以及测试得不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。为了识别和纠正软件错误、改正软件功能、非功能（性能）上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护
适应性维护
在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方 式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护
完善性维护
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性
预防性维护
预防性维护即软件再工程，是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护
2.4 各种维护类型和维护工作量的比例
改正性维护：17-21%
适应性维护：18-25%
完善性维护：50-66%
其他维护：4%
2.5 结构化维护VS非结构化维护
如果采用软件工程的方法进行软件开发，保证每阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护
如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，称为非结构化的维护
2.6 影响软件维护工作量的因素
系统的大小
程序设计语言
系统年龄
数据库技术的应用
先进的软件开发技术
其他一些因素
2.7 软件维护的过程
维护申请
维护修改报告
维护记录保存
维护后评审
维护后测试
维护后验收
2.7.1 维护阶段的工作事件流
2.8 可维护性
为了使得软件能够易于维护，必须考虑使软件具有可维护性
2.8.1 定义
•软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。
2.8.2 衡量的七个特性
可理解性 可使用性
可测试性 可移植性
可修改性 效率
可靠性
2.8.3 在各类维护中的侧重点
2.8.2 衡量特性
可理解性
可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度
可靠性
可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率
可测试性
可测试性表明论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。而且设计合用的测 试用例，取决于对程序的全面理解。一个可测试的程序应当是可理解的，可靠的，简单的
可修改性
可修改性表明程序容易修改的程度。一个可修改的程序应当是可理解的、通用的、灵活的、简单的
可移植性
可移植性表明程序转移到一个新的计算机环境的可能性的大小。它表明程序可以容易地、有效地在各种各样的计算机环境中运行的容易程度
效率
效率表明一个程序能执行预定功能而又不浪费机器资源的程度。这些机器资源包括内存容量、外存容量、通道容量和执行时间
可使用性
从用户观点出发，可使用性定义为程序方便、实用、及易于使用的程度
2.9 文档管理
维护合同
维护方案
维护手册
维护申请表
维护记录
维护报告
