软件测试用例知识点梳理

Posted 2020-10-28 正厚7期-杨秀梅

 

一、概念

        怎样以最少的人力、资源投入，在最短的时间内完成测试，去发现软件系统的缺陷（bug），保证软件的优良品质，是软件公司探索和追求的目标。

       ▲测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障

       ▲测试用例是指为实施测试而向被测试系统提供的输入数据，操作或者各种环境设置以及期望结果的一个特定集合。

        简单来说------测试用例就是解决要测什么，怎么测和如何衡量的问题

二、测试用例的属性：

              1.用例ID（编号）

              2.用例名称（）

              3.测试目的

              4.测试级别

              5.参考信息

              6.测试环境

              7.前提条件

              8.测试步骤

              9.预期结果

              10.编写人员

              11.测试结论（通过、不通过、阻塞）、实际结果、bug信息（bug id）、测试数据

三、测试用例的特征

            1） 最有可能抓住错误的

            2） 不是重复的、多余的

            3） 既不是太简单，也不是太复杂的

四、用例设计原则：  

           1） 测试用例对需求覆盖的完整性（测试尽量做到要全面，多纬度考虑）

             • 做到对需求的完全理解,从全局上把握需求，对需求进行归类，包括对正常   流、异常流等，做到需求的100%覆盖 。理顺了需求，用例写起来就顺手多了。

           2） 测试用例的有效性（对于需求变更或软件更新等导致的某些测试用例要及时更新，保证测试用例的及时有效性，主要针对时间同步及用例的可用性）

 

测试用例应该包含清晰的输入数据以及预期输出，如果环境或者业务发生

变更后，测试数据必须进行更新维护，用例基于数据驱动。

 

           3）测试用例的可理解性。（测试人员为什么要这样测试，有什么依据）

 

测试用例步骤必须描述清晰，不能出现模棱两可，以及重复的话语。

测试用例应该按照一定的顺序进行编写，这样执行的时候效率比较高。

 

           4） 测试用例的清晰性。（要条理清晰，便于理解，防止漏测）

 

                      1.测试用例的验证点必须明确清晰重点突出。

                      2.一个用例进行一个功能点的验证，一个萝卜一个坑。

                      3.对于流程性的用例建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。

                      4.测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。

 

           5) 测试用例的可维护性。（及时更新—需求变更，某些测试用例也要更新，无用的测试用例要删除，有用的要保留，该新增的要新增，该修改的要修改）

 

                    测试用例因为业务需求发生变更的时候，需要及时更新维护测试用例，做到测试用例的实时性和有效性。

                    测试用例需要细化和不断的完善，是个循序渐进的过程。

                    通过测试实践检验测试用例并添加、删除、修改测试用例

五、小结：

         Ross Collard在“Use Case Testing”一文中说:“测试用例的前10%到15%可以发现75%到90%的重要缺陷”—缺陷的群集性。如果你在项目日常结束后，仔细的
分析过我们的bug列表，那么你会觉得这句话非常适用。合理的提高我们的测试效率就是在编写测试用例的时候进行测试用例优先级的划分。

 

如何划分测试用例的优先级：

         1）用于冒烟测试的用例----最高优先级

         2）把基本路径以及各模块主功能的测试----高优先级别

         3）把你所有错误和边界值或确认测试----中优先级别

         4）把可用性测试，兼容性测试等----低优先级别

         5）将功能测试用例分为严重和不严重两类，对于不严重的功能测试用例降级为低优先级用例。

六、测试设计用例方法

        1、主要设计方法：◆等价类划分    ◆边界值分析法    ◆因果图法   ◆判定表驱动法   ◆场景法     ◆功能图法    ◆错误推测法     ◆正交实验设计法

2、等价类方法：

            （1）等价类定义：

把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。

划分等价类原则：

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

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

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

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

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

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

 

            （2）等价类划分：

                           1、等价类划分法作为一种最为典型的黑盒测试方法，它完全不考虑程序的内部结构，而只是根据程序的要求和说名惊醒测试用例的设计。

如何去做？

         1） 测试人员要对需求规格说明书中的各项需求，尤其是功能需求进行细致分析，然后将程序的输入域划分成若干部分，从每个部分中选取少数代表性的数据作为测试用例，经过这种划分，每一类的代表性数据在测试中的作用都等价与这一类中的其他值。（同一个集合中的每个数据的作用都是一样的）

        2） 如何区分  有效数据等价类与无效数据等价类

                有效数据等价类：由那些对程序的规格说明有意义的，合理的输入数据所构成的集合

               无效数据等价类：就是那些对程序的规格说明不合理的或者无意义的输入数据所构成的集合。

 

