软件测试基础_使用技术手段验证软件是否满足使用需求。 csdn

一、软件及测试

1.什么是软件

软件是控制计算机硬件的工具

2.什么是软件测试

使用技术手段验证软件是否满足使用需求

3.软件测试的目的

找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免潜在的软件错误和缺陷造成的隐患所带来的商业风险；提高软件测试的效率和软件产品的质量

4.主流技术

功能测试：主要验证程序的功能是否满足需求

自动化测试：使用代码或工具代替手工对项目进行测试

接口测试：使用代码或工具对服务端提供的接口进行测试

性能测试：模拟多人使用软件，查找服务器缺陷

二、软件测试分类

1.按测试阶段划分：

单元测试：针对程序源代码进行测试（单元：最小独立功能代码段）

集成测试：又称接口测试，针对模块之间的访问地址进行测试

系统测试：针对系统整体功能+兼容+文档（说明、安装文档）

验收测试：主要分为内测、公测，使用不同人群来发觉项目缺陷

2.按代码可见度划分：

黑盒测试：看不见源代码，主要对程序功能进行测试

灰盒测试：看见部分源代码，主要对程序接口进行测试

白盒测试：看见全部代码，主要对程序源代码进行测试

3.总结

系统测试和黑盒测试重点核心是功能测试

集成测试和灰盒测试又称接口测试

单元测试和白盒测试是对代码进行测试

自动化测试归属功能测试

性能测试、安全测试归属专项测试

三、测试流程

1.需求分析：

参与人员：前端、后端、测试、产品

目的：确保需求理解一致，了解被测试项目有哪些功能模块

2.测试计划：测什么（目标、范围）、谁来测（人员进度及安排）、怎么测（测试工具、测试策略）

3.用例设计：分析需求，提取测试点，设计用例覆盖测试点

4.用例执行：按照测试计划进行实施测试

5.缺陷管理：提交->验证->关闭

6.测试报告：bug分析及统计，测试中遇到的问题，测试总结（本次测试中的优点和不足）

四、测试用例

1.编写规范

用例编号：项目简称_模块简称_编号

用例标题：预期结果（测试点）

模块/项目：用例所属模块/项目

优先级：p0---p4（p0最高）

前置条件：操作步骤之前的操作

测试步骤：执行用例步骤

测试数据：执行步骤中的重点数据

预期结果：用例执行结果+不同用户隐性结果

五、用例设计方法

1.目标

能对穷举场景设计测试点

能对限定边界规则设计测试点

能对多条件依赖关系进行设计测试点

能对于项目业务进行设计测试点

2.解决穷举场景

等价类划分法：在所有测试数据中，具有某种共同特征的数据集合进行划分

分类：有效等价类：满足需求的数据集合

无效等价类：不满足需求的数据集合

步骤：明确需求，确定有效和无效等价类，提取数据编写测试用例

适用场景：需要有大量数据测试输入，但无法穷举测试的情况，例如输入框，下拉列表，单选复选框，典型代表：页面的输入框类测试

3.解决边界限制问题

使用边界值解决边界位数限制问题

上点：边界上的点（绿点）

离点：距离上点最近的点（黄点）

内点：范围内的点（蓝点）

步骤：明确需求，确定有效和无效等价，确定边界范围，提取数据编写用例

优化策略：上点必选（不考虑区间开闭），内点必选（一般选中间范围），离点开内闭外（开区间考虑内部离点，闭区间考虑外部离点）

适用场景：在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
典型代表:有边界范围的输入框类测试
单个输入框常用的方式：边界+等价类

4.解决多条件有依赖关系测试

判断表是一种以表格形式表达多条件逻辑判断的工具

组成：

条件桩：列出问题中的所有条件

动作桩：列出问题中可能采取的操作

条件项：列出条件对应的取值，所有可能情况下的真假值

动作项：列出条件项的各种取值情况下应该采取的动作结果

步骤：明确需求，列出条件桩和动作桩、填写条件项，对条件进行全组合、根据条件项的组合确定动作项、简化、合并相似规则(有相同的动作)，根据规则编写测试用例

适用场景：有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖关系。条件组合数量较少的情况。

5.业务测试覆盖

场景法也叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例

重点:

1、覆盖业务测试,需要使用流程图法

2、先测试业务，在测试单功能、单模块、单页面

6.错误推荐法

定义：通过经验推测系统可能出现的问题

思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

适用场景：当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。

六、缺陷介绍

1.定义

软件中存在的各种问题，所有不满足需求或超出需求的都是缺陷，简称bug；

没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷

2.标准

软件未实现产品说明书要求的功能

软件出现了产品说明书不应该出现的功能

软件实现了产品说明书未提到的功能

软件未实现产品说明书虽未明确提及但应该实现的目标

软件难以理解，不易使用，运行缓慢或者（从测试的角度看）最终用户会认为不好

3.产生的原因

需求阶段：需求描述不易理解，有歧义、错误等

设计阶段：设计文档存在错误或者缺陷

编码阶段：代码出现错误

运行阶段（硬件、软件）：软硬件系统本身故障导致软件缺陷

4.缺陷核心要素

缺陷的标题：描述缺陷的核心问题

缺陷的前置条件：缺陷产生的前提

缺陷的复现步骤：复现缺陷过程

缺陷的预期结果：希望得到的结果

缺陷的实际结果：实际得到的结果

缺陷的必要附件：图片、日志等信息

5.缺陷示例

6.提交注意事项

可重现：确定缺陷可以复现；唯一性：一个缺陷上报一个问题；规范性：符合公司或者项目要求

7.缺陷类型

功能错误，UI页面错误，兼容性，数据（数据库），易用性，架构缺陷