软件测试基础学习

2.1、软件测试概念

​ 从需求开始，贯穿整个研发过程，不只是找出软件错误，更是软件研发每一个环节一系列的总称，包含研发过程中的改进，软件质量的评定。软件测试人员是参与研发每个环节的关键角色。

软件测试目的：

1. 为了发现程序中的错误，以及按照产品需求执行软件的过程
2. 保障软件研发过程中文档的质量
3. 分析错误的产生原因、发展趋势，提出软件研发过程中改进意见
4. 未发现错误的软件测试也是有价值的，测试是评定软件质量的有效方法

软件测试对象：

​ 程序和文档

软件测试的价值：

1. 质量检测--尽可能的发现版本的缺陷
2. 质量改进--完善软件研发过程
3. 质量鉴定--证明软件版本是可以成功发布的
4. 质量督导--提升团队能力成熟度(默契)

软件测试七大原则：

• 软件测试应尽早执行，贯穿软件整个生命周期
• 穷举测试是不可能的，任何软件任何时间都有缺陷
• 充分注意测试中的集群现象，缺陷多的地方往往遗留的问题、缺陷也会更多
• 缺陷二八定律，80%的缺陷出现在20%的功能模块中
• 严格执行测试计划，排除测试的随意性
• 注意合法合理的输入，注意非法非预期的输入
• 杀虫剂悖论(抗药性)反复相同的测试用例，会使软件产生抗药性，此时可以换不同的测试方法或者换个软件测试人员，重新杀虫

2.2、软件测试类型和测试方法

2.2.1类型

​ web测试：网页测试

​ client测试：客户端测试

​ moble测试：客户端测试如webapp，app

​ Git/C2 集成测试：

​ E2E测试：在真实情况下把所有的真时情况全部模拟

​ alpha测试：在系统测试后，用户在开发环境下测试

​ beta测试：在alpha测试后，用户生产环境即线上环境进行测试

​ 兼容性测试：检查软件在不同硬件、软件平台上是否可以正常运行，即软件的可移植性

2.2.2测试方法

等价类：

等价类分有效和无效两类

有效是对程序的规范是有合理输入数据所构成的集合，无效是对程序的规范不合理或无意义的数据所构成的集合.

设计原则：

1. 每个等价类规定唯一的编号、
2. 设计一个新的测试用例尽可能的覆盖没有被覆盖的有效等价类，重这一步直到所有的等价类都被覆盖
3. 设计一个新的测试用例，使其覆盖一个尚未被覆盖的无效等价类，重复这一步骤直至无效等价类被覆盖

边界值：

• 内点：可以不测，区间内的点
• 上点：边界上的点
• 离点：离边界值最近的且与上点不在同一等价类的点(小数无离点)
• 【a,b】闭区间即和这个 (离点- ?) a<= age<= b (? -离点)，a、b为上点，a、b之间为内点
• (a,b)开区间即和这个 a< (离点-1 )(内点+2) age (内点-2) (离点-1)<= b ，a、b为上点

场景测试：

​ 运用场景对系统的功能点或业务流程的描述，从而提高测试效果的一种方法

​ 一般包括：从一个流程开始途中经过用例的每条路径，都可以用基本流和备选流表示。

错误推断法：

​ 基本思想-列举出所有可能出现的错误和发生错误的特殊情况，根据这些输入设计测试用例。

​ 常见依据

• 在单元测试中理出模块常见的错误
• 在之前产品发现的错误
• 客户使用中发生的错误
• 公共模块的功能
• 修复BUG的功能模块

正交法：

​ 是研究多因素、多水平的一种试验法，利用正交表对试验进行设计，通过少数试验替代全面的试验，根据正交表的正交性，从之前的试验中挑出适量有代表性的点进行试验，这些代表的点具备了均匀分散、整齐可比的特点。

​ 正交法主要用于时间紧，任务重的项目中。

2.2.3软件测试分类

软件测试

开发阶段分

