软件测试必掌握技能(黑盒测试，白盒测试......)_软件测试的计划、测试用例(白盒、黑盒测试各两个以上)

上一篇文章入门测试，首先要了解这些概念！！，我们已经聊了关于测试学习中的一些概念，本篇文章我们来学习软件测试所要真正的掌握的技能。

---

1.软件测试的生命周期

在上一篇文章我们学习了软件的生命周期：需求分析，计划，设计，编码，测试，运行维护，其中对于测试而言，又有自己的生命周期：需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估。

• 需求分析：测试人员了解需求，对需求进行分解，得出测试需求
• 测试计划：根据测试需求编写测试计划/测试方案
• 设计阶段：测试测试人员设计测试用例
• 测试开发：开发测试工具，开发自动化测试用例
• 测试执行：提交BUG,验收BUG
• 测试评估：产出测试报告

2.如何描述一个BUG

作为测试人员，发现BUG之后，对于一个BUG详细，形象的描述，这对于开发人员的修复BUG 的工作有很大的帮助，所以一个合格的bug描述应该包括以下几个部分：

• 发现问题版本：开发人员要知道出现BUG的版本，才可以在对应版本的代码中去修复BUG，并且版本的标识也有利于统计和分析每个版本的质量
• 问题出现环境：环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器的版本，电脑的操作系统等，如果是APP项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
• 错误重现的步骤：描述问题重现的最短步骤
• 预期行为的描述：要让开发人员知道怎样才是正确的，尤其要以用户的角度来描述程序的行为是怎么的，如果是依据需求提出的故障，能写明需求的来源是最好的。
• 错误行为的描述：描述错误的现象，crash等可以上传log，UI问题可以有截图。
• 不要把多个BUG放在一起：无法确定是同一段代码造成故障时，不能将bug放在一起。

3.BUG的级别

每一个公司根据业务不同对BUG的级别有不同的定义，例如：

• Blocker（崩溃）：阻碍开发或者测试工作的问题，造成系统崩溃，死机，导致数据库数据丢失等。
• Critical（严重）：
  系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
• Major（一般）：
  功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字过多等( 该问题实际测试中存在最多）
• Minor（次要）：
  界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠等

4.BUG的生命周期

• New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
• Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
• Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是Bug，则拒绝修改。
• Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改。
• Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
• 无效的bug：open->closed open-rejected-closed

 每一个BUG都是要经过这个流程才可以解决！！！

5.测试用例的设计方法(基于黑盒测试)

5.1基于需求进行测试用例的设计

基于需求设计测试用例是设计测试和开发测试用例的基础，第一步就是要分析需求，验证需求是否完整，无二义性等。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测 试点或者测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为功能测试需求和非功能测试需求

5.1.1功能需求测试分析

功能需求测试主要是包括，业务流程，界面相关，易用性等方面来进行设计测试用例。

5.1.2非功能需求测试分析

非功能相关主要包括：兼容性，安全性，性能相关，易维护性和可移植性等

5.2具体的设计测试用例方法

5.2.1等价类

我们对一个软件进行测试，输入的集合是无穷无尽的，不能全部都覆盖到，所以根据需求划分为若干个等价类，从所划分的类中选出一个测试用例，如果这个测试用例通过，则认为所代表的整个类都通过测试这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类：满足用户需求对应输入的集合就是有效等价类
• 无效等价类：不满足用户需求对应输入的集合就是无效等价类

超市买水果

有效等价类：苹果、桃子、梨

无效等价类：青菜、米、饮料......

5.2.2边界值

由于等价类法只是划分为大类进行测试，往往会忽略掉最容易出现问题的边界值，所以边界值法就是对等价类法的一个补充，把等价类的边界值作为测试用例。

边界值法必须知道的几个点：

• 上点：边界上的点
• 内点：边界内的点
• 离点：上点附近的一个点（如果是闭区间，是边界外的点，如果是开区间，是边界内的点）

此时上点：5,15  内点：10（不唯一），离点：6，16 

边界值所设计的测试用例

5.2.3判定表法

判定表是另一种另一种表达逻辑判断的工具，一个表格里有包含条件和结果。

判定表中的关系：恒等，非，与，或

• 恒等：条件为真，结果一定为真
• 非：条件为真，结果为假
• 与：只有条件全部为真，结果才为真
• 或：条件只有一个为真，结果为真

根据判定表设计测试用例：1)分析所有可能的输入和输出，2)找出输入和输出对应的关系    

