测试知识汇总

目录

软件测试开发流程

需求分析

评审测试用例

执行测试

提交 Bug 并推动 Bug 解决

回归测试

编写并提交测试报告

软件测试方法

白盒测试

黑盒测试

等价类

 灰盒测试

动态测试

α测试

β测试

冒烟测试

回归测试

随机测试

探索测试

为什么引入自动化测试

自动化测试框架包含哪些模块

基础模块

管理模块

运行模块

统计模块

常用的测试框架类型

模块化测试框架

数据驱动框架

关键字驱动框架

混合模型

测试框架设计原则

如何设计一个不错的测试案例

第一，等价类划分法

第二，边界值分析方法

第三，错误推测方法

---

软件测试开发流程

需求分析

在测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，对有疑问的地方进行标注。

具体可从以下进行：

• 分析产品功能点
• 产品核心竞争力
• Kano模型、马斯洛需求分析、多问几个为什么、上下文分析法

制订测试用例（重要）

工欲善其事，必先利其器；对测试而言，测试用例就是器，做好了才能把好关

• 使用思维导图列举测试大纲，尽量发散，想到什么就写什么，；先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点。

• 可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例

• 根据测试大纲制定测试用例，需包含模块名、测试优先级、操作步骤、期望结果、测试结果、备注

评审测试用例

• 测试作为主导，联合开发、项目经理、PM进行测试用例评审
• 可先讲解测试大纲，让开发、项目经理、PM心中对测试用例有个大概；后再进行详细测试用例讲解

执行测试

• 根据测试用例执行测试
• 发现问题保留现场，记录测试方法，通知开发解决问题
• 覆盖测试用例之外若有时间可进行探索性测试

提交 Bug 并推动 Bug 解决

• 在Bug管理工具上提交Bug，详细记录测试步骤

• 根据Bug严重程度划分Bug等级:致命、严重、一般、提示

• 推动开发解决问题，记录问题进展，一般聊天沟通，若问题严重则需通过邮件推动解决

回归测试

• 对已修复的 Bug 进行验证

• 对 Bug 所在模块进行基本功能测试；整体进行冒烟测试，确保不会因为修改 Bug 而引起其他功能出现问题

编写并提交测试报告

可使用金字塔原理设计测试报告，先总后分，上级统领下级，下级推导出上级，环环相扣

• 对Bug进行汇总，筛选出各个等级的Bug存活情况

• 制订Bug发现及解决曲线图，一般版本正常应是前期多，后期收敛，存活的是级别较低的Bug

• 总结归纳版本情况，评估发布与否

软件测试方法

白盒测试

概念：关注程序代码的具体细节，根据软件内部代码的逻辑结构分析来进行测试。主要是通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件质量。关注代码的实现细节。主要对程序模块的所有独立执行路径至少测试一遍、对所有的逻辑判定，取“真”或“假”的两种情况都要测试一遍，循环边界和运行界限内执行循环体等等

测试用例设计方法：逻辑覆盖、循环覆盖、基本路径覆盖、判定覆盖

优点：增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题

缺点：系统庞大时测试开销很大，难以测试所有运行路径；测试基于代码，只能验证代码是否正确，而不晓得代码设计是否合理，可能会遗漏某些功能需求

黑盒测试

概念：不考虑其内部结构，即具体代码实现，检测软件的各个功能能否得以实现，确认软件功能的正确性，依靠软件说明书来判断测试用例,关注具体的客户需求及软件功能。黑盒测试主要是为了发现：1.是否有不正确的或者遗漏的功能；2.输入是否能输出正确的结果；3.性能上是否满足要求

优点：①较为简单，不需要了解程序内部的代码及实现，与软件内部实现无关；②从用户角度出发，实际考虑用户使用的功能及可能出现的问题

缺点：不可能覆盖所有的代码，覆盖率较低

测试用例设计方法：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试法、场景法

等价类

输入域的各子集中，各个输入数据对于揭露程序中的错误都是等效的。

• 等价类划分：将全部输入数据合理划分成若干个等价类，在每一个等价类中取一个数据作为输入条件，就可以用少量代表性测试数据取得较好的测试结果。分为有效等价类（合理、有意义的输入数据构成的集合）和无效等价类
• 边界值分析法：大量错误是发生在输入输出范围的边界上，选定测试用例时应该选取正好等于、刚刚大于、刚刚小于边界值的值作为测试数据，而不是选取等价类中的任意值，作为对等价类划分的补充
• 错误猜测法：基于经验和直觉推测，列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例
• 因果图法：考虑输入条件之间的相互组合，也考虑输出结果对输入条件的依赖关系。原因即为输入条件或者输入条件的等价类，结果即为输出条件，把因果转换为决策表，为决策表中的每一列设计测试用例。
• 场景分析法：根据用户场景来模拟用户的操作步骤
• 大纲法：着眼于需求。将需求转换为大纲的形式，大纲表示为树状结构，在根和叶子节点之间存在唯一路径，大纲为每条路径定义了一个特殊的输入条件集合，用于测试用例。
• 随机测试法：不考虑任何用例和需求，完全站在用户的角度对产品进行测试

 灰盒测试

