软件测试基础

内容介绍

1. 软件开发过程模型
2. 测试模型
3. 软件测试分类
4. 测试用例
5. 测试用例设计方法：
   1. 等价类划分法
   2. 边界值分析法
   3. 判定表法
   4. 因果图法
   5. 正交法
   6. 场景法
   7. 流程图法
   8. 错误推测法
6. svn的使用
7. 缺陷管理

软件开发过程模型

1. 什么是软件开发过程模型？

软件开发人员在公司里面工作的过程

1. 为什么软件开发过程模型？

软件测试和软件开发有着密切联系。为了做好软件测试。

1. 常见的软件开发过程

瀑布模型      快速原型模型    螺旋模型

软件开发过程模型-瀑布模型

• 特点

1. 是线性模型的一种，在所有模型中都占据非常重要的地位。
2. 每一个阶段都执行一次，按照线性的顺序进行软件开发。

• 瀑布模型流程

1. 需求分析
   1. 1. 产品经理---用户反馈---需求
2. 设计
   1. 1. UI设计师。设计工作。
3. 编码
   1. 1. 开发拿着产品经理的需求分析-设计人员的设计-日复一日的敲代码
4. 实现  
   1. 1. 开发人员实现项目
5. 软件测试
   1. 1. 测试项目
      2. 备注：留出足够的时间开展测试活动，否则会导致测试时间不充足，很多问题在后期得以暴露
6. 实施
7. 交付

• 优缺点
  1. 1. 优点
        1. 软件开发的每一个阶段都很清晰明了
        2. 前一个阶段完毕后，只需关注后续阶段即可。
     2. 缺点
        1. 错误的传递
        2. 不适应需求的变化
        3. 软件测试介入的时间较晚，对于前期的错误往往无从发现和修改

软件开发过程模型

• 快速原型模型

快速的构建一个原型。把这个原型交给用户，让用户给出评价，开发人员根据用户的评价，修改原型，增加一写具体的功能

最终开发出用户满意的开发产品

• 1. 优缺点
     1. 优点
        1. 适应需求的变化，能够开发出更加让用户更加满意的需求
     2. 缺点：
        1. 不适合大型项目的研发
            
  2. 使用场景
     1. 用户的需求非常清楚全面，且在开发过程中没有或很少变化；
     2. 开发工作对用户参与的要求很低
         
• 增量模型
  又称为渐增模型，是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

1. 1. 优缺点
      1. 优点

将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展

以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。

开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

1. 1. 1. 缺点：

要求待开发的软件能给进行增量式的开发,否则会很麻烦

在软件开发过程中需求变化是不可避免的,增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性.

1. 1. 使用场景

进行已有产品升级或新版本开发

• 螺旋模型

优缺点：

       优点：

1. 风险驱动的方法体系
2. 每一个项目上线之前，都要去进行风险分析

缺点：

1. 风险分析需要专门的技术和才能
2. 一旦风险分析不到位，势必会造成重大的损失

使用场景:

适合使用大规模的软件项目

测试模型

1. 什么是测试模型 

测试人员在公司中工作的过程

1. 为什么要学习测试模型
2. 常见测试模型

V模型    W模型    H模型

测试模型-V模型

问题：测试V模型包含哪些流程？

测试V模型又叫做瀑布模型的变种。

• 流程

1. 需求分析

产品经理-用户反馈

1. 概要设计
2. 详细设计

统称为设计。概要：大概设计。详细：细细的设计

1. 编码

开发人员进行编码

1. 单元测试

对一个一个小模块的代码进行的测试。针对代码的测试

1. 集成测试

把一个一个小模块的代码集合起来进行的测试。针对代码的测试

1. 系统测试

拿到产品后，站在宏观的角度，测试产品的功能能否走的通。针对产品的测试

1. 验收测试

产品是否符合用户最终的需求

• 优缺点：

优点：

1. 每一个阶段都很清晰明了
2. 便于控制开发的每一个过程
3. 既包含底层测试（单元测试）又包含高层测试（系统测试）

缺点：