假设业务单据的处理规则为：“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优 惠”。

• 输入：提交订单，订单金额大于300，有红包
• 输出：优惠，不优惠

 

5.2.4正交表法

  

我们要了解两个名词：

• 因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）
• 水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值

使用正交表设计测试用例的步骤：

1. 充分理解需求
2. 确定因素，确定水平
3. 画正交表
4. 补充正交表
5. 将正交表转化为测试用例

使用正交表设计测试用例时用到allpairs这个工具，以注册用户为例，使用allpirs步骤为：

1. 将因素水平填写到excel中  
2. 将excel内容复制到 txt 文件  
3. cmd 进入allpairs 安装路径
4. 通过一个命令产生正交表  

所生成的测试用例：

  

5.2.5场景设计法 

案例：

设计ATM机取款场景进行测试用例的设计

其中步骤为： 插卡 --> 输入密码 --> 选择业务 --> 输入取款金额 --> 出钞 --> 取卡

设计的测试用例为：

   

5.2.6错误猜测法

案例：

以注册为例

1 、校验中特殊字符空格的处理 ?

2 、密码校验中的大小写？

3 、姓名中的特殊字符？

4 、密码发送是否明文

5.3一个完整的测试用例设计

我们设计测试用例时，不能直接上手测试点，这样会容易漏测，应该把测试用例进行归类，然后挨个设计测试用例，就不会出错。

测试用例万能公式：界面，性能，易用性，安全，兼容，功能

此时我们设计一个水杯的测试用例，首先归类，根据测试用例公式设计的测试用例如下：

  

 6.测试的分类

测试主要分为以下几个大类：

  

6.1按照测试对象划分

6.1.1界面测试

• 验证界面内容显示的完整性，一致性，准确性，友好性。比如界面内容对屏幕大小的自适应，换行，内容是否全部清晰展示；
• 验证整个界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符合需求；
• 对界面不同控件的测试，比如，对话框，文本框，滚动条，选项按钮等是否可以正常使用，有效和无效的状态是否设计合理；
• 界面的布局和色调符合当下时事的发

6.1.2可靠性测试

可用性指标一般要求达到4个或5个“9”，即99.99%或者99.999%：

如果可用性达到 99.99% ，对于一个全年不间断（ 7*24 的方式）运行的系统，意味着全年（ 252600min) 不能 正常工作的时间只有52min ，不到一个小时。

如果可用性达到 99.999% ，意味着全年不能正常工作的时间只有 5min 。

6.1.3容错性测试

• 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内 部消化掉，而不会导致系统出错甚至崩溃。  比如数据级测试，校验测试，环境容错性测试，界面容错性测试
• 灾难恢复性测试。 通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

6.1.4文档测试

 国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。

• –开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
• –用户文件:用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本。
• –管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

文档测试的关注点：

• 文档的术语
• 文档的正确性
• 文档的完整性
• 文档的一致性
• 文档的易用性

6.1.5兼容性测试 

• 系统自身版本的兼容，用户已有数据的兼容，数据兼容是重中之重，对用户来说，数据是最有价值的。
• 测试与应用环境的兼容性，比如操作系统，应用平台，浏览器的兼容
• 测试与第三方系统以及第三方数据的兼容性

6.1.6易用性测试

6.1.7安装卸载测试

