软件测试初步学习

软件缺陷的定义：

1.所有不满足需求或超出需求的都是缺陷；

2.没有不存在缺陷的软件，只是还没发现

广义软件测试定义

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

确认Validation

• 通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现

验证Verification

• 通过检查和提供客观证据来证实指定的需求是否满足

软件生命周期模型

1. 瀑布模型

   1. 强调时间顺序的严格执行，前阶段不完成，后阶段不开始

   2. 将测试放在编码之后。没有体现出测试贯穿软件生命周期的原则，可以避免需求问题一直延续到代码完成才暴露或者被发现

   3. 线性开发，用户末期才能看到开发成果，增加了开发风险

   4. 瀑布模型不适应用户需求的变化

2. 快速原型

   原型就是一个可以模拟操作、简单允许的模型，使用户和开发者可以对目标系统的概貌进行评价和判断

3. 增量模型

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

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

   一般会和迭代模型一起运用。

4. 迭代模型（优化）

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

5. 螺旋模型

   兼顾了快速模型店迭代特征以及瀑布模型店系统化与严格监控

   1. 引入风险分析
   2. 更适合大型的昂贵的系统级的软件应用

6. 敏捷开发模型

   敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

   1. 敏捷开发的高适应性，以人为本的特性。
   2. 更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

   缺点：

   1. 由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

一、软件测试流程

   获取测试需求 --> 制定测试方案 --> 开发与设计测试用例 --> 执行测试 --> 提交缺陷报告 --> 测试分析与评审 --> 提交测试总结 --> 准备下一版本测试

二、软件测试过程模型

1. V模型

   没有体现出“尽早地和不断地进行软件测试”的原则

2. W模型

   由两个V字模型组成，表示测试与开发的并行关系
   

3. H模型

   将测试活动完全独立开来（外包公司）

4. X模型

   探索性测试

软件测试过程理念

• 尽早测试

  • 测试人员早期参与软件项目

  • 尽早的开展测试执行工作

• 全面测试

  • 对软件的所有产品进行全面的测试

  • 软件开发及测试人员（有时包括用户）全面的参与到测试工作中

• 全过程测试

  • 测试人员要充分关注开发过程
  • 测试人员要对测试的全过程进行全程的跟踪

• 独立性、迭代的测试

  • 测试活动时独立的
  • 测试活动应该时循环往复、不断的进行

一、软件测试分类

1.按照开发阶段划分

• 单元测试

  又称模块测试，针对软件设计的最小单位。对程序模块进行正确性检验的测试工作。
  一般需要读程序和代码，了解程序内部结构。

• 集成测试

  比较多的涉及到接口测试，持续不断的过程

• 确认测试

  冒烟测试，在进行系统大规模测试之前，验证软件最基本的功能进行，保证基本的功能和流程能走通。

• 系统测试

  是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接。并最终满足用户的所有需求。

  全面的、全方位的，和硬件系统的联系，和系统软件的联系，和其他软件的关系

• 验收测试

  一般供求双方。

  • α测试：软件开发商自己进行的交付前都测试
  • β测试：软件需求方自己进行的测试
  • γ测试：第三方的软件测试

2.按照代码运行划分

• 静态测试

  代码测试：代码是否符合相应标准和规范

  界面测试：软件实际界面与需求相符

  文档测试：测用户手册和需求说明是否真正符合用户的实际需求

• 动态测试

  输入相应测试数据，检查实际输出和预期结果是否相符的过程。

  区分静态测试和动态测试，标准时看 是否运行程序

3.按照软件特性划分

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

4.其他测试

• 回归测试
• 冒烟测试
• 随机测试
• 猴子测试

软件测试的原则

• 所有测试的标准都是建立在用户需求之上
• 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。
  事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
