【笔记】软件测试1——基础

软件测试

一、软件测试基本定义

（一）什么是软件测试

使用人工或自动的手段来运行或者测试某个系统的过程，目的在于检验它是否符合规定的需求。弄清预期结果和实际结果的差别。

（二）软件测试的目的

以最少的人力、物力和时间找出软件中潜在的错误和缺陷

（三）软件测试原则

证明软件中存在缺陷
不能穷尽测试
测试应尽早介入
28原则（百分八十错误出现在百分之二十的地方，百分之二十的地方存在着百分之八十的错误；测试重点在于百分之八十的用户只用到百分之二十的地方，重点测试这百分之二十）
不存在缺陷谬论（不存在程序是没有错误的）
妥善保存一切文档

1.Testing shows presence of defects（测试显示软件存在缺陷）

测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。

2.Exhaustive testing is impossible（穷尽测试是不可能的）

现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

3.Testing early（测试尽早介入）

为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

4.Defect clustering（缺陷集群性（2/8原则））

缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。

一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

5.Pesticide Paradox（杀虫剂悖论）

反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug

为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。

测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

6.Testing is context dependent（测试活动依赖于测试内容）

根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

7.Absence of error - fallacy（没有错误是好是谬论）

有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。

（四）软件测试的标准

国际标准：ISO25010

国内标准：GBT20438、GBT18905

（五）软件测试的基本要求

外观界面测试
易用性测试
兼容性测试
安全性测试
性能测试
功能测试

（五）BUG的由来

bug：小虫子、小臭虫，现在指程序中的错误

二、测试与开发模型

（一）测试的工作流程

初级（黑色为甲方公司一般流程）：需求评审——指定测试计划——编写测试用例——测试评审——系统测试——测试报告——验收测试——完结

提高真实性：在流程的描述中添加细节点，变得可信，查看是否有接触测试

测试流程一般会先进行需求评审，参与到需求评审，在需求评审阶段，提出问题并进行需求的整改，

整改之后复评审，

确定需求定稿通过以后，结合项目的计划、技术内容，制定一个完整的测试计划，定好工作的内容；

定义完成后，根据需求文档来进行测试用例的编写；

编写测试用例之后，进行测试评审，测试评审的过程中，需要产品经理、开发相关人员、测试的相关人员等一起来做这个测试评审，由各方维度来评审测试覆盖面是否完成，业务流程是否能够很好的覆盖。

接着等待开发提交初版，进入到冒烟测试，通过冒烟测试来评估当前测试的版本的基本功能是否实现，正常流程是否实现，若是实现，则进入到系统测试，若是不通过，则返回给开发进行修改，提升代码质量；（下面的有冒烟测试的流程）

进入到系统测试，结合到之前定义的测试用例，对系统进行一个完成的版本的测试，测试完成后，将遇到的缺陷记录到缺陷管理工具里，后续会追踪开发，督促开发修改和跟进；

修改之后再根据版本再做迭代，一般迭代三到四个版本，让系统的功能稳定下来，然后再通过一两个小的版本的迭代，最终定好软件的质量；

基于最终的测试结果，生成一个测试报告；

测试报告生成后，评估系统是否达到发布的标准，达到则可上线。

初级（黑色为甲方公司一般流程）：需求评审——指定测试计划——编写测试用例——测试评审——冒烟测试——系统测试——测试报告——验收测试——完结

1.需求分析

需求文档产品文档产品详细设计说明书，分析需求的点，参与需求评审

快速熟悉项目

2.制定测试计划和测试方案

测试计划：测试正规项目的总体规划，测试范围、进度的安排、人力物力的安排、风险的评估、风险的规避 5W1H（why when who what where how）

测试方案：how 被测试的目标、选区什么样的测试工具、测试的方法、测试的重点

3、设计测试用例

边界值、等价类...

4、执行测试用例

5、评估测试报告

（二）开发模型

1.瀑布模型

特点：

1. 1. 1. 1. 阶段间具有顺序性和依赖性
      2. 推迟实现
      3. 质量保证的观点

瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易，从而显著降低软件预算。

优点：

1. 1. 1. 1. 开发的各个阶段比较清晰。
        强调早期计划及需求调查。
        适合需求稳定的产品开发。

缺点：

