原文链接：https://blog.csdn.net/weixin_44775434/article/details/125961878
一、测试是什么？
软件测试：查找软件缺陷，保障软件质量。（软件质检工作）
测试思维：
① 站在不同角度去验证软件质量（抵用券-已使用、已过期是否还能使用）
② 不同应用场景去验证软件质量（某宝双11-多人同时使用时，服务器是否正常处理请求）
③ 不常用功能覆盖去验证软件质量 (飞机手动模式，对功能全面覆盖验证)
测试总结：
需求第一；
永远站在用户的角度去测试软件；
测试人员的思维是一种破坏性的思维。
二、测试怎么做？
1、需求分析：根据产品需求文档，提取出规则要求；通过软件的需求推导软件测试需求；目的是明确软件有哪些功能和要求，为设计测试点做准备。
测试需求的获取途径：
从业务目标、结构、功能、数据、运行平台、操作进行综合分析；
以旧版本系统或者同类的软件系统作为参考；
与客户、产品设计人员、开发人员等充分沟通；
参加公司提供的业务培训；
从易用性、 用户体验等角度考虑；
从测试标准、行业规范进行提取。
需求评审的目的：尽早地发现缺陷，使需求规格说明书具有更好的可测试性；评审时确保需求文档的完整性、精准性、准确性、一致性、无二异性、相关性、可行性以及可测试性等。
2、测试点：要进行验证的点，根据需求规则设计测试点；设计测试点的目的是为了防止测试时有遗漏，为编写测试用例做准备。
3、编写测试用例的目的是为了指导测试点正确测试实施，为执行测试做准备。
4、测试用例的执行：执行用例就是执行测试。
当执行结果和预期结果不一致，则为缺陷。
发现缺陷需要进行缺陷管理（提交->开发修复->测试验证->关闭缺陷）。
执行时间：等待项目提测时，执行用例。
提示：提测前一天要进行冒烟测试（正向业务用例能够执行通过）。
5、缺陷管理：当执行用例结果和预期结果不符时为缺陷，就需要对缺陷进行管理
为什么需要对缺陷进行管理？
测试的目的就是减少软件缺陷（提交缺陷->等待修复->验证缺陷）；
为测试报告做准备。
6、测试报告：对于本次执行测试缺陷进行分析统计，对于本次测试实施进行总结
测试报告的主要内容：缺陷统计、缺陷分析、遗留缺陷、测试总结
三、软件产品的质量模型（六大特性）
功能性：能够满足明确和隐含要求的功能。
可靠性：能够处理异常情况，在错误中很快恢复。
易用性：易懂、易学、易用、漂亮好看。
效率性：占用少量的资源，提供适当的性能。
维护性：是指产品可被修改的能力。
可移植：是指软件产品从一种环境迁移到另外一种环境的能力。
四、软件测试常见分类
1、是否覆盖源代码：
黑盒测试
白盒测试
灰盒测试2、按照阶段划分：
单元测试：对软件中最小的可测单元进行的测试
集成测试：在单元测试的基础上，对多个单元组装后的产物进行测试
系统测试：在集成测试的基础上，把软件看作一个整体进行测试
验收测试：也叫交付测试，以最终用户的角度确认软件是否符合预期3、是否运行：
静态测试、动态测试4、是否自动化：
手工测试、自动化测试5、更多分类：
冒烟测试：对基本功能，主要功能进行的测试，避免测试资源的浪费。
回归测试：对BUG或者测试用例进行回归测试。
随机测试：假设第一次接触软件进行随机测试，避免惯性思维。
探索测试：同时做测试设计和测试执行，探索复杂场景，容易被忽略的场景。五、软件开发常见模型
1、瀑布模型
2、快速原型
瀑布模型
过程：需求分析 、概要设计、详细设计、编码、软件测试、软件维护
优点：阶段清晰
缺点：依赖于需求分析的成果
适用：需求明确的，大型项目
快速原型模型
过程：快速分析、构造、运行、客户评价
优点：支持客户参与，适应需求灵活的项目
缺点：文档不完善，不能满足大型项目的要求
适用：需求灵活的中小型项目
六、软件测试常见模型
1、V模型
2、W模型
V模型
过程：开发半个V，测试半个V
优点：包含了底层测试和高层测试
缺点：测试介入时间晚
W模型
过程：开发一个V，测试一个V
优点：测试介入时间早
缺点：步骤复杂，对人员要求高
七、测试计划
5W1H原则：
why – 原因（何因）
what – 对象（何事）
where – 地点（何地）
when – 时间（何因）
who – 人员（何人）
how – 方法（何法）
1、测试的目标和范围 – 测什么？
确定测试的目标（功能），确定需求的内容（各个模块）。2、任务分配和进度安排 – 谁来做？做什么？什么时间做？
分角色分任务，再预估下任务时间，做好统计。3、制定测试策略 – 如何做？怎么做？
根据需求确定测试的方法、工具、环境等。4、风险分析和预防计划 – 遇到风险怎么办？
考虑业务风险，安全风险，进度风险。5、验收项目各项指标 – 验收标准
项目相关的指标，如各个阶段的交付物、测试用例要求、缺陷修复要求等；什么样的产品质量是能够接受的八、测试用例
测试用例：执行测试时用户案例，保证测试点的正确执行。
设计测试用例：业务流程
测试用例需覆盖全测试要点
测试数据测试用例文档编写格式的要素：用例编号，用例标题，模块/项目，前置条件，优先级，测试数据，测试步骤，预期结果，实际结果。
九、设计测试点方法
1、等价类：解决穷举问题。
2、边界值：解决输入边界限制问题。
3、判定表：解决条件组合问题。
4、场景法：解决业务测试问题。
5、错误推断法：解决可能存在的问题。
等价类划分法：将测试数据中具有某种共同特征的数据集合，进行划分。分为有效等价类（满足需求的数据集合）和无效等价类（不满足需求的数据集合）。
使用场景：
针对需要有大量数据测试输入，但是没法穷举测试的地方。（输入框，下拉列表，单选复选框）
典型代表：页面输入框类测试。边界值分析法：选取正好等于、刚好大于、刚好小于边界的值作为测试数据。
使用场景：
在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)；常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语；
典型代表:有边界范围的输入框类测试。判定表法：等价类边界值分析法主要关注单个输入类条件的测试；并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。
使用场景：
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系；
判定表一般适用于条件组合数量较少的情况(比如4个条件以下)。场景设计法：场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用；
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。使用场景：
根据实际的应用场景，来测试业务用例，可以使用场景法。错误推断法：根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
使用场景：
提前预设程序中可能会存在的错误。十、缺陷管理
1、缺陷介绍
1、缺陷的定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。
2、缺陷的判定标准：
（1）少功能：软件未实现需求(规格)说明书中明确要求的功能。
（2）功能错误：软件出现了需求(规格)说明书中指明不应该出现的错误。
（3）多功能：软件实现的功能超出需求(规格)说明书指明的范围。
（4）隐形功能错误：软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求。
（5）不易使用：软件难以理解,不易使用,运行缓慢,用户体验不好。
3、软件缺陷产生的原因
（1）需求阶段：需求描述不易理解，有歧义、错误等。
（2）设计阶段：设计文档存在错误或者缺陷。
（3）编码阶段：代码出现错误。
（4）运行系统：软硬件系统本身故障导致软件缺陷。
4、软件缺陷的生命周期：
5、软件缺陷类型：功能错误、界面（UI）错误、兼容性、数据、易用性、改进建议、架构等。
2、缺陷编写
1、缺陷的核心内容：
缺陷的标题 – 描述缺陷的核心问题
缺陷的预置条件 – 缺陷产生的前提
缺陷的复现步骤 – 复现缺陷的过程
缺陷的预期结果 – 希望得到的结果
缺陷的实际结果 – 实际得到的结果
缺陷的必要附件 – 图片、日志等信息(证据)
2、缺陷描述：缺陷ID、缺陷标题、所属模块、预置条件、严重程度、预期结果、实际结果、复现步骤、附件、缺陷类型
3、缺陷的跟踪流程：
测试填写缺陷 → 开发修改缺陷 → 测试回归测试（跟踪bug闭环）
4、缺陷的提交流程
5、缺陷（报告）提交要素：
缺陷报告编号：缺陷的唯一性标志
严重程度：严重、一般、微小、建议
缺陷优先级
bug类型：代码错误、兼容性错误、设计缺陷、性能问题
缺陷状态：新建、打开、关闭、延期
6、提交缺陷注意事项：
可重现：缺陷可以复现
唯一性：一个缺陷上报一个问题
规范性：符合公司或项目要求
十一、测试报告
一、概述
包括项目背景、需求分析二、测试时间、测试环境
三、测试过程
评审记录、测试范围、测试用例四、功能实现清单
列出是否已经按照测试计划实现功能五、缺陷统计
测试缺陷统计；
测试用例执行情况统计六、测试统计情况
资源统计
执行情况
问题统计
问题列表
遗留缺陷七、测试总结
测试结论；（是否通过）
测试内容、测试用例的覆盖程度、bug的解决程度八、测试风险
十二、抓包
1、为什么要进行抓包？
（1）功能测试时跳过UI界面验证，验证后端程序处理能力。（如：请求支付100元，通过抓包修改请求价格0.1元，查看后端程序是否能正常处理）
（2）分析前端bug还是后端bug。（如：ui显示数据错误，提交bug时需要指定提交人，那是提交给前端开发还是后端开发呢？）
（3）弱网测试（如：app应用模拟4G、3G网络）
（4）接口测试时，缺乏接口描述文档，需要抓包获取。（如：查看支付宝请求信息）2、什么是抓包？（Fiddler）
通过工具抓取前端与后端的通信内容。3、需要掌握哪些知识
（1）抓包操作（http、https）；
（2）断点操作---拦截修改（请求、响应）；
（3）弱网测试。十三、项目实施
1、覆盖业务用例
① 正向
② 逆向2、单功能用例
① 功能：正向、逆向
② 非功能：UI、兼容、安全、易用性、性能等容错性测试：错误操作，给出友好提示
极限测试：弱网、弱电
特殊环境测试 不同场景环境
三轮测试： 以业务流程为主
以页面测试为主
以整个业务流程及页面为主十四、软件测试的风险分析与解决办法
一、软件需求的风险
1、软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差；
2、需求变更风险，在项目的后期频繁的需求变更会导致测试的时间不充分。解决办法：
1、在项目开发过程中的每一个阶段，尽量让用户参与进来；
2、多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现。二、人员的风险
1、核心测试人员的请假、离职；
2、测试人员的工作态度不端正、工作状态差；
3、测试人员的测试技术不足。解决办法：
1、给这些核心人员配置一些可以候补的测试人员来向他们学习，另外，对于一些关键的业务和技术一定要有文档；
2、另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况；
3、在测试每一轮后，在进行不同模块的交叉测试。三、代码质量的风险
如果开发人员提交上来的代码质量很差、很烂的话，软件缺陷很多，那么对于测试工程师来说漏测的可能性就越大。解决办法：
对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发工程师进行前期检查。四、测试环境的风险
解决办法：
测试部门在测试过程中搭建的测试环境的时候，尽量尽一切可能无限制的模拟用户使用的环境（硬件、操作系统的版本和补丁，数据库的版本和补丁）在测试的时候尽量和用户沟通要到用户真实的数据进行测试。以减少风险。五、测试工程师对产品的业务不熟悉
1、测试工程师不了解用户究竟是如何操作该产品和用户的操作习惯；
2、测试工程师介入到项目测试的时间太短。解决办法：
1、给测试人员进行培训；
2、让测试人员在项目的前期就介入到项目中去熟悉产品。六、测试深度和广度的风险
1、测试的广度，用户的操作肯定是千变万化的，测试工程师在测试的时候肯定不能100%覆盖到这些千变万化的操作。有些极端的情况容易被遗漏、测试不到；
2、测试的深度，比如有些软件只有在特定的情况下，比如多用户并发的情况下使用的过程中才会产生软件的缺陷bug，但是测试工程师在测试的时候忽略了这种情况，只有某几个测试工程师在测试使用这些功能。解决办法：
测试工程师在写测试用例的时候尽量提高测试用例的覆盖率（在测试用例完成后组织进行测试用例的评审工作）。七、测试工具本身可能产生误差
解决办法：
1、对于自动化的测试工具，一定要选择一些知名大企业比较成熟的测试工具；
2.、测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值；
3、不要过分的相信测试工具，最后一定要进行人工的审核和检查才可靠。4、另外可以用不同的测试工具运行相同的测试场景
八、测试资源的不充分
硬件资源不够、软件资源不充分、测试的时间不充足。解决办法：
申请更多的测试资源，如购置独立的测试服务器把测试环境和研发环境分开；要求招聘更多的测试人员；测试管理者做好测试风险的预估。