本篇中介绍软件测试中大量的基础概念, 主要包含需求, bug, 测试用例等概念, 一些生命周期的介绍, 常见的开发模型和测试模型等等.

一. 衡量软件测试结果的依据—需求

1. 什么是需求

生活中, 比如我们想说话, 不想上课了, 想吃饭, 这些都是我们的需求.

而在软件测试中需求的概念如下:

• 需求是满足用户的期望或正式规定的文档（合同、标准、规范）所具有的条件和权限。

需求又包含用户需求和软件需求。

• 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成 的任务。该需求一般比较简略。
• 软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

用户需求 通常是简略的(对应着上述中的 “用户的期望” ); 软件需求, 是用户需求的细化, 以及具体的实现细节, 最后演变成文档(正式规定的文档), 日常工作中不管是测试还是开发, 工作的直接依据就是软件需求.

软件需求 是 用户需求 转化而来的, 也就是说 软件需求 是 用户需求 的 进一步的细化和分解.

2. 案例 - 平台支持邮箱注册

假设我们现在要开发一个可以使用邮箱注册的一个注册系统, 如下图所示 :

这里的用户需求其实就是一句话: 平台支持邮箱注册.

这里要知道一个项目不是一个人来完成的, 而是一个团队; 每个人对注册系统的想法都可能是不一样的; 比如下面这种情况:

1. 有的人觉得都用邮箱注册了, 用户名就可有可无了.
2. 有的人觉得不需求验证码这一项, 邮件写错, 是收不到到邮件的, 也就没法注册了.

每个程序员, 思考问题的方式都是不同的, 如果只是基于基于用户需求那一句话去开发的话, 一个开发团队中每个人在想法都有差异, 那么如何保证每个人开发出来的东西具有一致性呢?

这个时候, 就需要将用户需求转化成软件需求; 把具体的实现细节写成需求文档, 指定每个部分是一个什么样的思维, 去实现一个怎样的功能; 开发人员就可以按照需求文档去进行开发; 这就好比我们用Java在写Servlet程序一样, 我们需要约定好前后端的交互接口; 接着就是围绕这个接口, 进行一系列的代码编写.

就好比下面这套软件软件需求规格说明书, 首先是提出用户需求, 然后再将用户需求转化成软件需求.

软件需求规格说明书

一、用户需求：

平台支持邮箱注册

二、软件需求：

1.1.1.1 注册账号

1.1.1.1.1 功能概述

用户可以通过填写邮箱信息在平台注册个人用户。

1.1.1.1.2 用户角色

匿名用户。

1.1.1.1.3 前置条件

无。
1.1.1.1.4 输入

序号	栏位名称	栏位说明	长度	类型	备注
1	姓名	必填，录入个人姓名	6至15	字符型
2	电子邮箱	必填，录入个人姓名		字符型
3	密码	必输，输入的密码隐藏*号显示，最短6位	6至15	字符型
4	确认密码	必输，输入的密码隐藏*号显示，最短6位	6至15	字符型
5	验证码	必输，输入的密码隐藏*号显示，最短6位		字符型
6	注册	注册操作		操作型

1.1.1.1.5 处理

1.1.1.1.5.1 基本事件流

1、 用户选择注册；

2、 系统展现用户协议界面，并请用户确认是否同意用户协议

1. 若用户不同意协议，系统禁止用户注册。

2. 若用户同意协议，用户进行注册信息填写。

3、 用户填写注册信息。

注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。

4、 用户提交注册信息；

5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收 到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。

6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。

7、 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2 扩展事件流

1、 用户注册并激活成功后，第一次登录平台时，提示用户完善信息；
1.1.1.1.5.3 异常事件流

1、 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。

2、 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出

用户注册成功

1.1.1.1.7 后置条件

该模块为用户登陆等的前置模块。

3. 从测试人员角度看需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例

以“用户登录”为例，来阐述下整个过程.

通过这样的方式，我们就可以有条不紊的完成我们职责。
而且，漏掉某一项测试的概率也会非常小。
如果漏掉了，再根据这个按照需求制作的表格，一个个查证，很快就能锁定，并且补上对应测试。

