软测必知理论知识(一)

文件索引地址：https://files.cnblogs.com/files/crstyl/%E8%BD%AF%E6%B5%8B%E5%BF%85%E5%8F%AA%E7%90%86%E8%AE%BA%E7%9F%A5%E8%AF%86%28%E4%B8%80%29.zip

 

软件测试必备理论知识总结

1 常见笔试题类型

1.1 测试用例设计

1.2 数据库

1.3 Liunx命令

1.4 测试理论知识

1.5 程序设计

1.6 逻辑题

2 必须掌握内容

2.1 快速熟悉公司的测试流程，能够快速开展测试工作

2.2 掌握常用的测试方法，理解测试方法与测试阶段的关系

2.3 熟悉缺陷管理跟踪，掌握常见的跟踪流程图

2.4 如何开展对物品的测试

3 测试流程&测试方法

3.1 常用的测试流程

3.1.1 公司的内部测试流程

瀑布模型

流程

原始需求

项目计划

需求文档

SRS

Software Requirements Specification

概要设计

HLD

High Level Design

高层次的设计

概要设计说明书

划分系统的功能、模块

                    系统

子系统        子系统          子系统

模块              模块              模块

功能              功能               功能

详细设计

LLD

Low Level Design

针对每个功能设计

针对功能画流程图

详细设计说明书

编码

CODE

测试

TEST

运营维护

SUPPORT

优点

简单方便

缺点

1、测试在后期才介入，发现BUG晚，风险高

开发修复缺陷的风险和成本高

2、上游工作未完成时，下游人员处于闲置等待，资源浪费

3、应对需求变更能力差

适用范围

小项目、小规模的公司

双V模型

三大测试阶段

系统测试

System Testing

系统测试是为验证和确认系统是否达到其原始目标， 而对集成的硬件和软件系统进行的测试

系统测试是在真实的或模拟系统运行的环境下， 检查完整的程序系统和系统的正确配置、连接、并能满足用户的需求

集成测试

Intergration Testing

集成测试也叫组装测试，是检验程序单元与部件的接口关系

逐步集成概要设计要求的程序部件或整个系统

单元测试

Unit Testing

单元测试又称为模块测试，是针对软件设计的最小单位---程序模块进行正确性检验的测试工作

其目的在于检查每个程序单元能否正确实现详细设计说明中的 模块功能、性能、接口和设计约束等要求， 发现各模块内部可能存在的问题

每个大的测试阶段都会有测试计划、测试设计、测试实现、测试执行

不同的阶段有不同的成果物

ST计划

《测试范围列表》

测试标准

人员/资源分配

风险防范

ST设计

测试策略

测试环境

测试工具的选择

测试数据/代码

ST实现

编写测试用例

《ST测试用例》

ST执行

执行测试用例

编写缺陷报告

回归测试

编写测试报告

优点

1、测试介入早，从需求阶段进行系统测试准备

2、测试全面

ST

IT

UT

缺点

1、测试成本高

2、对开发的成熟度要求高

3、开发和测试的进度及质量会相互影响

适用范围

大公司、成熟团队、质量要求较高的项目

敏捷测试模型

特点

1、迭代速度快，可以快速提交可用的版本

提早占领市场

2、文档少，在文档中投入的资源最少

缺点

1、开发和测试人员的技术及业务理解能力要求较高

2、对团队的配合协作程度要求高

3、要求软件架构设计要有很强的延展性和稳定性

否则，新增的或修改的功能 会大面积的影响成熟的老功能

适用范围

小项目、小企业，功能复杂度较低的项目

3.1.2 公司的外部测试流程

项目

验收测试

什么验收测试

对于项目类软件，由客户参与的测试流程

验收测试是项目回款的重要标志

流程

1、软件通过公司内部测试完成后，提交给用户进行试用

2、试用过程中，进行软件的调整或维护

3、试用期结束后，询问用户是否同意验收测试

4、若用户不同意，转向2

5、若用户同意，开始进行验收的准备工作

6、验收准备工作内容

1、确认验收的参与人

开发人

客户方

第三方（第三方）

2、确认验收测试的地点和环境设备的提供

3、验收现场的工作流程

7、验收测试具体实施

由主持人宣读验收测试的相关事宜，介绍来宾

由演示人进行项目使用的演示

开发方的测试工程师来做

演示结束后或过程中，回答专家或客户的提问

最终签署验收测试报告

产品

α测试

流程

1、公司内部测试结束后

2、邀请相关的潜在用户或行业专家代表进行软件试用

3、发放一定的劳务费，让用户或专家试用软件后提出问题或建议

4、收集问题或建议，反馈给测试或开发

5、问题确认后，进行讨论确定是否需要修改以及修改的方案

6、对问题或建议修改后，重新提交新的试用版本，让用户或专家再次试用

7、测试时间到达或无相关问题后，α测试结束

β测试

流程

1、公司内部测试或α测试结束后

2、公司对外发布β测试版本给所有的潜在用户

3、所有潜在用户都可以下载或免费使用β测试版程序

4、对于用户反馈的问题，提交给客服人员

5、客服人员对问题进行收集整理和反馈

6、相关负责人对问题进行分类汇总

7、决定哪些问题修改，哪些被废弃

8、软件免费给用户使用，用户提问题一般不会支付费用

9、若吸引到足够的用户试用，或试用结束，β测试结束

三种测试的区别

验收测试是针对项目类的软件，α、β测试是针对产品类的软件

