Part_1测试基础（上）

一.碎碎念

上一次发博客还是2021.4.27；断更三年，不愧是我！三年之期已到...

因为某些原因最近有跳槽的想法，所以在复习之前写的一些笔记，但是总觉得复习的效率和成果都不太好，于是又捡起了写博客这个方法，也就有了这个分类专栏（2024.9.18 杭州 阴）；

这个专栏会从软件测试基础开始，我在工作中常用的测试工具和测试方法也会涉及到，没有在工作中实际应用到的一些技术也会写，自动化会有的，持续集成也会有的，flag先立起来！冲！！

（测试入门必看啊各位未来的QA大佬们！！！）

二.软件测试基础

注：本章为测试基础章，为避免大量的文字导致阅读起来可能会有点枯燥，我会尽量和图片结合并加入一些自己的理解，也希望其他测试同学看了之后，也有自己的理解，ok，开始~

1.软件测试的定义

Q：什么是软件测试呢？

A：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估

部署环境，执行测试，反馈问题，提交报告；

这就是软件测试，后续的比如docker部署测试环境、UI自动化、Api自动化、Jmeter压测、Bug管理平台的使用、测试报告的生成等，我认为这些都是在这个定义上的扩展，让其变得更好更高效，仅此而已。

早些年，开发就是测试，但随着软件架构逐渐复杂，就有了专门的测试/QA(Quality Assurance)。

而软件测试的对象，也不再局限于软件/程序，到现在的，包括代码逻辑、操作手册、需求文档、数据等都成为了测试人员需要关注的东西。

想一想，测试对象为数据时，比如某宝app的所有商品，测试人员需要关注哪些重点？

2.软件测试的分类

按照不同的分类标准，软件测试有不同的类别：

a.按照阶段划分

这里的阶段如果按照测试阶段理解不太好记，但如果是按照开发程序的思路来理解，就会很清晰明了：（防止有同学还没有python基础，这里就先写的抽象一点）

上图我们从右往左看，从最开始的几行代码构成一个我们能测试的最小单元（类、函数）；针对这些最小单元的测试，那自然就叫单元测试；

这些一个个单元我们把它们集成起来，测试这些“集合体”，给它个名字那就叫集成测试；

而我们最后展现给用户的，是这些“集合体”再次整合，形成的系统，对该系统的测试那就叫它系统测试吧；

经过了QA的测试，到最后交付给用户之前一般还会有内测，就像游戏发布那样，也叫aplha测试，属于最后验收阶段，所以叫它验收测试。

测试分类	重点
单元测试	最小的可测试的单元，可以是一个函数、一个类
集成测试	在单元测试的基础上（不然会受阻于单元测试的问题）将所有单元的“集成体”，可以是某个模块、某个子系统进行测试；单元与单元之间的“连接”没问题
系统测试	整个系统的测试，主要根据需求进行测试
验收测试	检查软件是否符合用户的需求的测试阿尔法测试，一般由内部发起，也叫内测。贝塔测试，把产品交给用户进行体验测试，也叫公测

b.按照状态划分

状态就是静态和动态；

比较好理解，静态测试就是不用运行程序的测试；比如代码走查，SQL检查等。

那么动态测试就是需要运行程序的测试。

c.按照测试执行划分

按照测试执行的划分，可以分为冒烟测试、探索测试、随机测试、回归测试；

测试分类	重点
冒烟测试	测试软件的主要功能是否正常，是否具备可测试的条件
探索测试	根据自身经验，不看用例也不刻意与需求进行核对，快速验证产品功能
随机测试	完全随机的测试，任意发挥，往往会发现出乎意外的问题
回归测试	一轮测试结束以后，再进行快速的重复一轮测试。 主要回归策略有全量回归、新增功能回归、已发现的bug的回归

表情包分割...还有按照技术划分为功能测试、性能测试、安全性测试；

是否清楚代码逻辑划分为黑盒测试、白盒测试、灰盒测试。

三.软件测试基本原则

在开始对一个项目进行测试时，有一些基本原则是需要QA遵守的；有些原则可以帮助我们更快地发现问题，有些原则可以帮助我们更全得发现问题；

1.基于用户角度发现问题

产品最后都是要给用户用的；QA不仅要从自身角度出发进行测试，从用户角度看问题也很重要，有时候，一个按钮的边界范围、一个弹窗的逻辑、甚至一个css样式可能就会影响用户的去留；

2.越早介入测试越好

测试并不是在某个需求开发完或者开发的差不多时才介入测试，测试最早介入测试的时间是需求评审阶段（甚至是项目初创阶段），此时测试对象为需求文档、产品手册、UI设计等；在开发之前就熟悉需求，熟悉完需求之后就可以着手准备基本的测试用例。

3.二八原则

80%的bug，往往集中在20%的功能模块上（这是我跟了某勾课程学到的，个人认为蛮正确）；

4.反向测试用例

不仅要有正向的测试用例，还要有反向的测试用例；即考虑异常情况。

你还知道哪些原则或者约定俗成的规则嘞？

四.软件开发模型

