千峰教育-01-通用测试技术

1-通用测试技术

01-软件和软件分类

软件：控制计算机硬件的工具

• 程序
• 数据
• 文档

软件分类：

• 按层次划分：应用软件、系统软件
• 按组织划分：商业软件、开源软件【源代码开放】
• 按结构划分：单机软件、分布式软件

02-缺陷的定义

所有不满足需求或者超出需求的都是缺陷。

没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。

1.软件未实现产品说明书要求的功能-少功能
2.软件出现了产品说明书中指明不该出现的错误-功能错误
3.软件实现了产品说明书未提到的功能-多功能
4.软件未实现产品说明书虽未明确提及但应该实现的目标-隐藏功能错误
5.软件难以理解，不易使用，运行虽慢，用户体验不好-不易使用

03-软件测试的由来

• 起源于上世纪70年代中期
• 计算机是1945年由来的

软件测试：利用技术手段验证该软件是否满足使用要求
软件测试目的：减少软件缺陷，保障软件质量

04-缺陷的由来

缺陷的英文单词表示：

• bug
• defect

05-软件测试的定义1

正向思维

• 出发点：证明软件没有问题为目的的任何行为。

反向思维

• 出发点：以发现软件错误而执行一个系统的过程，测试是为了证明这个程序有错，而不是证明程序无错误。
• 一个好的测试用例是在于可以发现以前未发现的错误
• 一个好的测试是为了发现以前未发现的错误的测试

06-软件测试定义2

IEEE定义的测试

• 在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或者构件的某些方面给出评价【看运行过程是否章程】
• 分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性【看整个项目的研发过程是否符合要求】

广义软件测试定义：

对软件形成过程中的所有工作产品（包括程序和文档）进行的测试，而不仅仅是对程序的运行进行测试。

• 确认
• 验证

07-软件测试的目的

软件测试目的：减少软件缺陷，保障软件质量

• 以最少的人力和物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误得以修复，避免软件发布之后潜在的缺陷带来的商业风险。

08-测试和调试的区别

• 在主体、目标、方法都不同

• 测试是在已知的条件开始，使用预先定义的过程，并且有预先的结果；调试是从未知的条件开始，结束的过程可能不可预计
• 测试可以计划，可以预先制定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间相对比较困难
• 测试的对象包括软件开发过程中的文档，数据以及代码，而调试的对象一般只是代码

2-通用测试技术

01-软件工程

软件危机：是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

软件工程：

• 软件开发技术：软件开发方法学、软件工具和软件工程环境。
• 软件项目管理：软件质量，项目估算、进度控制、人员组织、配置管理、项目计划

02-软件测试开发模型

1.需求分析
2.概要设计
3.详细设计
4.编码
5.测试
6.验收测试

瀑布模型

1.可研与计划---项目计划
2.需求分析----需求规格说明书
3.概要设计
4.详细设计
5.编码
6.测试
7.运行/维护

最早提出软件开发的过程模型。

缺点【存在的问题】：

1. 强调时间顺序非常严格，前面阶段不完成，后面阶段无法进行，缺乏灵活性
2. 将测试放在了编码之后，没有体现出测试贯穿软件生命周期的原则，测试应该从需求就开始参与进去–可以避免需求的问题一直延续到代码完成之后才暴露或被发现。
3. 不适合用户需求的变化，因为不是从需求开始的，用户改了需求之后要编码完成才可以修改。

优点：

1. 为项目提供了按阶段划分的检查点，有一定的文档产出，可以从文档中去寻找问题。
2. 当前阶段完成后，只需要去关注后续阶段。

螺旋模型

• 螺旋模型是一种演化软件开发过程模型，引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。
• 螺旋模型更适合大型的贵的系统级的软件应用。

迭代模型

发布的软件就是可以运行的，在初级版本进行深入的研发，类型于更新。

在某种程度上、开发迭代是一次完整的经过所有工作流程的过程。

优点：

• 降低了在一个增量上的开支风险
• 降低了产品无法按照既定进度进入市场的风险
• 加快了整个开发工作的进度
• 迭代过程这种模式使适应需求的变化更容易些