1. 测试介入的时间比较晚，对于前期的一些缺陷往往无从发现和修改
2. 返工量大，模块与模块之间的灵活性低
3. 错误的传递过程

测试模型-W模型（双V模型）

问题3：说说W模型与测试V模型相比有哪些亮点之处？

• 流程

开发一个V：需求分析-概要设计-详细设计-编码-集成-实施-交付

测试一个V：验收测试设计-集成测试设计-单元测试设计-单元测试-集成测试—系统测试-验收测试

• 优缺点

优点：

1. 强调测试伴随整个开发周期，测试的不仅仅是程序，需求和设计同样也要进行测试
2. 每一个阶段都很清晰明了
3. 便于控制开发过程

缺点：

1. 不适用于小型企业
2. 只适用于中大型企业

测试模型-H模型

H模型的优缺点：

优点:

(1)开发的H模型揭示了软件测试除测试执行外，还有很多工作；

(2)软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

(3)软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

缺点:

(1)管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；

(2)技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

(3)测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

软件测试的分类

软件测试的分类-按照测试阶段进行划分

问题：说说什么是集成测试，什么单元测试，什么是系统测试

1. 单元测试

一个一个小模块的代码进行的测试

谁来做单元测试？

测试

什么时候做单元测试？

开发人员敲完一个小模块的代码后

单元测试通过的标准是什么？

需求

单元测试的现状是什么？

国内开发人员做单元测试比较多。

1. 集成测试

又叫做组装测试。是将一个一个小模块的代码组合起来进行的测试。

什么时候做集成测试？

单元测试完毕后

集成测试通过的标准

需求

集成测试是谁来做

测试/开发

1. 系统测试

拿到产品后，站在宏观的角度去看一下这个产品的功能，性能，兼容性方面是否符合需求

软件测试的分类-按照是否覆盖源代码进行划分

1. 黑盒测试

又称之为数据驱动测试。只关注输入和输出，不关注内部代码结构和原理。

1. 白盒测试

打开黑乎乎的盒子，去研究内部结构和程序。针对代码的测试。

1. 灰盒测试

介于白盒和黑盒之间的一种测试。既要测试部分源代码也要测试黑盒测试。

黑盒测试分类

问题：在公司中黑盒测试都测试哪些方面？

1. 功能测试

逻辑功能测试

界面测试

升级安装及卸载测试

兼容性测试

  不同的网络：2G，3G，4G，5G，有线，wifi

 不同的浏览器

 不同的操作系统 windows mac liunx

 不同的手机设备：安卓，苹果

易用性测试

1. 性能测试

时间性能

空间性能

  占据的内存空间

负载性能

压力测试

    当用户量非常大的时候，网站能否承受的住压力

一般性能

黑盒测试常见问题：

 界面上的问题。

 功能上的问题

 数据库中的问题。

   数据加载的正不正确

 性能问题。

软件测试的分类-按照是否运行进行划分

1. 静态测试

不运行代码，静静的看着文档，源代码，产品的一种测试

1. 动态测试

运行代码，比较一下预期结果和实际结果之间的差异。

软件测试分类-其他

1. 冒烟测试

拿到产品后第一次测试

1. 回归测试

第二次测试。

第一次测试完发现bug，提交bug给开发人员，开发人员修复bug,在做一次测试

1. 随机测试

随便测。往往所有的功能测试完毕后。

1. 验收测试

看一下是否符合用户最终的体验

验收测试的分类

1、阿尔法测试

公司的内测版本。

    只有公司内部人员测试的产品。只有公司内部测试人员能够接触到这个版本，因为这个版本时期的bug是最多的

2、贝塔测试

公测版本。

 公共的测试。除了公司内部测试人员以外，还有公司内部其他人也可以做一下测试。用户会在特定的网站上接触到该版本，但是大部分用户还是接触不到贝塔测试版本的。因为该版本还是有bug存在的。

3、伽马测试

  正式发行版的候选版本。

   此时bug量是最少的。

软件测试的分类-按照是否自动化进行划分

1. 自动化测试
2. 手工测试

