软件测试基础01_学习笔记

技能

能对app、web项目实现功能测试
能实用工具或者代码针对接口进行测试
能使用工具或代码实现性能测试
能使用或者代码实现自动化测试（UI、接口）

测试的基础知识

1.什么是软件测试

软件测试：使用技术手段验证软件是否满足需求。
目的：用最少的人力、物力、财力，找到软件中的问题并修复，从而降低商业风险 。

2.测试主流技能

1. 功能测试: 主要验证程序的功能是否满足需求。
2. 接口测试：针对模块或系统与系统之间数据请求地址进行测试。eg:jmeter、postman
3. 性能测试 ：模拟多人使用软件，查找服务器缺陷。
4. 自动化测试：使用代码或工具代替人工验证项目功能。

3.常见的测试分类

a.按测试阶段划分

1. 单元测试：针对源程序代码进行测试。(完成最小的软件设计单元（模块）的验证工作，目标是确定模块被正确的编码)
2. 集成测试：又称接口测试，针对模块之间访问地址进行测试。（通过测试发现与模块接口有关的问题）
3. 系统测试：对整个系统进行测试包括功能、兼容、文档等测试。（是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件）
4. 回归测试：是指发生在修改之后重新测试先前的测试用例，以保证修改的正确性。
5. 验收测试：主要分为内测(Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。并且在开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题)、公测（Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场。由用户记录在测试中遇到的一系列问题，并定期报给开发者），使用不同人群来发掘项目缺陷。

b.按代码可见度划分

1. 黑盒测试：（功能测试或数据局驱动测试）看不见代码，主要对程序功能进行测试。（着眼于程序外部结构、不考虑内部逻辑结构，针对软件界面和软件功能进行测试）
2. 白盒测试：（结构测试或逻辑驱动测试）看见全部代码，主要对程序源代码进行测试。
3. 灰盒测试：（集成测试）看见部分代码，主要对程序接口进行测试。

c.按代码运行划分

1. 静态测试：直接检查程序代码、界面或文档中可能存在的错误。
2. 代码测试：主要测试代码是否符合相应的标准和规范。
3. 界面测试：主要测试软件的实际界面与需求中的说明是否相符。
4. 文档测试：主要测试用户手册和需求说明书是否真正符合用户的实际需求。
5. 动态测试：实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否想符合的过程。

d.按代码运行划分

1. 功能测试：黑盒测试的一方面，检查实际软件功能是否符合用户需求。
2. 性能测试：关注软件中某一功能能在指定的时间、空间条件下，是否能够使用正常（时间性能和空间性能）
3. 安全性测试：验证按在系统内的包含机制能否在实际应用中对系统进行保护使之不受各种因素干扰。

e.测试策略

冒烟测试： 大规模执行测试之前，针对程序主功能进行验证，保证程序具备可测性。

4.测试模型

a. 质量模型：提供测试设计的不同角度视野和验证方向。

功能性：软件的功能是否满足需求
性能效率：性能效率满足实际需求
兼容性：软件能与主流硬件和软件兼容
易用性：便于使用
可靠性：性能和功能应用可靠
信息安全：信息在传输或者存储过程的安全程度
可维护性：便于维护
可移植性

b. 测试模型

1. 瀑布模型：项目计划、需求分析、软件设计、程序开发、软件测试、集成维护。
   缺点：由于各阶段划分完全固定，阶段之间产生大量文档，极大增加工作量；开发模型是线性的，用户只有等到整个过程的末期才能看到开发结果，增加开发风险；不适应鱼护需求变化。
2. w模型：简称“双v”模型，即以开发为主导的一个“v”和以测试主导的另一个“v”构成。
   优点：测试伴随整个产品开发周期，测试针对不仅是程序还有需求、设计文档；测试介入较早，及早发现问题，降低修复成本。
   缺点：实施起来比较复杂，难度大，对于需求阶段和设计阶段的测试设计需求较高。
   开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付。
   测试流程：系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统设计、验收测试。
   