验收测试是目的是回款的标志， α测试的目的是获取用户体验，修改完善软件， β测试的目的是吸引的用户使用，提早占领市场

验收测试是具体的准确的用户参与， α测试是邀请潜在的用户或行业专家， β测试是所有可能的潜在用户

验收测试相关费用可能由开发方支付也可能由客户方支付， α测试需要支付费用给参与的用户，β测试无需支付费用给参与的用户

3.1.3 快速熟悉测试流程，开展测试工作

询问测试主管，明确工作职责

角色

获取工作资料

SRS

《测试用例》模板

《缺陷报告》模板

《测试计划》

《测试方案》

何时正式的工作

入口准则

工作的过程

活动

工作的成果物

输出

检验成果物是否符合标准

出口准则

3.1.4 回归测试

回归测试隶属于测试执行阶段，测试流程的一部分

回归策略

完全重复回归

选择性重复回归

覆盖修改法

周边影响法

指标达成法

优缺点及适用范围

完全重复回归

优点

回归测试充分

缺点

消耗资源多

适用

资源充分

第一个版本和最后一版本回归必用

覆盖修改法

优点

消耗资源少

缺点

回归不充分

适用

独立功能回归或早期版本测试

周边影响法

优点

即考虑了资源又考虑了回归的效果

缺点

周边不容易确定

适用范围

有关联关系的功能测试

业务流程测试

公共模块测试

指标达成法

优点

指标可量化

缺点

指标的定义很难

适用范围

成熟度高的团队

3.2 测试方法

3.2.1 按照测试对象不同

黑盒

依据

SRS

对象

整个软件产品

理论目的

检查软件的功能实现与需求是否一致

实际目的

尽早达到验收或上市售卖的标准

评估标准

需求覆盖率（被测试的需求总数/全部的需求总数）

最低达到100%

介入时间

系统测试阶段

测试环境

接近或模拟用户使用环境

优点

简单高效

缺点

1、介入晚，发现问题晚

2、更多的是从用户的使用角度出发，进行功能相关的测试， 对后台数据库及代码逻辑没有进行检测

3、对于较复杂缺陷，很难准确定位

适用范围

所有项目上线或验收前都必须使用

灰盒

依据

概要设计说明书

对象

系统内部接口

子系统间的接口（接近黑盒）

模块间的接口

模块内的接口（接近白盒）

理论目的

检查系统内部接口实现与HLD是否一致

实际目的

准确定位缺陷

评估标准

接口覆盖率

被测试的接口总数/全部的接口总数

介入时间

集成测试阶段

测试环境

开发环境下测试

优点

1、能够快速定位系统内部接口出现的问题

2、提早集成，尽早发现模块或功能调用之间的问题

缺点

1、当调用关系复杂时，集成测试复杂度非常高，很难抽离出测试模型

2、技术复杂度最高

输入

输出

调用关系

无界面测试

适用范围

内部接口复杂度高，且质量要求较高

白盒

依据

详细设计说明书

对象

一个函数或一段独立功能的代码

二八原则

20%左右代码可能包含约80%的缺陷

被测试代码

核心业务和算法

新研发的

使用频率高

公共模块

算法复杂

理论目的

检查单元代码逻辑与详细设计是否一致

实际目的

尽早发现严重的BUG，降低修复的成本和风险

评估标准

逻辑覆盖率

语句覆盖率

分支覆盖率

条件覆盖率

分支-条件覆盖率

路径覆盖率

介入时间

单元测试

测试环境

开发环境

优点

1、介入时间早，发现问题早

2、对代码的覆盖度较高

3、发现问题后准确定位

缺点

1、工作量大，不是所有的代码都可以进行白盒测试

测试资源少

2、对测试人员的代码理解和编码能力要求较高

3、只是从代码逻辑角度出发，检查逻辑的正确性， 但是无法评估用户使用过程的易用性和相关流程的问题

适用范围

代码复杂度高，或属于公共核心算法

开发人员对某些代码逻辑或业务不是十分了解时

新研发的算法和功能

3.2.2 是否运行程序

静态测试

测试文档是否存在缺陷（测试效果不明显）

优点

介入时间早于动态测试

修复缺陷的成本和风险低

价值最高

缺点

需要有很强的需求分析和设计分析的能力

1、正规检视

需求评审

2、技术评审

HLD

LLD

需要有很强的代码审查能力

3、同行评审

代码走查

适用范围

新/复杂业务、算法、设计方案

动态测试

通过运行程序，检查软件是否存在错误

界面功能

内部接口

独立函数代码

优点

简单，发现问题效率高

缺点

相对于静态测试较晚

修复成本高

适用范围

所有项目必须使用动态测试

3.2.3 按照测试手段不同

手工测试

优点

测试灵活性强，可以积极主动发现缺陷

缺点

执行效率低

重复执行的内容会产生厌倦和疲劳

发现一些无法重现的缺陷无法使用手工测试进行重现

适用范围

所有的项目必须使用

自动化测试

优点

执行效率高，可以选择大量数据，频繁测试

可以代替手工进行一些无法完成的测试

性能测试

并发测试

压力测试

缺点

编写测试脚本技术要求高，工作量较大

不能主动发现BUG，只能按照程序指令执行

分类

功能自动化

Selenium

JAVA

Python

QTP

VBS

Appium

JAVA

Python

性能自动化

LoadRunner

基于C语言

Jmeter

JAVA

适用范围

手工测试已通过

需求是稳定的

项目周期长

测试脚本的使用次数越高，自动化成本越低

一般在10次以上