1. 需求

1.1. 需求的概念

简单的来说，就是一个人想要干什么，这就是需求。比如张三想要吃饭，想要工作…

在多数软件公司中，有两部分需求，一部分是用户需求，一部分是软件需求。

1. 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。
2. 软件需求：或者叫做功能需求，该需求会详细描述开发人员必须实现的软件功能。
3. 大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

笼统的来说，用户需求就是掏钱的金主提出的需求，比如金主的一句话，我需要一个登录的功能。而软件需求就是根据用户需求进行细化的文档，用以描述要实现的软件功能。

1.2. 为什么要有需求

一般来说，在公司中，开发测试都时根据软件需求来进行工作的。如果没有需求的，那对于开发人员和测试人员来说，就是没有统一的规定，那么工作可能就不能很好的展开。

比如在高考中，学校都是有录取分数线的，假如你考的学校没有分数线的这个标准，那么你就不能很好的开展你的学习了。

1.3. 测试人员眼中的需求

产品经理写好需求规格说明书之后，就会有详细的需求说明，那么在测试人员眼中的需求是是什么样子的呢？拿登录来举例子，测试眼中的需求如下图。

2. 测试用例

2.1. 为什么需要测试用例

测试用例如同剧本，把对某一个功能或业务进行测试的步骤用文档描述出来，用这个文档指导测试，这个文档就是测试用例，是执行测试所要参考的“剧本”。

设计测试用例是为了更有效、更快地发现软件缺陷，测试用例具有很高的有效性和可重复性，依据测试用例进行测试可以节约测试时间，提升测试效率。

测试用例具有良好的组织性和可追踪性，有利于测试管理。

2.2. 什么是测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了两大问题：测什么？怎么测？

如果要测试一个登录系统，该如何进行呢？

如上的一个登录界面，包括两个输入文本框，分别用来接收用户输入的账号和密码，测试时要把各种不同的用户名和密码进行组合来完成此页面的功能测试。

如下表列出了测试该功能的测试用例文档，包含了相应的测试该功能的测试点，每个测试点对应的测试用例都记录了测试时使用的特定输入以及测试软件的过程步骤。

2.3. 一个简单的测试用例

在测试系统登录功能时，只有输入正确的用户名和正确的密码，登录才能成功。如果没有输入争取的用户名和密码，情况又会如何？下面列举一些可能遇到的非正常登录情况。

1. 如果输入正确的用户名，而密码输入错误，登录应该失败。
2. 如果输入争取的用户名，不输密码，登录应该失败。
3. 如果用户名输错，输入正确的密码，登录应该失败。
4. 如果用户名和密码都不输，直接单击"登录"按钮，也不能通过登录。

以上这些都是测试点，每一个测试点都可以看作一个测试用例。下面以输入正确的用户名和错误的密码为例，展示一个简单的测试用例描述。

3. 软件测试的整体流程

1. 测试需求分析阶段：阅读需求，理解需求，分析需求点，参与需求评审会议。
2. 制定测试计划阶段：参考软件需求规格说明书、项目总体计划等文档确定本次测试的测试范围、测试内容、进度安排以及人力物力等资源的分配，制定整体测试策略。
3. 测试用例设计阶段：主要任务是依据需求文档、概要设计、详细设计等文档设计测试用例，用例编写完成后会进行评审。
4. 测试建模阶段：对被测形同的行为进行抽象和建模，针对业务逻辑复杂的功能和流程进行业务建模，可以为设计测试用例提供支持。
5. 测试执行阶段：测试设计完成后紧接着进入测试执行阶段，包括搭建环境、执行测试、缺陷管理等等。
6. 测试总结阶段：对整个测试进行评估和总结，编写测试报告，确认系统是否可以上线。

4. bug

4.1. 如何描述一个bug

一个合格的bug描述应该包括以下几个部分：

1. 发现问题的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的表示也有利于统计和分析每个版本的质量。
2. 问题出现的环境：环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3. 错误重现的步骤：描述问题出现的最短步骤
4. 预期行为的描述：要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
5. 错误行为的描述：描述错误的现象。
6. 其他：某些公司会有一些其他的要求，例如故障的分类：功能故障、界面故障、兼容性故障等。有些有优先级的分类。
7. 不要把多个bug放到一起，在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

4.2. bug的级别

不同的bug，其处理的紧急程度是不同的。优先级的衡量抓住了在严重性中没有考虑的重要程度因素，优先级的各个等级的具体描述可以参考下图。

4.3. bug生命周期

当一个bug被报告后，测试人员应该对它进行跟踪和响应的处理。而要进行有效的缺陷跟踪和处理，首先要了解缺陷的生命周期。

当一个软件缺陷被发现并报告时，意味着这个缺陷诞生了。缺陷被修正后，经过测试人员的进一步验证，确认这个缺陷不复存在，然后测试人员关闭这个缺陷，意味着缺陷走完了它的历程，结束其生命周期。

从上述可以看出，缺陷的生命周期可以简单地描述为“打开” -> “修正” -> “关闭”。

在缺陷的生命周期，必须设置一些缺陷的状态描述这些情形，并在整个软件开发组织中建立缺陷生命周期模型，以使整个开发团队对缺陷获得一致的理解。软件缺陷的主要状态描述如下表所示。

软件缺陷在生命周期中经历的状态变化的整体过程如下图所示。