• 软件项目一启动，软件测试也就开始，而不是等程序写完，才开始进行测试。
• 穷举测试是不可能的。
• 第三方进行测试会更客观，更有效
• 软件测试计划是做好软件测试工作的前提。
• 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
• 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。
• 重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）
• 应当把“尽早和不断地测试”作为测试人员的座右铭
• 回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见
• 测试应从“小规模”开始，逐步转向“大规模”。
• 不可将测试用例置之度外，排除随意性。
• 必须彻底检查每一个测试结果。
• 一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系
• 对测试错误结果一定要有一个确认过程

测试用例

1.什么是测试用例

简单地说，测试用例就是：

• 测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。 通常以表格形式存在。

• 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内

• 软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题己修改完成。

  测试用例需要经常更新么？(必须更新，尤其是发现过缺陷的测试用例。“杀虫剂效应”，一个发现过缺陷的测试用例，就相当于杀虫剂。必须使用“更强的杀虫剂”——新的测试用例（与之前的用例中数据类型保持一致）进行重新测试）

  用例设计和编写的作用

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

2.用例设计模板的说明

1、标识符（用例编号）:一般编号规则：TestCase-项目名称-模块名称-功能名称_0001
2、测试项。测试用例的测试目的。一般情况下，用一句话表明目的。例如：使用谷歌浏览器打开百度首页；在QQ登录界面输入正确的用户名密码能登陆上。（表明你的测试模块、测试对象、方式、事件。）

3、依赖用例：一般在流程上，下游的功能测试依赖于上游的功能测试的用例。例如：增加了一个数据的测试用例，将会被删除该数据的测试用例依赖。

4、测试步骤。用最朴实的语言，写出软件的操作步骤。要尽量详细

5、测试数据：单独整合测试数据。必须和测试步骤中的数据保持一致。

6、预期结果：准确、对象的准确，内容的准确性。原则上每一个操作，都要有一个结果。在重要的步骤之后，设定预期结果。一般和测试目的密切相关

7、测试结果。要求在测试执行完成后添加。没有执行保持为空。测试结果只有两个：通过/失败

8、测试人

9、备注：为了测试用例正常执行而做的特殊情况（如弱网、无网）

3.黑盒测试用例设计方法

等价类划分

• 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例
• 每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。
• 反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误

边界值分析法

• 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
• 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
• 分析规格说明，找出其他可能的边界条件

一 因果图法

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

因果图的优势在于够发现设计中存在的不足，例如在缺少输入时输出为何

二 判定表法

在一个程序中，如果输入输出比较多，输入之间和输出之间相互制约的条件比较多，在这种情况下应用决策表很合适，它可以很清楚地表达它们之间的各种复杂关系。

• 条件桩一列出问题的所有条件；

• 条件项一针对条件桩给出的条件列出所有可能取值；

• 动作桩一列出问题规定的可能采取的操作；

• 动作项一指出在条件项的各组取值情况下应采取的动作；

规则：任何一个条件组合的特定取值及其相应要执行的操作。在决策表中贯穿条件项和动作项的一列就是一条规则

三 场景法

1. 原理：

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

2. 设计用例的步骤

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

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

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

   • 对生成的所有测试用例重新复审，去掉多余的测试用例

   • 测试用例确定后，对每一个测试用例确定测试数据值

     场景法适用于解决业务流程清晰的系统或功能

一 正交试验法

• 概念：正交实验法就是利用排列整齐的表–正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最好效果。

• 这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格–正交表来安排试验并进行数据分析的方法。

• 基本思想：

• 在一项试验中,把影响试验结果的量称为试验因素(因子)，简称因素。在试验过程中,每一个因素可以处于不同的状态或状况，把因素所处的状态或状况，称为因素的水平，简称水平。

• 每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，能有效地比较试验结果并找出最优的试验条件。

• 在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中。

• 正交实验法实现的基本步骤

• 确定因素:这里的因素是指对软件运行结果有影响的软件

  确定因素的取值范围或集合(该步是为步骤3做准备的)

  因素的取值范围是指软件输入的取值范围或集合以及可用的硬件资源（不要放过文本框、按钮等需求中提及或者没有提及）

• 确定每个因素的水平
  根据因素的取值范围或集合,采用等价类划分、边界值分析以及其他软件测试技术,在每个因素的取值范围或集合内挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试值

• 选择正交表
  根据确定的因素和水平,选择适合的正交表
  如果没有合适的正交表可用或需要的测试用例个数太多要对因素和水平进行调整

• 正交表:一种特制的表,一般的正交表记为

  Ln(m^k)

• m是水平数,k是因素数,n是需要进行实验的次数(三者没有任何数学关系)n也是通过正交实验法设计的测试用例的个数

• 因素数:正交表中列的个数,即要测试的功能点。

• 水平数:任何单个因素能够取得的值的最大个数,即要测试功能点的输入值

• 正交表的种类：

  1. 各列水平数均相同的正交表
  2. 混合水平正交表

二 功能图法

功能图法又叫做状态迁移图。

• 来源：在遇到有事务流或由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦。
• 状态迁徒图法的目标
• 设计足够多的测试用例达到对系统状态的覆盖、状态–条件组合的覆盖以及状态迁移路径的覆盖

功能图法步骤

• 列出所有可能的输入事件，以ip N的方式命名（N1,2,3,4…)
• 把软件的打开的初始状态，定义为“空闲”状态
• 在“空闲”状态上加所有可能的输入（只加一次！)
• 为上一步产生的所有新状态，分别加所有可能的输入（只加一次！)
• 循环执行上一步
• 直到再没有任何新状态产生，列出所有的状态，生成状态表
• 组合任意可能的状态组合，写出相应的测试用例