3. v模型:揭示开发过程和测试过程中各阶段的对应关系。
   
   缺点：仅把测试过程作为需求分析、系统设计及编码之后的一个阶段，忽略了测试对需求分析、系统设计的验证需求的满足情况，一直到后期验收测试才被验证。
4. 快速原型模型：迅速搭建一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最后在确定需求基础上开发客户满意的软件产品。
   优点：适合预先不能确切定义需求的软件系统的开发；克服瀑布模型缺点，减少由于软件需求不明确带来的开发风险。
5. 增量模型：分批次地分析、设计、编码和测试这些增量组件。
6. 迭代模型
7. 螺旋模型：兼顾了快速模型的迭代特征以及瀑布模型的系统化与严格监控。
   优点：具备风险分析，适合大型且昂贵的系统级的软件应用。

5.测试流程

需求分析、测试计划【测什么：测试目标及范围；谁来侧：人员进度安排；怎么测：测试策略、测试工具 】、编写用例（用例设计）【设计执行测试的文档】、执行用例【执行测试的文档】、缺陷管理【提交、验证、修复、验证、关闭 】、测试报告【测试目标、测试过程、缺陷统计、数据分析、测试总结】

6.测试用例

1. 什么是测试用例？
   测试用例是为测试项目而设计的执行文档。
2. 什么是用例？
   用户使用的案例。
   考虑点：质量模型（功能、性能、兼容、易用、安全）。
3. 测试用例的作用
   防止漏测；实施测试的标准。
4. 用例设计编写格式
   用例编号、标题、模块、优先级、前置条件、测试步骤、测试数据、预期结果。
   
   用例的八大要素：
   用例编号：项目+模块+编号
   用例标题：预期结果+操作步骤；【预期结果（测试点）】；作用：方便评审、方便执行。
   模块/项目：所属项目或模块
   前置条件：要执行此条用例，有哪些前置操作
   优先级：表示用例的重要程度或者影响力P0~P4（P0最高）
   测试步骤：描述操作步骤
   测试数据：操作的数据，没有的话可以为空
   预期结果：期望达到达到的结果
   注意：验证码只有4条用例（正确、错误、为空、过期）

7.编写测试用例的方法

穷举场景、限定边界规则、多条依赖关系

等价类划分法

应用场景：可以用于解决穷举问题。（典型的代表：页面级的输入框测试、下拉列表、单选复选框）
在所有测试数据中，具有某种共同特征的数据集合进行划分。
分类：有效等价类（满足需求的数据集合，取一个即可）、无效等价类（不满足需求的数据集合，取一个即可）
步骤：明确需求；确定有效和无效等价类；提取数据编写测试用例。
用例执行：实际结果与预期结果不一致为缺陷。

边界值分析法

解决了边界限定的问题。（>、<、>=、<=）【最多7条用例、最少5条用例】
边界范围节点：选取正好等于、刚好小于或大于边界的值作为测试数据。
上点：边界上的点（正好等于）
离点：距离上点最近的点（刚好大于、刚好小于总共四个（两个内部离点、两个外部离点））
内点：范围内的点（区间范围内的数据）
步骤：明确需求；确定有效和无效等价类；确定边界范围值；提取数据编写测试用例。
优化：针对边界上的点【考虑开内闭外：开区间考虑内部离点、闭区间考虑外部离点】
应用场景：常见词语描述大小：尺寸、重量、最大、最小、至多、至少等修饰词语。
典型代表：有边界范围的输入框类测试。
注意：边界值可以覆盖等价类的长度，但是无法覆盖类型，所以设计用例时，必须两者相结合起来使用。

判定表法

解决多条件依赖问题。
定义：是一种以表格形式表达多条件逻辑判断的工具。
组成：

1. 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
2. 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
3. 条件项：列出条件对应的取值，所有可能情况下的真假值。
4. 动作项：列出条件项的各种取值情况下应该采取的动作结果。
   
   判定表中贯穿条件项和动作项的一列就是一条规则。
   假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方中规则。
   步骤：明确需求；画出判定表【1.列出条件桩和动作桩；2.填写条件项，对条件进行全组合；3.根据条件项的组合确定动作项；4.简化、合并相似规则】；根据规则编写测试用例；
   使用规则：有多个输入条件，多个输出结果，输入条件之间组合关系，输入条件和输出结果之间有依赖（制约）关系；判定表一般适用于条件组合数量较少的情况。

