〖Python接口自动化测试实战篇①〗- 自动化测试基础扫盲及项目的生命周期详述

前言：

✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 🐶哈士奇🐶 ，致力于用白话讲解技术知识的博主 ✌

🏆 CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主 🏆

📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀

💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬

🔥 如果感觉博主的文章还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主哦

📕 系列专栏：

🇨🇳 Python全栈系列 - [更新中]【 本文在该系列】

🍎 Python零基础入门篇

🍎 Python语法进阶篇

🍎 Python自动化办公篇

🍎 Python自动化测试实战篇

👋 网安之路系列

​ 🍋 网安之路踩坑篇

​ 🍋 网安知识扫盲篇

​ 🍋 Vulhub 漏洞复现篇

​ 🍋 Shell脚本编程篇

​ 🍋 Web攻防篇9月3日停止更新，转战先知等安全社区

​ 🍋 渗透工具使用集锦9月3日停止更新,转战先知等安全社区

​ ⭐️ 点点点工程师系列

​ 🍹 测试神器 - Charles 篇

​ 🍹 测试神器 - Fiddler 篇

​ 🍹 测试神器 - Jmeter 篇

​ 🍹 自动化 - RobotFrameWork 系列

​ 🍹 自动化 - 基于 JAVA 实现的WEB端UI自动化

🍹 自动化 - 基于 MonkeyRunner 实现的APP端UI自动化

文章目录

🐳 软件测试的意义与自动化测试实战篇介绍🐳 项目的生命周期🐬 项目的瀑布型生命周期🐬 项目的迭代型生命周期🐬 项目中的增量型生命周期🐬 项目中的适应型生命周期🐳 手工测试工程师现状

大家好，从今天开始呢我们将进入到 Python自动化测试实战篇章的学习。在这一篇章主要的学习内容是与软件测试有关，该领域与 Python 全栈编程是一个完全不同的角度。该篇章的重点在于测试、模拟人工操作这样的一个角度。该篇章主要涉及到三个方向：WEB端UI自动化、API接口自动化、Appium移动端自动化。小伙伴们加油呀。

🐳 软件测试的意义与自动化测试实战篇介绍

无论是大型的还是小型的项目，或者大大小小的技术团队，一般都离不开软件测试。软件测试在 IT 行业似乎一直是一个比较特殊的领域，为什么这么说，因为 “它” 既平凡又很特殊。软件测试看起来不需要什么高大上的技术（俗称 ‘点点点’ 工程师、或者 ‘背锅侠’），但是要想有一定的长足发展却又依赖着技术；尽管包含着各种误解的眼光，但是却又在互联网软件行业里实实在在的成长。

随着互联网的发展，还有移动互联的到来。快速的迭代、敏捷，测试人员也变得越来越重要，只会功能测试（也就是点点点）是无法适应行业变化需求的，长足的发展也是不够的，因为已经无法满足时代快速发展的要求，所以测试人员也需要不停的磨砺自身、不断的提高自己的测试技能、测试方法、测试效率… 这些也需要测试人员具备编程能力的技术支撑。

所以有句话说得好，那些喜欢创造世界的人去做了开发工程师、而想要拯救世界的人都去做了测试工程师。就像下图中画的那样，如果你想拯救世界，想要发现产品上的缺陷；愿意用自身的技术再软件测试领域大杀四方，那么在 Python自动化测试实战篇章 我们会从零开始，彻底的走进软件测试、测试开发的领域。

所以在这一阶段我们会从软件测试的一些基础开始学习，逐步深入到测试开发的核心；包括API接口测试、WEB-UI自动化测试、APP移动端应用自动化测试。

该阶段会以零基础的方式从最基本的测试脚本开始，逐步的让大家认识到自动化测试框架这样一片新的天地。

可能大家也会问，既然是 Python自动化测试实战篇章 ，那么究竟有什么样的 “实战” 呢？该章节是一以贯之的，我们会应用 “某旅游网” 从零开始设计测试框架让接口能够 “飘动” 起来，让前端页面能够更加自主自动的飞一会儿，同时也会使用大家使用的很广泛的 “百度APP” 来进行 “APP自动化” 的实战演练。

虽然都是自动化测试、都是测试开发，但是APP的自动化与接口自动化、WEB自动化还是有很大的区别的。

