【软件测试 】基础篇 —— 概念，需求，缺陷，开发模型

什么是软件测试？

找 bug 以及验证软件功能是否满足用户要求。

软件测试与开发的区别？

也是测试与调试的区别

1.目的不同：测试的任务是发现程序中的缺陷；调试的任务是定位并且解决程序中的问题。
2.参与角色不同：测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。调试由开发人员完成。
3.执行的阶段不同：测试贯穿整个软件开发生命周期，调试一般在开发阶段

软件测试的目的和原则：

目的：验证软件有或没有问题。
原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

什么是需求？

用户需求 -- 沟通 -- （形成）软件需求

前置模块与后置模块：比如对登录来说，注册就是它的前置模块。

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

什么是 bug

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软
件错误。

需求规格说明书不一定是正确的，如何保证需求正确？评审

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

写测试用例就需要知道产品需求，需求不明确时假设场景针对某一方面写或者写出公共性能。

软件生命周期：需求分析、计划、、设计、编码、测试、运行维护

软件开发模型

1.瀑布模型（Waterfall Model）：特点：串行，每个阶段独立。优点：适用于需求变更小的项目。缺点：发现缺陷时间比较晚

2.螺旋模型（Spiral Model）：特点：渐进式，适用于庞大，复杂，风险大的项目。优点：强调风险。缺点：风险评估需要人力，资源，时间。资金等投入

3.增量：逐块建造，模块（相互独立） --- >拼接。优点：显著降低项目风险

4.迭代：反复求精，轮廓（功能之间相互影响） ----> 细化。优点：显著降低项目风险

5.敏捷：

（1）四个宣言：（共 12 个）

• 个体与交互重于过程和工具 —— 沟通
• 可用的软件重于完备的文档 —— 轻文档（对文档依赖度降低）
• 客户协作重于合同谈判 —— 客户参与
• 响应变化重于遵循计划 —— 拥抱客户

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

（2）特点：

1. 周期短，1-4周。
2. 团队人数少 5-9 人。
3. 每天开晨例会（站立会，不超过15分钟）

（3）po（product owner）产品负责人 ，sm（scrum master）敏捷教练，team 团队，user story 产品故事。

敏捷开发模型流程：

1. po 整理 user story。
2. 开会议，确定第一次迭代内容。
3. 发布迭代计划会议，确定人员分配。
4. 开发——测试——上线

软件测试模型：V M X H

V 模型

串行，缺点，bug 发现时间比较晚

W（双Vmox）

并行有利于尽早发现bug，不适合敏捷开发模型

软件测试的生命周期：

需求分析：确认需求范围

制定测试计划：时间表（什么人？什么时间？做什么事情？）软件类，工具类的资源，风险

测试计划，测试开发：测试用例编写

测试执行：执行测试用例，缺陷管理

测试评估：编写测试报告（测试结论，缺陷分析）

如何描述一个 bug

1.发现问题的版本

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

2、问题出现的环境

环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3、错误重现的步骤

描述问题重现的最短步骤。

4、预期行为的描述

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

5、错误行为的描述

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

6、其他

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

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

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

例如，描述邮箱注册失败的bug

编号：（唯一）regedit_001

标题：邮箱注册提交失败（报 500 错误）

环境：win10 + 谷歌

操作步骤：

1.进入163首页

2.点击注册免费邮箱

3.输入页面所有信息（罗列输入项，特殊数据要写）

4.点击“已发送信息，立即注册”

预期结果：页面提示“注册成功”

实际结果：页面报 500 错误

如何定义 bug 级别

A Blocker（崩溃）：系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

B Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试

C Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。

D Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等

E 建议性 bug，如页面颜色不好看建议换一个

Bug的生命周期

一个Bug的整个生命周期，是从Open到Closed的所有状态。缺陷一般分为 7 个状态。

1. New : 新发现的 Bug 默认为 new【测试人员操作】
2.  Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。状态由 new -> Open。【测试人员完成】
3.  Fixed: 开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。状态由 Open -> Fixed。【研发】
4.  Rejected：如果认为不是Bug，则拒绝修改。Open -> Rejected。【研发】
5. Delay: 如果认为暂时不需要修改或暂时不能修改，则延后修改 。Open -> Delay。
6. Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。fixed -> closed【测】
7. Reopen：如果经验证Bug仍然存在（不通过），则需要重新打开Bug，开发人员重新修改。fixed -> reopen【测】

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

状态转换图：

如何发现更多的bug？

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！

2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！

3、多进行逆向思维和发散性的思维

4、不要局限于用例和需求文档

5、尽早介入项目, 不要等到开发的差不多了再介入项目

产生争执怎么办

1、先检查自身，是否bug描述不清楚

2、站在用户角度考虑问题 

3、BUG定级要有理有据（需站在用户的角度定考虑定位级别。）

4、提高自身的技术和业务水平

5、开发人员不接受时，不要争吵

开发人员一直不接受，可以发起Bug评审。Bug评审要注意的问题：缺陷的评审应该包括以下两个层面 ● 决定如何处理Bug。 ● 分析缺陷产生的原因，找出预防的对策。