软件测试基础

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

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

◉ 判定法

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

◉ 场景法

原理：

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