​ 单元测试(Unit Testing):对于软件最小可测单元进行测试
​ 集成测试(Integration Testing)：单元测试基础上，对两个已测单元或者多个单元进行组装测试，测试单元之间的接口：单元测试的扩展
​ 系统测试(System Testing)：集成测试，对于软件所有功能、安全性、性能、兼容性进行测试
​ UTA验收测试.(Acceptance Testing)：系统测试之后，由用户或者第三方验收公司，对软件进行测试，已查看是否符合用户需求(α、β)

是否运行分

​ 静态测试(Static Testing)
​ 动态测试(Dynamic Testing)

是否查看代码分

​ 白盒测试(White-box Testing)
​ 黑盒测试(Black-box Testing)
​ 功能测试(Functional Testing)
​ 界面测试(GUI Testing)
​ 冒烟测试(Smoke Testing)
​ 回归测试(Regression Testing)
​ 业务逻辑测试
​ 兼容性测试
​ 易用性测试
​ 性能测试(Performance Testing)
​ 负载测试：对系统指标不断施压，达到饱和
​ 压力测试：对系统不断施压直至系统崩溃
​ 并发测试：某个业务、相同业务同时访问用户的支持数量；最大并发=总用户/10
​ 稳定性测试
​ 灰盒测试(Gray-box Testing)

是否手工分

​ 手工测试(Manual Testing)
​ 自动化测试(Automation Testing)

其他

​ 用户验收测试
​ α测试(Alpha Testing)
​ β测试(Beta Testing)
​ 回归测试
​ 随机测试等等

2.3、软件测试的流程

流程：

​ 需求分析(需求串讲、反串讲)-

​ 测试计划(背景、时间节点、人员安排、风险、退出机制(测试结束的标志))-

​ 测试分析(思维导图)-

​ 测试设计(测试功能节点)-

​ 用例编写(规范，提高测试用例的覆盖度，用力的评审)-

​ 环境搭建

​ 用例执行

​ 缺陷提交

​ 回归测试(对缺陷修复后重新测试)-

​ 测试报告(测试环境、测试方法、测试用例、执行情况、缺陷分布情况、处理情况、测试结论(是否可以发布))

退出机制：

1. 测试用例覆盖度100%
2. 用例执行率100%
3. 缺陷2%~5%
4. 遗留的缺陷都要用合理的解决方案

2.4、测试用例的标准(规范)

• 测试用例标题必须验证二字开头
• 测试用力字数不可超过30个
• 测试标题不可出现二义性(如可不可以)
• 测试用例必须给出明确的结果
• 测试用例步骤必须给出实际数据
• 测试用例标题不能重复

2.5、测试用例要素和缺陷生命周期和要素

测试要素：

1. 用例编号(模块、子模块、测试场景)
2. 用例标题
3. 优先级
4. 前提条件
5. 执行步骤
6. 期望结果

缺陷要素：

1. 缺陷编号(模块、子模块、测试场景)
2. 缺陷标题
3. 缺陷优先级
4. 缺陷等级
5. 重现步骤
6. 期望结果
7. 实际结果
8. 附件(截图、日志)

缺陷生命周期：

提交(测试、开发)-确认(测试经理)-分配(测试组长)-修复(开发)-验证(测试人员)-关闭(测试人员)

什么是缺陷？

1. 不符合客户要求
2. 超过客户要求
3. 不符合客户习惯
4. 缺少对异常处理的反馈即页面提示

严重性分级：

• 致命：功能直接没有实现
• 严重：重要模块功能没有
• 一般：部分功能不直接影响整体软件运行
• 轻微：例如页面字体、颜色不对

软件测试误区：

1. 软件测试对程序的的测试
2. 软件测试在软件开发后进行
3. 软件质量只是测试的问题和责任
4. 软件发布后的缺陷都是测试人员的问题错误
5. 软件测试对软件人员的要求不高
6. 软件测试是测试的事情和开发无关

2.6、真实软件项目情况

1. 一般来说一个项目有十多个模块，每个模块大概有十五个接口
2. 开发测试的比例1:2~1:5之间
3. 实际一千行代码缺陷大概有10~20个
4. 每个开发平均每天写100行代码
5. 测试每天编写或执行的用例数量大概80~100，逻辑复杂的大概30多个
6. 测试人员每天发现缺陷3~5个左右
7. 一个迭代一般情况下1到2个月左右