测试用例

1. 什么是测试用例？

测试用例又叫做（test case），为了实现某种目的，由一组测试输入，执行条件，预期结果，以便验证是否满足某个特定的需求。

测试用例（test case）是一个场景，在这个场景中要完成对某个软件的测试，在这个场景中要去验证该软件是否符合你的预期。

1. 为什么要学测试用例

测试用例非常重要。通过大量的测试用例，去检验软件的运行效果，以便在这个过程中达到更好的目标

1. 现实生活中的测试用例

1. 买电脑，开机运行一下电脑，如果电脑没有开机，一定不会去买，如果电脑开机了，有可能不会去买。
2. 买手机，按下开机键手机，预期只要顺利开机，就买手机，如果不顺利开机，就不买手机

测试用例8大要素

1. 用例编号

字母和数字组成的。具有唯一性的

1. 测试项目

写的测试用例隶属于哪个项目

1. 测试输入

执行该条用例的时候，给与的外部条件

1. 预期结果

希望结果，往往来自于需求。

1. 用例级别

执行测试用例的优先级

1. 预置条件

执行测试用例的前提条件。

1. 测试环境（模块）

所隶属于哪个具体的模块

1. 执行步骤

执行这条用例，经过的步骤有哪些

测试用例设计方法

等价类划分法

1. 什么是等价类划分法？

定义：输入具有代表性数据的子集。

等价类划分法分类：

1. 有效等价类：满足题目需求的
2. 无效等价类：不满足题目需求的。和题目条件相反的一些情况，在加上一些特殊情况（中文、空格、空、特殊符合、小数、英文）

2、    如何使用等价类划分法去设计测试用例呢？

设计测试用例的步骤

1、明确需求

2、确定有效和无效等价类

3、编写测试用例

3、      测试两位数的加法计算器

         题目需求是：1-100之间整数的和

        1、明确需求

       2、确定有效和无效等价类

1. 编写测试用例

等价类划分法总结

1. 等价类划分法适用与什么样的情况

只要存在输入的功能

1. 规则

             一条测试用例中只允许出现一个无效等价类

边界值分析法

正常的生活中，往往大量的错误是存在在输入和输出范围的边界上的，而不是在输入范围的内部。

1. 什么是边界值分析法

边界值分析法也是一种常用的黑盒测试用例设计方法

边界：刚刚大于或者刚刚小于或者刚刚等于边界的值

1. 如何使用边界值分析法去设计测试用例

1 明确需求

2 确定有效和无效等价类

3 明确题目条件中的边界值

4 编写测试用例

1. 边界值取值

上点：就是指边界上得点，开区间的话，上点就是在域外，闭区间得话，上点就是在域内。

离点：指得就是离上点最近得点，如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外。

内点：域内得任意点都是内点。注意：边界值取值的数据都会作为单独的一条测试用例出现

举个例子：

[66, 88]
   上点就是66，88并且都是在域内。内点就是域内得任意点，离点是65，89

 (66，88)
     上点还是66，88只是都是在域外，内点还是域内得任意点，离点为：67，87

(66，88]
   上点是66，88其中一个是域内，一个是域外，内点就是域内得任意点，离点是：67，89
 

1. 两个1-100之间整数的和
2. 出现边界值错误本质原因

边界值分析法总结

边界值适用范围：

只要在题目条件中存在边界

边界值分析法往往和等价类划分法一起使用

判定表法

一、什么是判定表法？

适用范围：适用于多个输入和多个输出，而且输入和输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系的这种

二、为什么要用判定表法呢？

等价类划分法 和边界值分析法 只适用于单个输入的这种情况，他们没有考虑输入和输出的各种组合情况。

三、判定表有四个组成部分

1条件桩：题目条件中的输入

2动作桩：题目条件中的输出

3 条件项：输入对应的取值

4 动作项：输出对应的取值

四、如何使用判定表去设计测试用例？

1明确条件桩

2 明确动作桩

3 对条件桩全组合

4明确每个组合对应的动作桩

5一列就是一条测试用例

等价类划分法和边界值分析法区别

