软件测试概念篇

1. 软件测试常见问题

1) 什么是软件测试?

最常见的说法就是软件测试是找BUG发现软件缺陷，软件测试就是验证软件产品是否符合用户的需求

2) 调试和测试的区别?

• 目的不同
  • 调试：发现并解决软件中的缺陷
  • 测试：发现软件中的缺陷
• 参与角色不同
  • 调试：开发人员
  • 测试：测试人员，开发人员
  • 单元/集成测试主要由开发人员完成
  • 黑盒测试等主要是由测试来完成
• 执行阶段不同
  • 测试：测试贯穿软件的整个声明周期
  • 调试：一般在编码阶段

3) 测试人员需要具备哪些素质?

• 综合素质
  • 快速学习能力
  • 沟通能力
  • 文字能力
  • 开发能力
• 掌握自动化测试技术(项目测试+技术事务)
• 优秀的测试用例的编写能力
• 探索性思维
• 对测试的兴趣
• 必备的责任感和压力(居安思危)

2. 软件测试常见名词解释

1) 需求

需求：满足用户期望或正式规定文档(合同、标准、规范)所具备的条件和权能，包含用户需求和软件需求

IEEE 把软件需求定义为：
（1）用户为了解决某一问题或者达到某一目标而需要的功能和条件；
（2）这些条件和功能要求必须要被系统所满足，同时要满足相关的合同契约、标准、规范，或者其他一些正式强制性文件。需要指出的是，所需处理的软件需求是动态的，也就是系统的性能是不断发展的。

• 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户在使用产品时必须要完成的任务，比如说某某游戏就是没有甲方的，该游戏开发出来后直击推出让大众进行使用，该需求一般比较简略。甲方就是简单表达自己的需求而已。
• 软件需求：软件需求又叫做功能需求，该需求会详细描述开发人员必须实现的软件功能。

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

因为用户需求是五花八门的，公司需要对用户的需求进行分析，从市场可行性、技术可行性等方面进行分析，比如技术上是否能实现，技术上实现是否有难度？投入的人力和成本是否远远大于市场利润等，都是需要考虑的。

需求是测试人员开展软件测试工作的依据，从需求分析阶段测试人员就应该介入项目(测试应当贯穿于软件的整个生命周期)

以用户注册和登录为例子：

2) 软件错误(bug)

bug的由来(360百科)：

bug翻译成中文其实是虫子的意思。格蕾丝·赫柏(Grace Murray Hopper)，是一位为美国海军工作的电脑专家，也是最早将人类语言融入到电脑程序的人之一。1947年她对Harvard Mark 设置好后17000个继电器进行编程后，机器运行不久后突然停止了工作。于是他们爬上机器去找原因，在庞大的计算机内部继电器触点之间发现一只虫子，这显然是由于飞蛾受光和热的吸引，飞到了触点上，然后被高电压击死。所以在报告中，赫柏用胶条贴上飞蛾，并把"bug"来表示"一个在电脑程序里的错误"，"Bug"这个说法一直沿用到今天。

bug的概念：

1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间不匹配才是错误
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

3) 测试用例

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

假设要测试网易邮箱注册：

• 测试环境

  • win10
  • Google Chrome 版本 113.0.5672.93（正式版本）

• 测试数据：

  • 邮箱地址
  • 密码
  • 手机号
  • 验证码

• 测试步骤：

  • 打开谷歌浏览器，输入网易邮箱注册地址
  • 输入邮箱地址、密码、手机号、获取验证码、勾选用户协议

• 期望结果

  • 展示注册成功结果页，并且使用账号可以正常登录

为什么要设计测试用例？

围绕着软件需求来设计测试用例，解决了重复测试问题。设计测试用例的原则就是避免用后即弃。

3. 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事
物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

1. 需求分析
   • 分析用户是否合理(市场分析、技术上分析)
   • 指定出软件需求文档
2. 计划
   • 指定需求执行计划
   • 需要执行多久，什么时候开始，什么时候结束
3. 设计
   • 将需求细化成一个个任务，进行技术设计(设计哪些接口，采用哪些技术)
   • 产出设计文档
