软件测试

软件测试

为什么会需要软件测试?

1. 一款软件从无到有会经历很多的开发阶段由不同的人来参与开发，所以最终产出的软件功能可能会存在问题，因此为了保证软件的功能是可用且满足客户需求，我们必须要进行测试。
2. 分工明确，测试更精准。

软件测试的基本介绍

软件测试的作用

1. 通过测试可以发现并修复软件中存在的问题缺陷，从而提高用户对产品的使用信心
2. 测试可以记录软件运行过程产生的数据，从而为决策提供数据支持
3. 测试可以降低同类型产品开发遇到问题的风险

测试原则

1. 测试证明软件存在缺陷:无论执行什么样的测试操作都能保证当前软件是有缺陷的
2. 不能执行穷尽测试:有些功能是没有办法将所有的测试情况都罗列出来，所以任何的测试操作都有结束的时间。
3. 缺陷存在群集现象：对于软件功能来说，核心功能占20%，非核心是80%。在实际工作中会集中测试20%的核心功能，所以这个部分发现缺陷的几率就会高于80%。因此我们就会遇到缺陷都几种在20%功能模块里的现象
4. 某些测试需要依赖特殊的环境
5. 测试应尽早介入:为了更多的发现和更好的解决软件中的缺陷，追求测试工作尽早的开展
6. 杀虫剂现象:同样的一个测试不能重的执行多次，因为软件会对它产生免疫
7. 不存在缺陷谬论:任何软件不可能是完美的。

测试对象介绍

针对测试最经常测试的主体就是软件，但是一个软件不仅仅只有功能需要测试，我们可以将软件分为三个部分组成：功能集合+使用说明书+配置数据。对于一个软件来说从无到有需要不同的过程，我们可以将这个过程分为不同阶段，然后每个阶段都会相应有测试对象。

1. 需求分析阶段:各种需求规格说明书
2. 软件架构设计:API接口文档(接口测试)
3. 编码实现阶段:源代码(白盒测试、单元测试)
4. 系统功能使用:软件功能主题(当前行业做的最多的一种测试)

测试级别

软件的开发都会一句相应的开发模型，则测试级别指的就在这个模型当中我们人为定义的开发步骤。其中对于测试来说我们最常见的一种级别分类如下：

1. 单元测试:在软件测试中单元指的就是组成软件最小的底层代码结构，一般就是类、函数、组件
2. 集成测试:将多个单元模块组合在一起,然后验证它们之间沟通的桥梁是否能正常工作(接口测试)
3. 系统测试:由测试充当用户然后对软件的功能主体进行测试。
4. 验收测试:
   1. 内测
   2. 公测
   3. UAT测试 由客户派出对于业务非常精通的人员来使用该软件,从而对功能进行测试。
   4. 验收测试的核心就是让用户为当前软件买单

系统测试分类

1. 功能测试:验证当前的软件主体功能是否可用。
2. 兼容性测试:验证当前软件在不同的环境下是否还可以使用。
3. 安全测试:验证软件是否只是能授权用户提供功能使用。
4. 性能测试:相对于软件小号的资源它的产出能力。

常见的系统测试方法

按测试对象进行分类

1. 白盒测试:这种测试的主体就是软件的底层代码，不会在意外的界面是否OK，只要求底层功能实现，同时逻辑正确
2. 黑盒测试:这种测试就是指测试软件外在主体功能是否可用。
3. 灰盒测试:介于二者之间(接口测试)

按测试对象是否执行分类

1. 静态测试:指的就是测试不执行
2. 动态测试:将软件运行在着呢是的使用环境中进行测试。

按测试手段进行分类

1. 手工测试:由测试人员手动的对被测对象进行验证，优点就是可以灵活的改变测试操作及环境。
2. 自动化测试:所谓自动化主要有两种形，一种是自己写测试脚本，另外一种就是通过第三方的工具对被测对象进行测试。优点就是可以高效率的去执行一些人工无法实现的操作。

