测试必备基础知识总结

什么是软件测试

软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。

本质：软件测试是为发现软件错误而执行程序的过程。

例如场景：淘宝网用户登陆

大家都有在淘宝购物的经历吧，如果想要在淘宝进行购物，就必须登陆后才能进行。

那么能够登陆的前提是什么呢？必须是淘宝网的注册用户。

登陆的步骤是什么呢？在下图1中输入已经注册的用户名>输入已设定的密码>点击“登陆”按钮，步骤非常简单。

大家也一定会遇到过用户名和密码输入错误而无法登陆的情况，此时就需要重新的输入用户名和密码进行再次登陆。

上述场景对淘宝中匹配的用户名和密码能够成功登陆而非匹配的用户名和密码不能登陆的简单验证就是“软件测试”。

图1

 

什么是测试用例

测试用例是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。基础内容包括：测试目标描述、输入数据、测试步骤、预期结果。可能会根据各个公司模板的不同，增加用例编号、模块、用例编写人、创建日期、前提条件等内容。

我们以“淘宝网用户登陆”这个场景为例进行用例设计，把场景中的描述语言转化为用例的设计方法如下：

用例模板实例

编号	模块	用例描述	前提条件	输入数据	测试步骤	预期结果	实际结果
1	登陆	验证未登陆用户不能够购物	用户未登陆		1.访问淘宝网 2.购买任一商品	弹出用户登陆对话框
2	登陆	验证输入正确的用户名和密码能够登陆	用户已经注册	用户名： Kevin 密码： 123456	1.访问淘宝网 2.购买任一商品 3.在弹出的用户登陆对话框中输入测试数据中的用户名和密码 4.点击“登陆”按钮	1.登陆成功 2.进入付款页面
3	登陆	验证输入错误的用户名和密码不能够登陆	用户已经注册	用户名： Kevin 密码： 654321	1.访问淘宝网 2.购买任一商品 3.在弹出的用户登陆对话框中输入测试数据中的用户名和密码 4.点击“登陆”按钮	1.登陆失败 2.未进入付款页面

测试用例设计简单吧！接下来想一下登陆模块的扩展吧！例如：

用户名和密码多次输入不匹配时，系统该如何处理呢？

还有其他扩展点吗？请小白再仔细思考一下哦！

每个公司对于测试用例管理工具的选择是不同的，常用的工具有 Excel，TestLink，TestDirector等等。

小结

l 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。

l 一个成功的测试用例能够发现某个尚未发现的错误。

l 应当彻底检查每个测试用例的执行结果。

测试用例状态

在“用例模版实例”中有’实际结果”这一项，实际结果是测试用例状态的一个记录标识。当用例执行结果与预期结果相同时，在“实际结果”中标识“PASS”，说明该条用例是已经被执行过的，并且执行结果是“通过”；

当用例执行结果与预期结果不相同时，在“实际结果”中标识“FAIL”，说明该条用例是已经被执行过的，并且执行结果是“失败”。用例的其他状态如下：

UNEXECUTED 测试用例尚未执行

PASS 测试用例执行通过

FAIL 测试用例执行失败

WIP（Work in process） 测试用例正在执行中

BLOCKED 测试用例由于其他功能的影响或者其他Bug的影响或者环境因素等不能被执行

REQUIREMENT CHANGE 测试用例审核通过后需求发生变更，导致用例不能被执行

 

什么是软件自动化测试

自动化测试的本质是：用程序测试程序，是将测试用例章节中的测试用例，用代码来实现，即用代码完成测试步骤的执行、预期结果和实际结果的校验工作，因此想从事自动化测也就试工作需要有编码基础。

 

软件自动化测试工具种类繁多，在功能测试领域、性能测试领域、安全性测试领域以及白盒测试领域都有对应的成熟产品工具，刚接触自动化测试的小白建议从功能测试工具开始着手，目前业界流行的软件功能自动化测试工具如下表所示：

被测软件类型	推荐自动化工具
Windows应用	SilkTest、Ranorex
浏览器应用	Selenium
Android应用	Robotium、UIAutomator、Appuim、Monkeytalk
IOS应用	Appuim、Monkeytalk

 

什么是Bug

软件的Bug也叫缺陷，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

