软件测试两年半的我，谈谈自己的理解

从2020年7月毕业，就成为一名测试仔。日子混了一鲲年，感觉需要好好梳理一下自己的职业道路了，回顾与总结下吧。

一、测试的定位

做事嘛，搞清楚自己的定位很重要。

要搞清楚自己的定位，就需要先了解整个流程，然后通过流程中的“相对位置”来确认自己的位置。

对于一个产品大团队而言，从头到尾总是大概需要经过这么一些角色。（在大小团队中某些岗位可能合并或者分立，但大致是这么一些要做的事情）

1、需求提出者（产品经理、策划或者客户）
2、产品实现者（架构人员、开发人员）
3、质量验证者（测试人员：测试设计、测试执行、自动化团队）
4、销售
5、客户
6、交付/运维团队

而我们的定位，就来自于我们与其他角色的关系。

1、测试与需求：

首先，产品经理通过市场风向的研究，想要实现某个功能来满足客户需要，形成竞争优势； 或者 接收客户对于产品某些问题的反馈，提出一个解决方案。

以上这些，落到产品团队中，最终就成为一个个 待做的需求。然后向研发团队讲解自己期望实现的功能。

测试工作内容，归根结底就是“保障质量”。

而质量，其实不仅仅来源于开发的实现代码，也来源于“需求合理性”。

以极端情况举例，有可能需求提出了画面要“五彩斑斓的黑”，或者期望在现实世界建造一栋某个特殊造型的房子，而那个房子，本身完全不符合力学结构。

这种情况下，质量问题的来源，并不在开发，而是更前一个环节的需求层面。

因为各种原因（如理解偏差、新人上手），需求存在错误这种事情，是时有发生的。而当一个需求本身是存在错误的，如果等到开发已经投入实现了大部分之后才发现，无论是将就着做下去，还是推翻重来浪费的人力都将巨大。

因此，最近有了一个概念叫做“测试左移”，所说的就是测试应该在更早的阶段（如需求阶段）去发现问题，从而规避问题。

如果我们能在需求阶段，就把问题提出来，就能让后面的环节更加顺利。

输入：

a、产品经理讲解客户目前的痛点是什么

b、产品经理讲解提出什么样的需求方案，觉得可以解决客户的痛点

输出：

a、根据经验，说出这样的需求方案可能有什么坑 （比如和已有的某些功能存在重复、或者存在冲突）

b、根据产品所描述方案，输出“用户使用场景性”的测试用例

对测试的能力要求：

a、熟悉产品已有的几乎所有功能，特别是责任田内的。以便于能在第一时间反应发现，和新需求可能产生关联的会是哪些功能。

b、带入客户视角的能力。（可以参考5W1H的方法去带入和思考）

2、测试与开发：

作为测试，沟通的最多的人，无疑还是开发。

通常一个测试，需要同时对接多个开发，前端、后端，甚至后端可能还需要区分配置面、运行面，对某些产品可能还需要区分“客户端和服务端”。

而测试的策略通常又需要区分“黑盒测试”与“白盒测试”。

当进行黑盒测试时，我们只需要考虑功能是否能用，里面的细节不关心，这种情况下，我们对于开发输入的依赖相对没有那么大。只需要根据需求的特性，罗列出所有的可能输入项类型，以及输入后的期望输出即可。

而很多场景下，黑盒测试往往是不够的，一些问题往往出现在奇奇怪怪的地方。

这个时候，我们就需要白盒测试了，白盒测试的第一步，首先测试就需要也先基本理解运行的逻辑。对于开发的“原理设计文档”我们需要能够去看懂，这样才能从设计文档中，分析出我们所需要的测试点。

输入：

a、原理设计文档（以及讲解和评审会议）

b、

输出：

a、提出开发设计文档中可能存在问题的点（比如边界、兼容性等 任何开发没有考虑到的点）

b、测试设计文档+测试用例+测试策略

c、可测试性工具需求提交

对测试的能力要求：

a、需要能理解开发文档，并从中拆解测试点

b、需要能从测试点组装成测试用例

c、需要识别测试过程中可能需要用的工具与环境

误区说明：传统的流程上来说，测试只是开发的下一道流程。但已经不太适用于当下，特别是敏捷当道的状态下，要求测试能提前识别问题，也是不能再等到开发什么都搞完再接手了，而是要 几乎并行 地去开展工作。

3、测试与测试：

测试内部也有许多的分工，大体分为 “测试设计人员”、“测试执行人员”、“自动化测试人员”几种角色。

测试设计人员产出的用例，最终则会成为执行人员和自动化人员的输入项。

对于测试设计的能力要求：所输出的用例是可执行的，不存在歧义的，且可以验证到功能是否存在问题的。

对于测试执行的能力要求：在用例正确的前提下，是可以严格执行用例步骤的；在用例可能存在错误的情况下，是能够进行一定程度识别的。

