【测试基础篇1】一文搞懂软件测试基础知识，开启测试之路，走向测试人生巅峰

简介：一文搞懂软件测试，开启测试之路，走向测试人生。

一、软件测试的定义

维基百科定义：

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

百度百科定义：

软件测试（英语：Software Testing），是使用人工操作（手动测试）或者软件自动运行的方式（自动化测试）来检验软件是否满足用户需求的过程。

二、软件测试的目的

发现缺陷，并进行修复，以确保系统满足用户需求
质量评估，说明系统在相应时间点的质量情况，为是否发布版本提供决策依据
预防缺陷，在软件生命周期早期，通过对测试依据（如合同要求、行业标准、法律要求等）和需求文档进行测试，可以预防将缺陷引入代码中

不同的测试阶段，需要考虑不同的测试目标：

单元测试、集成测试和系统确认测试，测试的主要目标是尽可能的发现失效，从而识别和修正尽可能多的缺陷bug
用户验收测试，目标是确认系统是否按照预期工作
有些情况下，测试的主要目标是对软件质量进行评估，从而为利益相关人提供如下信息：在给定的时间点发布系统版本可能存在的风险
回归测试，通常是为了验证在开发过程中的软件或者需求变更是否引入新的缺陷bug

三、软件测试的原则

1、测试证明软件存在缺陷-Testing shows presence of defects

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

2、穷尽测试是不可能的-Exhaustive testing is impossible

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

3、测试尽早介入-Testing early

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

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

这个也是经验之谈了，一般认为，百分之80的缺陷集中出现在百分之20的核心功能区域。一旦你在某个功能模块找到缺陷，相关附近功能多半也会存在问题。
在项目实战中，在写缺陷报告的时候，做横向对比，比对类似功能，相近模块，版本，机型。指定回归测试策略的时候，也可以重点测试。

5、杀虫剂悖论（杀虫剂效应）-Pesticide Paradox

反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

6、测试活动依赖于测试内容-Testing is context dependent

根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。
比如：你在金融公司测试，安全性就是第一位。电子商务测试，功能性则更加重要。

7、不存在缺陷的谬论-Absence of error

软件测试不仅仅是为了找出Bug而存在的活动，而是还需要确认软件是否满足用户的期望和需求，如果产品不能满足用户的需求，即使没有出现任何缺陷，这个产品也是失败的。
“没有错误” 并不是我们的追求，在互联网时代，始终快速给用户创造最大的价值才是我们孜孜不倦的追求。

四、软件测试的对象

软件测试并不等于程序测试，软件测试活动应贯穿于软件定义与开发的整个生命周期中。
因此，需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及随软件版本发布的资料，都是软件测试的对象。

五、软件测试分类

围绕软件测试的目标，出现了多种软件测试活动和技术，有如下常见分类方法：

1、按测试执行方式划分：

1）静态测试：指的是不运行程序本身，仅通过分析和检查源程序的语法、结构、过程、接口来检查程序的正确性。对需求规格说明书、软件设计说明书、流程图分析、符号执行来进行找错。

检查项：代码的风格和规则审核；程序设计和结构审核；业务逻辑的审核、走查、审查与技术复审手册
静态质量：软件的质量主要有以下六个方面来衡量：功能性、可靠性、可移植性、可用性、有效性、可维护性
代码静态分析和文档测试都是属于静态测试

2）动态测试：动态测试指的就是运行被测的程序。检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性的等性能，这种方法主要是由三部分进行组成的：测试用例、执行程序、分析程序运行输出的结果。

大多数的软件测试就是属于动态测试的。

2、按测试阶段划分：

1）单元测试：单元测试是对软件组成进行的测试。其目的是检验软件基本组成单位的正确性。测试对象是软件设计的最小单元：模块，又称为模块测试。

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

2）集成测试：（也成联合测试，联调）、组装测试，将程序模块采用适当的集成策略组装起来

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

3）系统测试：将软件系统看成一个系统测试。包括对功能、性能以及软件所运行的硬软件环境进行测试。时间大部分在系统测试执行阶段，，包括了回归测试和冒烟测试

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

4）用户验收测试：验收测试是部署软件之前的最后一个测试操作，它是技术测试室的最后一个阶段，也叫做交付测试，验收测试的目的是保证软件的准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件的购买者展示该软件的原始的需求。