等价类方法总结：

 

        等价类技术提供了一个选择哪些数值，舍弃哪些数值的测试用例设计方法。运用等价类技术，可以将相似输出、输入、操作分成组，这些组就是等价区间，只要从等价区间选择一到两个有代表性的值作为测试用例来执行就等同于测试了所有值。当然，也可能存在编程人员编写了异常处理的代码（使用多个测试用例才能发现这个错误），但是在发现这种类型的缺陷方面存在其他更为有效的技术（比如代码审查）

 

运用等价类方法的步骤：

 

              1、 划分等价类（依据是需求）

 

             2、 建立等价类表（有效等价类和无效等价类）

 

            3、 设计测试用例

 

 

 

思路和方法：

 

              1、分析需求，挖掘隐式条件，确认边界值，划分等价类

 

              2、将划分出的等价类填入表格，进行编号

 

              3、对有效等价类，用一条用例尽量多的覆盖

 

              4、对于无效等价类，一对一的覆盖，最终得到测试用例

 

3、边界值分析：

 

边界值分析也是一种黑盒测试方法，是一种和等价类相关的技术，它具有很强的发现程序错误的能力。如果软件的能力达到极限时能够运行，那么在正常情况下就不会有什么问题。长期的测试工作经验说明“错误隐藏在角落，问题聚焦在边界上”大量的错误是发生在输入或者输出的边界上，而不是发生在输入输出的范围内。因此，针对各种边界值情况设计测试用例，可以查出更多的错误。

 

 

 

1）定义：

 

          边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

 

原则 ：

 

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

 

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

 

         ③ 根据规格说明书说明的每个输出条件，使用1原则。

 

         ④ 根据规格说明书说明的每个输出条件，使用2原则。

 

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

 

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

2）找点原则：

 

3、判定表法

             判定表驱动法：是分析和表达多逻辑条件下执行不同操作的情况的工具。

判定表组成：

             条件桩：列出了问题的所有条件

             动作桩：列出了问题规定可能采取的操作

             条件项：列出针对它所列条件的取值，在所有可能情况下的真假值

             动作项：列出在条件项的各种取值情况下应该采取的动作

             规则：任何一个条件组合的特定取值及其相应要执行的操作

 

注：判定表中贯穿条件项和动作项的一列就是一条规则。

（1）     判定表建立

 

           第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有2的n次方种规则

          第二步：列出所有的条件桩和动作桩

          第三步：填入条件项

          第四步：填入动作项。制定初始判定表

          第五步：简化。合并相似规则或者相同动作

（2）使用判定表的条件：

          1、规格说明以判定表的形式给出，或很容易转换成判定表

          2、条件的排列顺序不影响执行哪些操作

          3、规则的排列顺序不影响执行哪些操作

          4、当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则

          5、如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

判定表实例：

 

 

判定表法总结：

优点：

            1）充分考虑了输入条件间的组合，对组合情况覆盖充分。

            2）最终每个用例覆盖多种输入情况，有利于提高测试效率。

            3）设计过程中，对输入条件间的约束关系做了考虑，避免了无效用例，用例的有效性高。

            4）能同时得出每个测试项目的预期输出。

缺点：

            当被测试特性输入较多时，判定表的规模将会非常庞大输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合测试的输入做了组合，从而产生用例冗余。

5、 因果分析法

      定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

     因果关系: 4种符号分别表示规格说明中4种因果关系

     说明：

          因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。C1表示原因，通常置于图的左部；e1表结果，通常在图的右部。C1和e1均可取值0或1，0表示状态不出现，1表示某状态出现

 

4）因果图法—因果约束

      约束：  输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

       

        1--输入约束（能够有效输出结果所使用的条件之间有着相互制约的关系）

                  ① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

                  ② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

                  ③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

                  ④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

        2--输出约束

                  输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0

 

 

5、正交试验：

           正交测试用例设计又称组合实验法，利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明书中得到，往往因果关系非常庞大，以至于据此因果图而得到的测试用数目多的惊人，经软件测试带来学生的负担，为了有效地，合理地减少测试的工时与费用，可利用正交实验设计方法进行测试用例的设计。

           正交实验设计方法是依据伽罗瓦（Galois, 1811 – 1832,法国数学家）理论，从大量的测试数据（测试用例）中挑选适量的，有代表性的点（测试用例），从而合理地安排测试的一种科学实验设计方法。

正交试验法步骤和选择：

         用正交表设计测试用例的步骤

                 (1) 有哪些因素（变量）

                (2) 每个因素有哪几个水平（变量的取值）

                (3) 选择一个合适的正交表

                (4) 把变量的值映射到表中

                (5) 把每一行的各因素水平的组合做为一个测试用例

                (6) 加上你认为可疑且没有在表中出现的组合

如何选择正交表（考虑几因子几状态）

                   1. 考虑因素（变量）的个数

                   2. 考虑因素水平（变量的取值）的个数

                   3. 考虑正交表的行数

                   4. 取行数最少的一个

