1.软件定义

1.1什么是软件？

软件：是计算机系统中与硬件相互依存的一部分（程序+数据+相关文档）。

1.2软件的分类

• 按照功能划分:

        系统软件:  能够直接操作底层的硬件、并为上层软件提供支持的软件，如操作系统软件、各种硬件驱动程序等

        应用软件: 能够为用户提供某种特定条件的应用服务的软件，如金山词霸

• 按照技术架构划分:

        单机软件：直接在单个计算机上安装并运行的软件，如画图工具

        C/S 结构软件：C指的是客户端（Client）,S指的是服务器端（SERVER），这种软件是基于局域网或互联网的，需要有一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。不便于升级和维护（升级时需要重新安装每一个客户端）

        B/S 结构软件：B是指浏览器（Browser）,S指的是服务器端（SERVER）.这种软件是基于局域网或互联网的,不需要安装客户端，只需要有浏览器即可，便于升级和维护（升级时只需要升级服务器即可）

2.软件测试的定义

2.1软件缺陷

2.1.1什么是软件缺陷

软件缺陷也叫作bug。测试人员进行测试工作就是需要发现软件中的缺陷bug。不满足以下几个方面就是软件缺陷：

1. 软件未达到客户需求的功能和性能
2. 软件超出了客户需求的范围（画蛇添足）
3. 软件出现客户需求不能容忍的错误
4. 软件的使用未能符合客户的习惯和工作环境

2.1.2缺陷的处理过程

1）测试人员发现缺陷，缺陷状态设置为new

2) 开发经理验证缺陷：

        情况1：验证通过，开发经理会将缺陷指派给相应的开发人员来负责修改缺陷，并将缺陷状态设置为：open（打开的缺陷，开发方承认的缺陷）。

         情况2：如果验证没有通过，开发经理会拒绝该缺陷，并将缺陷状态设置为：rejected (被拒绝的缺陷，开发组不承认的缺陷)

3)开发人员修改指派给自己的缺陷，并将缺陷状态设置为：fixed（修改的缺陷，待返测的缺陷）  

4）测试人员对修改的缺陷进行返测：  

        情况1：返测成功，将缺陷状态设置为：closed（关闭、结束、可归档的缺陷）  

        情况2：返测失败，将缺陷状态设置为：reopen（重新打开的缺陷），开发人员会再次修改缺陷，直到缺陷通过返测被关闭时为止。    

2.1.3缺陷的严重程度

缺陷的严重程度(severity):表明这个缺陷有多糟糕，对程序有多大的影响。

分成5个级别：   1) urgent:造成死机，系统崩溃等最致命的缺陷   2) very high:非常严重的缺陷   3) high:严重的缺陷   4) Medium:中等程度的缺陷   5) Low:小问题 

缺陷的优先级(priority):希望程序员在什么时候在什么版本中解决这个缺陷。

2.1.4缺陷的优先级

优先级分成5个级别：   1) urgent:开发人员放下手头工作，立即解决的缺陷   2) very high:在本版本中解决的缺陷   3) high:在下一版本中解决的缺陷   4) Medium:在软件发布前将解决的缺陷   5) Low:尽量在软件发布前将缺陷解决（有可能在发布的软件产品中带有未解决的缺陷）

缺陷的集群效应： 一个搜索模块出问题，凡是调用该模块都出现问题，测试上不能写多个跟该模块相关的页面错误（黑盒测试没问题，白盒测试得清楚调用代码逻辑思维）

2.2什么是软件测试？

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程

软件测试的日常基本工作过程：

1、编写《测试用例》（目的，步骤，预期结果等）

2、执行测试（实际结果）

3、发现缺陷，填写缺陷报告

4、提交给开发方

因此软件测试最重要的技能是编写测试用例，要学会如何编写测试用例。 

2.3软件测试的目的

就是尽可能多的发现软件缺陷。

bug是测试过程中的产品而非目标。检查系统是否满足要求，站在用户角度思考产品或项目功能实现的正确性。 测试目的不仅仅为了找出错误，通过分析错误产生的原因和错误的分布特征，帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。

3.软件测试的分类

3.1从软件开发角度分：

• 单元测试：按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同，比如有具体到模块的测试，也有具体到类，函数的测试等。
• 集成测试：在单元模块的基础上，通过单元模块整合成系统，其主要目的是检查各模块之间的接口是否正确。
• 系统测试：把软件系统搭建起来，按照软件规格说明书中的要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。
• 验收测试：又分为阿法测试和贝塔测试。阿法测试是测试人员，开发人员等公司内部人员会根据前边所提到的需求，以及规格说明书来做相应测试，对软件进行完整的内测，以确定软件达到预期的效果。β测试是客户自己对软件进行公测。

3.2从软件结构和算法角度分：

• 黑盒测试：黑盒测试又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该类测试注重于测试软件的功能性需求。不用关注代码的底层实现，只需要对照规格说明书，来查看需要的功能是否已经实现。
• 白盒测试：白盒测试不同与黑盒测试，测试人员必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。
• 灰盒测试：介于黑盒测试和白盒测试之间，灰盒测试关注输入输出数据的正确性，又关注底层的实现逻辑，但又不像白盒测试那样详细完整，只是通过表象来简单判断它的运行状态。

3.3从软件的测试面分：

功能测试，性能测试（时间性能，空间性能）

3.4从软件测试化程度分：

手工测试，自动化测试

3.5软件的测试周期分：

