| 万叶集 |
|---|
| 隐约雷鸣，阴霾天空。 |
| 但盼风雨来，能留你在此。 |
前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 哈士奇 ，致力于用白话讲解技术知识的博主 ✌
CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主
如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步
人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。
如果感觉博主的文章还不错的话，还请关注、点赞、收藏三连支持一下博主哦
系列专栏：
Python全栈系列 - [更新中] 【 本文在该系列】
Python零基础入门篇
Python语法进阶篇
Python自动化办公篇
Python自动化测试实战篇
网安之路系列
网安之路踩坑篇
网安知识扫盲篇
Vulhub 漏洞复现篇
Shell脚本编程篇
Web攻防篇 2021年9月3日停止更新，转战先知等安全社区
渗透工具使用集锦 2021年9月3日停止更新,转战先知等安全社区
⭐️ 点点点工程师系列
测试神器 - Charles 篇
测试神器 - Fiddler 篇
测试神器 - Jmeter 篇
自动化 - RobotFrameWork 系列
自动化 - 基于 JAVA 实现的WEB端UI自动化
自动化 - 基于 MonkeyRunner 实现的APP端UI自动化
文章目录
- 软件测试的定义
- 软件测试流程
- 头脑风暴
- 需求分析
- 设计阶段
- 测试模块划分
- 测试计划 & 用例设计
- 用例评审
- 执行阶段
- 项目上线
该章节的主要目的是为了大家能够对 软件测试 有一个新的了解。先来讨论一个问题，到底什么是软件测试？
软件测试的定义在我们的行业里有一种解释：测试是产品的最后一道防线，使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求，或弄清楚预期的结果与实际结果之间的差别的过程。 这是一种现在大家普遍共识的一种 “软件测试” 的职业认知。
简单一些来说，软件测试其实就是 为了发现软件错误而执行程序 的过程。当然这样的认知也无可厚非…
但是个人观点认为，测试工程师 本质上的意义在于：保护用户与业务的利益 ，使得用户不受糟糕的设计、令人困惑且无以言表的用户体验、功能bug、安全隐私等问题的困扰，这才是 测试工程师 本质上的意义。
以上两个观点最大的差别就在于对测试理解的角度不一样，更多的人认为 测试 就是一个 捉虫师 (即 找bug ) 。带着这样的思维，测试就是项目的服务支撑提供者；而更高级的一点来说，就像 google、facebook 他们会将测试看做是 用户的保护者 ，是为了客户而存在的，我觉得这就是我们和最先进的测试思维最根深蒂固的认知上的差异。
软件测试流程 头脑风暴上一章节我们聊到了传统的测试方法，专注于业务、测试点的测试思路已经不再适用于飞速发展的互联网。在如今，软件测试已经体现在了项目的各个流程之中：从需求到设计、到执行、最后到项目上线每个阶段都有测试的影子。
举一个 微信抢红包的例子 ，以这个例子来聊一聊在软件测试的整个流程中，测试人员到底都要做些什么。
一般来说任何产品的来源可能就是一句话、一个念头。就比如 微信红包 这个需求的来源就是一个非常简单的想法。因为腾讯内部每年新年的第一天大家都会有去马总办公室领红包的传统，领红包的队伍就会从马总的办公室一直排队到楼下（三十几层楼啊）。
于是在一次基础产品中心的 "头脑风暴"中，开发人员希望开发类似于公司发红包传统的应用，把每年发红包利是行为变成一款互联网产品；然而把这样一个简单的念头变成实际可执行的需求其实还是一个非常复杂的过程。很多时候都需要N多次的头脑风暴的碰头会议，而在大公司里，头脑风暴这一个过程会邀请一些开发和测试的加入。需要研发与测试人员评估产品经理突如其来的想法的可行性，以及是否会对现有业务逻辑产生巨大的改变。
所以呢，在需求诞生之初就需要测试人员的参与。这个时候的 "测试工程师" 就是 "需求产生" 的把关人。一个成熟的 测试工程师 其实也需要像开发、像架构那样去思考，比如思考这个需求，应该怎么样去实现。（微信红包这个需求在微信的系统里应该怎么去实现，实现了对于我们现有业务会遭成那些不可预估的影响等等）
需求分析头脑风暴之后，确定了改需求的可行性。那么下一步就需要进行需求分析了，可能很多人都觉得需求分析这件事儿和测试没什么关系，用古人的话来装一下那就是 墙高基下，虽得必失。 什么意思？就是再高的墙，如果没有好的基础早晚是会倒塌的。
测试工作也是一样，如果没有更早的清晰的明确需求，没有坚实的基础，后患无穷。所以在需求分析阶段，测试人员的工作就是根据总结出的每个需求点归纳出我们的测试要点。分析需求的合理性，从而大致的确定测试的合理范围和测试工作的优先级；同时还需要找出需求里不确定的场景，来查缺补漏。
仍然拿 微信红包 来举例，很多时候产品方、业务方就会忽略这个问题。 比如红包未完全发放的场景，在微信群里发了10个红包，但是群里只有5个人，没有被领取的5个红包的金额在退款的时候究竟是退款到 当初发红包的银行卡 呢？还是退回到微信的 零钱余额 呢？ 这就需要测试人员帮助需求人整理完善这些他们容易忽略的一些需求点，同时也可以避免开发人员在开发阶段的遗漏。
由此发现，测试人员的需求分析其实也很重要。而测试人员发现的问题和疑问呢，一般情况下都会在后面的需求评审会议上大家会尽情的发现、讨论甚至争吵（吵架不是目的，重点在于针对需求的更好的分析和分解需求的点点滴滴）。这个时候的 测试人员 又扮演着 需求质量 的把控着这一角色。
设计阶段 测试模块划分接下来需求确定了，就到了设计阶段。对于 测试工程师 来说，在这一阶段的第一个任务就是 测试模块划分 ，很多测试人员（我周围也有）到了设计阶段就拿上需求、设计文档、UI 就开始写测试用例、自己的测试点了。
实际上这不是最好的方法，就很武侠小说里的秘籍一样，在秘籍的开头都会有一篇总纲（欲练此功，必先自宫？）。所以在正式的大展拳脚之前，也为自己的 测试模块划分 也设计这么一篇总纲。就好比 抢红包 的这个需求，如下图：（部分模块划分）
使用 Xmind 思维导图方式进行的模块划分会更加的清晰和完整，当然亦可以有其他方式划分模块，比如其他类型的脑图工具或者线框图之类的…
这种总纲的目的不是为了给别人看，目的是为了测试的时候在 设计测试用例 找测试点的时候，或者在帮助开发人员梳理要做哪些点的时候呢呢狗做到更加心中有数。
一个产品的项目，在开发、测试的时候到底有哪些测试点，哪些功能点最核心？哪些更次要？哪些又是边缘功能，通过一个思维导图可以一览无余。
测试计划 & 用例设计接下来就是 测试计划 与 测试用例设计 的部分了 ，这部分也是测试的老本行了。实际上在传统的测试思路里，这里才是测试的开始。
测试计划是描述测试项目与测试任务之间的关系，说明需要测试什么，将要如何测试，如何协调测试资源和测试时间等等，测试计划制定的是否合理高效直接会对测试项目的进度产生很大的影响；
而 用例设计 则是把待测的测试目标转化为具体的测试条件、测试用例，不仅仅对于测试人员，对于开发人员来说，也要在大脑中有这样一个过程，到底哪些点是重要的，要着重实现哪些点。当然了，这其中也需要包括是否需要性能测试？是否需要安全测试？哪一块可以自动化，要怎么运行等等…都是在这一步需要考虑到的。用例设计完成之后不是就OK了，就像开发人员写代码一样，代码编写完成后也需要 code review ; 所以测试人员的测试用例也需要评审。
用例评审见下图：
这张图是用例评审的全过程，有很多人也会觉得 用例评审 是一个特别流程化不太有益的过程。但实际上用例评审的重点在于七个字 “换个角度想问题” ，就像一千个人眼中就有一千个哈姆雷特一样。不管是开发还是测试或者是相同项目的团队 ，在长时间的接触一定的需求与工作的情况下，极有可能会形成一种固定的思维模式，从而可能会遗漏掉其他人能够看清，但是自己却忽略的点。
所以这也是 用例评审 的意义所在，除了 用例评审 之外，在做自动化测试的时候，对自动化测试的代码进行 code review 也是非常重要的。
执行阶段执行阶段 就是执行了，在新时代互联网测试过程中有一个很重要的流程就是 冒烟测试 。一直以来对于 冒烟测试 其实也有很多的误解，很多人都觉得进入了 冒烟测试 就是进入了 测试阶段 ；其实不然， 冒烟测试 只是作为提测的一个检查点而不是真正的进入了测试。
“冒烟” 这个词很形象，它最早来源与硬件测试行业。在对一个硬件进行更改和修复之后会直接给设备进行通电运行，如果这个被更改、修复的硬件没有冒烟，测试通过了测试；所以呢，冒烟测试 算是一个固化的校验工作。结果就是两种 ，通过 或者 不通过 。“通过” 则进入测试阶段， “不通过” 在打回去进行返工，等待下一次的提测。所以说，冒烟测试 其实就是对测试工作的一个保障，千万不要觉得这个很多余、没有用，因为 冒烟测试的属性是校验 ，校验常见的基本流程 就是基本的线性流程是否能通过。如果说连基本的线性流程都不通过，那么这个版本的提测又有什么意义？
冒烟测试的最好实践方法，其实就是自动化测试，因为他的测试点、流程很固化，可以利用自动化测试方式非常快捷、便捷的完成冒烟测试。这也是那些懂代码、会用代码的测试开发人员在互联网领域的用武之地之一。
接下来就是 测试执行 了，就包含了 用例执行、按照用例操作的 点点点 、查数据库、查日志、测试缺陷的提出、回归验证 等等等等… 这些都是 测试工程师 的基本功了。
一位优秀的 测试工程师 会在发现 bug、记录bug 的同时还会做以下几件事儿：
1、截图、必要的时候还会录屏（方便 bug 的复现）
2、去服务器上查看对应的日志，定位、查看 bug 报错的情况（甚至日志不是很详细的情况下，可以自己加上日志来帮助定位发生bug的数据）
3、再深入一些就是分析错误的原因，通过日志内容、报错的行数定位到发生bug的源代码，找出产生bug的具体原因帮助开发更好的修复bug
测试总结
最后呢，即便是 测试执行 完成了 ，也要进行一些自己的测试总结。这个总结不仅仅是给一个通过或者不通过的结论，还是测试阶段的一个很重要的过程。
与冒烟测试相反，它不是一个校验点，而是总结测试项目的整体情况、测试周期、缺陷分析、测试结果、测试风险等等问题。
项目上线有句俗话叫做 行百里者半九十 ，如果项目没有上线成功，那项目的意义无限约等于 0 。很多人都觉得 项目的上线 是 运维 的工作范畴，需要 测试人员 干什么？我们看下图：
实际上到了项目上线阶段，测试人员的角色仍然非常的重要。上线前要核实准备事项，发布顺序；上线中要做好线上验证测试；上线以后呢，要去跟踪线上的问题，如果发生问题还要进行迭代的修改问题与发布，保证完善的回归测试。同时将后续出现问题的这些点总结补充到测试用例、总结道自动化测试脚本代码当中，这样才是一个完整的项目流程。
当然，在项目流程里可能还会有些其他的任务，比如说自动化测试，在后面的章节在为大家进行详细的介绍。
其实在这种 敏捷的短迭代 下，很难在一个 迭代周期 中间进行自动化脚本的开发，所以更多的自动化工作可以放到在多个迭代的间隔期，在下一个迭代周期正式开始之前或者在下一个迭代周期的需求阶段，其实就是在测试人员不太繁忙的阶段去补充上一个迭代中需要自动化的部分。
还有一个和测试有关的部分，那就是监控。尤其是在大型系统上面，可能很多线上的问题很难在第一时间得到暴露，为了保障系统的稳定性和这些异常能够反馈给测试，所以很多时候我们希望能够增加一些监控与告警的机制去对接到邮箱、微信、钉钉等办公社交软件上，方便我们能够第一时间接收到这些异常的告警信息。
在很多公司，这种工作一般是由运维或者开发人员来完成的，但是在现在的一线互联网大厂，比如阿里，线上的监控也是测试工作的一部分，也便于阿里的测试能够在问题发生的第一时间得知，降低问题造成的影响。
所以一定要在第一时间去发现问题、解决问题，这就是监控所要解决的问题。
以上就是一个比较完整的测试流程，现在大家还会觉得测试很简单不需要技术，只需要 "点点点" 就能完成的么？ 实际上未来的测试、高级的测试对于技术的需求也很高，相比于开发人员来说。开发人员可能需要对某一种语言、某一个框架做到专精；而测试需要的则更广，更宽泛一些。
加油，未来的测试专家们！
