测试概述&软件生命周期&质量模型&测试策略

今天又没有写博客

已于 2024-05-22 11:02:17 修改

阅读量1.1k

点赞数 12

文章标签：功能测试

于 2024-04-10 09:59:43 首次发布

本文链接：https://blog.csdn.net/qq_48571849/article/details/137557335

版权

测试概述

测试的定义、目的与对象

定义：使用人工或者自动的手段来运行或者是测量软件系统的过程
目标：系统是或否满足用户规定的要求：系统的实际结果与预期结果之间的差异
目的：
- 测试是完成程序的过程，目的在于使系统更加符合用户的使用习惯，让系统在上线后带给客户极高的用户体验
- 测试应致力于发现至今为止未发现的错误
- 从用户的角度出发，希望通过软件测试暴露软件中隐藏的错误和缺陷并减少软件上线后的问题，使得产品更容易被接受
- 从软件开发者出发，希望测试成为证明产品中不存在错误、已正确的实现用户需求的过程
对象：
- 程序：功能正确、性能良好
- 文档：包括用户手册和运维手册，内容完整正确
- 数据：系统配置文件，符合国家规范

测试的原则（理解）

测试证明软件存在缺陷-Testing shows presence of defects
穷尽测试是不可能的-Exhaustive testing is impossible
测试尽早介入-Testing early
- 最好在需求阶段就开始介入
开发应避免检查自己的程序，软件测试应由第三方测试人员来负责
设计测试用例时应考虑到合法和不合法的输入
在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事
应长期保留所有测试用例，有助于修改程序后的回归测试
缺陷集群性（2/8原则）-Defect clustering
杀虫剂悖论（杀虫剂效应）-Pesticide Paradox
测试活动依赖于测试内容-Testing is context dependent
不存在缺陷的谬论-Absence of error

软件质量模型

软件质量模型是衡量一个优秀软件的维度

如：开发一款软件，它的部分需求如下

有10个功能，每个功能是什么样的…
支持web和app上运行
预估上线后每天会有20w用户在线

功能性

功能性需求：
- 测试人员要考虑的是：
  - 功能数量为10个
  - 每个功能的正确实现
  - 错误处理情况（需具有引导性）

性能

性能需求：
- 验证服务器每秒处理请求数（验证之前先计算20w人在线每秒需要处理多少请求）
- 服务器现有的硬件配置能否满足

兼容性

兼容性：
- 浏览器：谷歌、IE、火狐、欧朋、苹果
- 操作系统：Win系统，7，8，9，10，11 ，其他（Linux系统、Mac系统）
- 手机：分辨率、品牌、系统、网络、其他（和手机硬件是否兼容、和手机现有app是否兼容）

易用性

易用性：
- 简洁，参考竞品
- 友好
- 流畅
- 美观

可靠性

可靠性：
- 无响应（出现无响应）
- 卡顿（响应时间慢）
- 死机（系统崩溃）

安全

安全：
- 信息的传输
- 信息的存储

可维护性

可移植性

可移植性：
- 网站数据迁移

软件生命周期

软件生命周期是指软件开始研制到最终被废弃不用这一整个过程：
包括问题定义及规划、需求分析、系统设计、软件编程、软件测试、软件维护等阶段

在这里插入图片描述

测试模型

瀑布模型

在这里插入图片描述

是最早出现的软件开发模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，称瀑布模型

优点：
- 为项目提供按阶段划分的检查点
- 当前一阶段完成后，只需要关注后一阶段
- 可在迭代模型中应用瀑布模型
- 提供一个模板，使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导
缺点
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大的增加了工作量
- 由于开发模型是线性的，用户只要等到整个过程的末期才能见到开发成果，从而增加了开发风险
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段
- 瀑布模型的突出缺点是不适应用户需求的变化

V模型

RAD（Rapid Application Development，快速应用开发）模型是软件开发过程中的一个重要模型

在这里插入图片描述

优点：
- V模型中的过程从左到右，描述了基本的开发过程和测试行为
- 它非常明确地表明了测试过程中存在不同的级别，大体划分为以下几个不同的阶段步骤：客户需求分析、软件需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试
- 能够清楚地描述这些测试阶段和开发过程期间各阶段的对应关系
缺点
- V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，需求的满足情况一直到后期的验收测试才被验证
- 需求变更较大，返工量大

W模型

由Evolutif公司提出，相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动

优点
- 测试的活动与软件开发同步进行
- 测试的对象不仅仅是程序，还包括需求和设计
- 尽早发现软件缺陷可降低软件开发的成本
缺点
- W模型存在局限性，在W模型中，需求、设计、编码等活动被视为串行的，并且测试和开发保持着一种线性的前后关系，上阶段完全结束，才能正式开始下阶段工作
- 无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑

敏捷开发模型

是一种以用户需求进化为核心（强调沟通、弱化文档）、迭代、循序渐进的开发方法。
强调以人为本，专注于交付对客户有价值的软件，是一个用于开发和维持复杂产品的框架。
就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态。

敏捷开发原则
- 快速迭代
- 让测试人员和开发者参与需求讨论
- 编写可测试的需求文档
- 多沟通、尽量减少文档
- 做好产品原型
- 及早考虑测试
优点
- 通过快速、持续的交付有用的软件来满足客户的需求
- 强调的是和人活动，而不是过程和工具、客户、开发人员和测试人员不断地相互作用
- 工作软件经常交付（周而不是月）
- 业务人员和开发人员之间的密切日常合作，面对面交谈是最好的交流方式
- 持续关注卓越的技术和良好的设计，定期适应变化的环境
缺点
- 快速敏捷软件开发和软件测试
- 不是特别大的团队开发，因为交流成本大，比较适合一个组的团队使用（20-30）

测试策略

选择测试方法：选择最合适当前项目的测试方法（如项目紧急、频繁发版的时候）
角色与职责：需要在测试策略里面明确定义各个角色，以及该角色的职责
环境需求：它将描述测试时需要的系统环境（软件、linux、windows、数据库），包括软硬件以及网络环境等，在澄清环境需求时，测试组织可以识别出资源方面的风险
风险分析：影响测试过程的风险都应该尽早被识别出来，必须要有相应的解决办法以便消除或减轻这些风险
测试进度评估：测试进度将会评估完成测试所需要的时间，在设定进度的时候，首先需要明确测试范围，然后根据测试资源的多少来制定能被各方面认可的测试进度计划
回归测试策略：回归测试用来保证之前fix bug（修复这个问题的）代码不会影响软件的其他部分，这样需要我们选择已执行过的测试用例重新运行，测试人员需要找到一个方法来确定那些测试用例应该在回归测试中运行，用例不能太多，不能太少
优先级：测试范围内的东西不一定都是同样重要，加上测试资源各种有限，需为测试的模块排定优先级