关注输入输出的准确性，也关注内部的代码，但是没有白盒测试那么详细完整。

动态测试

实际运行被测程序，输入相应的测试用例，检查运行结果与预期结果的差异，从而验证程序的正确性、有效性和可靠性，并且分析系统运行的效率和健壮性。

α测试

一个用户在开发环境下的受控测试，模拟实际操作环境

β测试

多个用户在实际使用环境下进行的测试，如一些软件的公测

冒烟测试

在大规模测试之前，先对软件的基本、核心、主要功能进行测试，节省资源

回归测试

开发修正完代码后再回过头来做测试

随机测试

跳出思维的限制，没有思想、没有步骤地随机进行测试

探索测试

有思想，有步骤地测试一些复杂的、不常用地功能

为什么引入自动化测试

自动化测试是将自动化工具和技术应用于软件测试，旨在减少测试工作，更快，更经济地验证软件质量。有助于以更少的工作量构建质量更好的软件。

许多公司多多少少都在做自动化测试，但手动测试仍然占主要的比例，因为有些团队不知道如何在开发过程中更好的利用自动化测试来替代手动测试。

手工测试通常是工程师仔细的执行预定义的测试用例，将执行结果与预期的行为进行手工比较并记录结果。每次源代码更改时都会重复这些手动测试，由于都是人为参与，这个过程中很容易出错。

在组织中引入自动化测试时，需要投入大量财力和时间。 然而，一般没有太多的财务回报，至少在小规模开始时没有。 因此许多公司选择开源测试自动化工具，特别是在开始引入自动化测试的阶段。

通常，软件公司害怕投资自动化测试，不是因为负担不起这个投入，而是因为他们担心的回报不会像预期的那样，或者根本不会产生积极的投资回报率。

1. 降低成本（特别是问题出现时的成本）

如前所述，开始自动化测试的初始成本并不高，比如选用免费的开源工具。 但是，一旦您的组织全面展开自动化测试，您就会希望投资更好的工具、更好的服务器，雇用人力来维护基础设施等。这些成本绝对不是无关紧要的。

自动化测试不会自动生成。创建有价值的自动化测试需要花费时间和精力，而且不会在一夜之间发生。

如果您想证明引入自动化测试的合理性，不能只关注财务回报，而应考虑应用出现问题导致的隐性成本。例如一个问题在手动测试没有发现而出现在产品环境中，公司会花多少钱？你是否会失去客户？需要花多少时间、资源和资金来纠正这种情况？

如果每次对代码进行更改时，都重复执行一组非常强大的测试套件，可以降低问题出现在产品环境的风险。自动化测试有助于在软件开发生命周期的早期发现错误，从而降低交付故障软件的风险。

说到底，向市场提供高质量的产品重要性远大于任何其他类型的节省。

2. 节省时间

虽然初期建立自动化测试需要花费大量的时间和人力，但是一旦自动化测试建立了，您就可以重用这些测试。自动化测试的执行速度明显快于手动测试，不易出错，且节省人力。

在日常的代码修改过程中，您可以在每次提交时执行自动化测试，而不必通过设置环境或记住执行每个测试的步骤来持续执行手动步骤。一切都是自动完成的。

只要首次设置完成后，就可以重复运行你的自动化测试，从而将重复的手动测试时间从数周缩短至数小时。

同样一旦编写好，测试可以执行任意次。与手动测试仪不同，测试也可全天候，无人值守的执行。

在软件开发团队中，通常的做法是每天多次（通常是每次提交）运行基本单元测试，并且每天在下班后执行耗时的集成测试和UI测试。

3. CI和DevOps

自动化测试构成任何持续集成或DevOps设置的基础。从本质上讲，CI（持续集成）和DevOps都依赖于“Fail fast, Fail early”的理念。对代码库的每次提交都将自动进行测试，并将结果报告给开发人员。开发人员优先修复任何导致构建失败或导致主要测试失败的错误，确保主线代码始终按预期工作。

4. 准确性和可靠性

由于运行每个测试涉及多个先决条件，手动测试容易出错。另外每个测试可能需要不同的执行顺序。