测试阶段：系统测试之后
测试对象：整个的系统（包括软硬件）
测试人员：最终的用户或者需求方
测试依据：用户需求和验收标准
测试方法：黑盒测试
测试内容：同系统测试一样（功能。。。。文档等）

3、按是否查看代码分类：

1）黑盒测试（Black-box-Testing）：黑盒测试也称为功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，指关心软件的输入数据和输出数据。

2）白盒测试（White-box-Testing）：白盒测试又称结构测试，透明盒测试、逻辑驱动测试或基于代码的测试。白盒值的是打开的盒子，去研究里面的源代码和程序结果。
接口测试也是一种白盒测试。

3）灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，主要用于集成测试阶段。不仅观念朱输入输出的正确性。同时也关注程序内部的情况。

4、按测试手段分类：

1）手工测试：是由人一个一个的输入测试用例，然后观察结果、和机器测试相对应，属于比较原始，大事需要一个一个步骤进行测试。

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

2）自动化测试：在预设条件下运行系统或应用程序，评估运行结果、预先条件应该包括正常的条件和异常条件。简单的说自动化测试是把人为驱动的测试行为转化为机器执行的一种过程。

自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化
通常我们所说的自动化测试就是指的是功能自动化测试
自动化测试按照测试的对象来分：分为接口测试、UI测试等。接口测试的ROI（产出投入比）要比UI测试高。

自动化实施的步骤

完成功能测试，版本基本稳定
根据项目特性、选择合适的项目自动化工具，并搭建环境
提取手工测试的测试用例转化为自动化测试的用例
通过工具，代码实现自动化的构造输入，自动检测输出结果是否符合预期
生成自动化的构造输入，自动的检测世界古是否符合预期
生成自动测试报告
持续改进、脚本优化

5、按测试对象划分：

1）业务测试：是测试人员将系统的各个模块串接起来运行、模拟真是用户实际的工作流程，满足永续需求定义的功能进行测试的过程。

2）界面测试：界面测试也成为UI测试。测试用户界面的功能模块的布局是否合理，整体风格是否一致、各个控件的放置位置是否符合客户的使用习惯，还要测试操作界面操作便捷性、导航简单易懂性、页面元素的可用性，页面元素的可用性、界面中文字是否正确，命名是否统一，页面是否美观、文字、图片组合是否完美。

3）容错性测试：检查软件在异常条件下自身是否具有防护性的措施或密谋中灾难性恢复的手段

容错性测试和非容错性的测试。

4）文档测试

文档测试的关注点
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性

5）兼容性测试：兼容线性主要指的就是软件之间很好的运作，会不会有影响、软件和硬件之间是否能够发挥很好的效率工作，会不会影响导致系统的奔溃
6）平台测试

7）浏览器测试

8）易用性测试

易用性指的即使我们对于平时所使用的东西是否放在了合适的位置在我们是用的时候能够进行很好的找到。满足人体天生的人体工程学的范畴。

9）安装测试

测试程序的安装、卸载
典型的就是测试APP的测试的安装和卸载

10）安全测试

安全测试是一个相当于来说独立的领域，需更多的专业知识，例如Web的安全测试、需要熟悉各种网络协议，Tcp/Http,防火墙、CDN、熟悉各种操作系统的漏洞。熟悉路由器等。从软件来说熟悉各种的攻击手段，例如sql注入、Xss等。

11）性能测试

检查系统是否满足需求规格说明书中规定的性能
通常表现在以下的几个方面

对资源的利用（如内存、处理机周期等）进行精确地度量。
对执行间隔、日志文件（如中断、报错）
响应时间
吞吐量（TPS）
辅助存储区（例如缓冲区、工作区的大小）
-处理精度等进行检测

12）内存泄漏测试

造成内存泄漏的原因

内存分配完了忘记进行了回收
程序写法有问题
某些API函数的使用不正确，造成内存泄漏
没有及时的进行释放

6、按测试地域划分：

1）本地化测试：之前所有我们将的都是基于本地化进行测试的。

2）国际化测试：软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是这类软件产品进行测试。由于软件的全球普及。还有软外包行业的兴起，软件的本地化和软件的国际化俨然称为了一种软件测试的专门领域。
本地化和国际化的软件测试的一些测试要点。