最后讲一下软件开发模型吧；

这一点在工作中QA可能关注得不太多，但我切实遇到过这方面的问题；（写在文末吧，希望大家看了之后能避开这个坑）

1.边做边改

适合一些小项目，当场做，当场改；

优点：贴合用户需求，用户针对某一产品提出功能上的需求或者缺陷，开发人员立马进行针对性的修改，主打一个随心所欲，开发觉得合理就可以改，快；

缺点：没有标准流程、没有需求文档、甚至没有测试...

2.瀑布模型

顾名思义，像一条从高到低的河流，中间有多段瀑布一般：

流程一步一步往下推行，当前流程严格依赖上一流程。

优点：有管理，结构层次非常清晰；

缺点：测试介入晚，测试进度没有到100%时，和0没有差别；

3.快速原型

在瀑布模型的基础上，加了一个“构造原型”，快速解决前期需求不明确的问题，可以理解为，给用户看一下“样板间”。

优点：优化了瀑布模型，前期需求不一致导致的问题

缺点：测试介入得还是偏晚

4.螺旋模型

 螺旋模型将瀑布模型和快速模型结合，增加了风险分析，特别适合大型复杂的系统；

优点：解决了瀑布模型需求不明的问题，解决了测试介入晚的问题，将开发过程拆分为更小的单元，用户每阶段都可以参与产品体验；

缺点：需要经验更丰富的风险评估人员，迭代次数很多；

5.敏捷模型

a.敏捷开发框架Scrum流程图：

 

首先确定产品需求列表；根据需求列表，从中挑选出作为本次迭代完成的目标，目标周期1~4周；细化这些需求任务交由开发，每日立会汇报完成情况；做到每日集成；做完选出的需求之后进行会议演示；最后总结，提出优化加入下一轮需求列表中。

优点：以人为本易于开发和测试；

缺点：如果在开发过程中有人员更迭会导致交接困难；对测试和开发要求高；

b.XP极限编程:

 

把复杂的开发过程分为一个个小周期，分三个维度进行管理。

最里层：编程方法

• 用最简单的方法设计软件
• 小组编程：互相评审
• 测试驱动开发：先写测试代码，再写能测试通过的代码
• 重构：增强程序可复用性

中间层：小组实践

• 代码集体所有：每个人对代码负责，每个人都能修改代码
• 编码标准：遵循统一的标准
• 稳定高速的步伐：保持稳定高速的工作节奏
• 隐喻：用形象的比喻描述产品的特点
• 持续集成：每天把代码集成为产品，快速发现问题

最外层：交付与管理

• 小规模发布：1-3周发布一个版本，这个产品能够直接使用和验证
• 用户测试：用户参与测试
• 完整团队：围绕用户进行工作
• 计划Game：总结与计划

在开发模型这里讲下DevOps吧，最近的一个项目就是使用的敏捷开放框架Scrum；在DevOps中一般都会使用Scrum来推动持续开发；

 DevOps即开发、QA、运维整合协作，加速软件交付周期，同时保持高水准的质量和稳定性；

 还记不记得最开始我说软件测试的定义时，提到的一个观点，“后续的各类技术就是在该定义上的扩展”；比如后面会讲到的Jenkins做持续集成和交付，就是让上面这个流程变得更高效；

五.软件测试模型

篇幅原因，这里我就写一个双W模型吧；

其它的这里不多赘述，我在实际项目中QA团队使用的测试模型都是在双W模型上加以改动居多。

ok到这里测试基础的上半篇就差不多了，项目管理在本系列中不会被提到，如果是从立项开始的话，那还是有必要去了解一下的，或者项目在此之前没有其他QA。

文末，讲一下我遇到的坑点以及为什么说可以让各位避免吧；对，没错，我就是XXX Web项目在这之前没有其他QA的那个第一个呆瓜QA；当时已经是稳定两周一迭代，没有测试流程，没有测试用例，没有任何关于测试的文档。

如果有遇到这种情况的同学，组里还没有其他QA的话（是的，我们项目组就我一个QA）；在明确当前项目组的开发模型之后，比如我目前的项目组，敏捷开发模型；

亲身经历！！！

周三入职，熟悉业务，然后第二周就跟迭代了...当周直接测，新增了一个支付方式... 从那之后，我好像陷入了死循环（敏捷开发模型中的中间那块周迭代）；

现在回想起来，如果你也遇到这种情况，首先，严格按照开发模式来，测试在每个环节该做什么，就做什么，参与需求评审，写用例，再进入迭代圈执行测试，完善用例继续执行，再到后面的复盘，千万千万不要步我的后路，因为每次迭代需求和bug繁多，而陷入迭代怪圈。哪怕来不及测这次的需求和bug，那也不是你的责任（就一个QA，排这么多来不及测怪我咯）

历历在目，当时一起共事的产品的一句话，“一个人，一次迭代，二十多个需求，三十多个bug，你还是人吗？”

下篇会讲下用例设计，然后Part_2开始Linux吧（已经在草稿箱了，如此美妙的开局），以上！