测试学习打卡第一天——测试与开发模型基本介绍

一、测试与开发模型

1. 测试的工作流程
2. 开发模型
3. 测试模型
4. 开发和测试的关系

测试的工作流程：

1. 需求分析 阅读需求文档（产品文档 产品详细设计说明书 分析需求的点 参与需求评审 快速熟悉项目）
2. 制定测试计划和测试方案 （测试计划：测试整个项目的整体规划{测试范围 进度安排 人力物力安排 整体测试测略 风险的评估 风险的规避 【4w 1h why when who what where how】}测试方案 how 被测试的目标 选取什么样的测试工具 测试方法 测试的重点）
3. 测试用例设计 边界值 等价类......
4. 执行测试用例
5. 评估阶段 测试报告

• 开发模式

1. 瀑布模型

按照总体计划一步一步制定计划 一步一步执行 像瀑布一样 执行完一个才算下一个 最古老的模型

特点：按阶段生成检查点

1. 阶段间有顺序性和依赖性
2. 推迟实现
3. 质量保证的观点

瀑布模型是文档驱动的原型（每一个阶段完成都会有文档）

优点：1、每一个阶段都设置了检查点

1. 一个阶段完成后只关注下一个阶段
2. 可在迭代模型中应用瀑布模型

缺点：1、不适合需求模糊或者需求经常变动的系统（不确定不能用）

1. 用户等待时间长 完成较慢
2. 系统灵活性差
3. 一开始就是设计好的产品没办法存在早期阶段的反馈

1. 增量模型

把瀑布模型的顺序特征与快速原型法的迭代特征相结合 将软件看作一系列相互联系的增量，在开发过程中的各次迭代中，每次完成其中的一个量。

 

一个模块或者小的功能依次向下迭代。

最后项目呢越做越大 完成一个大项目 避免了瀑布模型的缺点

• 快速原型

 

快速建立起来可以在计算机上运行的程序。

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险 适合预先不能确切定义需求的软件系统的开发

      快速出产品

缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加工连续修改可能会导致产品质量低下 使用前提是要有一个展示性的产品原型，一定称得上可能会限制开发人员的创新。

• 螺旋开发模型

 

• 迭代开发模型

跟增量模型差不多  但是整个软件生命周期不能并行 必须开发完一个小模型之后在基础上迭代

• 敏捷开发模型

最主要的是现在在过程中概念比较火 简单设计 快速实现 （快速模型的一种） 上线的话先在小范围内上线 测试没问题慢慢扩大范围。

除了瀑布模型 其他都是为了避免瀑布模型开发的缺点 建议使用瀑布模型

• 测试模型

• V模型

 

V模型和瀑布模型有一些共同的特征，V模型中的过程从左到右，描述了基本的开发过程和测试行为。

优点：包含单元测试和系统测试 阶段清晰明了

缺点：测试介入较晚，对于前期缺陷无法修改，用时较长

• W模型（双V模型）

 

解决了V模型缺点

测试人员伴随项目始终

优点：测试伴随整个生命周期，测试和开发并行独立运行。

缺点：对需求测试技术要求太高 适用于中大型企业

测试和开发人员关系：

 

四、软件测试的分类

1. 测试阶段分
2. 是否自动化
3. 是否运行
4. 是否覆盖源码
5. 其他

五、测试用例

（1）、

概念：测试准备的小例子（一组数据与前提条件） 弄清楚预期结果

特征：1、有效性

1. 可复用性
2. 易组织性
3. 可评估性
4. 可管理性

（2）、测试用例的要素

 

1、测试用例8大要素：

【1】测试用例编号

【2】测试项目/模块

【3】预置条件

【4】测试输入

【5】预期结果

【6】操作步骤：明确给出数据描述

【7】测试用例标题：不能重复

【8】级别：测试用例重要程度   高、中、低级别

建议添加：

用例设计者 用例设计日期 对应的开发人员 测试结果 测试类型

1. 、测试用例设计原则

1. 明确性
2. 代表性
3. 简洁性

1. 、等价类划分法

 

测试中最完美的测试是穷举测试（把所有的数据都列出来）

类型划分：有效等价类   无效等价类（检测程序健壮性和容错能力）

设计测试用例步骤

1. 确定需求
2. 确定有效等价类和无效等价类
3. 对每条等价类设计测试用例

例：QQ登录

 

根据测试用例要素8必须编写

 

1. 、边界值法

 

大量错误发生在输入输出范围上

 

此图没有什么意义

1. 、因果图法

 

 

 

 

1. 、判定表法

是因果图最终产物

 

 

条件是输入

动作是输出

1. 、正交表法

选项和结果过多时，排列组合比较麻烦，用最小的过程获得最大的覆盖率。

便捷方式：利用allpairs.exe完成

首先，在EXCLE中敲击所有相应可能

 

然后，新建txt文件，复制到txt中

 

打开CMD，进入路径

 

最后结果如图：

 

1. 场景法

多数用于冒烟测试

时间触发控制数据流，随后形成场景。

 

人话释义：打电话整个过程 打通过程就是基本流

图像有点糊，可以看链接 

链接：(65条消息) 常用测试用例设计方法4-场景法_小宝的宝呢的博客-CSDN博客_场景法设计测试用例

（如有侵权联系我随时删除）

1. 流程分析法（流程法、功能图法）

把要做的黑盒测试把所有可能的路径所有可能到的路径以及模块都要覆盖到。

分为  广度  深度

用广度优先方式列取 用深度优先方式列取

1. 错误推断法

凭借经验和直觉直接推算哪里出错。从而有针对性的设计测试用例的方法。

 

1. 测试用例力度评审和总结

1、力度

简单 复杂 中庸

1. 测试用例设计方法总结

需求会变化 测试用例也会变化

及时响应变更比遵循计划更有价值

 

 

1. 测试用例的评审

 

• 缺陷 BUG 错误

什么属于缺陷?

缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户需求。

 

测试阶段发现缺陷怎么办？

 

不同公司缺陷报告是不一样的

 

 

• 自动化测试

 

自动化：脱离人力 自己自动实现

自动化用的频率较高

自动化测试：代码代替思维 脚本代替人工

            包括接口测试 性能测试 和自己写的程序

好处：节省人力 时间 物力 降低成本 有准确性 模拟人工难以实现的手段 衡量产品的质量 快速持续迭代发布产品的能力

执行对象是脚本 用例之间关联性强

手工测试和自动化测试是互补的

 

自动化测试核心 质量和效率

自动化测试需要掌握开发技巧

自动化测试分层：UI测试——集成接口测试——单元测试

什么适合做自动化测试？

项目变动少 项目周期足 项目资源足够 产品型项目

不适合自动化测试：定制性 一次性 项目周期很短 物理交互 测试很少运行 美观声音易用性测试

计算机组成：硬件系统 软件系统

听的是哔哩哔哩上胖达老师的课 个人觉得讲解比较详细 过程就是根据听课记下的（直接搜软件测试课程就行，没有报班）