初识软件测试

目录

软件测试的概念

调试与测试的区别

测试人员需要具备的素质

需求的概念

bug的概念

测试用例

软件的生命周期

开发模型

软件测试的生命周期

如何处理与开发发生争执的问题

---

软件测试的概念

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

软件测试岗位

测试人员包括软件测试工程师和软件测试开发工程师

上面的"开发"：指开发效能工具，比如：自动化测试工具、代码覆盖率工具、数据构造工具

软件开发工程师与软件测试开发工程师的区别

前者：开发为主；后者：测试为主，开发为辅

调试和测试的区别

调试与测试，主要有三个方面的不同，分别是目的，参与角色，执行阶段

目的

调试：发现并解决软件中的缺陷

测试：发现软件中的缺陷

参与角色

调试：开发人员

测试：测试人员，开发人员，比如单元测试，就主要由开发人员来测试

执行阶段

调试：编码阶段

测试：贯穿于软件的整个生命周期

测试人员需要具备的素质

综合能力：快速学习的能力，沟通能力，文字能力，开发能力

掌握自动化测试技术

优秀的测试用例设计能力

探索性思维，可从工作中积累经验

有责任感和一定的压力承受能力

需求的概念

需求包含用户需求与软件需求

用户需求：指甲方提出的需求，没有甲方，则就是终端用户使用产品时必须要完成的任务

软件需求：也叫功能需求，该需求会详细描述开发人员必须实现的软件功能

为什么用户需求不能作为开发和测试人员工作的依据？

因为要考虑市场可行性和技术可行性，所以需要对用户的需求进行需求分析

需求是测试人员开展软件测试的工作的依据！如果想要测试人员更好的了解需求，那么从需求分析

阶段就应该让测试人员介入

bug的概念

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

当需求规格说明书没有提到的功能，判断标准以最终用户为准。当程序没有实现其最终用户合理预

期的功能要求时，就是软件错误

描述一个bug

发现bug的版本，发现bug的环境、发现bug的步骤、期望的结果、实际的结果、其它：bug类

型：前端问题，bug等级：次要...

bug的级别

常见的有：崩溃、严重、一般、次要

崩溃：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据

库连接错误，主要功能丧失、基本模块缺失等问题

严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用，但

是不影响其它功能的测试

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

次要：主要就是一些优化建议类的问题

注意：实际bug的级别，还是要看具体的公司！！！

bug的生命周期

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

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

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

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

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

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

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

bug的终态就是closed，rejected--->closed   fixed ---> closed，如下图

测试用例

概念：为了实施测试而向被测试的系统提供的一组集合，包含测试环境、操作步骤、测试数据、预

期结果等要素

在工作中通常使用脑图来编写测试用例！！！

为什么要设计测试用例

围绕着软件需求来设计测试用例

解决了重复测试问题

原则：测试用例避免用后即弃！！！

步骤：提bug -> 开发人员对bug修复完成之后 -> 对bug进行回归验证

版本迭代：对新版本的历史功能也需要进行测试，用自动化测试来完成

软件的生命周期

需求分析：分析用户需求是否合理(市场分析、技术分析...)，产物：软件需求文档

计划：指定需求执行计划

设计：将需求细化成一个个任务，进行技术设计(设计哪些接口，采用哪些技术)，产物：设计文档

编码：开发人员按照需求文档以及设计文档来进行编码

测试：测试人员参考测试用例来执行测试

运行维护：项目上线之后对产品进行线上的维护，包括修复性维护，完善性维护，预防性维护

修复性维护：对项目中未发现的问题进行修复

完善性维护：对功能进行完善

预防性维护：为了避免产品在线上出现一些其它的问题，进行一些预防的手段

开发模型

瀑布模型

如下图，瀑布模型的软件开发流程。下图中的框架也是所有其它模型的基础框架

特点：线性的开发流程，不能够应对需求的变化

缺陷：测试被后置，就带来了两个问题

1、风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会

2、需要有足够的时间预留给测试过程，否则将导致测试不充分，从而将缺陷直接遗留给用户

瀑布模型最大的缺陷在于，可以运行的产品很迟才能被看到（上线）

使用场景：需求固定的小项目 

螺旋模型

如下图，螺旋模型引入了全流程的风险分析，每次分析完成之后都会生成一个新的原型

缺陷：软件开发时间变长，增加了人力、资金成本

适用场景：规模庞大、复杂度高、风险大的项目

增量模型

假如用户需求有A、B、C功能，开发完A我就直接上线供给用户使用，再慢慢完成其它功能，以人

物画为例，先画头、再画身体...

迭代模型

先开发一个基础版本(包含功能A、B、C)，但是A、B、C比较简陋，然后再在继续基础版本上对

A、B、C功能进行迭代优化，比如人物画，先画一个轮廓，再细化、补色

敏捷模型

敏捷宣言

个体与交互重于过程和工具。轻流程，强调人与人之间面对面的高效沟通

可用的软件重于完备的文档。轻文档，重产出

客户协作重于合同谈判。

响应变化重于遵循计划。比如用户功能需求变更，那么就需要完成用户新的功能需求

特点：轻流程，轻文档，重目标，重产出

scrum

三个角色

产品经理：收集用户的需求，编写需求文档，对产品负责的人

项目经理：负责召开各种会议，协调项目，为研发团队服务

研发团队：开发人员、测试人员、UI设计人员等待

五个会议

发布会议：产品经理拿出一些需求，介绍需求内容是什么，有哪些具体的功能需要实现

迭代计划会议：划分负责人，初步工时

每日例会：团队成员汇报各自完成了什么任务，以及遇到的一些可能无法解决的问题

演示会议：负责人来进行软件功能的演示以及介绍如何使用

回顾会议：总结本次迭代出现的一些问题，下一次迭代继续改进

软件测试的生命周期

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

需求分析：站在用户的角度：查看需求逻辑是否正确，是否符合用户的需求和行为习惯；站在开发

人员的角度：思考需求是否可以实现，或者实现起来难度大小

测试计划：指定测试计划，如测试的工时，人力的安排等等

测试设计、测试开发：设计测试用例，经验丰富的白盒测试人员可以开始单元测试

测试执行：参考测试用例来执行测试

测试评估：测试人员需要记录测试、做好缺陷管理，然后进行测试的评估

测试模型

V模型

特点：明确标注了测试的类型

           明确标注了测试阶段和开发阶段之间的对应的关系

缺点：测试后置

W模型

测试从需求阶段就开始介入了

缺点：上一个阶段完成下一个阶段才能开始

           开发模型和测试模型也保持着一种前后的线性关系

重文档、重过程 -------->  不支持敏捷模型

如何处理与开发发生争执的问题

具备批判性思维，多反思自己是不是bug描述的清不清楚

bug等级一定要有理有据

合理友好的进行沟通，站在用户的角度反问：如果你是用户，你能接受这样吗？

不仅能够提出问题，最好也能够给出解决方案

组织bug评审，邀请代表参加bug评审：产品代表、开发代表、测试代表，如何解决bug，如何预

防类似的bug