1. 1. 1. 1. 依赖于早期的需求调查，不适应需求的变化。
        单一流程不可逆。
        风险往往延至后期才显露，失去及早纠正的机会。
        问题在项目后期才开始暴露。
        前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

最大的问题：

测试工作后置，呆滞整改项目开发完成之后如果发现比较验证的问题，修改的成本巨大。风险后期才发现，难以回溯。

2.增量模型

把瀑布模型的顺序特征于快速原型的迭代特征相结合，将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

优点：

1. 能在较短的时间内向用户提交可完成部分工作的产品
2. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
3. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
4. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整

缺点：

1. 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
2. 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
3. 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程

3.快速原型模型

在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。

第一步是建造一个快速原型，实现用户与系统的交互，用户对原型进行评价，进一步细化徒开发软件的需求。通过逐步调整原型使其满足用户的要求，开发人员可以确定用户的真正需求是什么。

第二步是在第一步的基础上开发出用户满意的软件产品。

特点：

快速的建立起来的可以在计算机上运行的程序

快速原型模型优点:

1. 克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险。
2. 适合预先不能确切定义需求的软件系统的开发。

快速原型模型缺点：

1. 不适合大型系统的开发（适合开发小型的、灵活性高的系统）。
2. 前提要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
3. 所选用的开发技术和工具不一定符合主流的发展。
4. 快速建立起来的系统结构加上连续的修改可能导致质量低下。

4.螺旋开发模型

特点：

螺旋模式是将瀑布模式与快速原型模型结合起来（瀑布模型（系统化）+快速原型（迭代过程）+风险分析。）
强调了其他模型所忽视的风险分析
每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估
它是由风险驱动的

缺点：

强调风险分析，但要求许多客户接受并相信这种分析，是不容易的

完整的螺旋模型

简单的螺旋模型

5、敏捷模型

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。

特点：

短周期开发
增量开发
由程序员和测试人员编写的自动化测试来监控开发进度
通过口头沟通、测试和源代码来交流系统的结构和意图
编写代码之前先写测试代码，也叫做测试先行

缺点：

团队的组件较难，人员素质要求较高
对测试员要求完全掌握各种脚本语言编程，能执行单元测试、自动化测试

敏捷开发：

即根据用户需求，快速迭代。优点：及时快速敏捷，缺点：耗费人力物力

（三）测试模型

1.V模型

V模型是瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重后果。

V模型在软件开发的生存期里面，开发和测试活动几乎同时考试，两个并行的动态过程就会极大的减少bug和error出现的几率。

单元测试检测的开发是否符合详细设计的要求。

集合测试检测此前测试过的各组成部分是否能很好的结合在一起。

系统测试检测已集成在一起的产品是否符合规格说明书的要求。

验收测试检测产品是6否符合最终用户的需求。

优点：

既有底层的测试（单元测试）又有高层的测试（系统测试）；

将开发清楚的表现出来，便于控制开发的过程，当所有阶段都结束时，软件开发就结束了。

缺点：

容易让人误解为测试是在开发完成后的一个阶段；

由于其的顺序性，当编码完成后，正式进入测试时，一些bug可能不容易被发现并修改；

忽视了测试对需求分析，系统分析的验证，一直到后期的验收测试才被发现。

2.W模型

从V模型演化过来，实际开发是V，测试并行的V。W模型增加了软件开发中应同步进行的验证和确认活动，W明确表示出了测试与开发的并行关系。测试和开发是同步进行的，有利于尽早地全面的发现问题。

优点：

将测试贯穿到整个软件的生命周期，不仅要测试代码，还要对需求、设计进行测试；

测试人员更早的介入到软件开发过程中，能尽早的发现错误，降低开发成本；

测试与开发独立起来，并与开发同步。

缺点：

对有些项目，开发过程中没有文档的产生，所以W模型没法使用；

对于需求和设计的测试技术要求高，实践起来很困难。

依赖于软件开发和软件测试依然保持一前一后的线性关系，依旧无法支持迭代、自发性和需求等变更调整

特点：

强调尽早测试

强调不断测试

体现静态测试

3.H模型

真正的测试级别之间不存在严格的次序关系，各阶段间可以反复接触、迭代、增量。

H模型将测试活动完全独立出来，形成有几个完全独立的流畅，将测试准备活动和测试执行活动清晰地体现出来。

特性：

体现了”尽早测试、不断测试“的原则

体现了测试流程的完整性

