软件测试(学习笔记)

1.软件测试与质量概述

软件测试

1.软件测试的根本目的是为了保证被测试软件系统符合用户需求，或者为了校验被测试软件系统的实际输出是否与用户预期保持一致
2.软件测试有动态测试(通过运行软件来测试)和静态测试(通过阅读和评审代码来测试)两种设计方式。
3.软件测试流程：测试计划---->测试设计—>测试实施与执行---->测试评估。(软件测试需要过程管理)
4.软件测试围绕用户需求(以需求为中心)，关注用户预期，观察被测软件实际用户情况，来设计测试。

软件缺陷

1.软件缺陷五个方面

• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好，则是缺陷

• 软件未达到需求规格说明书中指明的功能，则是缺陷(检查正常功能，正常流程；检查性能)

• 软件出现了需求规格说明书追中指明不会出现的错误，则是缺陷(检查异常情况、检查无效用户输入的识别能力、检查无效用户输入的处理能力)

• 软件功能超出需求规格说明书中指明的范围，则是缺陷(无意加入，过错缺陷；认为加入，需求缺陷；认为加入，过错缺陷；认为加入，病毒)

• 软件未达到需求规格说明书中虽未指明但应达到的目标，则是缺陷(隐含特性，需求缺陷)
  2.设计测试的步骤：
  ----->1.关注系统的正常功能，正常流程，正常输入，以及对应的性能要求；
  ----->2.关注系统容错性，即系统再异常情况下的表现，对各种无效输入是否可以识别，是否可以以正确方式响应等
  ----->3.不要忘记随机测试
  ----->4.关注系统隐形需求，即在特殊外部环境下能否正常运行

  测试用例

  1.测试用例定义：测试用例是为了达到测试效率的要求而精心设计的数据。其核心内容包括：输入(数据+步骤)、预期输出、测试环境
  2.设计测试用例：从用户需求中找到所有可能输入，以及对应的预期输出，在正确的测试环境下运行测试，观察实际输出是否与预期输出一直。同时应满足测试效率高、测试风险低、测试数据少而精等。

  软件质量

  软件质量是：

• 软件产品中能够满足给定需要的性质和特性的总体

• 软件具有所期望的各种属性的组合程度

• 顾客和用户觉得软件满足其综合期望的程度

• 确定软件在使用中将满足顾客预期要求的程度
  软件质量就是软件本身质量+客户满意度。
  软件测试是软件质量保证的重要组成部分，但软件测试只能检验软件质量，不能提高软件质量。

2.黑盒测试

黑盒测试相关定义

1.黑盒测试就是只知道系统输入和预计输出，不需要了解程序内部结构和内部特性的测试方法。
2.黑盒测试强调的只是无需了解内部的实现机制，但并未限制其使用的阶段，因此，在查看函数代码之前，针对函数也是可以使用黑盒测试方法设计测试用例的，而设计单元测试用例及编写单元测试脚本，也是从黑盒的角度来设计测试数据的。
3.针对软件测试效率最高、风险最低的目标要求，测试用例设计方方法至少应从如下方面进行评价：

• 测试用例的覆盖度应尽量全面
• 测试用例的数量应尽量少
• 测试用例冗余度应尽量低
• 测试用例的缺陷定位能力应尽量高
• 测试方法的复杂度应尽量低

边界值测试

1.面向输入域的边界值测试

面向输入域的边界值测试一般步骤：
—>1.找到系统输入条件，基于独立性原则，确定每个输入条件的边界点
—>2.围绕每个边界点，确定边界附近的邻域方位，并挑选测试数据，若以a为边界值，则通常选择a - &,a+&为测试数据(&表示极小值，一般取1)
—>3.根据选定的测试数据，基于单边界原则(一组测试数据仅覆盖一种边界值)，设计测试用例
—>4.根据系统需求，补充边界测试用例
2.面向输出与的边界值测试
若被测对象的输入域与输出域很不相似，则可能需要面向输出域补充进行边界值测试，一般步骤如下：
---->1.找到系统输出，确定输出的边界点
---->2.围绕每个边界点，确定边界附近的邻域方位，并挑选测试数据，若以a为边界值，则通常选择a - &,a+&为测试数据(&表示极小值，一般取1)
---->3.根据选定的输出域测试数据，确定输入域对应的输入条件及数据，并设计测试用例

等价类测试

