软件测试两年半的我，谈谈本身的理解

软件测试两年半的我，谈谈本身的理解
从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+测试，是一个值得思索的方向，也可能是我接下来盼望致力于的方向。
等有更多成体系的想法与点子，再为诸位抛转。
末了： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们假如需要可以自行免费领取【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战堆栈，这个堆栈也陪伴上万个测试工程师们走过最困难的旅程，希望也能帮助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。