敏捷开发模型

增量模型

含义：把软件分割成独立的模块，分批次的完成和交付。

缺点：打破原有的软件结构和框架，可能会带来一定的风险。

增量模型一般和迭代模型一起使用。

• 软件增加了新功能
• 优化了…功能
• 修复了某些未知/已知bug

【增量模型是增加功能、迭代模型是更新优化模型】

快速原型模型

原型：模型（可以模拟 操作/简单运行）

典型应用和工具：Axure：制作原型。

3-通用测试技术

软件测试流程

• 获取测试需求
• 编写测试计划
• 制定测试方案
• 开发和设计测试用例
• 执行测试
• 提交缺陷报告
• 测试分析与评审
• 提交测试报告
• 准备下一版本测试

软件测试过程模型

V模型

【V模型是线性的操作方式】

优点：

验收测试的标准是用户的需求，用户需求对应指导验收测试的效果，每个阶段都有相对应的阶段。

缺点和不足：

• 软件测试没有尽早介入项目
• 需求的满足情况一直到后期的验收测试才被验证
• 忽略了测试对需求分析、系统设计的验证

W模型

两个V模型组成，一个V是软件测试全过程，一个V是软件开发全过程，明确表示出了测试与开发的并行关系。

优点：

• 测试的活动与软件开发同步进行
• 测试对象不仅仅是程序，包括需求和设计
• 尽早发现软件缺陷可降低开发的成本

缺点：

• 在W模型中、需求，设计，编码等活动被视为串行的，这样无法支持灵活的迭代。

H模型

h模型只针对测试的流程，软件测试是一个独立的流程！

h模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动就可按照某个次序先后进行，也可以反复进行。

X模型

X模型中定位了探索性测试，这是不进行事先计划的特殊类型测试，可以帮助有经验的测试人员在测试计划之外发现更多的软件错误。

测试过程（独立性）

A.研发团队内部的测试岗位

B.企业内部的独立于研发部门的测试岗位

C.专门的测试外包公司岗位

D.开发人员自己测试

由高到低：

C>B>A>D

软件测试过程理念

• 尽早测试
  • 测试人员尽早参与软件项目
  • 尽早的开展测试执行工作
• 全面测试
  • 对软件的所有产品进行全面的测试
  • 软件开发及测试人员（有时包括用户)全面的参与到测试工作中
• 全过程测试
  • 测试人员要充分关注开发过程
  • 测试人员要对测试的全过程进行全程的跟踪
• 独立的、迭代的测试
  • 测试活动是独立的
  • 测试活动应该是循环往复、不断的进行

测试作业面试题

4-通用测试技术

软件测试分类

按照开发阶段划分

• 单元测试

  单元测试一般要读程序和代码，单元测试都是由开发自己去做，（交叉完成），一般不认为是在做测试。

  测试人员为什么不做单元测试【因为看不懂代码】

  单元测试-模块测试。是软件测试的最小单位，目的在于检查程序单元能否正确实现详细设计说明中的模块功能。需要从程序内部结构出发设计测试用例，多个模块可以平行的独立的进行单元测试。【post隐藏数据，get显示数据】

• 集成测试

  集成测试-组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的，递增的测试。要检测程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件和整个系统。

  比较多的涉及到接口测试（接口测试工具和方法专门学习），企业非常需要接口测试工程师，是一个不断持续不断的过程。

• 确认测试

  确认测试-有效性测试。【功能是否实现、一般都是正向的测试】。确认测试通过才可以进行系统测试，有些地方把确认测试也叫“冒烟测试”，一般不作为正式的测试阶段。

• 系统测试

  全面的，系统所有功能的测试，模拟所有的软件用户的操作；全方位，和硬件的联系。

  在真实的系统运行的环境下，检查完整的程序系统和能否和系统正确配置、连接，并满足用户的所有需求。

• 验收测试

  一般供求双方。一般有三种验收测试的主体：

  a测试：软件的开发商自己进行的交付前的测试

  b测试：软件的需求放自己进行的测试

  r测试：第三方的软件测试

