【测试开发】概念篇 · 测试相关基础概念 · 常见开发模型 · 常见测试模型

【测试开发】概念篇

【测试开发】概念篇

1. 什么是需求

“想睡觉”，“不想上课”，“想吃饭”，这就是需求

而在互联网行业，什么是需求呢？

1.1 需求的定义

1. 用户/甲方需求
   • 例如QQ截图，用户想要长截图
2. 软件/功能需求
   • 对于刚才的用户需求，则需要（产品经理）写成细致的功能描述文档，例如长截图如何触发，如何操作（滚动），限制（大小/长度）

再例如一个软件需要有注册功能，注册这个笼统的就是用户需求，而其具体功能（输入姓名，邮箱，密码，确认密码，邮箱验证码，点击注册，是否同意协议，不同意会怎么样，输入不规范会怎么样…）这个详细的就是软件需求

我们开发一个产品，或者测试一个产品，要拿着这个软件需求进行测试/开发！

1.2 为什么有需求

没有需求拿来目标，怎么实现目标？

1.3 测试人员眼里的需求

而测试人员要将软件需求书里的每一个点，转化为一个个的测试点：

小练习：qq登录

1. 账号
   1. 功能
      1. 账号密码正确，登录成功
      2. …
   2. 兼容
   3. 性能
   4. 安全
2. 密码
3. 登录按钮
4. …

对测试点分类是必须要的！

1.4 如何深入了解需求

在项目的需求评审会议上了解：

1. 有什么需求
2. 为什么做这样的一个需求
3. 收益达到什么标准
4. 软件要做成啥样
5. 测试要何时开始，期限为多少天
6. 开发要何时开始，期限为多少天
7. …

但在开始做项目时，我们可以查阅文档（会议记录/笔记、软件需求文档、技术文档）

沟通一下，找产品经理了解软件功能，找开发了解软件的实现

2. 什么是测试用例

测试用例是一组集合，包含测试环境，测试数据，预期结果，操作步骤…

1. 测试环境
   • 例如OJ刷题系统，提供给学生一个测试环境（浏览器的一个页面）
2. 测试数据
   • 例如OJ刷题系统，自己输入测试数据、这道题检验是否通过的一组测试数据
3. 预期结果
   • 例如OJ刷题系统，通过率为100%
4. 操作步骤
   • 例如OJ刷题系统，写代码，提交
5. 测试序号
   • 例如OJ刷题系统，第1,2,3…
6. 测试标题
   • 例如OJ刷题系统，达到预期后，展现一个动画效果
   • 也就是对这一组测试用例的简单描述

在工作中，常常将测试用例称为 CASE

2.1 为什么有测试用例

1. 测试用例可以提高的是人员的工作效率

2. 测试用例可以降低测试人员工作的重复性问题

   如果没有事先列举出测试用例，假设现在有两个人去测试一个功能：

   1. 大马自己去测试功能，质疑对方的能力，就把能测的都测了执行了，大概100条吧
   2. 小马也是，就把自己想到的都测了一遍，大概90条吧

   这样就会出现，花费时间过长，并且两人测试重复性高的问题

   所以，他们的领导要求他们写成测试用例，统计起来再去执行，大概一百条，一半给大马，一半给小马~

3. 测试用例是建立自动化的基础，甚至是开发测试工具的基础

   自动化就是把测试人员的双手解放，让代码代替人员执行测试，既然如此我们就要有测试用例的集合，让代码以这些测试用例进行测试

2.2 练习=>手机打电话

3. 什么是bug

不严谨的说法：程序和规格说明书之间不匹配

准确的来说：当且仅当规格说明书存在的并且正确，程序与规格说明书之间的不匹配才是bug

• 规格说明书 => 软件需求文档

当需求规格说明书没有提到的功能和没有考虑到的点，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是bug

4. 开发模型和测试模型

4.1 软件生命周期

人的生命周期是：呱呱坠地 到 死亡

而软件的生命周期是：

1. 需求分析（诞生）

   • 分析需求是否合理，遵纪守法…
   • 比如，有登录没注册就不合理