为什么需求对软件测试人员如此重要?

• 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
• 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

如何才可以深入理解被测试软件的需求?

• 在未来的工作, 通过参加公司的需求评审会议来进一步理解需求, 这个会议一般都会阐述这个需求的背景.
• 查阅相关文档 (需求文档, 技术文档等).
• 学会沟通, 可以找产品了解软件功能, 找开发了解软件的实现.

二. 测试用例

1. 测试用例的概念

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

可以简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求; 测试用例解决了两大问题：测什么，怎么测.

2. 案例

这里用163网易邮箱的登录界面来举例说明

假设我们现在要开始写测试用例了; 现在我们有一组正确的用户名和密码.

用户名: qwe123456789

密码: xxxr987654

假设我们用以上正确的用户名和密码登录网易邮箱, 而且登录成功.

现在我们需要写一个测试用例, 它的标题: 正确的用户名密码，可以登录邮箱.

那么, 我们的测试用例, 具体是什么?

我们知道测试用例可以划分成以下内容:

1、测试环境 2、测试数据 3、测试步骤 4、预期结果

🍂首先我们来看具体的测试环境是怎么描述的

先思考我们是在什么样的环境下，访问的网易邮箱的主页网页?

这里列出我的环境,

1. 我的电脑系统是win11, 这是一个环境.
2. 使用的是Chrome浏览器
3. 给出浏览器的版本

对于我们测试开发人员来说: 环境的描述是越详细越好!

🍂测试数据

针对我们现在这里的场景, 很好描述, 就是给出的一组用户名和密码

用户名: qwe123456789

密码: xxxr987654

🍂测试步骤

1. 打开用Chrome浏览器，在地址栏中输入URL
2. 输入用户名和密码
3. 点击登录按钮/enter键，触发登录操作

🍂预期结果

登录成功, 并页面跳转

那么到这里这个测试用例就设计完了, 初学时看这个测试用例是正常的, 但这个里唯一缺点就是不够详细.

我们上面给出的测试用例标题是 “正确的用户名密码可以成功登录邮箱”，这其实是一个非常模糊和片面的说法; 而我们将进行了初步的划分, 也就是划分成了 4 个部分, 但其实划分出的这几个部分, 也是可以进行细分从而再划分成一个个的测试点的.

3. 为什么要有测试用例

测试过程中可能会遇到以下问题:

• 不知道是否较全面的测试了所有功能 –测试的覆盖率无法衡量
• 对新版本的重复测试很难实施
• 存在大量冗余测试影响测试效率

测试用例的产生就是为了解决上述的问题:

• 测试用例提高了测试人员工作效率, 解决了测试人员工作的重复性问题.
• 测试用例是建立自动化的基础, 而自动化就是把测试人员双手解放, 让代码代替人员执行测试

三. 软件错误 (BUG)

1. 什么是bug

软件错误的一般定义: 程序与规格说明之前不匹配; 其实这个说法是片面的, 准确的来说: 当且仅当规格说明是存在的并且正确 (软件需求, 规格说明书), 程序与规格说明之间的不匹配才是错误 (预期结果!=执行结果, 即bug).

当需求规格说明书没有提到的功能, 判断标准以最终用户为准: 当程序没有实现其最终用户合理预期的功能要求时, 就是软件错误 (bug).

2. 如何描述一个bug

首先, 我们要理解一件事: 为什么要描述一个 bug ?

当我们认为我们发现一个bug时, 我们是需要将这个bug告诉开发的, 但如果你只是简单的跟开发说这是一个bug, 你看一下, 开发可能就懵了, 他不知道这为什么是一个bug, 所以测试人员需要将bug描述清楚, 开发才好根据问题去修改.

通常, 一个合格的bug描述应该包括以下几个部分:

1. 发现问题的版本 (代码提交版本号)

• 开发人员需要知道出现问题的版本, 才能够获取对应版本的代码来重现故障; 并且版本的标识也有利于统计和分析每个版本的质量.

2. 问题出现的环境

• 因为在不同测试环境问题出现的情况也不一样
• 环境分为硬件环境和软件环境, 如果是web项目, 需要描述浏览器版本, 客户机操作系统等; 如果是 app项目, 需要描述机型, 分辨率, 操作系统版本等; 详细的环境描述有利于故障的定位.