本地化后的软件在外观上与原来版本存在着一些差异，外观是否整齐、不定样。
是否对界面元素进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示、日志等）。
在不同分辨率界面下是否显示的是正常的。
是否存在不同的字体的大小，字体设置的是否恰当。
日期、数字格式、货币等是否能够适应不同的国家的文化习俗。例如年、月、日，而英文是月日年。
排序的方式是否考虑到了不同语言的特点。
在不同个的国家采用的是不同的度量单位，软件是否能够自适应和转换。
软件是否能够在不同类型的硬件上正常运行。正文翻译是否正确，恰当是否有语法的错误。
软件是否能够适应不同的操作系统的平台。
联机帮助和文档是否已经进行翻译，翻译后链接是否正常。正文翻译是否正确，恰当是否有语法的错误。

六、软件测试的流程

1、分析测试需求

测试人员在制订测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。

测试需求分析其实也是对软件需求进行测试，测试人员可以发现软件需求中不合理的地方，如需求描述是否完整、准确无歧义，需求优先级安排是否合理等。测试人员一般会根据软件开发需求文档制作一个软件需求规格说明书检查列表，按照各个检查项对软件需求进行分析校验。

表列出了需要对软件需求进行什么样的检查，测试人员按照检查项逐条检查和判断，如果满足要求则选择“是”，如果不满足要求则选择“否”，如果某个检查项不适用则选择“NA”。表只是一个通用的软件需求规格说明书检查列表，在实际测试中，要根据具体的测试项目进行适当的增减或修改。

在分析测试需求时要注意，被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

先将需求规格说明书阅读一遍，熟悉项目的基本需求，对项目有个大概的框架思路；
时间充足的情况下，可以利用画流程图的方法来理清需求和自己的思路；
对照需求规格说明书将原型图仔细翻看一遍，对每个字段的来源去向有个思考，页面之间的跳转考虑清楚；
在以上几个步骤的过程中，整理出需要注重点，以及不能理解的问题，利用和同事之间讨论或是和项目经理确认，解决掉问题。

2、制订测试计划

测试工作贯穿于整个软件开发生命周期，是一项庞大而复杂的工作，需要制订一个完整且详细的测试计划作为指导。测试计划是整个测试工作的导航图，但它并不是一成不变的，随着项目推进或需求变更，测试计划也会不断发生改变，因此测试计划的制订是随着项目发展不断调整、逐步完善的过程。

测试计划一般要做好以下工作安排：

确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。
制订测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型(如功能测试、性能测试)选定测试环境和测试方法(如人工测试、自动化测试)。
安排测试资源：通过衡量测试难度、时间、工作量等因素对测试资源进行合理安排，包括人员分配、工具配置等。
安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，较好在各项测试工作之间预留一个缓冲时间以应对计划变更。
预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制订应对策略。

3、设计测试用例

测试用例(Test Case)指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。

测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。测试用例常用的设计方法包括等价类划分法、边界值分析法、因果图与判定表法、正交实验设计法、逻辑覆盖法等。

如何设计一份好的测试用例以及如何做好测试设计，这里只是简单的提一下，后面会单独开一章来讲软件测试设计。

4、执行测试

执行测试就是按照测试用例进行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。测试执行过程看似简单，只要按照测试用例完成测试工作即可，但实则并不如此。测试用例的数目非常多，测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。

当提交后的缺陷被开发人员修改之后，测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫，测试人员则需要编写新的测试用例。在单元测试、集成测试、系统测试、验收测试各个阶段都要进行功能测试、性能测试等，这个工作量无疑是巨大的。除此之外，测试人员还需要对文档资料，如用户手册、安装手册、使用说明等进行测试。因此不要简单地认为执行测试就是按部就班地完成任务，可以说这个阶段是测试人员最重要的工作阶段。

5、缺陷管理

将测试中发现的问题记录下来，分析原因，并给出改进意见。需要对缺陷进行跟踪和管理，直到问题解决。

6、编写测试报告

测试报告是对一个测试活动的总结，对项目测试过程进行归纳，对测试数据进行统计，对项目的测试质量进行客观评价。不同公司的测试报告模板虽不相同，但测试报告的编写要点都是一样的，一般都是先对软件进行简单介绍，然后说明这份报告是对该产品的测试过程进行总结，对测试质量进行评价。

一份完整的测试报告包含的要点

引言：描述测试报告编写目的、报告中出现的专业术语解释及参考资料等。
测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。
测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。
缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因，给出规避措施等建议，同时还要记录残留缺陷与未解决问题。
测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。
测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆想的。