软件测试概述--基础篇

文章目录

软件测试概述
- 软件测试基本概念
- 软件测试的目的和原则
- 软件测试的分类
- 测试用例

软件测试概述

软件测试基本概念

软件缺陷：俗话说就是bug。即计算机软件或程序存在某种破坏正确运行能力的问题、错误或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需求

软件缺陷出现的原因

产品说明书：说明书不够全面、经常修改，或者整个小组没有很好的沟通
设计：设计经常变更，沟通不足
编码：软件的复杂性、文档不足、进度压力可能都会使程序员犯错

软件测试的定义
概括来说呢就是为了发现错误而执行程序的过程；或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构，而精心设计的一批测试用例，并利用这些测试用例去执行程序，以发现程序错误的过程

软件测试的目的和原则

目的
就是要发现软件中存在的缺陷和系统的不足，提供预防或减少可能错误的信息，在过程中尽可能检测错误以防止该错误传递到下一阶段。

原则

不可能进行完全测试
测试中有风险存在
软件测试只能表明缺陷的存在不能证明产品已经没有缺陷
软件产品中所存在的缺陷与已发现的缺陷成正比
要避免软件测试的杀虫剂现象
及早的和不断的进行软件测试
进行回归测试
软件测试应该有计划、有组织的进行

软件测试的分类

按测试阶段划分

单元测试
自己的理解就是测试代码的，程序员也可以自行完成。单元测试是对软件设计中最小单位–程序模块进行的测试，它着重检查程序单元是否符合软件详情设计规约中对模块功能、性能、接口和设计约束等方面的要求，发现各模块内部肯呢个存在的错误。
集成测试
俗话说就是模块与模块间组合起来测试。集成测试是在单元测试的基础上，将已经通过单元测试的各模块有序的、递增的进行测试，它着重发现各模块接口之间的关系和相互协作中是否存在错误。在很多情况下，通过单元测试的模块集成到系统中往往还存在问题，就是由于它没有正确的与其他模块协作，或者出现了接口错误。集成测试依据的是软件概要设计规约
确认测试
确认测试是通过检验和提供客观的证据，验证软件是否满足特定预期用途的需求。它依据软件需求规格说明书，包括用户对软件的功能，性能和某些特定的要求。如果说前两种测试主要是验证软件是都在“正确的做事”，那么确认测试就是验证软件是否在“做正确的事”。
系统测试
系统测试是将通过已确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件，外设，网络和系统软件，其他支持软件，数据和人员等其他系统元素结合在一起，在实际的运行环境下，检测其是否能够进行正确的配置、连接，以满足用户的需求。系统测试一般依据系统需求规格说明书
验收测试
验收测试是指按项目说明书、合同、软件供需双方约定的验收依据文档等进行的完整一个系统的测试和评审，决定是都接收或拒绝接收系统。

按是否需要执行被测软件划分

静态测试
对于源代码：主要测试代码是否符合相应的标准和规范。
对于程序界面：主要测试软件的实际界面与需求中的说明是否相符。
对于文档：主要测试用户手册和需求说明是否符合用户的实际需求。
动态测试
指的是实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

按是否需要查看代码划分

白盒测试
软件的白盒测试是对软件的过程性细节做细致的检查。
这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。
因此白盒测试又称为结构测试或逻辑驱动测试。
黑盒测试
软件的黑盒测试意味着测试要在软件的接口处进行。
这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
因此黑盒测试又叫功能测试或数据驱动测试。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的。
可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了。
这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

按测试执行时是否需要人工干预划分

手工测试
手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。
自动测试
自动化测试适用于模块已经稳定，没有很大更改的大型项目，用于将手工测试转化成自动化代码，从而实现压力测试、回归测试等。

测试用例

测试用例设计
等价类划分法：
适用场景：
有数据输入的地方，就可以使用等价类划分法。如：输入框

测试思想：
从大量数据中划分范围（等价类），然后从每个范围中挑选代表数据，这些代表数据要能反应这个范围内数据的测试结果。

概念：
有效等价类：对程序来说，有意义的、合理的数据（正确的、有效的数据）
无效等价类：对程序来说，没有意义、不合理的数据（错误的、无效的数据）

边界值：
适用场景：
有数据输入的地方，在实际工作中，一般和等价类划分一起适用。、

测试思想：
边界值是程序员在编程时是最容易出错的位置，所以要测试边界。

概念：
是有效等价类和无效等价类之间的分界点，叫边界值（最小值，最大值）。还要测试次边界，也就是边界值两边的数据。

因果图/判定表：
适用场景：
在一个界面中有多个控件，如果控件之间存在组合关系或者限制关系，不同的控件组合会产生不同的输出结果，为了弄清楚不同的输入组合会产生怎样的输出结果，可以使用因果图或判定表。

概念：
因：输入条件
果：输出结果
就是通过画图的方式表达输入条件和输出结果之间的关系

正交排列法
适用场合：
在一个界面中有多个控件，每个控件有多个取值，要考虑不同控件不同取值之间的组合，且组合数量较大的话，我们就可以使用正交排列法。

思想：
使用最少的抽样数据达到最广的，覆盖率最高的统计结果。

正交表公式如下：
L：line 行
n：表示正交表有几行，需要测试的组合的个数
n值是固定的，一旦正交表确定n值就是固定的，不需要测试人员自己计算。
m：表示正交表中允许出现的最大值
根据每个控件的取值个数来确定m值
k：表示正交表有几列
根据组合的控件个数进行确定，选择合适的正交表

场景法：
适用场景：
业务比较复杂的软件系统都适合使用场景法，场景法是基于软件业务的测试方法，测试人员把自己当成最终用户，尽可能真实的模拟用户在使用此软件的操作情形：

重点模拟两类操作：
用户正确操作的业务过程—验证软件的业务功能是否正确实现
模拟用户错误操作的情形—验证软件的异常处理能力（健壮性）

测试思路：
场景法是模拟用户操作软件时的各种情景，主要用于测试软件的业务逻辑和流程。当拿到一个测试任务是，我们并不先关注某个文本框的等价类等是否满足要求，而是先关注它的主要功能和业务流程是否正确实现，这就需要场景法来完成测试。当业务流程测试没有问题，也就是软件的主要功能没有问题时，我们再去关注控件的等价类、边界值等细节测试。（先整体后细节）

场景划分：
1）基本流（有效流、正确流）
模拟用户正确的业务操作流程就是基本流
2）备选流（无效流、错误流）
模拟用户错误的操作流程就是备选流