毕竟手动测试人员是人类，人有不善于执行重复枯燥工作的特点，因此可以预料手动测试不会精确并有一定的几率出错。这会导致不准确的结果反馈到开发团队。

自动化测试每次都执行相同的步骤，不仅精确，而且结果可在最短的时间内提供给所有相关人员。

可靠性的另一个方面是在不同服务器上重新执行相同的测试。这使得能够快速验证测试是否在所有服务器上按预期运行，从而排除了服务器配置问题的可能性。

4. 性能测试

性能负载测试可确保您的应用程序可以处理预期和意外的用户负载。

如果您当前只在项目中使用手动测试方法，则负载测试可能会推迟到开发周期结束。按照敏捷方法和持续集成理念，应及早地进行性能测试，但现实是很大一部分项目团队执行做这个测试的时间太晚，最终导致产品发布推迟。

自动化性能测试能够同时运行数千个测试，模拟数百万用户，所有这些用户手动测试几乎都是不可能的。

5. 增加对软件的信心

敏捷方法建议使用sprint，即短周期的迭代。每个sprint通常2-3周。这需要一种新的方式来组织测试工作并要求更高的效率。

每个sprint都专注于开发一组小功能，但必须在其结束的时候提供较完整的新功能特性，还包括之前sprint的所有功能特性。如果没有适当的测试，在不破坏之前正常工作的功能特性的情况下提供全功能系统的风险很高。在每个sprint中反复手动测试所有功能会效率低下。

这也是自动化测试最大的好处。自动化测试并能够在每个sprint中快速重复测试，可以确保所有事情都按预期工作。

6. 衡量质量指标

可用于自动化测试的扩展和工具提供了测量许多代码质量指标的功能，例如代码覆盖率（即实际测试的代码百分比），技术债，代码语义检查等。

通常，当测试作为持续集成或DevOps工作流程的一部分执行时，可同时获取这些方面的测量数据。

之所以能够测量这些指标，是因为自动化测试代码本身与产品代码共存，通过在自动构建阶段解析源代码，能提供在几分钟内测量巨大代码库质量的机会。这在手动测试中根本不可能。

小结

如果您的产品质量是您的首要目标，我强烈建议您使用自动化测试作为日常开发实践的一部分。它将确保您的应用程序得到正确测试，并为研发、管理人员和客户提供信心。

自动化测试需要前期投入，并且需要花时间进行开发。这些投入会得到长期的回报：可以减少工作量，消除手动测试的错误，提高准确性，最终节省成本和时间。

总的来说，自动化测试是一种比手动测试更快获得故障反馈的方法，符合“快速失败，早期失败”的原则。它有助于实现手动测试无法提供的质量。在自动化测试中，

行为驱动的自动化测试

现已广泛为研发团队所接受，基于行为驱动(BDD)的测试脚本具有上手快、易维护、方便所有stakeholders沟通等特点。

如果您还没有一款合适的自动化测试工具来确保软件质量，您可以了解

自动化测试框架包含哪些模块

一个比较成熟的测试框架通常会包含 4 个部分，分别为基础模块，管理模块，统计模块和运行模块。

基础模块

造房子要稳固需要良好的地基。如果把自动化测试框架比作一辆汽车，那么自动化测试基础模块就是那四只轮胎，没有它们，这辆汽车寸步难行，它们一般包括如下部分。

• 可重用的组件

       一般来说用来降低开发成本，常见有日志模块，时间模块等

• 配置文件

       通常会包含测试环境的配置和应用程序的配置。其中测试环境配置用来减少环境版本切换，从开发到上线。

管理模块

管理模块就仿佛是车中的内饰，它对测试框架的使用操作体验有着直接的影响，分为测试数据管理和测试文件管理

• 测试数据管理

测试数据一般是测试用例用到的各种测试数据，他们是为了验证业务正确性而构造，每一组的测试案例通常会对应一对或多对测试数据。测试数据的创建又分为实时创建和事先创建，

实时创建是测试代码运行的时候才生成测试数据。好处是测试数据和测试代码解耦合，测试人员不用关心创建过程和业务调用链，通常用在测试的公用功能上。

事先创建，是指测试代码运行前就准备好的数据文件，其好处是数据拿来即用，几乎不耗费时间，由于没有业务调用，所以这在一定程度上减少了调用失败的风险；坏处则是数据文件本身需要维护，以保持可用性和正确性。

• 测试文件管理

测试文件管理就仿佛是车子的外观，给人第一印象。一个测试用例通常需要包含三个文件，分别是Page类文件，测试类文件和对象库文件。

这三个文件共同描述一个完整的测试用例。测试文件的结构清晰有助于他人理解测试框架的设计思想