对于自动化测试的能力要求：是要能使用自动化方法实现用例内容，并在后续迭代中可以持续自动化执行的。

4、测试与销售：

测试过程中，比如性能测试、稳定性测试，通常会产出一些产品指标数据。

通过实打实的指标数据，销售则可以更好的与友商PK，进行更好的推广，从而卖得更好，大家分得更多。

5、测试与客户：

前有提到，测试在产品团队内部，就应该把自己代入‘客户’的角度来进行工作。

大部分时候通过 ‘将心比心’的方法能比较好的做到这件事，但还是偶尔陷入‘以己度人’的误区。

这种情况下，就只有通过‘测试右移“的方法来实现了。

通过产品发布后，持续关注客户的使用情况以及反馈情况，来了解是否有解决客户的问题。（比如 通过网上问题报单数量）

6、测试与运维

在测试过程中，通常会用到一些测试方法与问题排查技巧。测试如果有做一个比较好的整理汇总的话，这些信息应该是可以作为运维人员的一份参考手册的

二、测试的关注点

壹、功能测试

1、本身功能测试

就像改一个房子，你希望它能遮风挡雨，能有卧室可以睡觉，有厨房可以做饭，有厕所可以~

这些就是功能点，你需要测试床是不是舒服，厨房有没有燃气，厕所有没有水等等功能性。

2、关联功能测试

在同一个产品下，有时候很多东西都是息息相关的，功能与功能之间的依赖，进程与进程之间的依赖。

修改其中某处地方，可能不只要考虑功能本身，还需要考虑和他相关的功能。

举个栗子，就像是大家买房装修，如果有某一户人家把承重墙给拆了，其他楼层也会受到影响。

贰、性能测试

性能优化，说白了，就是想要用最少的资源去做最多的事情。

而性能测试的数据，则是需要作为性能优化是否到位的一个表现。

通常就是通过控制变量来测试。

1、控制固定资源量不变，看单位时间内程序处理工作的数量。（比如，固定CPU吃满情况下，测试平均每秒可以进行多少次 乘法运算。 ）

2、控制需处理的数量不变，看资源消耗与耗时。（比如，就固定做十万次乘法运算，耗时多久，过程中CPU、内存、磁盘IO、网路带宽等消耗多少）

叁、可靠性测试

可靠性测试说白了就是考验极端情况下，程序还能不能干活。

比如人类，在-100度的高温下，和-100低温下，就无法工作了。在30度情况下，人类能勉强工作；40度情况下，基本上无法进行劳作了。

程序也一样，CPU压力大的情况下，是否能正常进行。网络状态差的情况下，是否能正常进行。客户端程序电脑休眠之后打开是否还能正常使用。

比如 朱日和演习，蓝军的各种buff就是可靠性测试下的压力。

可靠性下还有一个重要的分支，就是可恢复性，就像大家使用手机，有些情况下手机就是可能会出现卡死的现象。这个时候，只要选择强制重启基本上就可以解决99.99%的问题。而如果可恢复性做得不好的话，那就可能导致手机出现一次故障，然后就直接变砖了，里面的各种信息也丢失了。

例举几种常见的可靠性：

进程可靠性：1、进程启动失败 2、进程退出 3、进程挂死 4、进程Z/D/T

文件可靠性：1、文件损坏/丢失 2、文件读写权限异常 3、存储空间不足 4、存储介质故障

数据可靠性：1、数据库异常 2、数据丢失 3、数据损坏 4、数据内容错误

网络可靠性：1、弱网 2、断网重连 3、数据包过大，数据截断

时间可靠性：1、系统时间跳变（向前跳变、向后跳变、跳变范围跨小时/天/月/年）

资源可靠性：1、CPU过载 2、内存过载 3、磁盘IO过载 4、磁盘空间满 5、文件句柄 6、网络端口被占用 7、网络连接过载 8、数据库连接过载等

设备可靠性：1、设备掉电重启 2、设备关机重启

肆、稳定性测试

有些产品，是需要持续运行不出错的。

有些隐藏的极深的问题，是一时半会无法暴露出来的。

例如：每分钟会执行一个定时任务，这个定时任务会产生一个1MB的文件，原则上这个文件在每分钟使用之后都会删除掉。而中间出现了bug，文件因为权限问题或其他问题删除失败了。这个时候如果只是测试了几分钟，可能根本就无法发现这个问题。但如果程序持续运行1天、甚至1周，问题的影响就十分巨大了。

伍、兼容性测试

如果是一个有页面可以在浏览器访问的应用， 则需要考虑各种浏览器类型的兼容，各种浏览器（chrome、Edge、Firefox、IE、360浏览器、QQ浏览器）都需要能兼容。

如果是安装到终端上的应用程序，则需要考虑系统类型，如win7、win10、winserver、mac11、mac12、Linux。