软件质量

描述当前软件是否好用，在当前的软件行业里我们采用的一套标准是基于ISO组织制定的，需要我们记忆的就是软件质量的六大特性。

1. 功能性:软件需要满足用户显式或者隐式的功能
2. 易用性:软件易于学习和上手使用
3. 可靠性:指的就是软件必须实现需求当中指明的具体功能
4. 效率性:类似于软件的性能
5. 可维护性:要求软件具有将某个功能修复之后继续使用的能力
6. 可移植性:当前软件可以从一个平台移植到另一个平台上去使用的能力。

软件测试流程

1. 需求分析
   1. 当前阶段的核心目的就是梳理清楚我们需要设计的点是什么
   2. 需求的来源:需求规格说明书、API文档、竞品分析、个人经验
2. 设计用例
   1. 用例就是用户为了测试软件的某个功能而执行的操作过程
   2. 设计用例是有方法的(等价类、边界值、判定表)
3. 评审用例:对当前的用例进行添加或者删除
4. 配置环境
   1. 环境:指的就是当前被测对象运行所需要的执行环境，作为测试人员需要具备配环境的能力。(一般情况下都会使用一键安装的集成环境)
   2. 环境分类:操作系统+服务器软件+数据库+软件底层代码的执行环境
5. 执行用例
   1. 一般在执行用例之前我们会做一个冒烟测试，这种测试的核心就是快速的对当前软件的核心功能或者主题执行流程进行验证。如果冒烟测试阶段有问题，则可以将此版本退回。
   2. 如果冒烟测试通过那么才会开展全面的测试
6. 回归测试及缺陷跟踪
   1. 回归测试指的就是当我们将某个缺陷提交给开发之后，由他们进行修复，修复完成之后需要测试人员再次对其进行测试(回归测试)
   2. 缺陷跟踪:指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。
7. 输出测试报告:将当前的测试过程中产生的数据进行可视化的输出,方便其他人去查看。
8. 测试结束:当将整个测试过程中产生的一些文档进行整理归档，方便后续版本使用。

软件C/S与B/S对比

1. 标准:i相对于C/S架构来说，B/S架构的二端都是在使用现成的成熟产品。所以B/S会显示的标准一些。
2. 效率:相对于B/S架构来说，C/S中的客户端可以分担一些数据的处理，因此执行效率会高一些
3. 安全:B/S架构当中的数据传输都是以HTTP协议进行的输出,而HTTP协议又是明文输出，可以被抓包，所以相对于C/S架构来说B/S就显得不那么安全。
4. 升级:B/S架构只需要在服务器端将数据进行更新，前台只需要刷新页面就可以完成升级，而C/S架构当中必须要将二端都进行更新
5. 开发成本:相对于B/S架构来说C/S当中的客户端需要自己开发，所以相对于成本会高一些。

常见的图片类型

1. JPG:这是一种可以高度保留图片色彩信息的格式
2. PNG:该类型的图片可以实现透明
3. GIF:图片所占体积小,可以实现动图
4. PS:它是一种分层的图片

开发模型

瀑布模型

1. 需求分析→设计→编码→实现→软件测试→完成→维护
2. 测试阶段处于软件实现后,必须在代码完成后留出足够的时间给测试活动,否则将导致测试不充分,很多问题到项目后期才暴露。
3. 优点:开发的各个阶段比较清晰,强调早期计划及需求调查,适合需求稳定的产品开发
4. 缺点:依赖于早期的需求调查,不适应需求的变化,单一流程不可逆,风险往往延至后期才线路,失去及早纠正的机会.

快速原型模型

1. 实现一个基本原型,让用户对原型进行评价,逐步吊证,使其满足用户最终需求
2. 优点:适合不能确定需求的软件
3. 不适合开发大型系统

测试模型

V模型