体现测试流程的独立性

充分体现了测试过程（而非技术）的复杂性，强调了过程管理的重要性

测试流程：

　　--测试准备：所有测试活动的准备判断是否到测试就绪点。

　　--测试就绪点：测试准入准则，即是否可以开始执行测试的条件

　　--测试执行：具体的执行测试的程序

其它流程:回归测试、冒烟测试、探索性测试

H模型优点：

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

　　（2）软件测试完全独立贯穿整个生命周期与其它流程并发进行；

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

　　（4）软件测试可以根据被测对象的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

H模型的缺点：

　　（1）管理型要求高：要定义清晰的规则和管理制度，否则测试过程将很难管理和控制

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

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

　　（4）对整个项目组的人员要求非常高：在很好的制度下，大家都能高效的工作，否则容易混乱（对整个项目足够熟悉）。例如：你分了一个很小的迭代，但因为人员技能不足，使得无法完成，那么整个项目会受到很大的干扰。

总结：

V模型适用于中小企业

W模型适用于中大型企业

H模型人员要求非常高，很少有人使用。

4.X模型

X模型是唯一一个定位了探索性测试模式的测试类型。可以迭代

探索性测试：

— 是一种测试思维技术。

— 强调测试人员的主观能动性。

— 强调在碰到问题时及时改变测试策略。

— 分为自由式探索式测试、基于场景的探索式测试、基于策略的探索式测试和基于反馈的探索式测试

•优点

–给探索性测试建立了一种理论基础，可以更好地指导测试人员进行探索性测试。

–给单元测试及模块/接口测试提供一个行之有效的理论方法

•缺点

–只强调了测试过程中的部分内容，没有对需求、验收测试等内容进行说明

–没有描述测试与开发、需求等环节的关系

–没有描述出测试流程的整个过程

•适用范围

–项目高度模块化

–快速迭代

–短期项目

○X模型是软件测试里比较期望采取的一种模型。

○目前而言，用得更多的可能是W模型的一个变化，或者竖排是W模型和H模型的一个结合，我们的各个方面的测试内容是以W模型为准，而测试的周期、测试的方法、测试的进度是以H模型作为一个指导。X模型是对于我们一种最终测试或说熟练性测试的一个模板，如果我对于一个业务已经测试了超过五年，可以采用X模型。

（四）开发和测试的关系

相辅相成

目标不同

三、测试分类

四、测试用例

（一）测试用例的设计

测试用例的八大要素：

用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、测试步骤、预期结果。

1.等价类划分法

等价类与边界值测试输入框合适

使用最少的测试数据，达到最好的测试测试质量。避免穷举测试。

合理的假设：测试某等价类的代表等于对这一类其它值的测试。

有效等价类

无效等价类

举例：qq登陆

2.边界值法

3.因果图法

是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适用于检查输入条件的各种情况。

特点：

1.考虑输入条件的相互制约及组合关系

2.考虑输出条件对输入的依赖关系

核心：

因果图法比较合适输入条件比较多的情况，测试所有输入条件的排列组合。因即输入条件，果即输出结果。

案例

eg：

作判定表

最好根据每列的信息，写测试用例。

4.判定表法

适用场景：适用于多个输入和多个输出，输入和输出之间有相互的组合关系，输入输出之间有相互的制约和依赖关系。

eg：

优点：能把复杂问题啊按照各种可能情况一一列举处理，简明而易于理解，避免遗漏

缺点：不能表达重复执行的动作、例如循环结构

5.正交表法

使用场景：需求中条件的组合梁比较大的时候，需求两个两个相互组合的时候。

allpairs工具的使用：

1. 1. 利用excel准备一个表格
  2. 将表格内容贴到txt文本中，并保存
  3. 通过allpairs命令生成
  4. 拷贝结果到测试用例中

eg：

excel：

带标题的txt

运行

生成：

6.场景法

主要用于冒烟测试

eg：

7.流程分析法即功能图法

一般用于非常重要的系统（ATM机、医疗设备）。

使用广度图和深度图。

EG:

广度图：

深度图：

8.错误推断法

是给予经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

适用于项目时间比较杜纳，任务比较繁重的情况下，而且测试经验较多。

（二）测试用例的力度

（三）测试用例的方法总结

五、软件缺陷

（一）软件缺陷基本概述

1、定义