按照测试技术划分【可见代码度】

• 黑盒测试

• 白盒测试

• 灰盒测试

  

黑盒测试看结果，白盒测试看过程。

按照代码运行划分

• 静态测试

  • 不实际运行被测对象，只能静态的检查程序代码，及文档中可能存在错误的过程
  • 代码测试：主要测试代码是否符合响应的标准和规范
  • 界面测试：主要测试软件的实际界面与需求中的说明是否相符
  • 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求

• 动态测试

  指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以判断是静态还是动他的标准，在于判断是否运行程序。

按照软件特性划分

• 功能测试
• 性能测试
• 安全性测试

其他测试类型

• 回归测试

  • 在新版本的软件中重复之前测试的用例
  • 目的：
  • 1.验证之前版本的bug是否被修复
  • 2.确认修复这些缺陷没有引起新的缺陷

• 冒烟测试

  验证软件的基本功能是否实现，是否具备可测性，也叫可测性测试

• 随机测试

  测试人员基于经验和直觉的测试，发现一些边缘性的错误

• 猴子测试

  把自己当成是小孩，乱点，在这途中，让一些意想不到的操作造成错误的结果。

软件测试原则

• 所有的测试的标准都是建立在用户需求上
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间与质量冲突，时间要服从质量
• 事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估
• 软件项目一启动，软件测试就是开始，而不是等程序写完，才开始测试
• 穷尽测试是不可能的
• 第三方进行测试会更客观，更有效
• 软件测试计划是做好软件测试工作的前提
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性
• 应该把尽早和不断地测试作为座右铭

5-通用测试技术

测试用例：设计一个情况，软件程序能在这种情况下，能够正常运行并且达到程序所设计的预期结果。

测试用例模板

• 用例编号
• 用例标题
• 所属模块
• 优先级
• 前置条件
• 测试步骤
• 测试数据
• 预期结果

用例设计和编写的作用

• 有效性：测试用例是测试人员测试过程中的重要参考依据
• 可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率
• 易组织性：即使是小的项目，也可能会有几千年甚至更多的测试用例，测试用例可能在后面的测试过程中被创建和使用
• 可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证
• 可管理性：测试用例也可以作为检验测试人员进度，工作量以及管理测试人员工作效率的标准。

黑盒测试用例设计方法

【测试数据选择用等价类和边界值】

等价类划分法

将程序的输入划分为若干部分，然后从每个部分选取少数代表性数据作为测试用例。

等价类划分原则：

1.一个文本框，字符个数为6-8位
有效：范围内个数
无效：2个：小于6或者大于8
2.请输入11位手机号
有效：11位
无效：不是11位

等价类步骤：

1.有效等价类

2.无效等价类

百度注册需求用例设计

用户名：设计后不可更改，中英文均可，最长14个英文或7个汉字【用户名不可重复、不可为空】
手机号：11位手机号码
密码：长度为8-14个字符，字母/数字以及标点符号至少包含2种，不允许有空格、中文

有效	无效
中文、英文	数字、特殊符号
14英文/7中文	英文超过14/中文超过7
不能为空	空
不能重复	重复数据

用例问题

1.用例按照测试分类：功能、界面、性能、安全、接口

2.测试项必须是确定的。测试项中可以不写目的产生的结果。

3.身份证业务知识，最后一位是校验码（0~9，X）,身份证号（新版和旧版），数字和X，并没有字母。

4.测试步骤。表明操作的对象和方式，数据。

5.测试数据。没有数据，空着不写。

边界值法

边界值只是一个特定的数据。例如：文本框需要输入6-18位字符。

边界值有：

• 6个字符
• 18个字符

次边界，边界附近的值，按照系统规定的单位或者计算方式，一个数据的差异。

则6-18位字符，需要找：5，6，7，12，17，18，19.

面试题：【开内闭外】

（1）6《x《12 ,请问测试中x的边界值要选取哪几个进行测试
答案：5，6，9，12，13
（2）6<x<12 ,请问测试中x的边界值要选取哪几个进行测试
答案：6，7，9，11，12
（3）有一个文本框，输入文本的要求是不大于150字。
答案：取值范围是（0，150],那么边界值取0，1，75，150，151

