什么是软件测试
软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
本质：软件测试是为发现软件错误而执行程序的过程。
例如场景：淘宝网用户登陆，大家都有在淘宝购物的经历吧，如果想要在淘宝进行购物，就必须登陆后才能进行。那么能够登陆的前提是什么呢？必须是淘宝网的注册用户。登陆的步骤是什么呢？在下图1中输入已经注册的用户名输入已设定的密码点击“登陆”按钮，步骤非常简单。大家也一定会遇到过用户名和密码输入错误而无法登陆的情况，此时就需要重新的输入用户名和密码进行再次登陆。
上述场景对淘宝中匹配的用户名和密码能够成功登陆而非匹配的用户名和密码不能登陆的简单验证就是“软件测试”。
什么是测试用例
测试用例是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式。基础内容包括：测试目标描述、输入数据、测试步骤、预期结果。可能会根据各个公司模板的不同，增加用例编号、模块、用例编写人、创建日期、前提条件等内容。
我们以“淘宝网用户登陆”这个场景为例进行用例设计，把场景中的描述语言转化为用例的设计方法如下：
测试用例设计简单吧！接下来想一下登陆模块的扩展吧！例如：用户名和密码多次输入不匹配时，系统该如何处理呢？还有其他扩展点吗？请小白再仔细思考一下哦！
每个公司对于测试用例管理工具的选择是不同的，常用的工具有Excel，TestLink，TestDirector等等。
小结
一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。一个成功的测试用例能够发现某个尚未发现的错误。应当彻底检查每个测试用例的执行结果。
测试用例状态
在“用例模板实例”中有“实际结果”这一项，实际结果是测试用例状态的一个记录标识。当用例执行结果与预期结果相同时，在“实际结果”中标识“PASS”，说明该条用例是已经被执行过的，并且执行结果是“通过”；当用例执行结果与预期结果不相同时，在“实际结果”中标识“FAIL”，说明该条用例是已经被执行过的，并且执行结果是“失败”。用例的其他状态如下：
UNEXECUTED测试用例尚未执行
PASS测试用例执行通过
FAIL测试用例执行失败
WIP（Workinprocess）测试用例正在执行中
BLOCKED测试用例由于其他功能的影响或者其他Bug的影响或者环境因素等不能被执行
REQUIREMENTCHANGE测试用例审核通过后需求发生变更，导致用例不能被执行。
什么是软件自动化测试
自动化测试的本质是：用程序测试程序，也就是将测试用例章节中的测试用例，用代码来实现，即用代码完成测试步骤的执行、预期结果和实际结果的校验工作，因此想从事自动化测试工作需要有编码基础。软件自动化测试工具种类繁多，在功能测试领域、性能测试领域、安全性测试领域以及白盒测试领域都有对应的成熟产品工具，刚接触自动化测试的小白建议从功能测试工具开始着手，目前业界流行的软件功能自动化测试工具如下表所示：
什么是Bug
软件的Bug也叫缺陷，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
在“用例模板实例”中的第一条用例，如果未登陆的用户能够购物，那么这就是一个Bug。
Bug的状态
由于Bug从被测试人员发现到被开发人员修改需要经历一系列的流程，因此Bug是有状态的，基础的Bug状态变更流程
如图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.访问淘宝网
2.选中任意商品，并点击“立即购买”
期望结果：弹出用户登陆对话框
实际结果：未弹出用户登陆对话框，可以购买商品
是不是感觉和测试用例中包含的内容很像？其实提交Bug也就是将测试用例中状态为“Fail”的Case，反馈给开发人员并让其修改，然后对这一修改过程做的完整记录。
注意：
对Bug的描述一定要准确，确保开发人员能够通过Bug提交者编写的“复现Bug步骤”将Bug复现，在提交Bug时附上错误截图是非常有效的方法。
什么是测试大纲
测试大纲的编写目的是确定测试目标，明确测试范围，主要包括：
确认测试环境（软硬件环境）。
确认测试的模块以及模块中的主要测试点。
确认测试工具的使用（用例用什么编写、Bug用什么提交、是否使用自动化测试工具等等）
测试大纲主要由测试负责人编写。
什么是测试计划
测试计划的编写目的是细化测试大纲，并描述要进行的测试活动所需的资源、人力以及进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
测试计划主要由测试负责人编写。
测试类型有哪些
从软件开发的过程按阶段划分
包括：单元测试、集成测试、系统测试、验收测试和回归测试，具体请参考图3：
单独子模块的测试，一个模块的功能及常规错误测试，侧重于代码。
各模块联调测试，集中在各模块的接口是否一致、各模块间的数据流和控制硫是否按照设计实现其功能、以及结果的正确性验证等等。侧重于接口
针对整个产品的全面测试，既包含各模块的验证性测试和功能性测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。
让系统用户决定是否接收系统，是一项确定产品是否能够满足合同或用户所规定需求的测试。
图3
系统测试是目前测试人员工作量投入最大的领域，主要包括：功能性测试，性能测试，安全测试等等。
功能测试：
对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。注重产品的功能是否实现。
性能测试：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。在功能已实现的前提下，注重系统的响应时间。
安全测试：
安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。
回归测试：
当程序通过验收测试进行发布后，可能会遇到例如：客户反馈新Bug、新功能添加、软件重新改版等问题。这样就需要对软件进行重新测试，目的是确保新功能的正确性以及验证新功能的修改是否对原有功能造成了影响，于是引出了回归测试的概念。
回归测试最适合实施软件自动化测试。
从是否关心软件内部结构和具体实现的角度划分
包括：白盒测试、黑盒测试、灰盒测试。
白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
灰盒测试：灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试
完整的测试流程是什么
从图3中能够了解到软件开发的流程为：
需求分析概要设计详细设计编码测试，那么测试工作是从完成编码之后才开始吗？
在实际工作中测试从需求分析就已经开始了。具体开发人员和测试人员在各个阶段的职责，请参考下表：
小编：紫凝雪儿