【测开篇】测试基础

名词解释：

1. 什么是需求？

需求： 满足用户期望或者正式文档(正式文档包括：合同，标准，规范)所具有的条件和权能，这个需求包括用户需求和软件需求

用户需求： 可以简单的认为是甲方给乙方提供的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，这个需求一般比较简略。

举一个例子：

就好比是现在 甲方要求乙方设计一个声控灯。当时此时的甲方是面向群众的。

那么就会用五花八门的需求：灯亮的时长，灯何时亮，灯安装的位置，灯的颜色，灯的形状，灯的材质，灯的亮度，灯是要可以来联网的，灯要支持语音识别

软件需求： 也可以被称为功能需求，该需求会详细的描述开发人员必须要实现的软件功能。

在大多数公司在进行软件开发的时候会把用户需求转变成为软件需求。这其实也是产品经理的工作任务。

那么为什么用户需求不能够直接成为开发和测试人员的工作依据呢？

因为如果此时的用户需求就非常的离谱，就好比是让乙方设计一个纯金的声控灯，这就不能满足市场可行性。

还要就是如果让乙方设计一个永动机，我们知道这个问题如今物理领域还没有得到解决。我们的技术是实现不了的。还有就是我们的人力投入产出比，如果人力投入相对较大，但是产出却不高。那么此时的这个功能就没有必要实现。

用户需求：一个平台要支持邮箱注册

产品经理把用户需求细化成软件需求

需求是测试人员开展软件测试工作的依据，并且我们的这个需求是测试人员设计测试用例的依据。

2. 什么是Bug？

当且仅当软件规格说明是存在的并且正确，程序和规格说明之间的不匹配才是错误.

当需求规格说明书没有提到的功能，判断标准以最终用户为准，当程序没有实现其最终用户合理预期的功能要求时。就是软件错误。

3. 什么是测试用例？

测试用例是为了实施测试而向被测试系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等要素

那么为什么要设计测试用例？

我们是围绕这软件需求来设计测试用例的，设计测试用例的目的，一方面是为了测试人员方便测试，一方面就是解决重复测试问题。

设计测试用例的原则：测试用例避免用后即弃。

测试人员在向开发人员提交Bug---->开发人员对Bug修改完成之后—>对Bug进行回归验证

测试用例还用于 版本迭代 对新版本的历史功能也需要进行测试(自动化测试)

软件的生命周期

开发模型

1. 瀑布模型

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

缺陷：测试后置 风险往往迟至在后期测试阶段才显露，因而失去了及早纠正的机会。有足够的的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。这个模型的最大的缺陷就在于测试后置，因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工

尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。

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

2. 螺旋模型

一般在软件开发初期阶段需求不是很明确的，采用渐进式的开发模型。螺旋模型就是渐进式开发模型中的代表之一。

这个模型应用于规模庞大，复杂度高，风险大的项目尤其合适。这种迭代开发的模型给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代,那么此时回归测试就显得尤为重要

优点：强调严格的全过程的风险管理，强调各开发节点的质量，提供机会检讨项目是否有价值继续下去。

缺点：因为引入了非常严格的风险识别，风险分析和风险控制，这对于风险控制的技术水平提出了很高的要求。这样就需要人员，资金和时间上的投入。

3. 增量模型和迭代模型

增量模型：

==增量开发可以显著的降低项目的风险，结合软件持续结构机制，构成了当今流行的软件工程最佳实践之一。==增量模型鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的，可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改。构建出新的可执行软件版本，那么就意味着测试需要频繁的进行，测试人员需要与开发人员更加密切的合作

增量模型就相当于，我们平时画画，先画出人物的头，在画出躯干，然后再是四肢，就是相当于我这次把这个功能实现了之后推上线了。然后再实现了一个软件功能，然后再经过测试之后，推上线。

而我们的迭代模型是反复求精的概念，同样是画人物画，我们可以先画出人物的大致轮廓，再勾勒出基本雏形，再细化,着色。应用到我们的软件开发过程中，就好比我现在虽然把这个功能基本实现了，但是此时实现的代码比较简陋。然后再逐渐的迭代，一步一步的进益求精。

4. 敏捷模型

敏捷宣言：

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

可用的软件高于完备的文档；(轻文档，重产出)

客户协作重于合同谈判；

响应变化重于遵循计划；（相当于用户在某个时间段可能需要用到某个功能，但是过了几天之后，用户发现我此时不需要这个功能了，哈哈，唉，用户就是喜欢多变）

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

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

scrum

scrum是由product owner（产品经理）,scrum master（项目经理）和研发团队组成的。

三个角色：

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

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

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

Product BackLog: 表示的是需求代办列表(需求池)，这个池子专门放没有实现的用户需求。产品经理负责整理 user story 形成 product backlog

Sprint Planning Meeting:产品经理从需求池里选取几个需求，开展发布计划会议

发布计划会议: 产品经理负责讲解user story,对其进行估算和排序，发布计划会议的产出就是指定这一期迭代要完成的story列表即sprint backlog