6-通用测试技术

三角形用例实战

一个程序读入三个数，把这三个数看作一个三角形的三条边的长度值。输入三条边的长度，可以判断是普通的，等腰的，直角的，还是等边的。
（1）构成三角形：任意两边之和大于第三边
（2）直角
（3）等腰
（4）等边
（5）钝角
（6）锐角

首先是利用等价类划分法进行划分：

再对边界值进行划分：确认边长最大为多少？

7-通用测试技术

因果图法

• 是一种适合于描述对于多种输入条件组合的测试方法
• 根据输入条件的组合，约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法
• 它适合于检查程序输入条件涉及的各种组合情况

1.原因和结果的关系：

或：原因abc三者只要有一个成立，则d就成立

与：原因abc三者必须都成立，d才成立

2.原因之间的约束【假如原因成立用1表示，不成立用0表示】

（1）互斥（edusive）。A+B+C=<1

（2）包含（include)。3>=A+B+C>=1

（3）唯一(only)。A+B+C=1

（4）要求(request)。若A=1，要求B成立为1，比如原因A是发送验证码，那么原因B是手机号填好

3.结果之间的约束【假如结果成立用1表示，不成立用0表示】

（1）屏蔽(mask)。结果之间会出现A结果出现，B结果一定不出现。当你收到注册成功的提示，就不会收到数据填写错误的提示。

因果图案例

有一个饮料自动售卖机（处理单价为5角钱）的控制处理软件，如下：
1.若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就会送出来
2.若投入1元钱的硬币，同样按下“橙汁”或“啤酒”的按钮，则相应的饮料就会送出来的同时退回5角钱的硬币

分析原因和结果：

画出原因与结果，原因与原因，结果与结果之间的关系：

因果图使用中的局限性，当原因和结果很多的时候，就会导致关系连线很多，可读性低，因此作为局部的小功能。

列出所有的原因和结果的列表 ，设计初步的测试用例步骤

判定表法

应用场合：主要适用于多条件的内容组合和结果分析

条件桩：列出了所有的问题的条件，类似于因果图的原因。

动作桩：列出了所有问题会产生的操作，类似于因果图的结果。

条件项：列出针对它左列条件的真假取值。

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

判定表的步骤

• 第一步：确认规则的个数

  • 假如有n个条件，每个条件有两个取值(0，1)，故有2^n种规则

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

  • 填入条件项
  • 填入动作项，制定初始判定表

• 第三步：简化，合并相似规则或者相同动作

重点

测试用例的设计方法，没有哪一种方式是单独使用的

（1）所有的软件，都是因为某种操作才会导致一定的结果------考虑使用因果图

（2）所有的软件都有文本框--------考虑一定使用等价类、边界值

（3）

判定表实例

（1）合并1，2，3，4为一项，在疲倦的情况下，一律休息即可

（2）合并7，8为一项，在都不疲倦的情况下，不感兴趣就跳下一章

场景法

• 现在的软件几乎都是事件触发来控制流程的。测试时，可以生动的描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
• 基本流：软件功能按照正确的事件流实现的一条正确流程，通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点
• 备选流：除了基本流之外的各支流，包含多种不同的情况
• 场景列表：
  • 场景1 基本流
  • 场景2 基本流 备选流1
  • 场景3 基本流 备选流1 备选流2
  • …

场景法分析

重点:

基本流（软件功能能正确实现的流程）

备选流（基本功能流程之外的过程）

注意：

1.场景中必须要有基本流

2.场景中必须要有内容从用例的开始，到用例的结束

案例：ATM取款机的案例

基本流：

包含备选流：

场景:

基本流：插卡-输入密码-选择取款服务-选择取款金额-等待出钞-取出卡片

备选流：

1.卡片不是银行卡

2.卡片不是银联的卡

3.密码输错一次

4.密码输错两次，第三次输入正确

5.密码输入错误三次，冻结账号或者吞卡

6.选择存款服务

7.选择查询服务

8.选择转账服务

9.选择修改密码服务