运行模块

运行模块为测试框架的发送机，用于测试用例的组织和运行，通常包含下面几个部分

• 测试用例调度，驱动机制

• 错误恢复机制

测试框架应该具有一定的错误恢复机制，测试案例执行过程中，可能出现代码运行错误或环境导致的错误。

• 持续集成支持

测试框架应该能够和 CI 系统低成本集成，包括通过用户输入参数指定运行环境、测试结束后自动生成测试报告等。

统计模块

统计模块相当于车子的品质和口碑。一个完整的统计模块，可以告诉你当前测试有没有 Bug，还能分析软件质量的变化情况，统计模块一般包含下面几个模块

• 测试报告

测试报告应该全面，包括测试用例条数统计、测试用例成功/失败百分比、测试用例总执行时间等总体信息。其中，对于单条测试用例，还应该包括测试用例 ID、测试用例运行结果、测试用例运行时间、测试用例所属模块、测试失败时刻系统截图、测试的日志等信息。

• 日志模块

测试框架应该包括完善的日志文件，方便出错时进行排查和定位。

常用的测试框架类型

模块化测试框架

模块化测试框架是利用 OOP 思想和 PO 模式改造而来的框架。

模块化测试框架把整个测试分为多个模块，模块化有以下几个特征：

• 我们将一个业务或者一个页面成为一个 Page 对象；

• 这个 Page 对象，我们以一个 Page 类来表示它；

• 这个 Page 类里存放有所有这个 Page所属的页面对象、元素操作；

• 页面对象和元素操作组成一个个的测试类方法，供测试用例层调用。

简单来说，使用了 PO 模式的框架就可以叫作模块化测试框架。

• 模块化测试框架的好处在于方便维护，你的测试用例可以由不同模块的不同对象组成；

• 坏处在于你需要非常了解你的系统及这些模块是如何划分的，才能在测试脚本里自如地使用，否则你就会陷入重复定义模块对象的循环里。

数据驱动框架

数据驱动框架主要是解决测试数据问题。

在测试中，我们常常需要为同一个测试逻辑，构造不同的测试数据以满足业务需求，这些测试数据可以保存在测试代码里，也可以保存在外部文件里（包括 Excel、File、DB）。

数据驱动框架的精髓在于，输入 M 组数据，框架会自动构造出 M 个测试用例，并在测试结果中把每一个测试用例的运行结果独立展示出来。

在 Python 架构里，最出名的数据驱动框架就是 DDT。

关键字驱动框架

当把一系列代码封装为要给关键字，在测试的过程中，通过组合关键字的方式来生成测试用例，而不关心关键字如何运作的，这种为关键字驱动框架。

混合模型

并不一定要选择上面的三种框架之一，需要根据需求灵活的选择测试框架，在工作中可能经常需要糅合不同的框架模型，这样的模型就叫做混合模型。

测试框架设计原则

• 首先是清晰明了，学习成本低，其中包含代码规范和模块清晰明确。

• 通用性强，可维护，可扩展

• 对错误的处理能力强

       错误处理机制，能高效解决。系统日志清晰，方便调试。

• 运行效率高且功能强大

      支持测试环境切换，支持外部数据驱动，支持顺序并发，远程运行，报告完备详尽。

• 支持版本控制和持续集成

     版本控制回溯复盘，持续集成全局出发

如何设计一个不错的测试案例

「好的」测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。

一个“好的”测试用例，必须具备以下三个特征 。

• 整体完备性 ：「好的」测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

• 等价类划分的准确性 ： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

• 等价类集合的完备性 ： 需要保证所有可能的边界值和边界条件都已经正确识别。

三种最常用的测试用例设计方法： 等价类划分法、边界值分析法、错误推测方法。

第一，等价类划分法

我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。现在，我给你看一个具体的例子：学生信息系统中有一个考试成绩的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。为了测试这个输入项，显然不可能用 0~100 的每一个数去测试。通过需求描述可以知道，输入 0~59 之间的任意整数，以及输入 60~100 之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。那么这就可以在 0~59 和 60~100 之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。

你不要觉得进行到这里，已经完成了等价类划分的工作，因为等价类划分方法的另一个关键点是要找出所有「无效等价类」 。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。

在考虑了无效等价类后，最终设计的测试用例为：

有效等价类1：0~59之间的任意整数；

有效等价类2：59~100之间的任意整数；

无效等价类1：小于0的负数；

无效等价类2：大于100的整数；

无效等价类3：0~100之间的任何浮点数；

无效等价类4：其他任意非数字字符。

第二，边界值分析方法

边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。

第三，错误推测方法

错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。** 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。

错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。

总结：在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。