条件组合覆盖法

只要满足条件组合覆盖就一定满足语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，但是可能不会覆盖所有的路径
用于确定测试用例的最小数量，以覆盖系统中的所有条件组合【保测试用例能够覆盖所有可能的有效条件组合，通过组合这些取值，生成所有可能的有效条件组合】
eg:if(x>0 && y>0) 下嵌套 if(m>0 && n>0)，使用条件组合覆盖法至少有多少个用例 ?
首先，我们列出所有条件的可能取值：
条件1：x > 0 (T, F)
条件2：y > 0 (T, F)
条件3：m > 0 (T, F)
条件4：n > 0 (T, F)

T, T, T, T
所以，至少需要1个测试用例来覆盖所有可能的条件组合
eg:if(x>0 && y>0) 下嵌套 if(m>0 || n>0)，使用条件组合覆盖法至少有多少个用例 ?
首先，我们列出所有条件的可能取值：
条件1：x > 0 (T, F)
条件2：y > 0 (T, F)
条件3：m > 0 (T, F)
条件4：n > 0 (T, F)

T, T, T, T
T, T, T, F
T, T, F, T
T, F, T, T
F, T, T, T
F, F, T, T
所以，至少需要6个测试用例来覆盖所有可能的条件组合。

有区别的原因：当条件 “m > 0 || n > 0” 成立时，无论其他条件的取值如何，都会执行内部代码块；条件 “m > 0 && n > 0” 必须同时成立才会执行内部代码块，因此只需要一个测试用例就能覆盖所有可能的条件组合

正交试验法；因果图法；状态迁移法

场景法

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

错误推荐法

通过经验推测系统可能出现的问题。

8.缺陷管理

1. 缺陷的定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
2. 缺陷的判定标准：【需求说明书 】少功能、功能错误、多功能、隐性功能错误（未实现需求说明书中未明确指明但应该实现的要求。eg:比如登录成功后页面没有进行跳转）、不易使用。
3. 缺陷产生的原因：需求阶段：需求描述不易理解，有歧义、错误等；设计阶段：设计文档存在错误或者缺陷；编码阶段：代码出现错误；运行阶段：软硬件系统本身故障导致软件缺陷。

缺陷的生命周期

注入bug->发现bug->消除bug
软件测试人员提交缺陷报告；
测试负责人审核后将缺陷分配给相关开发人员修复；
缺陷被修改后有测试人员根据缺陷报告中修改记录进行返测；
返测通过的缺陷由负责人关闭；
返测未通过的缺陷直接返回给开发人员重新修改，然后再由测试人员返测，直到测试和开发达成一致处理意见。

缺陷的核心内容

缺陷的标题：描述缺陷的核心问题。【操作数据描述+预期+实际】
缺陷的预置条件：缺陷产生的前提。
缺陷的复现步骤：复现缺陷的过程。【操作步骤+数据】
缺陷的期望结果：希望得到的结果。
缺陷的实际结果：实际得到的结果。
缺陷的必要附件：图片、日志等信息（证据）。

提交缺陷的要素

缺陷报告编号（可以用用例ID来描述）、严重程度、缺陷优先级、bug类型、缺陷状态（用于描述却缺陷是否修复）、缺陷描述（前置、步骤、预期、实际）。

缺陷类型

功能错误、界面错误、兼容性、数据、易用性、改进建议、架构。
利用抓包查看请求和响应来区分是否是前端还是后端功能bug。

9.测试用例的编写

9.缺陷编写

a.缺陷报告示例

缺陷ID、缺陷标题、缺陷状态、严重程度、优先级、所属模块、缺陷描述、附件（日志和截图）。

b.缺陷的跟踪流程

发现bug后，首先应确认bug是否可复现。