10.选择取款金额

11.选择其他金额

12.账户金额不同

13.ATM机没钱了

14.账户取款金额达到取款机的当日取款上限

15.账户取款金额达到账户当日取款交易上限

16.取款机掉线了

17.取款机停电了…

场景设计：

1.场景1 ：基本流

2.场景2： 基本流 备选流4

3.场景2： 基本流 备选流5

…

8-通用测试技术

正交实验法

使用的工具：正交表

统计和分析实验数据，从大量实验中找出合适的实验数据组合。

大量的实验组合中，挑选一部分具有代表性的点，进行试验，分析实验。

实施步骤

• 分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框，按钮的需求）
• 分析每个因素的水平数量，充分利用等价类，边界值（需求中的说明和未说明的都要分析）
• 选择正交表。只有特定的因素数和水平数的组合才有对应的正交表

正交案例

完全的排列组合：333=27

功能图法

功能图法步骤

• 识别和列举所有的输入（操作）事件，以ip N（input）（N=1，2，3）
• 定义空闲状态（初始状态），一般以软件启动的时候就叫空闲状态
• 为空闲状态加操作（只加一次）
• 为第三步所产生的新状态加操作（只加一次，并且曾经加过的操作，不再重复添加）
• 循环为所有的新增状态加操作，直到没有新状态产生为止
• 组合任意的状态，以列表的形式展现，设计和编写测试用例

用例设计方法综合选择

• 首先进行等价类划分
• 在任何情况下都必须使用边界值划分法
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
• 对于参数配置类的软件，要用正交实验法选择较少的组合方式达到最佳效果
• 可以使用错误推测法追加测试用例

9-通用测试技术

缺陷的定义

1.软件未实现产品说明书要求的功能-少功能
2.软件出现了产品说明书中指明不该出现的错误-功能错误
3.软件实现了产品说明书未提到的功能-多功能
4.软件未实现产品说明书虽未明确提及但应该实现的目标-隐藏功能错误
5.软件难以理解，不易使用，运行虽慢，用户体验不好-不易使用

缺陷的属性

属性名称	描述
缺陷类型（type）	自然属性划分的缺陷种类
缺陷严重程度（Severity）	因缺陷引起的故障对软件产品的影响程度
缺陷优先级（Priority）	缺陷必须要被修复的紧急程度
缺陷状态（Status）	缺陷通过一个跟踪修复过程的进展情况
缺陷起源（Origin）	引起的故障和事件第一次被检测的阶段
缺陷来源（Source）	缺陷的起因
缺陷根源（Root Cause）	发生错误的根本因素

缺陷的分类

缺陷类型	描述
功能（Function）	正向的注册功能无法实现就是功能缺陷
界面（UI）	界面太丑，颜色不好区分
文档（Documentation）	影响发布和维护，包括注释，用户手册，设计文档
软件包	比如按理生成5个文件，实际只有3个文件
性能	不满足系统可测量的属性值，如执行时间，事务处理率等
系统/模块接口	与其他组件、模块或者设备驱动程序、调用函数等

注意：需求分析，设计阶段，文档类型缺陷多；集成测试阶段，一般接口类型的缺陷多一点；系统测试阶段，功能、界面类型的缺陷多一些；验收测试阶段，更多关注性能缺陷；实施过程，可能遇到的是软件包的缺陷。

缺陷的严重程度

缺陷严重等级	描述
致命	用户数据据受到损坏，死机，悬挂等
严重	主要功能丢失，数据不能保存
一般	系统次要功能没有实现，但是不影响用户的正常使用
较小	操作不方便或遇到麻烦，但是不影响功能的操作和执行

缺陷修复的优先级

缺陷优先级	描述
立即解决（P1级）	系统注册功能无法使用（无法登录，购买，结算，支付等功能无法实现）
高优先级（P2级）	缺陷严重，影响测试，需要有限考虑
正常排队（P3级）	缺陷需要正常排队等待修复
低优先级(P4级)	缺陷可以在开发人员有时间的时候被纠正

面试提问

1.缺陷的严重程度和缺陷的优先级有什么关系？

