我在头条中写了太多关于测试技术的文章，众多测试小白表示强烈的抗议！于是我准备了这篇介绍测试相关基础知识非常适合测试小白的文章。如果你想踏入测试领域，文章中所有的知识点请你务必牢记！因为他们都是初级测试工程师的必会知识点。本文涉及的理论知识都是在具体实践工作中能够使用到的相关知识点，因此更具有针对性。文档在基础知识部分介绍了软件测试的概念、测试用例的设计方法、什么是Bug以及Bug的管理方法、什么是测试大纲、什么是测试计划、测试类型都有哪些以及具体的测试流程是什么；相信通过对本文的学习，小白会对测试相关概念以及具体测试工作内容有总体的印象，这样在具体的工作中不会感到毫无头绪，一头雾水。小白在进入职场接受具体测试业务培训时会感觉相对轻松，也会为培训人员减少部分工作量。
软件测试
软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。本质：软件测试是为发现错误而执行程序的过程。文章源自玩技e族-https://www.playezu.com/191278.html
例如场景：淘宝网用户登陆文章源自玩技e族-https://www.playezu.com/191278.html
大家都有在淘宝购物的经历吧，如果想要在淘宝进行购物，就必须登陆后才能进行。那么能够登陆的前提是什么呢？必须是淘宝网的注册用户。登陆的步骤是什么呢？在下图中输入已经注册的用户名>输入已设定的密码>点击“登陆”按钮，步骤非常简单。文章源自玩技e族-https://www.playezu.com/191278.html
大家也一定会遇到过用户名和密码输入错误而无法登陆的情况，此时就需要重新的输入用户名和密码进行再次登陆。上述场景对淘宝中匹配的用户名和密码能够成功登陆而非匹配的用户名和密码不能登陆的简单验证就是“软件测试”。文章源自玩技e族-https://www.playezu.com/191278.html
测试用例
测试用例是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。基础内容包括：测试目标描述、输入数据、测试步骤、预期结果。可能会根据各个公司模板的不同，增加用例编号、模块、用例编写人、创建日期、前提条件等内容。我们以“淘宝网用户登陆”这个场景为例进行用例设计，把场景中的描述语言转化为用例的设计方法如下：文章源自玩技e族-https://www.playezu.com/191278.html
用例模板实例
测试用例设计是不是灰常的简单！接下来想一下登陆模块的扩展吧！例如：用户名和密码多次输入不匹配时系统该如何处理呢？使用手机验证码登录时系统该如何处理呢？使用手机扫码登录时系统该如何处理呢？还有其他扩展点吗？文章源自玩技e族-https://www.playezu.com/191278.html
另外，每个公司对于测试用例管理工具的选择是不同的，常用的工具有Excel，Word，TestLink，TestDirector，在这里我比较推荐excel，因为它简单方便学习成本极低。文章源自玩技e族-https://www.playezu.com/191278.html
小结文章源自玩技e族-https://www.playezu.com/191278.html
一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。文章源自玩技e族-https://www.playezu.com/191278.html
一个成功的测试用例能够发现某个尚未发现的错误。
应当彻底检查每个测试用例的执行结果。
测试用例状态
在“用例模板实例”中有“实际结果”这一项，实际结果是测试用例状态的一个记录标识。当用例执行结果与预期结果相同时，在“实际结果”中标识“PASS”，说明该条用例是已经被执行过的，并且执行结果是“通过”；当用例执行结果与预期结果不相同时，在“实际结果”中标识“FAIL”，说明该条用例是已经被执行过的，并且执行结果是“失败”。常用的用例的状态如下：
UNEXECUTED测试用例尚未执行
PASS测试用例执行通过
FAIL测试用例执行失败
WIP（Workinprocess）测试用例正在执行中
BLOCKED测试用例由于其他功能的影响或者其他Bug的影响或者环境因素等不能被执行
REQUIREMENTCHANGE测试用例审核通过后需求发生变更，导致用例不能被执行
备注：不同的公司会有不同的用例状态，但是核心内容都是一致的。
Bug
软件的Bug也叫缺陷，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。在“用例模板实例”中的第一条用例，如果未登陆的用户能够购物，那么这就是一个Bug。
Bug的状态
由于Bug从被测试人员发现到被开发人员修改需要经历一系列的流程，因此Bug是有状态的，基础的Bug状态变更流程如下图所示：
Open：测试人员发现了一个Bug，并提交。
修改中：开发人员接收Bug，开始修改。
已改：开发人员修改好Bug，等待测试人员验证。
关闭：测试人员验证Bug被修改好后，将Bug状态更改为“关闭”；如果验证Bug未被改好，需要将Bug状态重新更改为“Open”。
验证Bug是非常重要的测试环节。在理想的项目中，项目结项时Bug全部应该是“关闭”状态。在实际情况中各个公司Bug的变更流程要比这个基础流程复杂很多很多，但是万变不离其中，核心东东就是这四个！
Bug的等级划分
按照Bug的重要程度通常分为：阻碍测试、致命、严重、一般、低级和建议，可以使用Blocker、A、B、C、D表示。由于本文是测试的入门文章，所以这里对bug级别的解释只涉及功能测试，具体级别定义如下：
Blocker
某错误导致主要功能测试无法继续执行
主要功能未实现，影响测试进度
正常操作导致系统无法工作，引起频繁假死、崩溃
严重的数据问题
主要需求未覆盖或覆盖不完整
A
主要功能未实现，并未响测试进度
严重的数据问题
正常操作引起假死、崩溃、异常
某错误导致主要功能进行部分测试，但不影响测试进度
B
主要功能部分未实现，次要功能没有完全实现，并不影响测试进度
较严重的数据问题
较常见操作引起的假死、崩溃、异常
功能实现与产品需求不符
C
次要功能没有完全实现但不影响使用
轻微的数据问题
重现几率较低的假死、崩溃、异常等
D
建议性问题
实际工作中我们重点关注Blocker、A、B级别的bug！
Bug的模板
Bug是测试人员提出的并且需要开发人员改正的问题，要让别人改正，首先要保证自己写的Bug是规范的、正确的、完善的，因此为Bug创建一个书写模板是非常必要的。
Bug模板包括的主要内容有：Bug的描述、Bug的严重程度（公司都有各自的标准）、发现Bug的版本、复现Bug的步骤、以及期望结果和实际结果。例如：我们假设在淘宝网用户登陆场景中有个Bug:未登陆的用户能够购物。那么该如何描述这个Bug呢？
Bug的描述：用户在未登录的条件下能进行购物
Bug的严重程度：A
发现Bug的版本：version0.2
复现Bug的步骤：
1.访问淘宝网https://www.taobao.com/
2.选中任意商品，并点击“立即购买”
期望结果：弹出用户登陆对话框
实际结果：未弹出用户登陆对话框，可以购买商品
是不是感觉和测试用例中包含的内容很像？其实提交Bug也就是将测试用例中状态为“Fail”的Case，反馈给开发人员并让其修改，然后对这一修改过程做的完整记录。
注意：
对Bug的描述一定要准确，确保开发人员能够通过Bug提交者编写的“复现Bug步骤”将Bug复现，在提交Bug时附上错误截图是非常有效的方法。
测试大纲
测试大纲的编写目的是确定测试目标，明确测试范围，主要包括：
确认测试环境（软硬件环境）。
确认测试的模块以及模块中的主要测试点。
确认测试工具的使用（用例用什么编写、Bug用什么提交、是否使用自动化测试工具等等）
测试大纲主要由测试负责人编写。
测试计划
测试计划的编写目的是细化测试大纲，并描述要进行的测试活动所需的资源、人力以及进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
测试计划主要由测试负责人编写。
测试类型
从软件开发的过程按阶段划分
包括：单元测试、集成测试、系统测试、验收测试和回归测试，具体请参考下图：
系统测试
主要包括：功能性测试，性能测试，安全测试等等。
功能测试：
对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。注重产品的功能是否实现。
性能测试：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。在功能已实现的前提下，注重系统的响应时间。
安全测试：
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
回归测试
当程序通过验收测试进行发布后，可能会遇到例如：客户反馈新Bug、新功能添加、软件重新改版等问题。这样就需要对软件进行重新测试，目的是确保新功能的正确性以及验证新功能的修改是否对原有功能造成了影响，于是引出了回归测试的概念。
从是否关心软件内部结构和具体实现的角度划分
主要包括：白盒测试、黑盒测试、灰盒测试。
白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
测试流程
软件测试流程图中能够了解到软件开发的流程为：
需求分析>概要设计>详细设计>编码>测试，那么测试工作是从完成编码之后才开始吗？在实际工作中测试从需求分析就已经开始了。具体开发人员和测试人员在各个阶段的职责，请参考下表：
注意：从上表可以看出，测试用例的设计与编码是同时进行的。在产品开发完成后，根据现有产品来设计测试用例的工作方法是不正确的。
评论