三 其他用例设计方法

• 测试大纲法
  • 一种着眼于需求的方法
  • 进行详细的需求分析，将其转化为思维导图（树形结构）
  • 无需用例设计。一般从根节点开始分析，到叶节点为止。这样的一条路径就是一条测试用例。
  • 一般用于快速的测试和过程记录。
• 探索性测试法
  • 基于经验和直觉
  • 是计划内测试用例设计的补充
  • 也需要设计测试用例
• 猴子测试法（随意性测试）
  • 没有书面测试用例，测试往往不太真实
  • 许多测试都是冗余的，不能达到指定的覆盖度
  • 难以重现测试

四 用例设计方法综合选择

• 首先进行等价类划分
• 在任何情况下都必须使用边界值分析方法
• 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
• 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
• 状态迁徙图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
• 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
• 可以用错误推测法追加一些测试用例
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

如何对已有的等价类测试用例进行化简？

在有效域内利用强覆盖标准的等价类测试建立决策表的输入，然后对等价划分后的预期输出加以细化，建立决策表的输出，然后对输出相同、输入相似的测试用例加以合并，即可实现对等价类测试用例的化简。

注意：决策表不适用于输出，也不适用于无效域，当输入条件相互独立时，无需使用决策表。

一 缺陷

1.基本概述

1. 5大定义：

• 软件未实现产品说明书要求的功能
• 软件出现了产品说明书指明不应该出现的功能
• 软件实现了产品说明书未提到的功能
• 软件未实现产品说明书虽未明确提及但应该实现的目标
• 软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

2. 缺陷的属性：

缺陷类型（type）；缺陷严重程度（Severity）；缺陷优先级（Priority）；缺陷状态（Status)；缺陷起源（Origin）；

缺陷来源（Source）；缺陷根源（Root Cause）

3. 缺陷的类型

4. 缺陷的严重程度

   对软件使用功能的影响

   

5. 缺陷的修复优先级

   很大程度上取决于缺陷对测试工作的影响程度。

   

缺陷的严重程度和优先级的关系：

1）两者不存在必然的直接关系

2）也可以说严重性是空间维度、优先级是时间维度

6. 缺陷的状态

   指缺陷通过一个跟踪修复过程的进展情况

   

7. 缺陷的来源，起因

8. 缺陷的根源

   

二 缺陷的生命周期（bug处理过程）

