。

日子混了一鲲年#xff0c;感觉需要好好梳理一下自己的职业道路了#xff0c;回顾与总结下吧。

一、测试的定位做事嘛#xff0c;搞清楚自己的定位很重要。

要搞清楚自己的定位谈谈自己的理解从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、需要识别测试过程中可能需要用的工具与环境误区说明传统的流程上来说测试只是开发的下一道流程。

但已经不太适用于当下特别是敏捷当道的状态下要求测试能提前识别问题也是不能再等到开发什么都搞完再接手了而是要

几乎并行

“测试设计人员”、“测试执行人员”、“自动化测试人员”几种角色。

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

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

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

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

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

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

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

大部分时候通过

‘将心比心’的方法能比较好的做到这件事但还是偶尔陷入‘以己度人’的误区。

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

通过产品发布后持续关注客户的使用情况以及反馈情况来了解是否有解决客户的问题。

比如

通过网上问题报单数量6、测试与运维在测试过程中通常会用到一些测试方法与问题排查技巧。

测试如果有做一个比较好的整理汇总的话这些信息应该是可以作为运维人员的一份参考手册的二、测试的关注点壹、功能测试1、本身功能测试就像改一个房子你希望它能遮风挡雨能有卧室可以睡觉有厨房可以做饭有厕所可以~这些就是功能点你需要测试床是不是舒服厨房有没有燃气厕所有没有水等等功能性。

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

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

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

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

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

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

1、控制固定资源量不变看单位时间内程序处理工作的数量。

比如固定CPU吃满情况下测试平均每秒可以进行多少次

2、控制需处理的数量不变看资源消耗与耗时。

比如就固定做十万次乘法运算耗时多久过程中CPU、内存、磁盘IO、网路带宽等消耗多少叁、可靠性测试可靠性测试说白了就是考验极端情况下程序还能不能干活。

比如人类在-100度的高温下和-100低温下就无法工作了。

在30度情况下人类能勉强工作40度情况下基本上无法进行劳作了。

程序也一样CPU压力大的情况下是否能正常进行。

网络状态差的情况下是否能正常进行。

客户端程序电脑休眠之后打开是否还能正常使用。

比如

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

可靠性下还有一个重要的分支就是可恢复性就像大家使用手机有些情况下手机就是可能会出现卡死的现象。

这个时候只要选择强制重启基本上就可以解决99.99%的问题。

而如果可恢复性做得不好的话那就可能导致手机出现一次故障然后就直接变砖了里面的各种信息也丢失了。

例举几种常见的可靠性进程可靠性1、进程启动失败

2、进程退出

3、数据包过大数据截断时间可靠性1、系统时间跳变向前跳变、向后跳变、跳变范围跨小时/天/月/年资源可靠性1、CPU过载

4、磁盘空间满

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抓包工具nslookupdignsupdatepingtracerttcpdump……数据构造类POSTMANApiFoxFiddler……自动化类RF框架selenium……资源观察类telegramtop命令……测试站点搭建NginxApacheXAMPPBind9DNS服务器……以及各种自制脚本测试的势韩非子说抱法处势而用术。

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

唯一的缺点就是很虚。

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

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

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

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

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

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

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

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

四、测试的时间管理通常一个开发同时可能就投入在一个需求之中。

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

怎么安排时间谁先谁后时间分配五、测试的未来而早在多年前AI用于测试的话题就存在了。

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

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

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

1、挑战是什么ta能替代我们的哪些能力2、机遇是什么ta有哪些能力可以为我们所用AI测试是一个值得思考的方向也可能是我接下来期望致力于的方向。

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

今天的分享就到此结束了

如果文章对你有帮助记得点赞收藏加关注。

会不定期分享一些干货哦......最后感谢每一个认真阅读我文章的人看着粉丝一路的上涨和关注礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。

希望对大家有所帮助……如果你不想再体验一次自学时找不到资料没人解答问题坚持几天便放弃的感受的话可以加入下方我们的测试交流群大家一起讨论交流学习。