2. 计划

   • 谁开发，谁测试，开发多久，测试多久…
   • 就是那五个W…

3. 设计

4. 编码

   • coding

5. 测试

   • 测试报告

   

6. 运行维护

   • 如果有线上问题，此时测试人员需要协助开发定位问题 + 解决问题，之后重新上线

7. 停服（死亡）

4.2 开发模型

1. 瀑布模型

   无非就是把刚才的生命周期串在一起：

   

特定：线性的

优点：每个阶段做什么，产出什么非常清晰

缺点：风险往往迟至后期的测试阶段才显露，因此失去及时纠正的机会！

• 例如，需求分析出现问题，却在测试才被发现，一步步回溯到需求分析才发现问题，这样花费的时间、人力、精力也很大

适用的项目：

• 小型项目适用于此模型

2. 螺旋模型

   无非就是把刚才的生命周期反复几次：

   

特性：迭代的

优点：

• 每个阶段都会进行风险分析，避免一些线上问题发生

缺点：

• 可能迭代次数太多，项目迟迟无法上线
• 风险分析可能会分析错，请专家则人力和财力的投入

适用项目：

• 适用于比较大，风险比较多的项目

对于以下模块，略讲，以一个上课软件为例（登录，创建课程，上课）

• 主要是区分模型是“增量型”还是“迭代型”

3. 增量模型

   • 登录功能开发完毕 -> 创建课程功能开发完毕 -> 上课功能开发完毕

   

4. 迭代模型

   • 登录功能开发一部分 -> 创建课程功能开发一部分 -> 上课功能发一部分

   

5. 敏捷开发

   • 个体之间的高效交互

敏捷宣言：

个体与交互重于过程和工具

• 个体之间面对面沟通

可用的软件重于完备的文档

• 开发文档，需求文档，更 关注最终的软件符不符合用户需求

客户协作重于合同谈判

• 一份合同必然无法涵盖每个需求，所以要多与客户合作沟通，也就是客户协作

响应变化重于遵循计划

• 变化是特别常见的，而不是一昧追求计划，而是拥抱变化！

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

• 以上的对比，后者并不能摈弃，后者也很重要，而是更看重前者

6. 敏捷开发中的 scrum模型

三个角色：

• scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

其中：

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

流程：

4.3 测试模型

4.3.1 敏捷中的测试

挑战1：轻文档

挑战2：快速迭代

1. 测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主
2. 测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设 计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试
3. 敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一 起研究Bug出现的原因。

4.3.2 V模型

特点：左边是开发，右边是测试，类似于瀑布模型（折了一下）

优点：测试被划分为许多类型

缺点：测试人员介入太晚，发现问题的时机太晚，故不适用于敏捷

4.3.3 W模型（双V模型）

特点：开发一个V，测试一个V

优点：测试人员在较早地介入了需求

缺点：

1. 测试人员和开发人员一定长度上还是串行的（相关的准备都依赖于其左侧的开发模块，例如集成设计测试依赖概要设计、单元测试设计依赖详细设计）
2. 这个测试模型不能拥抱变化，在验收测试发现问题，依旧要在测试V上不断回溯找到问题，故也不适用于敏捷

4.3.4 H模型

优点：

• H模型中的测试活动是一个独立的流程，只要满足了测试就绪条件，就可以开始测试活动
• 这种灵活的组织方式，使得H模型完全具备了前两个模型的优点——测试既可以与所有的开发活动紧密结合，又足够灵活满足敏捷和迭代的开发模型

缺点：

• H模型的灵活也造就它难以驾驭的特点
• 如果管理者没有足够的经验就实施H模型，可能会事倍功半，测试活动的成本收益比会比较低

总之，测试模型有三种，优缺点各不相同==建议一般的软件开发过程采用W模型，实施敏捷和迭代开发的可以考虑采用H模型。==

---

文章到此结束！谢谢观看
可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭🦆！’

希望枯燥的概念没有让你丧失对测试的兴趣！

---