软件测试必掌握技能(黑盒测试，白盒测试......)

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

---

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的生命周期

一个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等价类

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

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

超市买水果

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

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

利用等价类设计测试用例：例如一个软件登录用户名长度测试(默认6-15位)

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界面测试

界面测试（简称 UI 测试 ) ，指按照界面的需求（一般是 UI 设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

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

6.1.2可靠性测试

可靠性（ Availability ）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务 的时间占总时间的百分比表示。

可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%

可用性指标一般要求达到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易用性测试

易用性在 ISO25020 标准中指容易发现，容易学习和容易使用。易用性包含七个要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性

6.1.7安装卸载测试

应用的安装和卸载在任何一款 APP 中都属于最基本功能。一旦出错，就属于优先级为紧要 Critical 的缺陷。主要需要考虑以下方面：

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

6.1.8安全测试

安全性是指信息安全，是指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面，系统常见的安全漏洞和威胁如下

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

6.1.9性能测试

要进行软件产品的性能问题分析，首先要对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见的性能问题如下：

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

衡量一个系统性能好坏的关键性指标有，用户响时间，事务平均响应时间（ TPS ），吞吐率，每秒点击次数，内存和CPU 使用率等。

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α测试

α 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。

注意：α测试不能由程序员完成

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

6.4.2β测试

Beta 测试是一种验收测试。 Beta 测试由软件的最终用户们在一个或多个场所进行。

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

α测试与β测试的区别： 

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

6.4.3第三方测试

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

6.5按是否运行划分

6.5.1静态测试

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

6.5.2动态测试

动态测试（ dynamic testing ），指的是 实际运行被测程序，输入相应的测试数据，检查实际输出结果 和预期结果是否相符 的过程，所以判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

大多数软件测试工作都属于动态测试。

6.6按是否手工划分

6.6.1手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。总结优缺点：

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

6.6.2自动化测试(Automation Testing)

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。

自动化测试按照测试对象来分，还可以分为接口测试、 UI 测试等。接口测试的 ROI （产出投入比）要比UI测试高。

6.7按测试地域划分

6.7.1国际化测试

本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试 的一些要点。

• 本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
• 是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
• 在不同的屏幕分辨率下界面是否正常显示。
• 是否存在不同的字体大小，字体设置是否恰当。
• 日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。
• 排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
• 在不同的国家采用不同的度量单位，软件是否能自适应和转换。
• 软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
• 软件是否能在Windows或者其他操作系统的当地版本上正常运行。
• 联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误。

6.7.2本地测试

之前我们所讲的全是本地化测试。

---

 到此已经全部分享完关于测试必须掌握的技能，希望对大家有所帮助！！！