1. 发现缺陷。由测试人员
2. 提交缺陷。由测试人员
3. 确认缺陷。一般由测试主管、或者质量保证（QA)、由产品经理进行确认。
4. 分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷就由谁分配。分配的对象可能是开发、也可能是UI、也有可能是产品经理。
5. 修复缺陷。主要由开发修复。被分配的对象修复
6. 验证缺陷。测试自己去验证缺陷有没有修复成功。
7. 关闭缺陷。只能是测试人员进行。（谁关闭谁负责）

三 缺陷的识别

• 通过测试用例中的预期结果进行识别
• 通过需求规格说明书进行识别
• 通过用户手册及其他文档进行识别
• 通过同行业相类似成熟的商业软件来识别
• 通过和开发人员的沟通进行识别
• 通过和有经验的测试人员沟通进行识别
• 参照同行业隐式需求进行识别

四 缺陷报告

• 缺陷报告编写目的

  • 易于搜索软件测试报告的缺陷
  • 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确
  • 软件开发人员希望获得缺陷的本质特征和复现步骤
  • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

• 预期读者

  • 开发人员、质量管理人员、市场人员、运维人员……

• 模板：

1. 缺陷编号。Bug_项目名称_模块名称_功能名称_0001
2. 所属模块。一级模块/二级模块/三级模块
3. 优先级。缺陷的修复紧急程度
4. 严重程度。S1>S2>S3>S4
5. 缺陷概述。用简单一句话描述缺陷的基本情况。
6. 缺陷的描述。将缺陷的复现步骤、预期结果和实际结果列出来。
7. 提交人。
8. 备注。一般写产生该缺陷的特殊情况。将bug的截图作为备注信息

• 缺陷报告编写准则

  • Correct(准确）:每个组成部分的描述准确，不会引起误解
  • Clear(清晰）:每个组成部分的描述清晰，易于理解
  • Concise(简洁）:只包含必不可少的信息，不包括任何多余的内容
  • Complete(完整）:包含复现该缺陷的完整步骤和其他本质信息
  • Consistent(一致）:按照一致的格式书写全部缺陷报告

• 缺陷描述的准则

1. 可以再现。针对最大多数的缺陷都是如此。但是有一小部分的缺陷难以收到（类似闪退、奔溃这种不可再现的缺陷，无须做到。针对可以重复出现的闪退也要进行步骤的详细描述）
2. 单一准确
3. 完整统一
4. 不做评价。不对缺陷的出现的严重程度和缺陷表现出来的效果进行主观臆断。
5. 补充完善
6. 特定条件

测试需求和测试用例、缺陷报告的关系？

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

• 获取测试需求是测试测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试方向和内容。例如:

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

2. 分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用。

3. 识别出软件的重要功能和次要功能。

获取测试需求的过程中，测试人员就要有相应的分析成果。一般用xmind这样的思维导图工具分析，或者使用需求跟踪矩阵来完成需求分析的获取和分析。

设定测试中需求的正、反向，优先级。

当有了测试需求后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点都要被测试

因此测试过程中，衡量需求的覆盖程度就非常重要。例如：

需求的覆盖程度=被测试用例覆盖的需求数/需求点总数

进行计算和说明。

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

1. 设计的测试用例总量。

2. 执行的测试用例数量。

3. 未执行的测试用例数量。

4. 执行通过的测试用例总量。

5. 执行失败的测试用例总量。

6. 提交的缺陷总量。

   以上六个数据符合如下的数量关系

   1 = 2 + 3

   2 = 4 + 5

   6 >= 5 提交bug的数量，多于执行未通过的用例数。一条用例的预期结果数量是固定的（甚至是唯一的）。但是会发现了用例预期之外的缺陷

   测试过程中发现的缺陷，除了一部分是用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的。

   通过通过执行的/执行的总数 可以表现出系统的质量是否合格。

   通过执行的用例/设计测试的总数 可以表现出系统的需求是否得到满足。