为什么会需要软件测试?
- 一款软件从无到有会经历很多的开发阶段由不同的人来参与开发，所以最终产出的软件功能可能会存在问题，因此为了保证软件的功能是可用且满足客户需求，我们必须要进行测试。
- 分工明确，测试更精准。
软件测试的基本介绍
软件测试的作用
- 通过测试可以发现并修复软件中存在的问题缺陷，从而提高用户对产品的使用信心
- 测试可以记录软件运行过程产生的数据，从而为决策提供数据支持
- 测试可以降低同类型产品开发遇到问题的风险
测试原则
- 测试证明软件存在缺陷:无论执行什么样的测试操作都能保证当前软件是有缺陷的
- 不能执行穷尽测试:有些功能是没有办法将所有的测试情况都罗列出来，所以任何的测试操作都有结束的时间。
- 缺陷存在群集现象：对于软件功能来说，核心功能占20%，非核心是80%。在实际工作中会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就会遇到缺陷都几种在20%功能模块里的现象
- 某些测试需要依赖特殊的环境
- 测试应尽早介入:为了更多的发现和更好的解决软件中的缺陷，追求测试工作尽早的开展
- 杀虫剂现象:同样的一个测试不能重的执行多次，因为软件会对它产生免疫
- 不存在缺陷谬论:任何软件不可能是完美的。
测试对象介绍
针对测试最经常测试的主体就是软件，但是一个软件不仅仅只有功能需要测试，我们可以将软件分为三个部分组成：功能集合+使用说明书+配置数据。对于一个软件来说从无到有需要不同的过程，我们可以将这个过程分为不同阶段，然后每个阶段都会相应有测试对象。
- 需求分析阶段:各种需求规格说明书
- 软件架构设计:API接口文档(接口测试)
- 编码实现阶段:源代码(白盒测试、单元测试)
- 系统功能使用:软件功能主题(当前行业做的最多的一种测试)
测试级别
软件的开发都会一句相应的开发模型，则测试级别指的就在这个模型当中我们人为定义的开发步骤。其中对于测试来说我们最常见的一种级别分类如下：
- 单元测试:在软件测试中单元指的就是组成软件最小的底层代码结构，一般就是类、函数、组件
- 集成测试:将多个单元模块组合在一起,然后验证它们之间沟通的桥梁是否能正常工作(接口测试)
- 系统测试:由测试充当用户然后对软件的功能主体进行测试。
- 验收测试:
系统测试分类
- 功能测试:验证当前的软件主体功能是否可用。
- 兼容性测试:验证当前软件在不同的环境下是否还可以使用。
- 安全测试:验证软件是否只是能授权用户提供功能使用。
- 性能测试:相对于软件小号的资源它的产出能力。
常见的系统测试方法
按测试对象进行分类
- 白盒测试:这种测试的主体就是软件的底层代码，不会在意外的界面是否OK，只要求底层功能实现，同时逻辑正确
- 黑盒测试:这种测试就是指测试软件外在主体功能是否可用。
- 灰盒测试:介于二者之间(接口测试)
按测试对象是否执行分类
- 静态测试:指的就是测试不执行
- 动态测试:将软件运行在着呢是的使用环境中进行测试。
按测试手段进行分类
- 手工测试:由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境。
- 自动化测试:所谓自动化主要有两种形，一种是自己写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。优点就是可以高效率的去执行一些人工无法实现的操作。
软件质量
描述当前软件是否好用，在当前的软件行业里我们采用的一套标准是基于ISO组织制定的，需要我们记忆的就是软件质量的六大特性。
- 功能性:软件需要满足用户显式或者隐式的功能
- 易用性:软件易于学习和上手使用
- 可靠性:指的就是软件必须实现需求当中指明的具体功能
- 效率性:类似于软件的性能
- 可维护性:要求软件具有将某个功能修复之后继续使用的能力
- 可移植性:当前软件可以从一个平台移植到另一个平台上去使用的能力。
软件测试流程
- 需求分析
- 设计用例
- 评审用例:对当前的用例进行添加或者删除
- 配置环境
- 执行用例
- 回归测试及缺陷跟踪
- 输出测试报告:将当前的测试过程中产生的数据进行可视化的输出,方便其他人去查看。
- 测试结束:当将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。
软件C/S与B/S对比
- 标准:i相对于C/S架构来说，B/S架构的二端都是在使用现成的成熟产品。所以B/S会显示的标准一些。
- 效率:相对于B/S架构来说，C/S中的客户端可以分担一些数据的处理，因此执行效率会高一些
- 安全:B/S架构当中的数据传输都是以HTTP协议进行的输出,而HTTP协议又是明文输出，可以被抓包，所以相对于C/S架构来说B/S就显得不那么安全。
- 升级:B/S架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级，而C/S架构当中必须要将二端都进行更新
- 开发成本:相对于B/S架构来说C/S当中的客户端需要自己开发，所以相对于成本会高一些。
常见的图片类型
- JPG:这是一种可以高度保留图片色彩信息的格式
- PNG:该类型的图片可以实现透明
- GIF:图片所占体积小,可以实现动图
- PS:它是一种分层的图片
开发模型
瀑布模型
- 需求分析→设计→编码→实现→软件测试→完成→维护
- 测试阶段处于软件实现后,必须在代码完成后留出足够的时间给测试活动,否则将导致测试不充分,很多问题到项目后期才暴露。
- 优点:开发的各个阶段比较清晰,强调早期计划及需求调查,适合需求稳定的产品开发
- 缺点:依赖于早期的需求调查,不适应需求的变化,单一流程不可逆,风险往往延至后期才线路,失去及早纠正的机会.
快速原型模型
- 实现一个基本原型,让用户对原型进行评价,逐步吊证,使其满足用户最终需求
- 优点:适合不能确定需求的软件
- 不适合开发大型系统
测试模型
V模型
- 需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试
- 单元测试:针对单一的程序模块进行的测试
- 集成测试:又叫组装测试,在单元测试的基础上,对所有模块进行测试,多用于接口测试
- 系统测试:将整个软件看做一个整体来进行测试,包括功能、性能、兼容性
- 验收测试:
- 优点:包含了底层测试和高层测试(系统测试),清除的标识了开发和测试的各个阶段,自上而下逐步求精,每个阶段分工明确,便于整体项目的把控
- 缺点自上而下的顺序导致测试工作在编码之后,就导致错误不能及时的进行修改,实际工作中,需求经常变化,导致v模型步骤反复执行,返工量很大,灵活度较低
W模型
- 需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试 验收/系统测试设计→集成测试设计→单元测试设计→单元测试→集成测试→系统测试→验收测试
- 优点:更早介入测试,可以发现开发初期的缺陷
- 缺点:依赖开发与测试保持一前一后的线性关系,对于当前很多项目在执行过程中根本不产生文档,那么W模型无法适用。
测试种类
黑盒测试
完全不考虑内部结构和内部特性,只关心软件的输入输出数据
功能测试
是黑盒测试的一方面,检查实际软件的功能是否符合用户的需求。
- 逻辑功能测试
- 界面测试
- 易用性测试
- 安装测试
- 兼容性测试
- 随机测试(探索性测试) 对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分,尤其对以前测试发现的重大bug进行再次测试,可以结合回归测试一起进行。
性能测试
- 时间性能(事务响应时间等)
- 空间性能(系统资源消耗)
- 一般性能
- 稳定性测试
- 负载测试 通过加压，观察系统的响应时间、吞吐量等，知道系统的极限性能指标
- 压力测试 通过增加负载，查看系统在峰值使用情况下的操作行为，容错、可恢复能力，发现隐患
- 容量测试 系统承受大量数据，测试系统是否能够正常处理，通常和数据库有关
白盒测试
研究里面的源代码和程序结构
软件测试的相关方法
- 等价类划分法,思考步骤如下:
- 边界值法,思考步骤如下:
- 因果图法(适用于输入条件之间有相互制约、相互依赖的情况)
- 判定表法,根据因果图来制作判定表,具体思路如下:
- 场景法(模拟真实用户去操作所列出的正确流程以及错误流程)
- 流程分析法
- 正交表法
测试方法的选择
- 如果是测试功能和流程,要使用场景法
- 需要输入数据的地方,我们要使用等价类划分法,要注意配合边界值来做详细测试
- 如果有条件组合的情况,我们要使用因果图制作出判定表
- 配置类软件,组合比较多,我们要使用正交表来科学的选择测试用例
- 如果没有达到覆盖标准,就要增加一些测试用例
- 依靠经验追加一些测试用例(错误推断法)
缺陷的表现形式
- 功能、特性没有实现或者部分实现
- 设计不合理、功能不明确、逻辑不清楚或存在矛盾
- 实际结果和期望结果不同
- 没有达到规格说明书要求的性能指标
- 运行出错、崩溃、终端、界面混乱
- 数据不正确、精度不够、不完整或格式不同意
- 用户不能接受的其他问题,如存取时间过长、界面不美观
- 硬件或软件存在的其他问题
软件缺陷的状态
- 提交 已提交的缺陷
- 打开 确认提交的缺陷,等待处理
- 拒绝 不需要修复或不是缺陷
- 修复 缺陷被修复
- 关闭 确认修复的缺陷,将其关闭
- 推迟 可在以后解决,但要确定修复日期或版本
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