如果程序调用的东西涉及到指令集的层次，则还需要考虑如 intel、AMD等各种不同芯片的情况。

如果程序的传输，是涉及到需要加密的，则还需要考虑到加密算法的问题。国际密码标准 与 中国商用密码标准 都需要考虑兼容。

如果程序的逻辑，是与时间相关的， 则需要考虑时间跳变、时区兼容、12小时/24小时制的兼容

以上只是部分例子，有机会再好好整理一下。

陆、可运维性测试

大家的期许，肯定是完美的。

但现实世界是，产品总会有不够完美的地方，在一些特定的场景下，就是可能会产生问题。

这个时候，可运维性就十分重要的了。

当产品出了问题，当客户询问原因的时候。如果可运维性做得足够好，那可能问题就会在很短的时间，几分钟之内得到答案。

而如果可运维性做得极差，那么当产品在客户处出现问题，甚至可能出现无从下手的原因。

这里带入客户的角度模拟两个场景，

1、产品坏了，打电话去问客服，然后向对方描述现象，对方告诉你是什么什么原因导致的，需要怎么怎么样处理可能就好了。然后工程师上门，咔，好了

2、产品坏了，打电话去问客服，对方说，嗯~啊~这个~得具体现象具体分析。 然后工程师上门，查了半天没得结果，说还得回去看代码再研究一下。

如果你是客户，对于这两种现象会有怎么样的评价。

柒、安全性测试

当前的大环境下，安全性测试一般会有专业的安全团队来负责。但一般测试如果能稍微了解一些相关的概念，也是有所帮助的。

三、测试的道法术器势

最近发现，用“道”、“法”、“术”、“器”、“势”来拆分任何一个事情，都是很好用的。

道，是根本性的规律。通常是自然而然存在的。

法，是一般性的规律。一般是由人自己定的。

术，是具体的实践方法。

器，是工具。

势，是指当前的客观条件与形式。

"道不易，法简易，术常易"

韩非子说，抱法处势而用术。

测试的道

对于测试来说，道很简单，就是尽可能的发现bug。

竭尽所能地去保障产品的“质量”。

测试的法

能提前识别问题的测试左移方法

能持续运营问题的测试右移方法

分层测试的方法（UI、接口、后端等）

求全的冗余测试方法

求快的精准测试方法

求稳的最后一包全量测试方法

求快的分步增量测试方法

撒网捞bug之法

漏网之鱼追捕之法

突发问题补救之法

问题复盘之法

测试的术

1、自动化技术

2、接口测试技术

3、单元测试技术

4、搭建沟通桥梁的话术

测试的器

网络类：

wireshark抓包工具

nslookup

dig

nsupdate

ping

tracert

tcpdump

……

数据构造类：

POSTMAN

ApiFox

Fiddler

……

自动化类：

RF框架

selenium

……

资源观察类：

telegram

top命令

……

测试站点搭建：

Nginx

Apache

XAMPP

Bind9（DNS服务器）

……

以及各种自制脚本

测试的势

韩非子说，抱法处势而用术。

不知道大家有没有感觉，保障质量，这句话看着哪里都很对。

唯一的缺点就是，很虚。

而只有结合“势”，我们才能得到一个答案，团队希望投入多大的成本来保障质量，是否愿意为了质量而做出时间上的妥协。

对于求稳的产品，大家希望的是用尽全力保障质量，但凡发现有风险，就必须要解决后才能发布。

对于高速迭代的产品，大家的重点是“先推出去”，无论如何像让客户体验起来，用起来。

在这两种截然不同的“势”下，我们所需要遵从的“法”，使用的“术”，自然也是需要随之改变的。

总结

掌握了器，大抵我们就成为了一个合格的工具人。

掌握了术，干起活来我们基本上得心应手。

掌握了法，我们测试工作上所要做的事情，基本上达到了知其然且知其所以然。

掌握了道，才能在长时间的路上不走偏。

四、测试的时间管理

通常一个开发，同时可能就投入在一个需求之中。

通常一个测试，对接的是将近一个组的开发，可能有多个需求。

怎么安排时间？谁先谁后？时间分配

五、测试的未来

而早在多年前，AI用于测试的话题就存在了。

在AI飞速发展的今天，我们都见识到chatGPT的冰山一角。

大家纷纷讨论，哪些职业可能会被chatGPT家族所取代。

对新技术，我通常会思考两个问题。

1、挑战是什么？ta能替代我们的哪些能力？

2、机遇是什么？ta有哪些能力可以为我们所用？

AI+测试，是一个值得思考的方向，也可能是我接下来期望致力于的方向。

等有更多成体系的想法与点子，再为诸位抛转。

今天的分享就到此结束了， 如果文章对你有帮助，记得点赞，收藏，加关注。会不定期分享一些干货哦......

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入下方我们的测试交流群大家一起讨论交流学习。