从内部看，软件缺陷产品开发或者维护过程中存在的错误、毛病等各种问题

从外部看，软件缺陷是系统所需要实现某种功能的失效或者违背

即，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求。

2、具体包含（程序、数据、文档）

1. 1. 1. 1. 未达到需求规格说明书中的功能
      2. 出现了需求规格说明书中致命不会出现的错误
      3. 功能超出了需求规格说明书的范围
      4. 未达到需求规格说明书中没有指明，但应该达到的目标
      5. 测试人员或者用户任务软件难以理解、不易适用、运行速度慢或者最终用户任务不好

3、表现形式

1. 1. 1. 1. 功能、特性没有实现或者部分实现
      2. 设计不合理，功能特性不明确，逻辑不清楚或者存在矛盾
      3. 产品实际结果和所期待的结果不一致
      4. 没有达到需求规格说明书所规定的性能指标
      5. 运行出错，终端、崩溃、界面混乱
      6. 数据不正确、精度不够，不完整，格式不统一
      7. 用户不能接受的其他问题，超时、界面丑陋
      8. 硬件或者系统软件上存在的其他问题

4、缺陷产生的原因缺陷产生是不可避免的

1. 1. 1. 1. 需求解释或者记录错误
      2. 用户需求定义错误
      3. 需求说明存在问题
      4. 编码说明、程序代码有误
      5. 硬件或者系统存在错误
      6. 文档错误、内容不正确、拼写错误

缺陷产生的根源：

1. 1. 1. 1. 交流不充分
      2. 软件的复杂性
      3. 开发任务的错误
      4. 需求的变化
      5. 进度的压力

5、缺陷的修复费用

缺陷越迟发现产生的修复费用越高。

（二）缺陷报告

缺陷报告的一些字段及说明

测试报告作用：

1. 1. 记录测试结果
  2. 方便开发人员进行缺陷的定位
  3. 为后期统计缺陷提供依据

1、缺陷的状态

状态	含义
new	新建，缺陷的初始状态
assigned	已指派，分配给具体的开发人员
open	打开，开发人员开始修改缺陷
fixed	修复，开发人员秀嘎缺陷完毕
closed	回归测试通过，关闭缺陷
reopen	回归测试失败，再次打开
postpone	推迟修改
duplicate	与已提交的Defect重复
reject	拒绝修复，可能为测试人员对于需求理解错误

2、缺陷的跟综

要点：测试从测试人员开始，也应该由测试人员结束。

3、严重程度

五个等级：（严重程度的分级，并不统一）

1. Fatal：致命的缺陷。造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题
2. Critical：严重错误。系统的主要功能部分丧失、数据不能能保存，系统的次要功能完全丧失，问题局限在本模块，导致模块功能失效或者异常退出。如系统资源占用过大，功能没有做完。
3. Major：一般的软件缺陷。次要功能没有完全实现但不影响适用。如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等。
4. Minor：较小的软件缺陷。较小错误的软件缺陷，使操作者不方便或遇到麻烦，但不影响功能性的操作和执行。例如：对话框弹出位置，步骤较多，输入项太麻烦
5. Enhancemental：建议问题。由问题提出人对测试对象的改进意见或测试人员提出的建议、至义，例如：错别字、颜色、按钮大小

4、优先级

级别	定义	说明
P1	立即解决	缺陷导致系统几乎不能正常运行、使用，或严重妨碍测试的执行，需立即修正，尽快修正；
P2	高级优先	缺陷严重，影响测试，需要优先修正，如不超过24小时修正；
P3	正常级别	缺陷需要修改，只要正常排队修复即可；
P4	低优先级	缺陷可以在开发由时间的时间修复，若没有时间可以不修正。

优先级不固定。

5、缺陷的表现形式

分类	说明
代码问题	不满足需求、功能实现错误；对产品或项目质量有影响bug可同一划入
设计缺陷	页面美观性、协调性、错误字等
用户体验	对产品、项目的建议性意见，不强制要求修改
性能问题	进行性能测试的使用，eg：网络延迟、内存问题、CPU占用、硬盘问题
安全问题	业务功能存在的安全问题
兼容问题	在部分环境表现正常，在部分环境中表现不正常
接口问题	涉及有模块间数据传递时使用
配置问题	由于提供的配置不当或者配置不能够满足实际要求而出现的问题
其他问题	上述不能归纳进来的问题