软件测试学习之旅----概念篇

需求是什么？

需求简而言之就是想要干什么事。在互联网方面主要分为用户需求和软件需求

• 用户需求：用户想要软件实现的功能（相对来说比较简单，没有具体的实现细节，有时候可能就是用户的一句话，但我们需要将其具体化）
• 软件需求：用户需求的具体化，有用户需求转化而来（开发人员根据软件需求进行软件开发）
  举个例子吧
  

软件测试的生命周期

需求分析---->测试计划---->测试设计/开发---->执行测试---->测试报告—>运行维护

• 需求分析：分析需求，细化需求，验证需求的正确性和合理性
• 测试计划：规划测试人员数量，规划测试时间、范围和目的
• 测试设计/开发:分析需求，从细化的需求中提炼功能点，设计测试用例
• 测试执行：执行测试用例，记录bug
• 测试报告：测试的范围，有多少测试用例执行了，余留了多少测试用例，发现了多少bug，修改了多少bug（验证通过确定修改了），遗留的bug和解决方案
• 运行维护

开发模型和测试模型

开发模型有五种常用的，瀑布模型，螺旋模型，敏捷模型，迭代、增量模型

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是 线性顺序进行的软件开发模式。

• 优点：各个阶段比较独立，看重需求分析和软件测试
• 缺点：无法适应需求的变化，测试到编码后才介入，导致前期的缺陷无法及时发现和修正
• 应用场景：适用于需求稳定的项目

螺旋模型

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不 允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

• 优点：强调软件的质量，每一次迭代进行严格的风险分析，讨论项目是否有必要进行下去
• 缺点：引入风险管理，会投入大量的人力物力
• 应用场景：前期需求不是很明确，并且有风险，项目比较庞大的系统开发

迭代、增量模型

迭代和增量模型一般配合使用，例如，一个系统有四个功能，ABCD四个模块，要在两周之内完成

• 迭代模型：第一周开发人员完成ABCD四个模块的基础功能，第二周，在基础功能之上进行细化和完善（迭代模型的的抗风险能力更强）
• 增量模型：第一周完成AB模块，第二周完成CD模块

敏捷模型

敏捷模型是现在主流的模型，它轻文档，轻流程，看重目标和质量，可以适应需求的变化，目标是交付一个高质量可用的软件
scrum是现在主流的敏捷开发的一种形式，它主要包含三部分的成员，crum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

• PO：产品经理product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• SM：项目经理scrum master 负责召开各种会议，协调项目，为研发团队服务，负责保证整个敏捷流程的顺利实施
• ST：scrun Team研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付高质量的产品。

scrum的流程

1. 发布计划会议
2. 迭代计划会议
3. 开发过程中的每日站会
4. 产品演示评审会
5. 回顾会议

测试模型主要有两个，v模型和w模型

软件测试V模型

V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种

• 优点：左边开发的每一个阶段和右边测试的每一个阶段一一对应，同时也是有右边每一个测试的依据
• 缺点：测试介入晚，前期的错误和风险到后期才发现，会失去及时纠正的机会

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试 与开发过程，图中明确表示出了测试与开发的并行关系。

• 特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
• 优点：测试阶段和开发阶段在两个独立的V模型里面，测试介入得比较早，在项目初期就介入了，前期的风险可以及时被发现
• 缺点：W模型每一个阶段任然是一个串行的过程，不能适应需求变化的项目，所以无法应用到敏捷开发

BUG

什么是bug？

凡是实现效果和需求不相符的都可以认为是BUG.一般分为两种情况

• 当软件需求存在并且合理，如果软件功能和软件规格不想符合，就是一个bug
• 当软件需求不存在的时候，用户需求存在且合理，软件功能和用户需求不相符，就是一个bug

对bug我们要心存敬畏, 但是不要害怕. 程序猿身上背负的bug, 就是一个老兵身上的疤痕, 最值得骄傲的军功章（没有事不可能得啦，不是在写bug，就是在修改bug的路上（笑哭））

bug的等级

bug一般分为四个等级，崩溃、严重、一般、次要

• 崩溃：系统运行阻断，严重影响了开发人员和测试人员的工作，需要立马修复
• 严重：系统还可以运行，但是已经不稳定了，如果在运行下去，可能会产生严重的后果
• 一般：系统可以稳定的运行，但一些次要的功能还没有实现，可能会影响用户的体验
• 次要（建议性）：用户需求中没有严格要求的，但影响用户的视觉体验（界面的文字提示内容，图片的排版等）要不要改需要和产品经理商量

线上出现崩溃级别的bug怎么办？
回退到上一个版本

bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
BUG状态转换图

●New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
●Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
●Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
●Rejected：如果认为不是Bug，则拒绝修改。
●Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
●Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
●Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

如果测试人员提了一个bug，开发人员已经修改了，但是测试人员测试的时候，发现bug依旧存在，有哪些原因？

• 测试人员忘记拉取最新的代码到测试环境进行发布（先从自身找问题）
• 开发人员没有吧代码更新到测试环境
• 开发人员没有修改好

如何描述一个bug？

• 版本号（代码版本号）
• 测试环境（平台），不同的浏览器对同一个系统的同一个页面解析是不同的
• 测试步骤和测试数据
• 实际结果
• 预期结果
• 附件（错误截图，错误日志等）

举例：

如果碰到bug和开发人员产生冲突怎么办？

• 先检查自己的bug是否描述清楚
• 检查bug的定级是否按照公司的标准来的
• 站在用户的角度去说服开发人员
• 不断提高自己的业务水平和技术水平
• 和开发人员，产品经理商量bug的解决方案

但这些都是套话啦，现实中情商高一点，多和开发人员走动走动搞好关系，出了bug一起解决岂不美哉！