• 软件不同的安装和卸载方式；
• 应用是否可以在不同的环系统，版本下安装（安装兼容性）
• 安装或者卸载过程中是否可以手动暂停，或者取消
• 安装空不足的时候系统是否有提示
• 是否可以正常的卸载，以及应用软件的各种卸载方式
• 卸载和安装过程中出现环境问题，软件是否可以正常并且合理的应对，比如死机，断电，断网等

6.1.8安全测试

• 输入域，如输入恶性或者带有病毒的脚本或长字符串；
• 代码中的安全性问题，如SQL/XML注入
• 不安全的数据存储或者传递
• 数据文件，邮件文件，系统配置文件等里面有危害系统的信息或者数据；
• 有问题的访问控制，权限分配等
• 假冒ID：身份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性

6.1.9性能测试

• 资源泄露
• 资源瓶颈
• 线程死锁，线程阻塞
• 查询速度慢或效率低
• 受外部系统影响越来越大

6.1.10内存泄漏分析

• 分配完内存之后忘了回收。
• 程序写法有问题，造成没办法回收（如死循环造成无法执行到回收步骤）。
• 某些API函数的使用不正确，造成内存泄露。

• 人工静态法：代码走读，人工查找未被回收的内存。
• 自动工具法：借助相应测试内存泄漏的工具，如Visual Leak Detector，记录每次内存分配，清楚告诉用户内存是如何泄漏的。

6.2按是否查看代码划分

6.2.1黑盒测试(Black-box Testing)

黑盒测试用到的测试方法有，等价类，边界值，因果图，场景法，错误猜测法等

6.2.2白盒测试(White-box Testing)

白盒测试的测试目的是：

通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致 

• 代码覆盖率比较高

白盒测试的缺点：

• 业务功能覆盖不高

白盒测试和黑河测试测试的重点不同，没有哪一个好哪一个坏，只要符合当前业务，能够保障软件质量的测试方法，就是一个好的测试方法 

6.2.3灰盒测试(Gray-Box Testing)

6.3按开发阶段划分

测试金字塔：

      

6.3.1单元测试

• 测试阶段：编码后或者编码前（TDD）
• 测试对象：最小模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码和注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

6.3.2集成测试

• 测试阶段：一般单元测试之后进行
• 测试对象：模块间的接口
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：单元测试的模块+概要设计文档
• 测试方法：黑盒测试与白盒测试相结合
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

6.3.3系统测试

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）测试人员：黑盒测试工程师
• 测试依据：需求规格说明文档
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

例如：一部手机在出厂之前，会将所有的功能都测试一遍，包括手机本身，和手机上的App

6.3.4回归测试

6.3.5冒烟测试

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，则测试人员可以让开发人员重 新修复代码直到冒烟测试通过，再开始进行系统测试。

   

回归测试和冒烟测试都属于系统测试。

6.3.6验收测试

• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）。
• 测试人员：主要是最终用户或者需求方。
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试(功能...各类文档等)

例如：买到新手机，一般会有7天包退，一个月包换，我们会尽量在7天内把手机的所有功能都试一遍。

6.4按测试实施组织

6.4.1α测试

手机出厂前最后一次测试，开发和测试人员不参与，其他人进行测试

6.4.2β测试

用户购买手机之后，参与测试人员是购买者，使用的场所和环境已经不是开发环境

α测试与β测试的区别： 

• 测试场所不同：α测试是由用户在开发环境下测试，β测试是一个或多个场所进行测试
• α测试的环境是受开发方控制的，用户的数量较少，比较集中；β测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
• α 测试先于β 测试执行。通用的软件产品需要较大规模的β 测试, 测试周期比较长

6.4.3第三方测试

介于开发方和用户方间的组织的测试 

6.5按是否运行划分

6.5.1静态测试

所谓静态测试（static testing）就是不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。不以测试数据的执行而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。

6.5.2动态测试

6.6按是否手工划分

6.6.1手工测试(Manual testing)

• 优点：自动化无法替代探索性测试、发散思维结果的测试。
• 缺点：执行效率慢，量大易错。

6.6.2自动化测试(Automation Testing)