Week Sprint: 每日例会，每天scrum master召集站立会议，团队成员回答昨天做了什么，今天计划做什么，遇到了什么问题(通常为站会快速过一下几个问题，每日站会的意义：及时了解项目进度，预知风险，规避风险)

演示会议： 迭代结束之后，召开演示会议，相关人员都要受邀参加，团队负责向大家展示本次迭代取得的成果，期待大家的反馈记录下来，有产品经理整理，形成新的story

回顾会议： 项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

测试模型

1. V模型

特点：每一个阶段的独立性强，左边每一个阶段是右边测试阶段的依据，和右边每一个测试阶段一一对应。

其实V模型是瀑布模型的一个变种

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

2. W模型

W模型又被称为双V模型

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

缺点：每一个阶段都是串行执行的，一个阶段完了之后就进行下一个阶段(不支持敏捷开发) 也就是不拥抱变化，就是用户在W模型后期如果有需求变化，这个W模型是不支持的。

软件测试的生命周期

Bug

如何描述一个Bug？

1. 测试版本号(代码版本信息）

   在我们的实际开发工作中，是要管理代码版本的，那么此时就不得不说一下我们的代码管理神器—Git 就好比说此时用户正在使用的一款软件产品出现了重大故障(服务器 出现故障)，那么此时最好的不就办法就是回退代码版本，即把以前的软件版本挪上来，继续让用户使用该软件，那么此时就减低的用户的流失，挽回了公司的效益。

   假设现在有一个外卖系统的代码。
   

   那么为什么要在master上拉取分支，在然后在分支上提交代码呢？为什么不直接提交到master分支上呢？

   首先是绝对不能在master上提交没有非测试的代码的

   因为这个master分支是主干，如果在主干上提交代码（没有经过测试），那么把该代码上线之后，就会产生一系列的bug，那么此时的公司就会损失大量的客户。

   假设此时测试人员AB在DevA分支上发现了一个Bug，不能实现拼音匹配，此时的修改Bug的人员是G

   那么此时如果不告诉G出现Bug的代码的版本号，那么此时的人员G就像是一个无头苍蝇一样，不知道修改那个版本的代码。

   其实这个版本号就是为了方便开发人员复现Bug用的。

   开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2. 测试环境

   • web系统：

     • 硬件设备信息，电脑品牌，型号

     • 软件设备，操作系统

     • 浏览器，那一个浏览器(浏览器的版本号) IEm火狐，Chrom ,dege等

     APP

     • 软件设备，安卓，IOS ，windows，鸿蒙，塞班等
     • 系统的版本号
     • 硬件设备：手机品牌 电脑品牌

     网络条件

     • 好
     • 弱网

3. 测试数据

   给开发人员提交测试数据也是为了更加快速的复现问题

4. 测试步骤

   即发现Bug的操作操作步骤

5. 测试实际结果更好的编码

   使用测试实际结果和测试预期结果作比较，让开发人员知道该怎样

6. 测试预期结果

   要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

7. 附件，错误日志，错误截图等

   更详细的描述Bug错误信息，让开发人员快速定位出现Bug的代码块

8. 其他

   某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高

9. 不要把多个Bug放到一起

   在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

如何更好的描述一个Bug举例：

标题：使用谷歌浏览器打开首页后，第一个banner页上面的二维码被注册登录空间遮盖，导致无法扫描二维码。

发现Bug的浏览器版本： 107.0.5304.107（正式版本） （64 位）

**发现Bug环境：**win11 Chrome

发现Bug的步骤： 打开Chrome浏览器，访问首页链接：https://101stu.101eduyun.com/subjects/2022/202206assembly/index.html

期望结果： 首页的第一个Banner上的二维码清晰可见，可以通过手机扫描

实际结果： 首页的第一个Banner上的二维码被登录注册页面遮盖，导致手机扫描二维码失败

其他： 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，测试人员创建Bug new

开发人员收到了Bug，查看是否是Bug，如果是Bug Open 如果开发人员不认为是一个Bug，开发人员就把状态改为Rejected

还有就是修复Bug，如果认为不重要就不着急修复 delay 着急的话那么就把这个Bug加以修复** Fixed** 然后在进行Bug回归验证 如果这个Bug确实修复了 那么就关闭这个Bug Closed 如果回归测试之后，这个Bug 依然没有修复，那么就ReOpen

如果我们发现一个Bug，但是开发人员认为不是一个Bug，测试人员和开发人员发生争执怎么办？

• 首先反思是不是自己创建Bug的时候，描述Bug不够清楚(具有批判性思维)

• Bug的定价要有理有据

• 站在用户的角度上跟开发人员耐心友好的交通 反问 如果不是用户这样的结果你能接收吗？

• 能够提出Bug的同时也能提出解决方案

• 如果这样开发人员还是不准备修改Bug，那么只能组织Bug评审 邀请相关代表参加 产品代表 开发代表 测试代表

  如何修复Bug,提出结果方案

  如果避免此类的Bug