4. 编码
   • 开发人员按照需求文档以及设计文档来进行编码
5. 测试
   • 测试人员参考测试用例来进行测试
6. 运行维护
   • 项目上线后对产品进行线上维护
   • 修复性维护：对项目中为发现的问题进行修复
   • 完善性维护：对功能进行完善
   • 预防性维护(居安思危)：为了避免产品在线上出现一些其它的问题，进行一些预防的手段。

4. 开发模型

1) 瀑布模型

瀑布模型是其它模型的基础框架

• 特点：
  • 线性的开发流程，强调开发的阶段性，强调早期计划及需求调查
• 缺陷：
  • 测试被后置，只有当上一部做完之后才开始下一步
  • 风险往往到后期测试阶段才显露，因而失去及早纠正的机会
  • 没有有足够的时间预留给测试活动，否则导致测试不充分，从而把缺陷直接遗留给用户
  • 瀑布模型最大的缺陷是：可以运行的产品很晚才能被看到，假设软件需求文档的设计出现了问题，在测试阶段才被发现，测试把这个问题告诉开发，而开发说和我无关，开发就把这个问题告诉设计那边，就这样一直上上层传递，导致整个项目需要大面积的反工。这就会导致项目延迟上线，或者被同行抢占先机导致更大的损失。

所以瀑布模型的使用场景：需求固定的小项目，因为它不能应对需求的变化。

2) 螺旋模型

螺旋模型引入全流程的风险分析，每次分析完成后都会产生一个新的模型。

螺旋模型分为4个象限，每转一圈都会经过指定计划、风险分析、实施工程、客户评估这个步骤，且每转一圈都会形成一个新的版本，经过一轮又一轮的改进最后实现成品。也就是测试要跟着开发的迭代而迭代。

螺旋模型的优点：引入全流程的风险管理，强调了软件在开发阶段的质量，有着全过程的风险评估来确定下一步是否继续。

螺旋模型的缺陷就是，它引入非常严格的风险分析，拉长了项目的时间线，而风险分析又需要一些专业人士，也增加了人力和资金成本。

螺旋模型的使用场景：前期需求不确定，规模庞大、复杂度高、风险很大的项目。

3) 增量模型和迭代模型

增量模型

假设用户有三个功能能需求$A、B、C...$，如果使用螺旋模型或者是瀑模型就需要把这三个功能做完之后再进行上线，而增量模型就不一样，它把3个功能分开开发，完成一个就上线一个。开发完$A$直击让用户使用，三个功能的开发互不影响。

增量模型可以降低项目风险，但在此模型中每次迭代意味着都要更新软件的版本，测试就得频繁进行同时和开发还得紧密合作。

迭代模型

迭代模型比较简单，同样假设用户有$A、B、C$三个需求。如果使用迭代模型模型，就先把$A、B、C$三个需求的基本功能实现，也就是一个比较简陋的版本，还不能够满足用户的要求，接下来再对这些功能进行迭代优化。适用前期于不能完整确定需求的项目

4) 敏捷模型

敏捷软件开发的宣言：

1. 个体和互动高于流程和工具
2. 工作的软件高于详尽的文档
3. 客户合作高于合同谈判
4. 响应变化高于遵循计划

也就是说，尽管后者有其价值，当我们更重视前者的价值。

• 敏捷宣言第一点体现强调人与人之间面对面的高效沟通（轻流程）
• 第二点说明更看重产出（轻文档）
• 第四点体现出变化大于计划，因为用户的需求是会突然发生变化的。

通过敏捷宣言总结出敏捷模型的特点：

• 轻流程
• 轻文档
• 重目标
• 重产出(可交付的软件)

然而敏捷模型只是一个大的方向，有一个非常常见的敏捷开发模型scrum

scrum里有三个角色和五个会议

三个角色：

• 产品经理：手机用户的需求，编写需求文档，对产品负责的人
• 项目经理：负责召开各种会议，协调项目，为研发团队服务
• 研发团队：开发人员、测试人员、$ui$设计人员等

五个会议：

产品经理负责整理需求，并对其进行排序，形成需求列表，

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