3. 错误重现的步骤

• 描述问题重现的最短步骤, 方便为开发人员复现问题

4. 预期行为的描述

• 要让开发人员指导怎么样才是正确的, 尤其要以用户的角度来描述程序的行为是怎样的; 如果是依据需求提出的故障, 能写明需求的来源是最好的.
• 要相信：测试人员是最懂需求的。

5. 错误行为的描述

• 描述错误的现象, crash等可以上传log, UI问题可以有截图.

6. 其他

• 某些公司会有一些其他的要求, 例如故障的分类: 功能故障, 界面故障, 兼容性故障等; 有些有优先级的分类, 严重影响测试需要开发人员优先修改的, 可以设置优先级为高.

7. 不要把多个bug放到一起

• 在无法确认是同一段代码造成的故障时, 不要将bug放在一起提交.

总之, 我们对于BUG的描述越详细, 越招同事待见.

3. bug的级别

对于BUG的级别, 每个公司都不一样, 这里列出的只是普遍的情况:

1. Blocker(崩溃)

• 系统崩溃, 不能运行, 死循环, 数据库死锁, 资源分配不均, 黑屏, 闪退, 阻塞.
• 线上(用户使用的环境)出现崩溃级别的BUG: 回到上一个可稳定运行的历史版本.

2. Critical(严重)

• 服务器可以用, 但是不稳定, 继续使用会产生严重的错误; 一级菜单错误, 数据库插入数据错误, 威胁到用户的安全等.

3. Major(一般)

• 系统可以稳定的运行, 次要的功能没有实现, 提示语不完整, 弹出框没有关闭按钮, 不影响用户的使用.

4. Minor(次要/建议)

• 建议性的, 提示信息重叠(看不清楚), 界面排版不符合用户使用习惯, 颜色不符合软件使用场景.

注意: 如果发现崩溃级别的BUG, 那么此时就需要停止测试, 进行测试打回.

4. bug的生命周期

BUG的生命周期: 从发现这个bug 到 解决这个bug, 整个的一个流程.
简单来说: BUG的生命周期 就是 BUG 的 各种生存状态.

● New: 新发现的Bug, 未经评审决定是否指派给开发人员进行修改.

● Open: 确认是Bug, 并且认为需要进行修改, 指派给相应的开发人员.

● Fixed: 开发人员进行修改后标识成修改状态, 有待测试人员的回归测试验证.

● Rejected: 如果认为不是Bug, 则拒绝修改.

● Delay: 如果认为暂时不需要修改或暂时不能修改, 则延后修改.

● Closed: 修改状态的Bug经测试人员的回归测斌验证通过, 则关闭Bug.

● Reopen: 如果经验证Bug仍然存在, 则需要重新打开Bug, 开发人员重新修改.

无效的bug：open->closed open-rejected-closed

问题: 发现一个BUG, 开发人员修改了, 通知测试人员验证, 但是测试人员又复现了这个BUG, 是哪些可能的原因引起的?

答: 测试环境不一样; 开发人员理解不到位, 没有修改成功; 代码在开发人员修改之后未进行远程提交代码, 测试人员用旧版本(有问题的代码)进行测试.

5. 如果因为bug和开发人员产生冲突, 该如何处理?

要认认识到一点: 一定不能吵架, 一定要理性的去看待问题.

1. 先从自身找问题: 确保操作没有问题, 确保自己对需求理解的没有问题, 检查看自己对BUG的描述是否清楚.
2. 确保自身没有问题的情况下和开发好好沟通.
3. 站在用户角度考虑问题, 从用户的角度去说服开发人员, 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员, 更加积极地, 高质量地修改bug, 因为有些时候, 真的是有些bug可改可不改; 但是改了的话, 用户的体验会非常好; 而且, 有些bug产生的原因是因为在需求文档中没有描述的很清楚, 此时也可以去找产品经理去沟通.
4. 我们测试人员, 不光要能发现问题, 还应该能够提出解决问题方案给开发.
5. 第三方会议, 可能你已经经过了多轮沟通, 但是开发人员仍然拒不接受; 此时可以发起Bug评审, 找产品经理讨论, 后面就会开展一个第三方会议, 测试人员, 开发人员, 产品经理会一起讨论这个bug的最终解决方案; 但要注意, 作为测试人员, 开会之前, 我们一定要明确问题产生原因, 问题是什么, 解决方案是什么; 开会之后就会得到关于这个bug的处理结果: 问题要不要解决, 什么时候解决, 由谁去解决.