1. 需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试
2. 单元测试:针对单一的程序模块进行的测试
3. 集成测试:又叫组装测试,在单元测试的基础上,对所有模块进行测试,多用于接口测试
4. 系统测试:将整个软件看做一个整体来进行测试,包括功能、性能、兼容性
5. 验收测试:
   1. 内测版
   2. 公测版
   3. 候选版
6. 优点:包含了底层测试和高层测试(系统测试),清除的标识了开发和测试的各个阶段,自上而下逐步求精,每个阶段分工明确,便于整体项目的把控
7. 缺点自上而下的顺序导致测试工作在编码之后,就导致错误不能及时的进行修改,实际工作中,需求经常变化,导致v模型步骤反复执行,返工量很大,灵活度较低

W模型

1. 需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试 验收/系统测试设计→集成测试设计→单元测试设计→单元测试→集成测试→系统测试→验收测试
2. 优点:更早介入测试,可以发现开发初期的缺陷
3. 缺点:依赖开发与测试保持一前一后的线性关系,对于当前很多项目在执行过程中根本不产生文档,那么W模型无法适用。

测试种类

黑盒测试

完全不考虑内部结构和内部特性,只关心软件的输入输出数据

功能测试

是黑盒测试的一方面,检查实际软件的功能是否符合用户的需求。

1. 逻辑功能测试
2. 界面测试
3. 易用性测试
4. 安装测试
5. 兼容性测试
6. 随机测试(探索性测试) 对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分,尤其对以前测试发现的重大bug进行再次测试,可以结合回归测试一起进行。

性能测试

1. 时间性能(事务响应时间等)
2. 空间性能(系统资源消耗)
3. 一般性能
4. 稳定性测试
5. 负载测试
6. 压力测试　　

白盒测试

研究里面的源代码和程序结构

软件测试的相关方法

1. 等价类划分法,思考步骤如下:
   1. 确定有效等价类和无效等价类
   2. 有效等价类划分(题目条件,还要注意边界值(极值),中间在随意找个值)
   3. 无效等价类划分(跟有效等价类相反,其他特殊情况(中文、特殊字符等))
2. 边界值法,思考步骤如下:
   1. 确定边界情况
   2. 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据
   3. 边界值的取值一句输入范围区间不同而有所不同
   4. [1,10] 取值0,11,1,5,10
   5. (1,10) 取值1,10,2,5,9
   6. (1,10] 取值1,11,5,2,10
3. 因果图法(适用于输入条件之间有相互制约、相互依赖的情况)
4. 判定表法,根据因果图来制作判定表,具体思路如下:
   1. 条件桩 所有条件
   2. 动作桩 所有结果
   3. 条件项 针对条件桩的取值
   4. 动作项 针对动作桩的取值
5. 场景法(模拟真实用户去操作所列出的正确流程以及错误流程)
6. 流程分析法
7. 正交表法

测试方法的选择

1. 如果是测试功能和流程,要使用场景法
2. 需要输入数据的地方,我们要使用等价类划分法,要注意配合边界值来做详细测试
3. 如果有条件组合的情况,我们要使用因果图制作出判定表
4. 配置类软件,组合比较多,我们要使用正交表来科学的选择测试用例
5. 如果没有达到覆盖标准,就要增加一些测试用例
6. 依靠经验追加一些测试用例(错误推断法)

缺陷的表现形式

1. 功能、特性没有实现或者部分实现
2. 设计不合理、功能不明确、逻辑不清楚或存在矛盾
3. 实际结果和期望结果不同
4. 没有达到规格说明书要求的性能指标
5. 运行出错、崩溃、终端、界面混乱
6. 数据不正确、精度不够、不完整或格式不同意
7. 用户不能接受的其他问题,如存取时间过长、界面不美观
8. 硬件或软件存在的其他问题

软件缺陷的状态

1. 提交 已提交的缺陷
2. 打开 确认提交的缺陷,等待处理
3. 拒绝 不需要修复或不是缺陷
4. 修复 缺陷被修复
5. 关闭 确认修复的缺陷,将其关闭
6. 推迟 可在以后解决,但要确定修复日期或版本