等价类测试基于等价类划分的思想，使用有限的测试用例达到穷尽测试的目标。
1.面向输入域的等价类测试
目标：以有限的测试用例达到穷尽测试的目的，满足测试无漏洞、无冗余。
基本原理：采用分而治之的思想，将输入域进行等价划分，其中，等价划分满足三个约束(分而不变、合而不变、类内等价)，然后在每个等价类中抽取一个数据，从而将不可能的穷尽测试转化为有限个数据构成的测试用例的集合。
基本步骤:
---->1.在有效域内，基于独立性原则，将数据划分到不同的有效等价类中，然后选择弱覆盖标准或强覆盖标准设计测试用例
---->2.在无效域内，将数据划分到不同的无效等价类中，然后基于单缺陷原则设计测试用例
---->3.需要注意的是：在收到输入条件之间的关联性影响，以及等价划分的正确性影响时，等价类测试得到的测试用例不一定能保证无漏洞、无冗余。
2.面向输出域的等价类测试
若被测对象输入域与输出域很不相似，则可能需要面向输出域补充进行等价类测试，步骤如下：
---->1.在输出域内，划分等价类
---->2.在每个等价类中随意抽取一个数据
---->3.针对选择的输出测试数据，确定输入条件及数据，设计测试用例

场景法测试

场景法测试时面向业务流程的测试设计方式。
边界值测试和等价类测试主要解决了数据穷尽测试问题，面对业务流程的测试，可基于事件流的思想采用场景法进行测试。
基本原理：以事件流为核心，从系统某个初始态开始，到达某个结束状态为止所经过的路径就够长一个用例场景。

注意：从原理图可以看出，如果备选事件流过多，则将导致要测试的场景数量会变得十分庞大。因此，备选事件流的选择需要结合等价划分的结果，在某个节点选择备选事件流时，凡是不符合正常业务流程的，均可统一划归为异常业务流程，作为备选事件流。

测试用例设计的一般步骤：
---->1.基于风险确定基本事件流和备选事件流
---->2.以基本事件流和备选事件流构件场景
---->3.从场景设计测试用例，即找到输入条件，判断是否有效条件、是否触发条件、需要取哪些测试数据，并得到系统预期输出。

决策表测试

决策表测试是分析和表达多逻辑条件下不同操作的执行情况的一种测试方法，该法主要针对等价类测试中测试用例存在冗余的情况进行处理，当输入条件之间存在相互关联时，容易造成等价类测试用例的冗余，通过在有效域内利用强覆盖标准的等价类测试建立决策表，并对相似的测试用例进行合并，可在一定程度上降低测试用例的冗余。
方法：在有效域内利用强覆盖标准的等价类测试建立决策表的输入，然后对等价划分后的预期输出加以细化，建立决策表的输出，然后对输出相同、输入相似的测试用例加以合并，即可事项对等价类测试用例的花间。
决策表不适用于输出，也不适用于无效域，当输入条件相互独立时，无需使用决策表。

正交表测试

正交表测试的核心时正交表，形如：L_n(q^s),由三个要素构成，也就是因素
s，水平q和考核指标。在正交表测试用，s表示输入条件的个数，q是针对每个输入条件所取得的测试数据个数；符合n表示该正交表生成的测试用例的个数。
设计测试用例方式：对于某个被测对象，已知实际的输入条件个数S，以及每个输入条件对应的取值个数，若要选定某个正交表，形如：L_n(q^s)，那么，输入条件的个数大S应该不大于候选正交表的输入条件小s，每个实际输入条件的取值个数大Q应保证相等，并满足大Q不大于候选正交表的取值个数小q；最后，实际的最少实验次数，也就是最少测试用例数N，应保证不大于候选正交表的测实验此时n。

组合测试

组合测试(成对测试)就是不同测试方法对应不同类型的覆盖，如单因素组合覆盖、成对组合覆盖、k维组合覆盖等。等使用最多的是成对测试和三因素测试。
成对测试实际就是将所有对系统产生影响的因素的取值，按照两两组合原则而产生，目标是以最少的测试用例满足最大的成对组合覆盖率。
正交测试满足成对测试。
启发式算法采用逐条生成测试用例的策略，测试用例的构件过程如下：
—>1.构造一个集合，该集合包含所有需要被覆盖，但还没有被付给的因素的取值组合，设为T1
---->2.每次生成一条测试用例T_c,将其加入测试用例集合T，并从T1中删除已被测试用例t_c所覆盖的因素组合
----->3.重复2，直到测试用例集T覆盖所有被覆盖的因素的取值组合，也就是T1集合为空为止。
启发式算法有ATEG和IPO方法等。
自动生成测试用例工具：PICT。

3.白盒测试

白盒测试就是基于程序的源代码，已知产品的内部工作过程，主要程序的内部结构战开测试，关注程序实现细节的测试方法。

控制流分析技术