1. 等价类划分适用于有单个输入的情况
2. 边界值分析法适用于题目条件中有边界的情况
3. 边界值分析法适用于单个输入
4. 边界值分析法往往和等价类划分法一起使用

判定表法和边界值法区别

1. 判定表适用于有多个输入和多个输出，输入和输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系
2. 边界值分析法适用于题目条件中有边界的情况
3. 边界值分析法适用于单个输入
4. 判定表法有四个组成部分，分别是条件桩，动作桩，条件项，动作项

因果图法

1. 因果图法是什么？

因果图法是一种利用图解法来分析输入的各种组合情况，从而设计测试用例的方法。

因果图法适用于有多个输入和多个输出，而且输入和输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系

因果图法是通向判定表法中的一个中间过程。

判定表法：

1 明确条件桩

2 明确动作桩

3 对条件桩进行全组合

4 明确每个结果对应的动作桩

1. 编写测试用例

因果图的核心：

第一个核心是因。 因代表的是输入。

第二个核心是果。 果代表的是输出。

因果图中的基本符号

1 恒等（=）。原因出现，则结果出现，原因不出现，则结果不出现。

2 非（~）：不是。原因出现，结果不出现，原因不出现，结果出现。

3 或（V）：或者。or。当众多原因中有一个存在的时候，那么结果也会存在。当众多原因中没有一个存在的时候，那么结果就不会存在。

4 与（^）:而且。当众多原因中都存在的时候，那么结果才会存在。当众多原因中，有一个不存在，那么结果页不会出现。

因果图的画法

1. 标识输入和输出

备注：用文字表示输入和输出

1. 画出因果图

1. 画出判定表

正交法

对于一个小小的字符属性设置程序而言，就有9*9=3^4=81条测试用例

那么有没有一种方法能够使用最小的测试过程集合获得最大的测试覆盖率呢？

正交法-定义

定义：使用最小的测试过程集合获得最大的测试覆盖率。

大白话：测试用例的条数少一点，测试出来的bug多一点。

正交法又叫正交实验法，又叫正交排列法

正交表的概念

一、正交表是一种特制的表。用:Ln(mk)来表示

1 L:line 行数 测试用例的行数

2 n:number 数量 测试用例的数量

3 k:控件的个数 k因素

4 m:每个控件下对应的取值个数 m水平

k因素m水平

 举例：L9(34)

4个控件

3个取值

9条测试用例

4因素3水平

使用正交法设计测试用例

一、使用正交法设计测试用例步骤：

1 根据需求形成因子状态表。因子：控件 状态：控件下的取值

2 确定所用的正交表

3 将正交表中的字母用文字代替

4 设计测试用例 一行就是一条测试用例

1 根据需求形成因子状态表。因子：控件 状态：控件下的取值

2 确定所用的正交表

3 将正交表中的字母用文字代替

4 一行就是一条测试用例

标准的正交表对应的工具—正交设计助手

1、新建

1. 点击实验-新建实验

1. 在弹出的设计向导中分别填写对应的描述（标准正交表），正交表，因素与水平

4、 点击确定

5、 输出 ---保存为.csv的文件

场景法

1 定义

适用于多个功能间的组合测试。

2 为什么要引出场景法

从用户角度出发：用户平时使用的都是多个功能

从测试人员自身出发：保证测试的全面性

3 场景法两个重要的概念

基本流：从头到尾流程都是正确的

备选流：从头到尾功能中某一个流程出现了错误

如何使用场景法去设计测试用例？

1 确定项目角色

2 确定该角色的常用功能

3 根据需求构建测试场景

4 一条场景就是一条测试用例

流程图法（功能图法）

流程图法中一条路径就是一条测试用例。

注意：流程图法在去设计测试用例的时候，要尽可能全面的覆盖所有的路径分支。

流程图法适用范围：

1 适用于多个功能间的组合测试

2 在冒烟测试时经常使用

错误推测法

利用测试人员的经验，找到软件中经常出错误的地方，去设计测试用例的一种方法。

适用范围：项目紧，任务急