代码收藏家 软件测试- 基础篇 && 用例篇铺垫案例
文章目录
回顾上篇博客[软件测试 – 概念篇](https://blog.csdn.net/DarkAndGrey/article/details/125281778?spm=1001.2014.3001.5501)基础篇软件测试的生命周期如何描述一个BUGBUG的级别 – 仅了解BUG的生命周期如果因为 BUG 和 开发人员产生冲突，该如何处理？- 面试问题
为下一篇用例篇博文做铺垫
回顾上篇博客软件测试 – 概念篇
1、什么是需求
1、满足用户的期望【用户需求】 2、满足合同规定的文档（标准，规范，合同）所需要的条件和权限【软件需求】 软件需求，是用户需求的进一步细化，是具体的实现 和 规范。
2、什么是BUG？
1、只有但软件测试需求存在并且合理，如果软件功能和软件规格说明书（软件需求文档）不匹配，就是软件错误（BUG）。 2、如果软件需求规格说明书（软件需求文档）不存在，就以用户需求为基准，但同样是在 存在并合理的前提下，如果软件功能和用户需求不匹配，则视为软件错误（BUG）。
3、什么是测试用例
测试用例，就是向被测试的系统发起的一组集合。 这组集合包含了 测试环境，测试数据，测试步骤，预期结果。【主要记住这4个】 【其实这组集合，还有很多其他的东西，比如：测试的功能模块，优先级（先测试那个），是否手动测试（手动测试，还是自动化测试）】 这里我们再来复习一下：测试环境是什么？ 测试环境：被测系统所在主机上的操作系统，以及具体版本，而且 被测系统，还可能嵌套在某个系统执行，比如浏览器。此时浏览器的内核，以及版本号都需要提供。 测试用例 是 我们测试的依据
4、软件开发的五大模型
1、瀑布模型 2、螺旋模型 3、增量模型 && 4、迭代模型 这两个模型的抗风险能力也不错！ 简单来说： 假设我们要实现一个系统，该系统需要 4个模块 ABCD。 增量模型： 将4个模块分为两个部分【AB，CD】，先完成 AB 模块，然后再来完成 CD 模块。【使每部分的开发联系起来】 迭代模型：先将4个模块的基础 框架搞定，然后在这个基础上，继续完善4个部分的一些代码。【你可以理解为盖房子，先打好基础，然后再一层层完善。】 5、敏捷模型 核心思想：轻流程，轻文档，重目标，重产出，响应变化，
软件测试的两大模型
V模型 W模型
从这篇博文开始，我们将作为一名刚刚加入测试团队的菜鸟，开始一次测试之旅。 在这里我们将讨论以下问题：
软件测试的生命周期 如何描述一个bug 如何定义bug的级别 bug的生命周期 产生争执怎么办
先回顾一个点：软件开发的生命周期
1、需求分析 2、计划【时间，人员，功能的方向和范围】 3、设计【功能，框架，算法】 4、编码 5、测试 6、运行维护
那么，软件测试的生命周期包含哪几个部分？
1、需求分析 2、测试计划 下面只是列举了一部分 3、测试设计 / 测试开发 根据需求，写出测试用例 4、测试执行 此时开发已经完成，执行测试用例，验证功能， 在验证功能的过程中，可能会遇到 软件功能与需求不相符的七情，也就是出BUG了。 于是，测试人员就会把这个BUG 交给 开发人员。 等到开发人员处理好了之后，我们测试人员又要对其进行验证。 5、测试评估 1、写了多少测试用例，执行了多少测试用例。 2、剩余的测试用例，为什么不把它执行完。 3、BUG数量。 4、已解决的BUG数量 5、遗留的BUG，以及解决方案。 6、此次测试的范围和测试功能都要说清楚。
首先，我们要理解一件事：为什么要描述一个 BUG ??
为了给开发人员看。 文字 和 口头 描述，都是存在的。 除此之外，还有 禅道，jira，tapd。 但实际上，我们是有专门的 BUG管理工具。 这个工具里面，它会把 BUG需要描述的地方，讲得非常清楚。
下面我们来看一下具体如何描述一个 BUG
1、测试的版本号（代码的版本信息） 2、测试环境 比如：QQ音乐的播放界面，在360浏览器上支持，在IE浏览器上不支持。 连操作都不能，更别提放音乐了。 3、测试数据 4、测试步骤 就是怎么去操作，会出现BUG，帮助开发人员更快的复现问题。 5、测试的实际结果 不看到结果，我们怎么知道验证的软件功能是否正确？ 拿着预期结果 与 实际结果 进行比较，如果匹配，表示软件功能实现完成，反之，则软件功能实现失败。 这样开发人员就知道，他需要关注的地方在哪里 6、附件：错误日志，错误截图等等。。。 还是一样的，为了更好的辅助开发人员复现 BUG，早日解决bug。 7、其他 某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高 8、不要把多个bug放到一起 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
总之，我们对于BUG的描述越详细，越招同事待见。 开发人员都会抢着和你合作！
对于BUG的级别，每个公司都不一样，这里只是讲典型的，普遍的情况。
崩溃： 系统无法正常执行：出现崩溃，操作死锁，死循环，黑屏。。。 出现以上这些情况会严重阻碍测试人员的工作，应立即反馈给开发人员进行修改 严重 系统可以运行，但是不稳定，继续运行下去会造成严重的损失。 一般都是 重要的功能没有实现，或者功能和需求不匹配。 还有就是 用户数据存储错误 一般 次要的功能没有实现，或者有错误，但是不影响系统，系统可以稳定的运行 建议 这种类型的bug，可能需求上没有写。只是会影响到用户的体验。 比如： 1、界面排版很挫，不符合大众的审美、 2、显示的信息没有进行换行处理 。。。。
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，必须由测试组长评审后才决定是否Open并分派给开发人员。 测试人员Open的Bug可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则： 测试人员对每一个BUG的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。 对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。
如果因为 BUG 和 开发人员产生冲突，该如何处理？- 面试问题
1、检查，查看自己对BUG的描述是否清楚 2、从用户的角度去说服开发人员 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修改Bug。 因为有些时候，真的有些bug可改可不改。 但是改了的，用户的体验会非常好。 而且，有些bug产生的原因是因为 在需求文档中没有描述的很清楚！ 虽然 软件需求 是 用户需求 的进一步细化，但是有些时候，产品经理也考虑的不是很周全。 又或者说，没有产品经理该怎么办？ 下面我们来看一个例子 3、BUG定级要有理有据【根据公司的规范】 如果只是你自己觉得这个BUG很严重，人家开发人员肯定不干！ 人家是为公司打工，又不是为你。 4、要不断提升 自己的 业务水平，和 技术水平。 不但能够发现BUG，并且能够定位。 还能够提出解决方案 【这些能力，工作久了，自然也就具备了】 5、开发人员不接受时，不要争吵, 可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。 找产品经理讨论，后面就会开展一个三方会议、 测试人员，开发人员，产品经理会一起讨论这个bug的最终解决方案。
也就是说：遇到bug不要慌！有人比更着急！你只需要做好你本分的工作就OK了。 大家都是出来打工的，没必要计较！
其实就是一个实战案例：QQ登录测试用例 下面，我们来看一下，具体的测试点有哪些? 我只对难理解的部分，做出注释。来源：Dark And Grey