导致程序结构变得复杂的主要因素，以及控制程序执行流程发生变化的主要因素就是判定节点。控制流分析方法的核心就是围绕判定节点来设计测试用例，展开测试。
控制流分析三个关注方面：

• 关注节点判定表达式。利用不同的覆盖指标，对判定表达式中所包含的数据变量、子表达式等进行检查，分析可能的程序分支，即对判定的测试
• 关注路径。判定节点的引入对程序的执行路径带来不同程度的影响，需要分析路径风险，优选路径进行测试，保证测试效率，即独立路径测试
• 关注循环体，即针对循环的测试

对判定节点展开测试用例设计

名称	含义	特点及不足
语句覆盖	设计测试用例时，需要保证程序中每一条可执行语句至少执行一次	控制流图中的点覆盖；是最弱的覆盖指标；仅关注可执行语句，而非判定节点；对隐式分支无效
判定覆盖	设计测试用例时，应保证程序中每个判定节点取得每种可能的结果至少一次	控制流图中的边覆盖；满足语句覆盖；仅关心表达式的整体取值，不能覆盖到每个子条件的所有取值情况
条件覆盖	设计测试用例时，应保证程序中每个符合判定表达式中，每个简单判定条件的取真和取假至少执行一次	不一定满足判定覆盖。即局部全覆盖不等于整体全覆盖
判定/条件覆盖	测试用例设计应满足判定节点的取真、取假分支至少执行一次，且每个简单判定条件的取真和取假也至少执行一次	判定覆盖+条件覆盖
条件组合覆盖	测试用例的设计应满足每个判定节点中，所有简单判定条件的所有可能的取值组合情况至少执行一次	方法简单，但测试用例太多，冗余严重
修正的判定/条件覆盖	再满足判定/条件覆盖的基础上，每个简单判定条件都应独立地影响到整个判定表达式地取值	判定覆盖+条件覆盖+独立影响性；步骤如下：1.列出所有地简单判定条件；2.构件真值表；3.对每个简单判定条件，找到独立影响对；4.抽取最少独立影响对

同行评审

静态白盒测试不需要实际运行被测软件，而是直接对软件形式和结构进行分析。静态白盒测试主要包括代码检查、静态结构分析、代码质量度量等。
代码检查主要是通过同行评审来发现缺陷，主要以评审会议为形式，通过多人对软件交付物进行检查，从而发现缺陷或获得改进优化的机会。同行评审方法遵循的评审流程大同小异，但随着这些方法的正式程度不同，适用的对象、评审形式等方面也存在一定的差异。
同行评审流程图：

三类评审结果：
---->正常：评审专家做好了评审准备，评审会议顺利进行，达到了预期目的，达成明确的评审结论，不需要再次评审
---->延期：30%以上的评审专家并未做好评审准备，会议无法正常进行，需要重新安排评审日程
---->取消：初审阶段就发现工作产品中存在太多问题，需要作者进行修复，然后再进行第二次同行评审

展开出部的程序结构分析

静态结构分析就是通过分析程序相关的图标，从而快速了解程序设计和结构，更好地理解源代码，找到程序设计地缺陷和代码优化的方向。
1.看函数调用图
---->1.看函数调用层次，层次太深，将增大集成测试的负担，造成风险。对栈造成压力，容易导致溢出。要再函数调用层次于单个函数复杂度之间达到平衡
----->2.看函数调用关系，标识高风险节点。调用层次深的节点，根节点，出度大的节点，入度大的节点，都是高风险节点。
----->3.看递归调用。如果存在递归调用，尽量改为循环
---->4.看孤立节点。尽量避免孤立节点
2.看控制流图
---->1.看孤立节点。从控制流图看是否存在孤立节点
---->2.看出口节点。从出口带来高复杂度，应尽量避免多出口
---->3.看环复杂度。环复杂度应控制再10以内
---->4.非结构化设计。应尽量避免非结构化设计
改进结构设计不合理的函数：
---->1.避免孤立节点
---->2.避免多次适用return语句，尽量将有效性校验前置
---->3.应将完成单一功能的语句块改为函数调用的方式，降低单个函数复杂度
---->4.尽量不适用强制跳转(goto)或强制结束(break)语句，避免非结构化设计

路径测试

路径测试就是对程序路径的执行进行测试，保证路径执行是按照设计的预期进行的。独立路径测试要解决一下三个核心问题：

