您好，我是程序员小羊！
前言
这是一篇功能测试专栏系列《揭秘功能测试的秘密：从初学者到专家的必备指南》本系列将深入探讨了软件测试的基础知识和实用技巧，从手动测试到自动化测试工具的使用，涵盖了测试流程、测试用例设计、测试执行与报告生成等关键内容。无论你是软件测试新手，还是想要提升测试技能的开发者，这篇教程都将为你提供全面的指导，助你掌握软件测试的最佳实践，打造高质量的软件产品。后续内容大概会分三篇文章写完，中级会穿插一些扩展知识（软件测试需要具备的基础知识【功能测试】）感谢大家支持，大家可以先赞后看，养成好喜欢哦！！！！
为什么选择测试开发方向？
当然是因为开发线路真的是太卷了，就业环境也不行，软件测试领域有多个发展方向，掌握功能测试、自动化测试、性能测试、安全测试等才能找到工作哦，但现在单纯功能测试也很难找到岗位了。那我们根据现在行情需要用到哪些技术呢！
暂时测试要学会的主流技术
1、功能测试
2、⾃动化测试
3、接⼝测试
4、性能测试
主流⽅向建议：
1、功能测试+接⼝测试
2、⾃动化测试+接⼝
3、功能+性能
这篇文章大概会很长，但是也是最全的一篇讲解基础到功能测试实战的一篇文章了，希望大家能够理解，制作不易！！！
软件测试的定义
在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。简单地说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。简称：找bug（找开发麻烦）
使用技术手段验证软件是否满足使用需求
正文 第一阶段(测试基础知识)
下面为基础了解知识，后面没有标准重点的，只要了解就行！
一、软件测试目的
用最少的人力、物力、财力，找到软件中的问题并修复，从而降低商业风险，如下图所示（减少bug）
二、软件基本组成
三、软件产生的过程：
三、软件测试的分类
1.1单元测试
说明：单元也叫模块测试，针对程序源代码进行测试（单元：最小独立功能代码段）；
提示：
（1）国内单元测试⼀般开发⾃测
（2）单元测试可以解决-快速定位缺陷
（3）提高测试执行效率
1.2集成测试
说明：集成测试又叫接口测试，通常在单元测试的基础上，单独的模块合在一起测试
1.3系统测试
说明：系统测试，指的是将整个软件系统看为一个整体进行测试，测试的依据是软件需求说明书，针对系统整体功能+兼容+文档（说明、安装文档）
1.4验收测试
说明：
(1)α测试：Alpha 是内测版本，通常只在软件开发者内部交流，或忠实的粉丝之间发布，该版本软件的bug较多，普通用户最好不要安装。
(2)β测试：
Beta是公测版本，是对所有用户开放的测试版本这一版本通常由软件公司免费发布, 用户可从相关的站点下载通过一些专业爱好者的测试, 将结果反馈给开发者, 开发者们再进行有针对性的修改。
(3)γ测试：指的是软件版本正式发行的候选版。该版本已经相当成熟了, 与即将发行的正式版相差无几, 成为正式发布的候选版本。
1.5按覆盖源代码（代码可见度划分）
1.6按是否运行分类
静态测试： 指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误过程。
动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
1.7按照是否自动化
1、人工测试：也叫做手工测试，测试人员手动去进行的测试
2、自动化测试：利用代码或者工具帮助人工进行测试
1.8测试其他分类
1、冒烟测试：冒烟测试就是对系统进行最基本功能的测试，保证基本的功能和流程能走通
2、回归测试：当修复一个BUG后，把之前的测试用例在新的代码下进行再次测试
3、随机测试：随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分
4、探索性测试：探索性测试意味着同时设计测试和执行测试。测试人员通过测试来不断学习被测系统。
总结：
系统测试和⿊盒测试重点核⼼是功能测试
集成测试和灰盒测试⼜称接⼝测试
单元测试和⽩盒测试是对代码进⾏测试
⾃动化测试归属功能测试
性能测试、安全测试归属专项测试s
四、测试原则（知道）
- 只能证明软件存在问题，不能证明不存在问题
- 不能进行穷尽（穷举）测试，应该分类别测试
- 测试工作要尽早的介入，降低修复成本（需求文档–ui、程序、测试）
- 缺陷存在集群现象，二八原则：20%的模块中存在80%的缺陷
- 测试依赖环境（系统、浏览器）
- 杀虫剂现象
- 不存在缺陷谬论
五、质量模型（重点）
其实我们在测试过程中核心就是使用质量模型去进行测试，质量模型能告诉我们，测试时应该考虑的方面
那么下面就来介绍下质量模型
软件测试质量模型系统化地评估和提升软件质量。主要模型包括：
ISO/IEC 9126：定义功能性、可靠性、可用性、效率、可维护性和可移植性六个质量特性。
ISO/IEC 25010：改进版，增加了兼容性和安全性。
上面是官方的一些术语：
下面是通俗的解释：
质量模型：通俗的来说就是衡量一个优秀软件的维度，想证明这个软件好好只要满足以上图片这么要求，肯定是good的！！！
我们可以通过一个案例来解释这个模型：
需求：
1、开发一款网络游戏（要求：10个主功能）
2、游戏支持web（浏览器）端、App端
3、游戏上线后预计每日，20W用户玩家在线
总结
软件测试质量模型系统化地评估和提升软件质量，也是我们测试需要必须掌握的。
重点：功能、性能、兼容、易⽤性、安全
结论：无论测试硬件或软件，都应该从以上⼏点来进⾏分类验证
六、测试流程（重点）
1.1需求分析（评审）
前提：阅读1遍需求⽂档，记录不明确之处。
参与⼈员：前端、后端、测试、产品
⽬的：
1、确保各部⻔需求理解⼀致
2、各⻆⾊对需求进⾏查漏补缺
3、了解软件有些功能
提示：需求分析阶段->软件还未实现（刚⽴项）
需求文档：我会放几份在资源里，供大家免费下载！！！
1.2测试计划
说明：指导测试执⾏的⽂档（重要）
测什么（⽬标、范围）
谁来测（⼈员进度及安排）
怎么测（测试⼯具、测试策略）
测试计划：我也会放几份在资源里，供大家免费下载！！！
具体来说测试计划应包括以下内容：
① 概述：编写目的、项目背景。
② 测试任务：测试目的、测试参考文档、测试范围、测试提交
文档。
③ 测试资源：软件配置、硬件配置、人力资源分配。
④ 功能分解：整体功能模块划分。
⑤ 测试安排。
⑥ 相关风险。
1.3用例设计（重点）
说明：保证能准确验证软件测试点执⾏的⽂档，防⽌漏测，衡量软件是否通过的标准
1、分析需求
2、提取测试点
3、设计⽤例覆盖测试点
用例设计：我也会放几份在资源里，供大家免费下载！！！
具体来说测试用例应包括以下内容：
① 按模块汇总测试用例数量；
② 测试用例应包含以下元素：模块名称、功能项、用例说明、
前置条件、输入、执行步骤、预期结果、重要程度、执行用例测试结果。
具体如何设计用例，编写用例，请看我之前写的那篇文章软件测试理论（*重点用例方法编写）
1.4用例执行
说明：实施测试
执行用例，不通过的用例，进行缺陷管理
1.5缺陷管理
说明：用例执行不通过的，也就是软件中存在的各种问题，都为缺陷，简称bug；
1、少功能 2、功能错误 3、多功能 4、缺少隐性功能 5、易用性（软件测试人员专业⻆度）
提交->验证->关闭
缺陷管理一般有两种管理方式：
2.1 excel示例
Bug 清单应包括以下内容：
按模块和Bug 严重程度汇总Bug 数量；
Bug 清单应包含以下元素：角色、模块名称、功能项、摘要描述、
操作步骤、预期结果、实际结果、缺陷严重程度、附件说明（截图）。
2.2使用禅道（项目管理工具）
具体详细介绍可以看我写的了解软件的缺陷
1.6测试报告
1、bug分析及统计
2、测试中遇到的问题
3、测试总结（本次测试中的优点和不⾜）
测试报告应包括以下内容：
① 概述：编写目的、项目背景。
② 人员安排。
③ 测试设计：测试用例设计方法、测试方法。
④ 用例汇总：用例汇总。
⑤ 测试回顾：进度回顾、功能测试回顾。
⑥ Bug 汇总：Bug 汇总。
⑦ 测试结论。
测试报告：我也会放几份在资源里，供大家免费下载！！！
结尾：
感觉这篇文章还是有很多不足之处，大厦之成，非一木之材也；大海之阔，非一流之归也，当然也希望大家能持续关注下，文章从浅到深，也欢迎大佬们的随时指导！！！可能会有人觉得枯燥，但要知道基础测试就是这样，现在公司大部分测试基本都是点点点，基础概念反而没有那么重要了，下篇会继续写干货~
扩展（了解）：
一、开发模型的介绍：
在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，如：
软件测试与软件的开发模式有着紧密的联系，我们作为一名测试人员，应该充分理解软件的开发模式，以便找准自己在其中的位置，从而发挥自身的价值。
1.1、瀑布模型
说明：瀑布是线性模型的一种，每一个阶段只执行一次，通过文档驱动。
优点：
(1) 开发的各个阶段比较清晰，当前阶段完成后，只需关注后续阶段。
缺点：
(1) 不适应需求的变化。
(2) 风险往往延至后期才显露，失去及早纠正的机会。
1.2、快速原型模型
说明：快速原型模型是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。特点：(1)快速得构建软件的原型(2)支持用户参与
优点：
(1)克服瀑布模型的缺点，减少由于软件需求不明确带来的项目开发风险。
缺点：
(1)不适合大型系统的开发(适合开发小型的、灵活性高的系统)。
1.3、螺旋模型
说明：螺旋模型引进了风险分析活动
优点：（1）螺旋模型很大程度上是一种风险驱动的方法体系。
缺点：(1) 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识。
二、软件测试模型
2.1、V模型
V模型是最具有代表意义的测试模型，最早是由Paul Rook在20世纪80年代后期提出，由英国国家计算机中心
文献中发布，旨在改进软件开发的效率和效果； V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系。
V模型标明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系。
优点：(1)测试V模型即包含了底层测试又包含了高层测试；
缺点：(1)当需求变更时将会导致返工量非常大，模型灵活性比较低。
2.2、W模型
说明：测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试。
优点：
(1)强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，还包括需求和设计。
(2)更早地介入测试，能尽早得发现缺陷进行修复。
缺点：
(1)对于测试技术要求高，实践起来困难。
软件修复成本：