这就是该篇章具体的内容，再细节的就等到后面的章节我们在详细的一一开始学习吧。

🐳 项目的生命周期

接下来我们就聊一聊一个产品或者一个项目从开发到上线的一个完整的生命周期是怎么样的。说的通俗一点，就好比一个网站已经做好了，到底怎么样把它推上线。面向客户呢？

另一方面通过这方面好好了解一下软件测试到底是什么？

试想一下，项目上线之前需要做哪些工作？换句话说，当我们的一个项目开发完成之后就可以直接上线面向客户交付使用了么？答案当然是否定的，刚刚开发完成的项目距离上线还有一段的距离。

接下来我们就看看一个完整项目的生命周期。

🐬 项目的瀑布型生命周期

我们一直在强调着一个词生命周期，这个词听起来非常的专业、也略微的高大上，实际上也没有那么的深奥。以现实生活中的场景举例，花开花落这是花的生命周期，种瓜的瓜、种豆得豆这又是 西瓜（随便什么瓜）与大豆的生命周期。

简而言之，当我们说到什么东西的生命周期的时候，就是在说其所谓的一生。而项目的生命周期（也就是项目的一生）比较特殊，不同的项目也会有属于各自的不同的变化。（就像不同的人一样）

如果将其进行一个归类的话，可以简单的分成瀑布式、迭代式、增量型与适应型这几类。见下图：

瀑布型生命周期：分析 —> 计划 —> 设计 —> 构建 —> 测试 —> 部署 。这就是项目的瀑布形式的生命周期，也是一种传统的项目周期。

敏捷型项目周期：这是一种现在比较流行的项目周期构建方式，在一个很大的项目里，分成多个子迭代的子项目。每个迭代中都需要重复一段像瀑布型的生命周期。

从传统的瀑布式开发到如今的敏捷迭代，其中经历了很曲折的发展过程。在我刚从事互联网行业的时候，基本上所有的项目都是这种 “瀑布型周期的项目” ；而现在，“敏捷” 的这种方式充斥这整个互联网行业的绝大部分公司。阿里、京东、腾讯、头条、拼多多等一线大厂全部都是敏捷式的项目周期。

可能到了这里，大家还不是很能够理解这两种大方式下的差异。我们继续深入且通俗的来解读一下。

首先有一种生命周期类型叫做预测型生命周期，也就是刚刚所说的瀑布式模型，它的特点就是按部就班的实施。从需求到完成，一气呵成。适用于那些从早期就能够确定范围、确定时间、确定成本的项目。

举个例子：某公司今年营收不错，准备搞一个大型的年会。为了能够让今年的年会完美的举办并落幕，提前半年就开始了准备。并且还请了某知名餐厅五星级的大厨来负责年会的晚宴，在该场景下：晚宴的菜单是制定好的、参加的人数是定好的、举办的时间也是确定好的。该五星级大厨，只需要根据菜单在举办年会的时间把一道道美味菜肴送上餐桌就可以了。就像下图这样，从菜谱的制定到菜品的摆盘上桌就可以了。

面对这样的需求明确、时间明确、成本明确的项目，最适合的就是预测型生命周期。

🐬 项目的迭代型生命周期

除了上文这样传统的项目，现有的互联网项目主要分成了三大种，第一种就是迭代型生命周期。从迭代型的标准来看，该类型的项目比较适用于需要通过一系列重复的循环的活动来渐进地增加产品的质量的项目。

说简单一点，就是一个项目或者一个模块上线使用了。比如说像 “微信” ，做一个新的功能模块，但是经过灰度测试，用户反馈不是太好，这个时候就需要这种迭代型生命周期方式了。

就好比上文所举例的五星级大厨准备晚宴的场景，晚宴上有人反馈说某道菜品不是特别的好需要大厨改善一下。那么大厨需要做什么呢？他需要首先针对菜品进行调味、优化之后再出菜、找一些客人试吃、得到试吃的反馈之后；再继续做一轮调味、出菜、试吃、反馈…最终达到改进这道菜令客人满意的目的。如下图：

​