在“用例模版实例”中的第一条用例，如果未登陆的用户能够购物，那么这就是一个Bug。

Bug的状态

由于Bug从被测试人员发现到被开发人员修改需要经历一系列的流程，因此Bug是有状态的，基础的Bug状态变更流程

如图2所示：

图2

Open：测试人员发现了一个Bug，并提交。

修改该中：开发人员接收Bug，开始修改。

已改：开发人员修改好Bug，等待测试人员验证。

关闭：测试人员验证Bug被修改好后，将Bug状态更改为“关闭”；如果验证Bug未被改好，需要将Bug状态重新更改为“Open”。

验证Bug是非常重要的测试环节。在理想的项目中，项目结项时Bug全部应该是“关闭”状态。

在实际情况中Bug的变更流程要比这个基础流程复杂很多很多…

Bug的模板

Bug是测试人员提出的并且需要开发人员改正的问题，要让别人改正，首先要保证自己写的Bug是规范的、正确的、完善的，因此为Bug创建一个书写模板是非常必要的。

Bug模板包括的主要内容有：Bug的描述、Bug的严重程度（公司都有各自的标准） 、发现Bug的版本、复现Bug的步骤、以及期望结果和实际结果。

例如：我们假设在淘宝网用户登陆场景中有个Bug: 未登陆的用户能够购物。那么该如何描述这个Bug呢？

Bug的描述：用户在未登录的条件下能进行购物

Bug的严重程度：A

发现Bug的版本：0.2

复现Bug的步骤：

1.访问淘宝网http://www.taobao.com/

2.选中任意商品，并点击“立即购买”

期望结果：弹出用户登陆对话框

实际结果：未弹出用户登陆对话框，可以购买商品

是不是感觉和测试用例中包含的内容很像？其实提交Bug也就是将测试用例中状态为“Fail”的Case，反馈给开发人员并让其修改，然后对这一修改过程做的完整记录。

注意：

对Bug的描述一定要准确，确保开发人员能够通过Bug提交者编写的“复现Bug步骤”将Bug复现，在提交Bug时附上错误截图是非常有效的方法。

 

什么是测试大纲

测试大纲的编写目的是确定测试目标，明确测试范围，主要包括：

确认测试环境（软硬件环境）。

确认测试的模块以及模块中的主要测试点。

确认测试工具的使用（用例用什么编写、Bug用什么提交、是否使用自动化测试工具等等）

测试大纲主要由测试负责人编写。

 

什么是测试计划

测试计划的编写目的是细化测试大纲，并描述要进行的测试活动所需的资源、人力以及进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

测试计划主要由测试负责人编写

 

测试类型有哪些

从软件开发的过程按阶段划分

包括：单元测试、集成测试、系统测试、验收测试和回归测试，具体请参考图3：

图3

系统测试是目前测试人员工作量投入最大的领域，主要包括：功能性测试，性能测试，安全测试等等。

l功能测试：

对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。注重产品的功能是否实现。

l性能测试：

为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。在功能已实现的前提下，注重系统的响应时间。

l安全测试：

安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。

l回归测试：

当程序通过验收测试进行发布后，可能会遇到例如：客户反馈新Bug、新功能添加、软件重新改版等问题。这样就需要对软件进行重新测试，目的是确保新功能的正确性以及验证新功能的修改是否对原有功能造成了影响，于是引出了回归测试的概念。

回归测试最适合实施软件自动化测试。

从是否关心软件内部结构和具体实现的角度划分

包括：白盒测试、黑盒测试、灰盒测试。

白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

 

黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

灰盒测试：灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

 

完整的测试流程是什么

从图3中能够了解到软件开发的流程为：

需求分析>概要设计>详细设计>编码>测试，那么测试工作是从完成编码之后才开始吗？

在实际工作中测试从需求分析就已经开始了。具体开发人员和测试人员在各个阶段的职责，请参考下表：

	开发人员	测试人员
需求分析阶段	了解需求；需求确认	了解需求；需求确认
概要设计阶段	开发计划的编写；选择使用哪种技术；开发架构的搭建	测试大纲编写；测试计划编写
详细设计阶段	在架构中考虑如何将需求转化为代码	测试用例编写
编码阶段	代码实现	测试用例编写；测试用例评审
测试阶段	修改Bug	执行用例；提交Bug；验证Bug