【软件测试】软件测试概念 | 测试用例 | BUG | 开发模型 | 测试模型 | 生命周期

---

一、什么是软件测试

1.什么是软件测试

• 软件测试就是找BUG，发现缺陷
• 软件测试只是一个样本测试，具有不可穷尽性。

软件测试就是验证软件产品特性是否满足用户的需求。

在早期，更多的是将软件测试看做对软件产品的“检验” ，检查软件的每个功能是否正常运行正常

• 验证软件功能执行的正确性，可以是否能正常工作。
• 测试的活动是以测试人员“预期的结果（需求定义）”为依据，看是否符合需求

测试：就是保障软件的质量

2.软件测试和调试的区别

调试：开发自己调试，确保程序做了程序员想做的事，发现问题，解决问题。在开发阶段进行。

测试：测试和开发一起执行。确保程序解决了它要解决的问题，来发现问题。测试伴随软件的整个生命周期

测试人员需要的素养

技能：

1.测试用例设计的能力

2.编程能力（编写测试工具、自动化测试用例）

3.技术快速学习的能力、业务快速学习能力

非技能

1.沟通合作能力

2.文字表达能力（写测试用例、编写测试文档、BUG）

3.抗压能力

4.责任感

---

二、软件测试概念

1.需求

1.需求的定义

• 用户需求：甲方提出来的需求，或者用户要完成的任务

• 软件需求：功能需求，详细描述需要实现的软件功能

软件需求是产品经理写的

软件需求是测试人员进行测试的基本依据

用户需求就是一句话，软件需求是一个文档（详细描述用户需求应该如何实现）

2.测试人员眼中的需求

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

• 业务需求—>软件功能需求点—>测试需求点—>测试用例

• 从软件功能需求出发，无遗漏的识别出测试需求。直接关系到用例的测试覆盖率
• 对于每个测试需求点，需要具体设计测试用例
• 测试工程师在需求分析和设计阶段开始介入

2.测试用例

Test Case

1.测试用例概念

• 测试用例是一组集合，包含测试环境、测试数据、预期结果、操作步骤

例子：测试环境：windows+Chrome +本地

测试数据：用户名字符串、密码字符串

​ 操作步骤：输入用户名、输入密码、点击登录按钮

​ 测试预期：登录成功

• 测试用例可以提高测试人员的工作效率，降低工作的重复性
• 测试用例是建立自动化的基础

3.BUG 软件错误

• 当且仅当规格说明书（软件需求）是存在的并且正确。程序与规格说明之间的不匹配（预期结果!=执行结果）才是错误
• 当程序没有实现最终用户合理预期的功能要求时，就是软件错误。

4、开发模型和测试模型

1.软件的生命周期

• 需求分析：分析需求是否合理、需求是否完整
• 计划 ： 谁开发、谁测试、开发多久、测试多久…
• 设计 : 设计应该如何实现功能
• 编码 ：进行具体的代码编写
• 测试 ： 对代码功能进行测试，出具测试报告后才能上线
• 运营维护 ：如果线上有问题，测试人员需要协助开发定位、解决问题

2.开发模型

1.瀑布模型

• 需求分析产出：需求文档
• 设计环节产出：技术文档（涉及到哪些接口，库表，mq, 定时任务…）、UI视觉搞

特点：线性的

优点：强调开发的阶段性，每个阶段做什么，产出什么非常清晰

缺点：风险往往会推迟到后期测试阶段才会显露，失去及早纠正的机会

适应的项目：小型的项目

2.螺旋模型

优点：每个阶段都会进行风险分析，避免发生一些线上问题

缺点：风险分析可能会分析错，需要大量人力财力时间的投入

适应项目：比较大的项目、风险比较多的项目

3.增量、迭代

增量：逐块建造的概念，做完一个模块，再做下一个模块

迭代：反复求精，先整体，再细节 （就像素描，先画一个轮廓，再画手、画脸）

4.敏捷

敏捷宣言

• 拥抱变化、请流程、重交付、轻文档、重交互

​ 个体与交互重于过程和工具（个体之间面对面沟通）

​ 可用的软件重于完备的文档 （开发文档、需求文档）

​ 客户协作重于合同谈判

​ 响应变化重于遵循计划

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

scrume开发模式

三大角色

product owner(产品经理)

scrum master(项目经理)

team(研发团队)：后端开发、前端开发、UI设计师、测试

流程

1.产品经理收集用户需求

2.项目经理将需求进行优先级的划分、计划项目什么时候开始和结束、由谁来做

3.每日站会，汇报昨天的工作。如果没有完成，遇到了什么问题、今天计划要做什么。

4.演示。

3.测试模型

1.V模型

特点：左边是开发、右边是测试、类似于瀑布模型

优点：测试被划分成很多类型

缺点：测试介入太晚，问题发现的时间太晚

2.W模型（双V模型）

特点：开发一个V 、测试一个V

优点：测试人员尽早的介入

缺点：测试人员和开发人员在一定程度上仍是串行的。并且不能拥抱变化、不能适应于敏捷

三、软件测试基础

1.软件测试的生周期

• 需求分析->测试计划->测试设计、测试开发->测试执行->测试评估

需求分析：需求是否完整、需求是否正确

测试计划：确定由谁测试、什么时候开始测试、结束测试

测试设计：写测试用例（手工测试用例、自动化测试用例）、编写测试工具

测试执行：执行测试用例

测试评估：测试人员产生测试报告

2.描述一个BUG

1.发现问题的版本

2.出现问题的环境

3.错误重现的步骤

4.预期行为的描述

5.错误行为的描述

6.其他。比如BUG复现的前置条件、BUG给谁、BUG的优先级

1.BUG的优先级

• 根据bug的影响程度进行划分

1.Blocker(崩溃)：阻碍开发、测试工作的问题，系统崩溃、死机、数据库数据丢失、主要功能丧失…

2.Critical(严重):只要功能部分丧失、数据库保存调用错误、用户数据丢失

3.Major(一般)：功能没有完全实现，但是不影响使用、如操作时间长、数据库表中字段过多。

4.Minor(次要)：优化、建议类、不影响功能的使用。如错别字

强调：如果发现崩溃级别的bug，就需要停止测试，测试打回

2.BUG的生命周期

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

• Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。

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

• Rejected：如果认为不是Bug，则拒绝修改。

• Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。

• Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。

• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

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

3.如何发现bug

1.测试的二八定律：80%的故障集中于20%的模块

2.开发的二八定律:80%的故障集中于20%的开发人员

3.进行逆向思维和发散性思维

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

5.尽早介入项目

4.如何进行测试

1.充分理解需求

​ 文档（产品文档+技术文档）

​ 项目功能问题问产品。模块底层如何实现问开发

​ 参加会议

2.确定测试计划

3.执行测试

​ bug在开发修复之后，一定要进行验收

4.项目上线 +维护

点击移步博客主页，欢迎光临~