软件测试概念基础——小记

1. 什么是软件测试

软件测试就是软件测试人员验证软件是否满足用户的需求。

2. 软件测试和软件开发的区别

本身：
开发：广度小，专业度高
测试：所需技能较为广泛，但专业度低
软件测试 VS 软件调试
目的：
软件开发人员要确保程序做了他想让程序实现的功能
软件测试是测试人员确保程序实现了它应该实现的功能
角色：
测试是开发人员和测试人员共同完成
开发是开发人员
阶段：
软件测试贯穿整个软件开发的生命周期
软件开发是在开发阶段

3. 什么是需求

用户的期望和满足合同（文档、规则、标准）的规定所需要的条件和权限。
软件需求是用户需求转换来的。它是用户需求的细化，是用户需求的具体实现细节和规范。
用户需求比较粗略，直接实现会有困难，因为没有细节，所以需要软件需求把用户需求细节实现和规范，把用户需求变成一个具体可实现的过程文档。

4. 需求是软件测试的依据

验证需求，保证需求正确性、可操作性。细化需求，从需求提炼出一个一个测试项。
以用户登录为例子：

软件测试人员从需求测试阶段就开始介入

5. 什么是BUG

当且仅当，程序规格说明书（软件需求)存在并且合理，如果软件功能和软件规格说明书不相符合，我们就说是软件错误;
当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不相符合，就说明是软件错误;

6. 什么是测试用例

测试用例就是向被测系统发起的一组集合，包含测试环境、测试数据、测试步骤、预期结果。

7. 开发模型

软件开发的生命周期
需求分析——计划——设计——开发——测试——运行维护

瀑布模型

特点：
阶段性强，每一个阶段比较独立；看重前期的需求分析和后期的测试。

缺点：测试在编码后期才开始介入，导致前期存在的问题后期才会发现，失去补救的机会。

螺旋模型

适合于项目庞大、风险大、需求不是很明确的项目。

特点:
强调每一个迭代的测试质量和风险分析

缺点：
风险管控人力物力投入很多，成本比较大

增量模型 迭代模型

同一个系统的四个模块A B C D 两周完成得话

增量模型:
第一周开发A B功能模块
第二周开发C D功能模块

迭代模型：
第一周先开发ABCD的基础功能
第二周再在第一周的基础之上完全其它的功能

特点：
抗击风险能力强

敏捷模型

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

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

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

scrum

scrum里面的角色
scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队) 组成。

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

scrum的基本流程

• 产品负责人收集需求，负责整理user story，形成左侧的product backlog。
• 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
• 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
• 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

8. 测试模型

V模型

特点:
每一个阶段独立性强
左边每一个阶段是右边测试阶段的依据和右边每一个测试阶段一一对应
瀑布模型变种

缺点：
编码后才进行测试
前期的错误后期才会发现，会失去错误及时纠正的机会

W模型

特点：
每个阶段独立性强
测试一开始就介入，可保证前期的问题及时发现和纠正。

缺点：
每一个阶段都是串行的过程，一个阶段完成后进行下一阶段
不支持敏捷开发

9. 软件测试的生命周期（软件测试的流程）

需求分析——测试计划——测试设计/开发——测试执行——测试报告

需求分析：分析需求；验证需求的正确性、合理性；细化需求、根据需求去提炼测试点。
测试计划：确定测试范围、目的、目标、测试人员、测试工具、时间、测试环境。
测试设计/开发：开发测试用例
测试执行：开发人员已经提交代码，执行测试、提交代码
测试报告：本次迭代的测试情况进行分析和总结；写了多少测试用例执行了多少；发现了多少bug，修改了多少bug; 剩余bug 的解决方案；测试的覆盖率

10.如何描述一个bug

1.测试版本（代码提交版本号）
2.测试环境
不同测试环境问题出现的情况不一样

web系统
（Mac、Windows操作系统）
不同浏览器（谷歌、IE、火狐、edge、Safari、360、搜狗）及不同版本

APP
软件环境：ios 安卓 鸿蒙 塞班 windows 安装系统的版本
硬件环境：不同的设备，手机的品牌、不同的系列

3.测试步骤
测试数据和执行测试的详细步骤

4.实际结果
5.预期结果
6.BUG产生的log日志、错误截图等附件

11. BUG的级别

1. 崩溃
阻碍开发或测试工作的问题。
系统崩溃，不能运行，死循环，数据库死锁，资源分配不均，黑屏，闪退，阻塞
线上（用户使用的环境） 出现崩溃级别的Bug:回一个上一个可用的稳定的历史版本
2. 严重
服务器可以用，但是不稳定，继续使用会产生严重错误；一级菜单错误，数据库插入红黑数据错误，威胁到用户安全等。
3. 一般
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
4. 建议（次要）
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等;如：界面排版不符合用户的使用习惯

12. BUG的生命周期

BUG状态转换图

问题：发现一个BUG，开发人员修改了，但测试人员测试后又复现了这个BUG，是哪些可能原因？
1.测试环境不一样
2.开发人员理解不到位
3.代码，开发人员修改后，没有提交代码到远程，测试人员用的旧的（有问题的代码）进行测试。

13.产品上线了，用户反馈了你未测试出的bug，你会怎么做

作为测试人员，当用户反馈了未测试出的bug时，你需要立即采取以下措施：

1.确认问题：先仔细阅读用户反馈的问题，确认问题的具体表现和影响范围。
2.复现问题：在现有版本环境上尝试复现问题，记录下复现的步骤和结果。
3.反馈问题：将复现的情况向开发团队反馈，提供详细的复现步骤和结果，以便开发团队能够快速定位和解决问题。
4.跟进问题：跟进开发团队的处理进度，确保问题得到及时解决，并及时向用户反馈处理结果。