软件测试基础（二）-需求、测试用例

一、软件测试需求分析

1、为什么要需求分析

a、软件测试需求是设计测试用例的依据。

b、有助于保证测试的质量和进度。

c、软件测试需求是衡量测试覆盖率的重要指标。

2、软件测试需求分析步骤

a、列出需求文档中的具有可测性的原始需求；

b、对每⼀条需求进行细化分解，形成可测试的分层描述的测试点；

c、对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型；

d、建立测试需求跟踪矩阵，对测试需求进行管理。

3、测试点分析

a、通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）。

b、各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在交互的功能项，给出对应的验 证内容（功能业务测试）。

c、考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界面的验证，异常情况 （界面、易用性、兼容性、安全性、性能）。

4、测试需求相关方的影响

开发约束

• 由于了解需求不明确，功能研发不合格导致很多BUG
• 对于BUG反复修改，影响进度和团队情绪
• 进度影响，很可能使公司产品失去市场先机

测试约束

• 与开发是相互制约的关系，如果不了解需求，会大部分时间都被开发牵着鼻子走
• 不能及时发现开发的偏差，影响进度和团队情绪
• 没办法保证测试质量

5、看需求文档需要抓住的核心东西是？(重要！）

a、产品是给谁服务的？（问身边的：产品经理，测试）

b、产品的核心流程是什么？ 核心流程最好使用思维导图的模式把流程梳理出来 。

c、如果产品里面有专业术语（咨询产品或者是自己百度搜索）

d、梳理出产品哪些逻辑不是很清楚，梳理出来后，专门约产品经理或者是其他测试，让对方协助我们来讲解下这部分。

二、测试用例的七大设计方法

1、测试用例定义

测试用例是为特定的目的而设计的⼀组测试输入、执行条件件和预期的结果。简单地说，测试用例就是设计⼀个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

2、测试用例步骤

拿到需求文档 → 分析需求（画思维导图）→编写用例 →划分用例优先级

3、测试用例编写的特征

⼀致性：主要包括用例模板⼀致；各同事的编写⼿法⼀致；以及用例的细腻度⼀致。

覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对哪些功能会产⽣影响的覆盖；对各种场景的覆盖等 。

可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。

执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行⼈对待执行用例的态度。不要因为用例简单或者⼀些外界的因素，导致部分用例未实际执⾏标为通过的情况。

持续更新：要及时不断的更新，要尽量减少用例库中失效的用例。

复用性：主要用例可以被不断的复用，从而减少维护成本。

4、测试用例组成元素

即：用例ID； 用例名称； 测试目的； 测试级别； 参考信息； 测试环境； 前提条件； 测试步骤； 预期结果； 设计⼈员。

最为重要的4个用例组成元素：用例名称； 前提条件； 测试步骤； 预期结果；

注：环境：

a、测试环境：给测试使用的环境，指的是一个产品还没上线前测试的环境。

b、预发布环境：介于测试环境与线上环境中间，但是它也是可以给客户使用的环境，一般不开放，只供研发内部人员使用。

c、线上环境：给真实的用户使用的环境。

5、编写测试用例的三种方式：

a、思维导图，结构化看起来非常的好，但是不够细。

b、使用excel，特点是写起来非常浪费时间，但是非常细。

c、checklist， 只考虑被测对象的大概的点，一句话能够描述清楚要测试的测试场景。

下面我们分别用上述三种方式来进行实战：

积分流程：

积分成长值流程：

方式一：思维导图 

 

方式二：Excel

积分流程：

积分成长值流程：

方式三：checklist

其中：checklist使用的场景具体如下：

a、开发转测了，但是时间非常紧张（发一个hotfix版本，来修复这个issue），要求今天上线，那么这个时候测试编写checklist把需要测试的点梳理出来进行测试,同开发、产品经理等进行讨论。

b、上线前使用checklist列出上线后必须需要测试的点（必须要进行的测试点往往指的是一个产品的核心流程）比如，京东购物商城，主线就是搜索商品，加购物车，下单，物流，收货等这些流程线。

三、测试用例设计方法

1、等价类划分法

a、定义：在所有测试数据中，具有某种共同特征的数据集合进行划分。

b、分类：

• 有效等价类：满足需求的有效数据集合
• 无效等价类：不满足需求的无效数据集合

即：测试一个产品，需要考虑它的正确场景，也需要考虑它的异常场景。

c、举例：如电话号码，那么有效数据就是符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字等。

2、边界值分析法

边界值测试用例是针对等价类测试用例方法的补充，因为等价类测试用例的方法只考虑到了输入数据的有效数据和无效数据，但是没有考虑到边界的情况。

a、定义:是对输⼊或输出的边界值进行测试的⼀种测试方法。

b、举例：比如我们在新浪邮箱的注册页面，我们需要注册“邮箱地址”，我们输入“123”，系统就会提示用户：

3、判定表驱动分析方法

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

b、判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利⽤判定表能够设计出完整的测试用例集合。

在⼀些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

c、判定表通常由四个部分组成，如下图所示：

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

d、举例：如招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果，如年限，薪资，地区等等，需要先列出来，然后判定表驱动分析方法。

4、因果图法

在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）来判断程序的结果情况.

a、定义：指的是被测对象有多个输入条件，根据不同的输入条件之间的关系（并且，或者，非）来匹配筛选出不同的结果。

b、排列组合：因果图是根据输入的不同条件来根据排列组合来设计不同条件下的测试用例。

c、举例：比如我们在boss直聘里，搜索“软件测试工程师”，这一职位，我们还想要，输入区域、学历要求、工作经验这三个，这就是一种并且的关系。

5、正交实验分解法

在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化测试用例的个数，选择有代表性的数据来进行测试

a、定义：因果图根据输入的N个不同条件，这样组合下来会导致测试用例的个数是呈指数级的增加，这样导致测试的资源（人力，时间资源）上根本无法满足测试的时间要求。那么这个时候只需要测试有代表性的数据就可以了，那么使用的方法就是正交实验分解法。

b、举例：比如我们在拉勾网，去测试“软件测试工程师”这一职位，由于学历、地狱、薪资、年限等的不同，我们不太可能去排列组合，这时候我们可以去测试全国互联网比较发达的地方的数据就可以了。

从某种程度上来说，以上五种测试方法都是功能性测试。

6、错误推测方法

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

b、错误推测方法的基本思想： 列举出程序中所有可能有错误和容易发生错误的特殊情况。

c、针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题。

一般会有以下的特殊情况：

i、在波浪式的交互过程中，一直往下滑动，可能会出现浏览器的卡死，比如淘宝的首页。

ii、在列表中翻页可能也会存在浏览器的卡死。

iii、Java语言编写的应用程序，大概率可能存在内存泄露(Java.lang.OutOfMemory，简称：OOM)

内存泄漏：一个应用程序都会分配内存，比如分配了2G，但是程序在使用的过程中，由于程序受到了太大的压力，导致使用的内存超过了分配给自己的内存，那么就会导致内存溢出。 

iv、一码通，对该应用程序进行二维码扫描并且一直在进行扫描，那么很有可能存在扫描二维码后出现不了结果或者是导致结果一直加载中。

7、场景设计方法

a、定义：指的是针对一个系统从输入流开始一直到输出流的完整性的测试，主要考虑的是被测对象的业务流程，也就是各个不同场景方法的测试。

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

c、举例：比如淘宝，从一个商品上架一直到商品的出售。

8、功能图分析方法

a、定义：它是非功能性的测试用例设计方法，是针对被测程序内部的一种测试方法，主要测试的对象是被测程序的内部代码，使用代码的逻辑来验证被测对象的程序逻辑是否存在问题，是白盒的一种方法。

b、功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中的内容。

逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法，该方法要求测试人员对程序的逻辑结构有清楚的了解，由于覆盖测试的目标不同，逻辑覆盖可分为:语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖及路径覆盖。

路径测试：是指根据路径设计测试用例的一种技术，基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

实战：通过思维导图，编写有关”车主小程序首页“的测试用例，当然也会有考虑不周全的地方。

其中：openID：从小程序来的所有订单以及请求，小程序都会自带一个唯一的标识，唯一的标识就是openid

四、编写测试用例

1、编写测试用例的依据是什么？

答：1）需求文档以及系统的产品业务逻辑；

       2）开发的技术方案，在技术方案里面会有程序内部的设计原理和逻辑流程图；

       3）个人的工作经验，比如任何一个产品都需要考虑异常的逻辑下程序的容错能力，以及产品的性能测试。

2、编写测试用例的技巧：
1）在一个新的环境里面，首先确认在什么地方编写测试用例，以及以什么方式编写；
2）确认清楚后，编写一小部分，然后让对方去看下颗粒度，在对方的建议上继续调整。

3、怎么确保你编写的测试用例把测试点都包含进去了？

答：1）首先，会把系统中可能存在的各个业务逻辑使用思维导图都列出来，使用到的测试用例方法是判定表驱动分析方法； 

       2）产品的正常功能，使用到的测试用例方法主要是等价类，边界值以及因果图；

       3）产品的非正常功能下，系统的容错能力，主要使用到的测试用例方法是错误推测法；

       4）同时也会考虑被测产品的性能测试，以及它的安全性的测试（脚本注入）；

       5）设计测试点需要考测试对象被依赖的测试点的场景（比如：积分成长值流程的测试，是依赖积分流程这一模块的）.

4、实战：

"读书会列表"需求文档如下：

  

测试用例如下：

"热评书潮"需求文档如下：

测试用例如下：

 五、评审测试用例

1、评审测试用例都有哪些人参与？开发、产品、测试、PM(leader)

2、测试用例的评审的流程：

1）自己编写完测试用例后，预定会议室，同时和大家约这个开会的时间看是否都能够参加；

2）到约定的时间，组织相关的人到会议室（那么这个时候会议的主持人就是你自己，会议的气氛以及氛围营造都是你自己来控制的）

3）开始评审的时候，你给大家描述每个测试点，大家都在听：

A、当大家没有问题的时候，可能会回应你，也可能不会；

B、当描述的过程中，如果哪个测试点有问题，别人会立刻提出来，会议主持人需要把别人提出的问题立刻记录下 。

4）评审结束，做最后的总结.

3、评审测试用例注意事项：

1、评审的过程中，如果别人提出疑问，针对有的疑问需要不同角色（产品，开发，测试）讨论决定结果；

2、评审的过程中，某些测试场景以及测试结果可能存在问题，别人提出来，需要直接在现场修改自己的测试用例；

3、有的疑问需要挑战的地方比较多，不需要现场调整，那么就需要在现场记录在本子上。

4、评审结束，总结性的发言：针对别人提出来的疑问，做一个汇总。

5、评审结束之后，根据别人提出的疑问，调整（完善）测试用例，调整结束后，再次把测试用例发送到工作群里面，同时@相关的人。