四. 开发模型和测试模型

1. 软件开发的生命周期

软件开发的生命周期, 其实就是一个软件从无到有的过程, 可以分成6个阶段, 即需求分析, 计划, 设计, 编码, 测试, 运行维护.

• 需求分析: 分析需求是否合理，需求是否完整
• 计划: 谁开发, 谁测试, 开发多久, 测试多久…
• 设计: 设计技术文档 (涉及哪些接口，库表，mq，定时任务…), UI设计稿等…
• 编码: 就是开发写代码了
• 测试: 编写测试用例, 执行测试用例, 提交BUG, 产出测试报告
• 运行维护: 项目部署上线, 如果有线上问题, 此时测试人员需要协助开发定位问题以及解决问题.

2. 软件测试的生命周期

软件测试的生命周期: 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估.

1. 需求分析

• 验证需求的正确性, 以及合理性.
• 接着便是细化需求, 找出测试点, 方便后面写测试用例.

2. 测试计划

• 确定软件由谁测试, 什么时候开始测试, 什么时候结束测试
• 要测试哪些模块

3. 测试设计、测试开发

• 根据需求, 写出测试用例 (手工测试用例, 自动化测试用例)
• 编写测试工具

4. 测试执行

• 此时开发已经完成, 就要执行测试用例, 验证功能了.
• 在验证功能的过程中, 可能会遇到软件功能与需求不相符的情况, 也就是出BUG了; 此时, 测试人员就会把这个 BUG 交给开发人员, 等到开发人员处理好了之后, 测试人员要再次对其进行验证.

5. 测试评估

• 测试人员产出测试报告, 大概包含有以下的内容.
• 1、写了多少测试用例, 执行了多少测试用例.
  2、剩余的测试用例, 为什么不把它执行完.
  3、BUG数量.
  4、已解决的BUG数量.
  5、遗留的BUG, 以及解决方案.
  6、此次测试的范围和测试功能都要说清楚.

3. 开发的五大模型

瀑布模型(Waterfall Model)

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次，因此是线性顺序进行的软件开发模式。

特点:

• 线性的开发流程，不能应对需求的变化

优点:

• 每个阶段该做什么, 要产出什么都是非常清晰的.

缺点：

• 风险往往迟至后期的测试阶段才显露, 因而失去及早纠正的机会.
• 测试阶段处于软件实现后, 这意味着必须在代码完成后有足够的时间预留给测试活动, 否则将导致测试不充分, 从而把缺陷直接遗留给用户.

瀑布模型适用于需求明确, 低风险, 小型的项目, 这样即使测试后期问题才出现, 解决起来成本也不至于太高.

瀑布模型的一个最大缺陷在于：可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。

尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

简单来说: 瀑布模型, 一旦是开始项目操作, 中途是没有 “刹车 和 回炉” 的操作; 之所以称为 瀑布模型，想一下, 你有见过瀑布的水逆流而上吗？或者说, 你见过瀑布的水, 流到一半静止的吗？采用 瀑布模型，是没有 “后悔药” 可以吃的.

螺旋模型 (Spiral Model)

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

螺旋模型任务区域（4个象限），各象限含义如下：

• 制定计划——确定软件目标，选定实施方案，弄清项目开发的限制条件；
• 风险分析——分析评估所选方案，考虑如何识别和消除风险；
• 实施工程——实施软件开发和验证；
• 客户评估——评价开发工作，提出修正建议，制定下一步计划。

优点:

• 每个阶段都会进行风险分析，避免一些线上问题发生, 随着过程进展演化, 开发者和客户能够更好地理解和对待每一个级别上的风险, 使用原型实现作为降低风险的机制.

缺点:

• 模型的成功依赖于风险评估的专门技术, 也就是说风险分析可能会分析错.
• 需要人力财力的大量投入.

螺旋模型适用于大规模软件项目, 这种风险比较多的项目.

增量模型 && 迭代模型

假设我们要实现一个系统, 该系统有 4个模块 ABCD.

增量模型: 就是将4个模块按顺序进行开发，先完成 A, 然后完成B, 接着完成C, 最后后再来完成 D 模块 (可以理解为盖楼, 第一层盖好装修好后再继续第二层…).

迭代模型：先将4个模块的基础 框架搞定, 然后在这个基础上, 继续完善4个部分的一些代码 (可以理解为盖楼时, 先盖好整体楼盘, 然后再一层层修饰).

敏捷模型

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。

在会议上，他们提出了《敏捷宣言》http://agilemanifesto.org/： 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观。

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

核心思想: 轻流程, 轻文档, 重目标, 重产出, 响应变化.

由敏捷宣言可以看出：

敏捷其实是有关软件开发的社会工程(Social Engineering)的。

敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

敏捷开发有很多种方式，其中 scrum(敏捷开发) 是比较流行的一种。

scrum里面的三大角色

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队, 由许多人构成后端开发, 前端开发, UI设计师, 测试等)组成。

• 其中product owner负责整理user story(用户故事/需求)，定义其商业价值，对其进行排序，制定发布计划，是产品的负责人.
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发

与瀑布不同, scrum将产品的开发分解为若干个小sprint(迭代), 其周期从1周到4周不等, 但不会超过4 周; 参与的团队成员一般是5到9人, 每期迭代要完成的user story是固定的, 每次迭代会产生一定的交付.

下面我们来看一下 scrum(敏捷) 的基本流程:

• 首先, 产品负责人负责整理user story，形成product backlog.
• 发布计划会议: 紧接着就会进行发布计划会议, 产品经理(PO)把整理好的用户需求进行讲解, 排优先级; 找出优先级高的组成本次的迭代内容，形成sprint backlog（任务列表).
• 迭代计划会议: 项目经理(SM) 和 研发团队(ST)人员一起把本期要迭代的需求进行分解, 进行任务分配和时间估算(需求进行优先级划分, 计划项目由谁去做, 什么时候开始, 什么时候结束).
• 分配完了之后, 就进入了开发阶段
• 每日站会: 开发阶段每天都会进行站会, 主要就是说说昨天工作有没有完成, 如果没有完成, 遇到了什么问题, 以及今天计划做什么.
• 演示会议: 本次迭代结束之后就会召开演示会议, 相关人员都受邀参加, 团队负责向大家展示本次迭代取得的成果; 期间大家的反馈都会记录下来, 由产品经理整理成新的用户需求, 放到下—期迭代中.
• 回顾会议: 最后, 就是回顾会议, 回顾本次敏捷流程, 把不好的地方找出来, 下次迭代改进, 优化敏捷流程, 因为敏捷流程随着我们不断的实践, 不断实施这个流程, 敏捷流程会越来越贴合实际, 开团团队的默契也会上升, 从而开发的效率也随之提高.

以上流程中, 项目产品的开发会分为若干次小迭代进行, 而且每天都会进行站会交流, 这就让项目的开发过程根据变化而变化, 适应于敏捷模型.

4. 软件测试模型

V模型

V模型, 是由瀑布模型演变而来的.

各个阶段的大概过程如下:

• 用户需求: PO将用户需求收集形成软件需求.
• 需求分析与系统设计: 验证需求是否正确, 确定编程语言, 确定框架等.
• 概要设计: 项目结构如何设计.
• 详细设计: 每个接口涉及哪些库表, 涉及哪些任务.
• 编码: 写代码.
• 单元测试: 比如再Java当中就是测试每一个方法和类.
• 集成测试: 将许多方法集成, 测试不同模块接口间是否可以正常的配合使用.
• 系统测试: 对整个系统功能进行测试, 也要保证模块和模块之间不会互相影响.
• 验收测试: 产品和运营确认软件系统符合用户和利益相关者的要求.

特点:

• 左边是开发, 右边是测试.
• 左边每一个阶段 和 右边的阶段，都是一一对应的
• 左边的每个阶段是右边测试每一个阶段的依据

优点:

• 测试被划分成许多类型

缺点:

• 还是像瀑布模型一样的老问题, 它是串行执行的, 测试人员介入太晚, 让前期的问题，后期才发现，导致前期问题不能及时解决

W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动, W模型由两个V字型模型组成, 分别代表测试与开发过程, 图中明确表示出了测试与开发的并行关系;

就比如说, 如果用户需求完成, 下层级的需求分析与系统设计, 概要设计就会开始工作; 与此同时, 验收测试也将开始编写测试用例和搭建测试环境.

特点:

• 测试的对象不仅是程序, 需求, 设计等同样要测试, 测试与开发是同步进行的.

优点:

• 测试人员尽早介入了需求, 有利于尽早地全面的发现问题.

缺点:

• 需求, 设计, 编码等活动被视为串行的; 测试和开发活动也保持着一种线性的前后关系, 上一阶段完全结束, 才可正式开始下一个阶段工作; 比如系统测试的开始条件是集成测试完成且无无重大bug.
• 并不能支持需求变化, 也就是无法支持敏捷开发模式.

五. 如何开始第一次测试

作为一个菜鸟在进入测试团队开始第一次测试的时候, 我们需要做很多的准备：

1. 阅读所有项目有关的文档, 包括: 需求文档, 设计文档, 用户手册.
2. 尽可能参加各种项目会议, 了解项目的背景, 人员组成, 尽可能的了解需求和业务; 特别针对业务专业性较强的项目, 例如银行业务, 需要了解各种业务知识, 如高低柜, 一二三类账户等, 存款, 贷款等.
3. 熟悉项目所使用的测试管理工具, 配置管理工具, 获取对应的地址和登录方式.
4. 阅读已有的测试方案和测试案例.
5. 阅读旧有的bug库, 了解系统功能; 尤其重要的是和现有的测试团队保持一致的故障定级原则.
6. 了解公司的规范要求, 特别是用例编写规范, 用例执行规范, bug提交规范, 测试工具工具使用规范等.

在进行了以上的准备工作之后, 第一次测试工作到来了, 我们需要与测试组长确认具体的工作内容:

1. 测试的计划是什么?
2. 测试的内容是什么? test case有多少? 安排了几天执行? 有没有自由测试的时间?
3. 我要测试的内容开发人员是谁? 需求人员是谁?
4. 分配给我的测试内容是否需要特殊的测试资源? 资源是否满足需要? 在我们确认了以上内容之后. 就可以开始测试的执行了.

六. 测试的执行和bug管理

测试的执行要完成下面的基本流程:

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告

执行测试时除了要做到测试用例和需求的覆盖外, 还要有临时发挥的能力; 根据自己的经验, 对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷.

不能拘泥于测试用例或者已经有的测试方法, 在测试执行过程中要不断总结测试方法和测试故障模型; 真正优秀的测试人员在执行测试时是想着做, 做着想, 这样的测试效果才好, 尤其是在测试过程中, 对程序的处理相当了解的情况下, 测试的思路会更加清晰和全面.

每个公司其实都是有指定的Bug管理工具的, 用于记录, 跟踪和管理软件测试过程中发现的Bug或缺陷.

Bug管理系统是软件测试过程中必不可少的工具之一, 让测试人员和开发人员更方便的进行交互, 帮助测试团队更好地管理和追踪软件缺陷, 提高测试效率和软件质量.

如何发现更多的bug?

1. 软件测试同样存在二八原则, 80%的故障集中于20%的模块, 如果某部分问题较多, 加强测试广度和深度!
2. 开发人员也存在二八原则, 80%的故障集中于20%的开发人员, 如果某些开发人员的bug较多, 加强他开发模块的测试广度和深度!
3. 多进行逆向思维和发散性的思维, 这个依赖于测试人员的经验, 对于初学者来说, 应该去写测试用例，多看看别人的测试用例来增长经验.
4. 不要局限于用例和需求文档.
5. 尽早介入项目以便尽早理解需求, 不要等到开发的差不多了再介入项目.