以现在常用的 “微信” 举例，在当初 “微信” 刚刚上线的时候，来自用户的反馈也是很差的。当时也是 “QQ” 正如日中天的时候，大家都觉得 “微信” 的功能也不是很强，使用上也不是很方便，为什么要用这玩意儿。（有兴趣的小伙伴可以去各大应用平台上关于微信最早的评论会发现一水的都是差评）就是在这样的差评中，“微信” 在一次又一次不停的迭代、不停的修改中才完善成了现在这个样子。当然了，除了这样的迭代，微信也在不断的推出新功能：比如抢红包、拍一拍、视频号等… 这种新增的功能也就是接下来我们要介绍的增量型生命周期。

🐬 项目中的增量型生命周期

增量型生命周期就非常适用于需要进行拆分、需要分步实施，最终达到项目目标的这一类项目。

依然以上文的五星级大厨来举例，比如说大领导要求大厨在年会上做一道 “开水白菜” (小科普：真有这道菜，川菜十大名菜之一，而且是国宴必备的一道菜)，但是大厨不会做，所以大厨只能现学现做现调味、试吃、反馈；再调味、再… 最终目的是为了增量叠加，在年会餐桌能够摆上这道菜。

🐬 项目中的适应型生命周期

刚刚说的迭代型生命周期与增量型生命周期确实有些复杂了，但是它们确实能够更好的满足项目的实际需求。 它们都有一个共同的特色，就是本身能够预知需求的前提之下，就是知道需要干什么。比如说迭代型，知道最终的目标是什么 —> 就是优化产品，把现有功能优化到最完美，追求用户的极致体验；而增量型是什么？就是现在有十个功能，需要一个一个的去推动、去上线。

和这两个相比较而言，接下来所要介绍的适应型生命周期就显得有些可怕了，就是现在最火最流行的敏捷。

在现在实际的互联网公司当中最多的就是 “敏捷” 这样的生命周期，还是以上文的五星级大厨来举例子。

比如说，这个大厨遇到了一个外国客户。这个老外就说一句我要吃的。大厨做了份蛋炒饭、老外不满意；再做一个汉堡，老外呢，说还凑合、但是缺少中国元素；于是大厨给他在汉堡里面夹了个臭豆腐... 老外满意了。

从大厨的这个举例我们可以看出来，这种不停的去尝试做各种菜式的方法就好比是适应型生命周期：

适应型生命周期：更多的是去响应变化，对项目的钱途和范围并不是十分的明确。这个时候就需要将项目划分为若干个短小的迭代周期，在每个周期都产出可验证的交付物。以此去获取用户的反馈，从而最终产出用户需要的结果。

无论是如何。每一个迭代和小的周期，项目的过程一定是下图这样的。从需求到设计到编码到测试再到交付、运行、维护，这几乎是所有项目的通用的一个生命周期。也是上文我们所提到的完成编码的开发到上线的一个距离所在。

距离体现在哪里？那就是项目迭代的过程里永远都离不开的两个字 测试 。大家说到 “测试” 两个字往往会有一种误解，一种对于 “测试” 的刻板印象。那就是点点点、没前途（没钱途）、没什么技术、能力不强，唯一的好处可能就是 妹子多 。

实际上软件测试在项目的进程里，是十分重要而且必要的。虽然软件测试的入门门槛不太高，但是实际上它的发展方向是非常广泛的。大家理解中的那种点点点的手工测试工程师，实际上在大厂大部分的测试工程师已经不再局限于手工测试了，他们都拥有着不弱于开发的代码能力。他们会进行自动化测试、会开发一些小工具，这种现在最流行的一种叫法我们叫做测试开发工程师，当然了在待遇方面也丝毫不弱于开发工程师。

🐳 手工测试工程师现状

从《中国软件测试从业人员调查报告》，在软件项目的测试环节，手工测试占到 89%，相对开发来说，手工测试的门槛低，薪资普遍较低于开发人员，所要求的知识面虽然有一定广度，但缺乏深度。

因为手工测试门槛不高，使得大量的毕业生、甚至是非专业人员涌入这个行业，从而加剧了这个行业的激烈竞争。对于工作几年仍处于手工测试的人员来说，都会有强烈的危机感。由于工作的技术含量不高，薪资的涨幅遇到瓶颈，另一方面受到新进入者的威胁，公司花 8K 招来的人能够胜任手工测试工作，那么就不会花 18K 招聘人做同样的工作。

因此，从自身的发展来说，手工测试人员非常需要通过自动化技术来增加自己有竞争力，所以就职业发展方向而言，成为一名测试开发工程师是一个非常不错的选择。