测试开发-测试基础

一、测试基础

软件测试基础

什么是软件测试？
软件测试时软件形成过程的文档、数据以及程序进行的测试。

软件测试的目的
测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修复各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

就业方向该如何选择

方向（一）：功能测试+接口测试
方向（二）：功能测试+性能测试
方向（三）：功能测试+web自动化

功能测试：
测试主要验证程序的功能是否满足需求

自动化测试：
使用代码或工具代替手工，对项目进行测试

接口测试：
使用代码或工具验证程序中的接口是否访问正常

性能测试：
模拟多人使用软件，查找服务器缺陷

测试分类

按阶段划分
单元测试：针对程序源代码进行测试
集成测试：针对程序接口进行测试
系统测试：针对程序功能、非功能进行测试
验收测试：使用不同用户（内测、公测）进行测试

按代码可见度划分
黑盒测试：不关注源代码，针对程序UI功能进行测试
灰盒测试：针对程序部分代码进行测试（接口）
白盒测试：针对程序源代码进行测试

其他
性能测试：归属专项测试
自动化测试：归属功能测试

测试流程

需求评审、编写测试计划、用例设计、用例执行、缺陷管理、测试报告

测试用例

1、什么是用例
用例：用户使用的案例

2、什么是测试用例
测试用例：是为测试项目而设计的执行文档

3、测试用例的作用

• 防止漏测
• 实施测试的标准

4、用例设计编写格式

• 用例编号：项目_模块_编号
• 用例标题：预期结果（测试点）
• 模块/项目：所属项目或模块
• 优先级：表示用例的重要程度或者影响力P0～p4 (P0最高)
• 前置条件：要执行此条用例，有哪些前置操作
• 测试步骤：描述操作步骤
• 测试数据：操作的数据，没有的话可以为空
• 预期结果：期望达到的结果

二、测试用例设计

黑盒测试用例设计

测试策略
测试用例设计方法可以组合为一个整体的策略，因为每一种方法都可以提供一组具体的有用的册数用例，但是都不能提供一个完整的测试用例集。

一组合理的策略如下：
1、如果规格说明包含输入条件组合的情况，应首先使用因果图分析法。

2、任何情况下都应使用边界值分析法，边界值分析法可以产生一系列补充的测试条件，多数甚至全部条件可以被整合到因果图分析中。

3、为输入和输出确定有效和无效等价类，在必要情况对上面确认的测试用例进行补充。

4、使用错误猜测增加更多的测试用例。

5、针对上述测试用例，检查程序的逻辑结构，如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能，那么增加足够数量的测试用例，以使覆盖准则得到满足。

1、等价类划分

1）确定等价类

有效等价类代表对程序的有效输入；无效等价类代表的是有其他不正确的任何输入。如果需要，我们还可以将一个等价类划分为更小的一些等价类。

比如，规格说明规定了“请输入书籍的数量（1~99）以及书籍的类型（硬皮、软皮或活页）”。它们对应的等价类分别如下：

书籍数量：

无效等价类	有效等价类	无效等价类
X<1	1<=X<=99	X>99

书籍类型：

有效等价类	有效等价类	有效等价类	无效等价类
硬皮	软皮	活页	其他

2）生成测试用例

1.为每个等价类设置编号

输入条件	有效等价类	无效等价类
书籍数量	a 1<=X<=99	b X<1 c X>99
书籍类型	d 硬皮 e 软皮 f 活页	g 其他

3）适用场景
针对：需要有大量数据测试输入，但是没法穷举测试的地方。

• 输入框
• 下拉列表
• 单选复选框

典型代表：页面的输入框类测试。

2、边界值分析法

1）、边界范围节点
选取正好等于、刚好大于、刚好小于边界的值作为测试数据。

• 上点：边界上的点(正好等于)
• 离点：距离上点最近的点(刚好大于、刚好小于)
• 内点：范围内的点(区间范围内的数据)

2）、边界值法设计用例步骤

1. 明确需求
2. 确定有效和无效等价类
3. 确定边界范围值
4. 提取数据编写测试用例

3）使用场景

• 在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
• 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语
• 典型代表:有边界范围的输入框类测试

3、判定表法

1）判定表法的引用

• 案例: 验证“若用户欠费或者关机，则不允许主被叫”功能的测试
• 说明：
  等价类边界值分析法主要关注单个输入类条件的测试
  并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试

2）、判定表定义及组成部分

• 定义：是一种以表格形式表达多条件逻辑判断的工具
• 组成：
  条件桩：列出问题中的所有条件，列出条件的次序无关紧要
  动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
  条件项：列出条件对应的取值，所有可能情况下的真假值
  动作项：列出条件项的、各种取值情况下应该采取的动作结果
• 规则:
  判定表中贯穿条件项和动作项的一列就是一条规则
  假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则

3）判定表法设计用例步骤

1. 明确需求
2. 画出判定表
   2.1列出条件桩和动作桩
   2.2填写条件项，对条件进行全组合
   2.3、根据条件项的组合确定动作项
   2.4简化、合并相似规则(有相同的动作)
3. 根据规则编写测试用例

4）使用场景

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
• 判定表一般适用于条件组合数量较少的情况(比如4个条件以下)

5、场景法

扩展：流程图
使用标准图形和箭头来表达程序或业务的走向

流程图对测试人员有什么作用？
1、能够看懂流程图，设计业务用例
2、当需求文档信息不全是，能够根据需求，梳理出流程

1）、介绍

• 说明：
  场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例
• 意义：
  用户使用角度:用户平时使用的不是单个功能，而是多个功能组合起来进行使用
  测试人员角度:平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

2）、适用场景
根据实际的应用场景，来测试业务用例，可以使用场景法

6、错误推荐法

1）定义
通过经验推测系统可能出现的问题

2）思想
根据经验列举出可能出现问 题的清单，根据清单分析问 题可能原因，推测发现缺陷

3）场景
1、时间紧任务量大时，根 据之前项目类似经验找出易 出错的模块重点测试
2、时间宽裕通过该方法列 出之前出现问题较多的模块 再次测试

三、缺陷介绍

1、缺陷的定义

软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

2、缺陷的判定标准

• 软件未实现需求(规格)说明书中明确要求的功能–少功能
• 软件出现了需求(规格)说明书中指明不应该出现的错误-功能错误
• 软件实现的功能超出需求(规格)说明书指明的范围-多功能
• 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求–隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用

3、缺陷产生的原因

需求阶段：需求描述不易理解，有歧义、错误等。
设计阶段：设计文档存在错误或者缺陷。
编码阶段：代码出现错误。
运行阶段：软硬件系统本身故障导致软件缺陷。

4）软件缺陷类型

• 功能错误
• 界面（UI）错误
• 兼容性
• 数据
• 易用性
• 改进建议
• 架构

四、项目实战

1、需求·发布文章

2、测试点提取

思路： 1、UI原型覆盖 2、规则覆盖 3、兼容性覆盖

3、设计用例

页码： 1 2