• 二者之间没有任何直接的关系
• 不要认为严重的缺陷修复优先级就高
• 如果碰到，优先级和严重程度都高的缺陷，也只是偶然。例如，QQ的帮助按钮会有经常闪退的现象。严重程度很高，但是优先级就很低。[因为没啥人用]

2.提交缺陷时能不能夸大或者降低缺陷的严重程度和优先级？

• 不能。测试员要做到有原则，诚实，公平客观
• 不能私人关系”帮“好友减少不良影响
• 不能”狼来了"

缺陷状态

缺陷状态	描述
激活或打开（open）	【测试人员】等待提交的缺陷，等待处理，存在源代码中
已修正或修复	【开发人员】被开发人员检查和修复的缺陷，通过单元测试认为已解决但是还没有被测试人员验证
关闭或非激活	测试人员验证之后，确认缺陷不存在的状态
重新打开	缺陷没有修复成功，需要重新打开
推迟	这个软件缺陷可以在下一个版本修复
保留	暂时修复不了，一般由开发人员设定，测试人员确认
不能重现	开发无法再现这个软件缺陷，需要测试人员检查缺陷复现的步骤
需要更多信息	开发能再现这个缺陷，但是开发人员需要一些信息，例如缺陷的日志文件，图片等
重复	这个软件缺陷已经被其他测试人员发现
不是缺陷	这个问题不是缺陷
需要修改软件规格说明书	由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书

缺陷的来源

缺陷来源	描述
需求说明书	需求说明书的错误和不清楚引起
设计文档	设计文档描述不明确，和需求说明书不一致
系统集成接口	各个模块参数不匹配，开发组之间缺乏协调引起的缺陷
数据流（库）	数据字典，数据库错误
程序代码	代码编码问题

缺陷的生命周期

• 发现缺陷和提交缺陷是测试人员；
• 确认缺陷是测试主管，或者产品经理确认；
• 分配缺陷是经确认之后，有效的缺陷会指派给相关人员进行处理，一般由谁确认的缺陷就由谁分配，分配的对象也有可能是开发，也可能是产品经理。
• 修复缺陷是主要有开发修复，也有可能是产品经理修复问题
• 验证修复是测试去验证缺陷有没有修复成功。
• 关闭缺陷是测试人员进行，否则出了问题，测试认识一律不背锅。

面试提问

针对你工作中发现的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）

回答前面的缺陷的生命周期

缺陷的识别

依据：需求文档、设计文档、产品原型、测试用例、都是客观的依据

同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通

测试人员在识别缺陷的时候，要很灵活的对待

缺陷报告

• 缺陷编号 BUG-项目名称-模块名称-功能名称-001
• 缺陷标题
• 缺陷所属模块。一级/二级/三级
• 缺陷状态
• 严重程度
• 优先级
• 缺陷描述
• 附件

缺陷跟踪流程

测试是黄色的，开发是绿色的。

提交缺陷注意事项

1.可复现

2.唯一性

3.规范性

面试题：当你发现缺陷后，首先会怎么办？

首先保证缺陷可复现，确认是bug，

提交时：要检查缺陷是否已存在。

缺陷编写规范

1.准确

2.具体

3.简洁易懂

4.次序清晰

需求，用例，bug的关系

测试的基本流程：获取测试需求-编写测试计划-制定测试方案-设计和开发测试用例-执行测试**-提交缺陷**-测试分析和评审-测试总结-准备下一版本的测试

获取测试需求：

（1）分析出系统的模块和组织结构

（2）分析出软件的基本功能和运行流程。

（3）识别软件的重要功能和次要功能

测试中，最能体现测试人员工作量的指标是缺陷的数量和用例的数量

（1）设计的测试用例数量

（2）执行的测试用例数量

（3）执行通过的测试用例总量

（4）执行失败的测试用例总量

（5）提交缺陷的总量

**提交bug数量多于执行未通过的用例数量。**一条用例的预期结果数量是固定的（甚至是唯一的）。测试过程中，发现的缺陷，除了一部分是用例执行带来的，还有一部分是测试人员本身经验和直觉带来的。