• 找到一张用于记录程序路径的地图
• 确定测试所需最少线性无关路径数
• 找到所有可能迅速找到缺陷的最佳独立路径
  1.程序图：程序图是反映程序结构复杂程序的一种图示，可以看作是一种简化、压缩的流程图或控制流图。
  流程图特点：对节点形状进行简化，采用统一的形状标识；忽略数据声明；忽略注释语句；压缩串行语句；压缩循环结构
  2.环路复杂度：环复杂度是一种定量描述程序结构复杂度的度量模型，可采用三种方式确定程序的复杂度：
  ---->1.直接观察法。观察程序图将二维平面分隔为封闭区域和开放区域的个数
  ---->2.公式法。V(G) = E - N + 1;
  ---->3.判定节点发：V(G) = P + 1
  3.设计测试用例
  基本步骤：
  ---->1.将代码转为程序图，作为路径测试的地图
  ---->2.计算程序图的环复杂度，确定独立路径测试集合规模
  ---->3.找到所有独立路径
  ---->4.剔除不可行路径
  ---->5.补充路径测试
  ---->6.根据覆盖的路径，设计测试用例
  独立路径的确定步骤：
  ---->1.确定主路径：主路径就是程序图中风险最高的那条执行路径。从结构来看，就是包含判定节点数目最多的一条路径
  ---->2.确定其他路径：以主路径为基础，针对主路径中的每个判定节点，一次覆盖已有独立路径中尚未覆盖的判定分支，生成新的独立路径。如果主路径未覆盖程序图中所有的判定节点，则需要针对主路径未覆盖到的那些判定节点，确定其余路径，直至找到所有独立路径
  不可行路径问题：受到需求或程序设计的影响，当程序中存在相互关联的判定或循环结构时，可能引入不可行路径。不可行路径破坏了独立路径测试的完备性和冗余性，给测试带来了额外的困难。

场景爆照

黑盒测试中，当场景中包含的事件流越多，可构成的场景越多，可能无法穷尽，造成场景爆炸问题。
场景爆炸三种解决方案：
---->1.基于独立路径构件典型场景：将场景原理图看作程序图，借鉴独立路径测试方法，确定典型场景。优势时可以保证场景相互独立，无漏洞，但不可避免不可行场景。
---->2.基于事件流的个数构建典型场景：根据事件流个数，本着面向缺陷隔离的独立测试原则，对每个事件流单独设计测试。优势是易于缺陷定位，但仍不可避免不可行场景，且不保证场景独立和完备
---->3.基于需求构件典型场景：根据原始需求设计场景。优势是保证每个场景可行，但场景之间多存在冗余，且场景设计严重依赖于测试人员对需求的熟悉程度
建议的适用策略：

• 当事件流之间相互独立时，建议基于独立路径设计场景
• 否则，建议先基于独立路径设计场景，并保证场景可行，然后基于需求补充场景

4.测试管理

管理测试用例

测试用例的管理需要解决两个问题：如何组织测试用例和如何报告测试用例
1.如何组织测试用例：即通过分析用户需求，设计测试用例，从测试用例库中抽取不同的测试用例，构件多个测试集，在不同的测试轮次中使用不同的测试集执行测试，记录发现的缺陷，并对应到相关的测用例。
如：

2.报告测试用例：即通过测试用例报告来详细记录测试用例的输入、预期输出，体现测试用例与需求的对应，支持测试用例的精确执行和责任划分。测试用例报告就是要回答：谁，在什么条件下，对什么进行测试，如何进行测试，发现了什么问题，依据的需求式什么，与其他测试用例有何关联。

管理缺陷

1.缺陷的基本属性：可重现行；严重性；优先级；可修复性
无法重现的缺陷无法修复，但不是任何缺陷都可以重现。因此，要保证发现的缺陷可以重现的措施如下：

• 备份相关环境和数据
• 测试过程中，详细记录每一个执行步骤和系统的响应
• 改变输入条件，输入数据，操作步骤，或测试环境，尝试重现缺陷
• 一旦缺陷可以重现一次，重复执行至少3次
  严重性式缺陷的客观属性，用于客观评价缺陷对系统造成的破坏力。一般分为三级：严重的，一般的，次要的
  优先级：式缺陷的主观属性，式指项目组对缺陷的处理优先级，带有主观意见。一般分为三级：高、中、低。
  可修复性式指缺陷在软件产品发布之前是否可以得到修复。不是所有缺陷在产品发布之前都可以得到修复，但应尽量使缺陷在产品发布之前进行修复。该特性在缺陷报告中不体现。
  2.缺陷的报告
  缺陷报告回答如下问题：
• 谁，何时，在何处，发现了什么缺陷？
• 谁，何时，提出怎样的处理意见？
• 谁，何时，如何修复该缺陷？
• 谁，何使，如何验证该缺陷？测试结果如何?
  3.缺陷跟踪