• 冒烟测试：冒烟测试是指对提交测试的软件在进行详细深入的测试之前而进行的预测试，这种预测试的主要目的是暴露导致软件需重新发布的基本功能失效等严重问题，检验软件是否具备可测性。
• 回归测试：软法bug后，通知软件开发人员修改，将这个问题修改完成于下一个测试版本内。 软件测试工程师取得新的测试版本后，必须用同一个用例来测试这问题，确保该问题已经被修改完成。这就是回归测试。
• 随机测试：所有输入的数据是随机产生的，目的是模拟用户的真实操作，发现边缘性错误。
• 安全测试：从开发过程完成到发布阶段，对产品进行检验，验证产品符合安全需求的定义。

4.软件测试的原则

◎所有测试的标准都是建立在用户需求之上

◎软件测试必须基于”质量第一”的思想区开展各项工作，当时间和质量冲突时，时间要服从质量。

◎事先定义好产品质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。

◎软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始测试。

◎穷举测试是不可能的。

◎软件测试计划是做好软件测试工作的前提。

◎测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法区设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。

◎ 对发现错误较多的程序段，应进行更深入的测试，一般来说，一段程序中已发现的错误数越多，其中存在的错误率越大。

◎ 重视文档，妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）

◎ 应当把“尽早和不断的测试”作为测试人员的座右铭

◎ 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见

◎ 测试应从“小规模”开始，逐步向”大规模”转变

◎ 不可将测试用例置之度外

◎ 必须彻底检查每一个测试结果

◎ 一定要注意测试中错误的集中出现，这和程序猿的编程水平以及习惯息息相关

◎ 对测试错误结果一定要有一个确认的过程

5.测试用例

5.1测试用例定义

简单地说，测试用例就是： 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。

5.2测试用例模板以及包含内容

用例编号： 测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。

命名规则:TestCase+项目名+模块名+接口名

测试项：描述被测试的详细特性，代码模块等

测试步骤：测试步骤是指如何执行用例，先做什么后做什么，是有顺序的概念在的。步骤和用例的目标需要是一致的，任意一个偏离目标整个case就是无意义的。

依赖性：如果一个测试用例依赖于其他用例。或者受其他用例的影响，就应该在此注明，所列的特性更加具体。还要指出引用的产品说明书或者测试用例所依据的其他设计文档。

输入数据：该说明列举执行测试用例的所有输入内容或者条件

预期结果：描述进行测试用例预期的结果

测试结果：通过/不通过  

5.3设计测试用例

5.3.1测试用例编写注意事项

 不要设计“穷举测试用例”

◉ 在详细测试用例与有效测试时间找到平衡点

◉ 好的测试用例应该多关注“反向测试问题”

◉ 测试用例库应该不断更新和维护

◉ 测试用例可以复用，但要注意数据有效性和环境变化

◉ 测试用例是设计出来的，不是写出来

◉ 多去学习经验丰富的测试工程师所设计的测试用例

◉ 针对不用的需求类型和测试对象，灵活采用不同的测试用例设计方法

5.3.2黑盒测试用例设计方法

◉ 等价类划分法

原理:

 把程序的输入域划分为若干部分，然后从每个部分中选取少数代表性数据作为测试用例。

 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误

反之，如果某一类中的一个例子没有发现错误，这一类中的其他例子也不会查出错误

确定等价类的原则：

在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类

在输入条件规定了输入值的集合或者规定了”必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类

在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类

在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类

在规定了输入数据必须遵循的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类(从不同角度违反规则)  

 在划分的等价类中，各元素在程序处理中的方式不同的情况下，则应在该等价类基础上进一步划分为更小的等价类 

◉ 边界值分析法

原理：

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试的输入数据

如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据

分析规格说明，找出其他可能的边界条件

边界值的选择原则：

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据 

如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的数作为测试数据

 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例 

◉ 因果图法

原理：

因果图法是一种适合于描述对于多种输入条件组合的测试方法

 根据输入条件的组合，约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法 

它适用于检查程序输入条件设计的各种组合情况

因果图使用方法：

第一步：根据功能说明书中规定的原因和结果之间的关系画出因果图

 

第二步：根据功能说明在因果图中加上约束条件 其中互斥，包含，唯一，要求是对原因的约束，屏蔽是对结果的约束。

含义如下：

互斥(exclusion)：表示不同时为1，即a,b,c中至多只有一个1

包含(include)：表示至少有一个1，即a,b,c中不同时为0

唯一(only)：表示a,b,c中有且仅有一个1

要求(request): 表示若a = 1,则b必须为1，即不可能a=1且b=0

屏蔽(mask)：表示若a=1,则b必须为0 

◉ 判定法

是分析和表达多逻辑条件下执行不同操作的情况的工具，它由以下几个内容组成：     ※条件桩:    列出了问题的所有条件，通常认为列出的条件的次序无关紧要。     ※动作桩： 列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。      ※条件项：列出针对它左列条件的取值，在所有可能情况下的真假值。      ※动作项:列出在条件项的各种取值情况下应该采取的动作。

◉ 场景法

原理：

现在的软件几乎都是用事件触发控制流程的。测试时，可以生动地描绘出时间触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。 备选流：除了基本流之外的各支流，包含多种不同的情况。

 

◉用例方法综合选择 

首先进行等价类划分法

在任何情况下都必须使用边界值分析法

如果程序的功能说明中含有输入条件的组合情况，则一开始就可选择因果图法和判定表驱动法。 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例