正交试验法小结：

                 利用正交实验设计方法设计测试用例，比使用等价类划分、边界值分析、因果图等方法有以下优点：1）节省测试工作工时；2）可控制生成的测试用例数量；3）测试用例具有一定的覆盖率

 

 

6、状态迁移：

            状态转移测试是一种基于产品规格分析的黑盒测试技术，对系统的每个状态及与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程。

            对象：状态转换测试中，测试对象可以是一个具有不同系统状态的完整系统，也可以是一个在面向对象系统中具有不同状态的类

           • 适应场景：如淘宝订单处理、缺陷处理流程等。

测试强度：

           • 覆盖所有状态、调用所有的函数、覆盖所有的路径

状态迁移方法步骤：

            步骤一：根据需求提取全部状态；

            步骤二：绘制状态迁移图；

            步骤三：根据状态迁移图推导测试路径（状态迁移树）；

            步骤四：选取测试数据，构造测试用例。

 

步骤四：根据测试路进行用例设计（输入部分）

(1).完成预定->已支付->已取消；

(2).完成预定->已支付->已出票->已取消；

(3).完成预定->已支付->已出票->已使用；

状态迁移

总结：

        状态迁移法实际测试了被测系统各种状态的转换，这些状态转换的测试在实际工作中是容易遗漏的，只要能够将这些状态的转换测试到，是否采用状态迁移法并不重要，因为状态迁移法只是提供了一种将多个状态的转换串联起来进行测试的思路（思维模式）。

         实际工作中，在业务流程中都涉及到了复杂的业务场景（即业务状态的迁移）。而这些业务场景在需求规格中往往不能够完全阐述清楚，容易出现遗漏。所以当被测系统的业务场景复杂时，在工程中应用这种针对状态迁移测试的思路完成对复杂业务场景的测试有时是很有必要的。

7、场景法

         在实际测试中，经常有这种情况，像安装程序向导，它是由多个界面组成的，并且他们之间彼此有联系，而且他们之间是有流程顺序的，在面对这种测试时，我们就可以使用今天介绍的场景法了。照例还是先看一下基本概念，基本流就是按照正确的事件流来实现的流程。备选流就是出现故障概念，基本流就是按照正确的事件流来实现的流程。备选流就是出现故障或缺陷的过程。场景就是若干事件流首尾拼接构成一个测试场景。来看一个场景图

 

场景法：

        1. 方法简介

            现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

            基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

 

 

 

 

（3）设计 步骤

             1. 根据说明，描述出程序的基本流及各项备选流

             2. 根据基本流和各项备选流生成不同的场景

             3. 对每一个场景生成相应的测试用例

             4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

 

 

 

 

 

8、其他测试方法：

★软件测试有两个基本方法：通过测试和失败测试。

★通过测试：主要用于验证系统和它的需求是否一致。确认软件至少能做什么，一般通过分析需求说明设计测试用例。为了确定程序是否满足目标，就必须执行通过测试。

★失败测试：确信软件在普通情况下正确运行之后，就可以采取各种手段找出缺陷。纯粹为了破坏软件而设计和执行的测试用例称为失败测试或迫使出错测试。

失败测试主要用于证明“一个系统不做不需要它做的事情”，也就是说，要设计测试用例来考察程序超出需求规格说明的严格范围时的行为。

失败测试虽然与通过测试看起来相似，但是它是蓄意攻击软件的薄弱环节。

★错误猜测：（错误推测）本身不是一种测试技术，而是可以运用到所有测试技术中产生更加有效的一种测试的技能。

    错误推测是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

★随机测试：随机测试指测试中的所有输入数据都是随机生成的，其目标是模拟用户的操作。

测试方法的选择：

一个好的测试方法将给软件测试带来事半功倍的效果，在世纪的测试工作中可以按照下面的原则运用适合的相关测试技术。

             1、 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。

            2、 用等价类划分方法补充一些测试用例。

            3、 用错误推测法再增加一些测试用例。

            4、 如果程序的功能说明中含有输入条件的组合，应在一开始就选择用因果图法。

            5、 如果程序的某功能适合自动测试，则可采用自动测试方法以及随机测试方法进行测试。

            6、 用例尽可能地遍历各个模块。

            7、 测试用例表格设计要符合要求（必填字段等等）

备注：

实际工作过程中优先选择怎样的测试方法的补充：

            1） 基于业务操作流程分析，首先采用的是场景法，保证主要功能没有问题。设计相关用例（涵盖了状态迁移，因果图、判定表等）。

            2） 根据输入过程每一个输入项，采用边界值、等价类设计用例。

            3） 设计到查询条件找功能，条件之间组合关系的，套用正交表进行用例设计。