测试-八戒

每一年，IT互联网技术都在变，那2024年，需要具备哪些知识，才能让我们在软件测试行业里混得风生水起呢？我认为有以下十点：1、Linux必备知识Linux作为现在最流行的软件环境系统，一定需要掌握，目前的招聘要求都需要Linux能力。2、Shell脚本掌握shell脚本，包括shell基础与应用、shell逻辑控制、shell逻辑函数等。3、互联网程序原理自动化必由之路：前端开发基础知识以及互联网网络必备知识。4、MySQL数据库。

随着互联网、敏捷、CICD的流行，越来越多的传统测试经理的职位已经很少了，更多的是对测试开发、测试架构师、以及细分领域顶级专家的需求（如 安全测试、性能测试），我们很难成为全才，所以确定清楚自己所在的细分领域很重要。如下是我自己对“测试开发架构师”的理解，个人愚见，仅供参考：1）掌握开发语言技术，为自动化测试打好基础：编程语言：Java、python、js等，不光要学会如何使用这些语言，更重要的要学习源码，受益匪浅。数据库：mysql 、ES、oracle等。

测试岗位的入门者，我是这样想的，花尽可能少的时间在功能测试的执行上，而多花时间思考如何将手工的 case 转化为自动化的 case，并实现出来。测试最重要的其实是效率，问题是发现不完的，因此要提高发现问题的效率，让机器代替人做更多的事，而人要做的是创造性的事务，比如用例点的设计上，这是核心。

优秀测试和普通测试之间的差别在于测试人员如何思考：测试人员的测试设计选择，解释所观察到的能力，以及非常令人信服地分析描述这些现象的能力。然而，在实际工作中，我们更多的看到了测试人员在电脑前点点点，或者拿着手机在办公区域边走边操作着，看到他们的这些行为，自然而然的就觉得他们的工作其实很容易，很简单，因为可以很容易的模仿测试人员的外表，看到的他们的行为，但却很难理解到他们的思考方式。对于测试人员是否优秀恰恰不在于他们的工作表象，而在于他们的思考方式，那么优秀的测试人员和普通的测试人员思考方式到底有哪些不同呢。

近在做测试时，突然想到了这么个问题——在测试的过程中对某个功能想得越开，测试就完整，就越彻底！当然我们在产生与该功能相关的想象时，其中最关键的是不能脱离需求，不能脱离该软件本身；不然这样的测试就适得其反了。1、想到在该软件中与该功能相关的功能；2、想到在该软件中与该功能相似的功能；3、站在客户或者用户的角度想，自己会用的很舒服吗，习惯大多数人的使用吗？如果在该功能上添加某个细节会让客户或者用户使用的更顺手。可以给项目经理和做需求的讨论，以便确定(切记：不要私自做主)；

每个都应该有自己的“测试认知”，都应该得到“尊重”，论坛绝不是大牛们的一言堂。

每个都应该有自己的“测试认知”，都应该得到“尊重”，论坛绝不是大牛们的一言堂。

作为一枚从事通信行业测试的老年少女测试媛，入职离职也有两三次了。现在又在一家企业入职了。虽然心里也清楚离职和入职，无非也就是从一个公司的坑里跳出来，再跳到另外一个公司的坑里罢了，明明知道老东家的坑是填不完的了，也知道老东家的坑是有多大和多深。新东家则一无所知啦，但坑总是有的。前几天办入职了，跟上家公司一样，一进来没人做新人工作的交接和培训，就差是直接甩项目过来了。公司给我配了一台十年前的台式组装电脑，和一本打开就蓝屏的笔记本，台式电脑只有一个盘，硬盘总共的容量不超80G。

有没有感觉忙忙碌碌，一年又一年，却发现自己在测试的道路上好像没啥长进测试群、测开群、自动化群，没少加；文章、公众号、网盘的资源没少关注和搜集；大佬推荐的书没少买，书上落灰了都没碰过；每天过的很忙碌，但是依旧没有行动；为什么？多看，多写，多想，多问，多记。每天的工作任务自己划分好，每天规划好自己学习什么知识，看书，视频都可以，每天进步一点点。自动化的代码多上手练习，多写多模仿优秀的代码，慢慢自己理解透，变成自己的东西。

测试工程师不仅要有过硬的技术实力，也需要培养软实力。硬实力决定着起点是基础，软实力决定能够走的多快多远。在平常的工作中需要不断升级打怪，修炼并提高自身的软实力。特别是作为一名测试工程师，未来的转型方向很多，而软实力可以决定着转型方向。如转型做测试经理、项目管理、产品，甚至是QA。首先对软实力进行分类，一级分类是初级测试工程师必须具备的；二级分类是穿插在平时的工作中的，项目过程中少不了跟研发、产品、项目对项目过程中的需求、Bug、资源、进度等进行沟通协调；

总结提炼自然不必多说，苦练基本功嘛（嘿嘿）。多思考和探索的心态则是需要注意和培养的。要知道，虽然在平时，我们大多数时候可能更多的是在拧螺丝，但是我们一样也可以跳出来，看自己，多思考下自己工作的不足，多思考更多的去应对工作，解决工作中困难的方式。毕竟工作不是一道天堑，所以肯定存在条条大路指向最终的结果，多尝试和探索，或许就会有不一样的收获。久而久之，便可以形成自己的经验，授人以渔。

今天和一个网友讨论了一下关于互联网行业中测试的情况，希望能够了解现在的互联网行业主要的测试工作内容。小编根据以往的工作经历和经验情况，来做一个总结和整理。现在的岗位划分主要是分为两大类：测试工程师 和 测试开发工程师，从名字上可以看出，两者对于开发的占比会有明显的区别，理论上来说的话，测试工程师的开发占比会低一些，而测试开发工程师的开发占比会高一些。当然这是最理想的情况，至于为什么是最理想的情况，后面再来进行阐述。

有同学说，测试没价值，我们测试团队刚被拆散了。也有同学说，公司不重视测试，我觉得我们就是测试得太好了。哪天线上出个bug，老板们就知道测试的价值了。还有人给测试同学规划职业发展路径，就是不做测试，技术好的转行去做开发，能说会道的去做项目经理、产品经理。也有人说，测试应该左移右移。不过左移右移的，其实是测试的工作职责和意识，而不是测试人员的肉身。是这样的吗？用金融业常用的前-中-后台的说法来讲，一个测试人员的专业路径，大体上是这样的：1.成为高绩效员工。你测试，我放心。2.带领团队获得绩效。

最近转正，需要完成一个OA任务，其中有一项“你认为软件测试工程师岗位核心任务是什么？”要求写出三到五条，并简单地阐明。这个问题似乎很好回答，软件测试工程师不就是做测试？仅仅这样吗？从需求、原型着手，分析测试需求，编写测试用例，制定测试计划（策略），实施接口测试、集成测试、冒烟测试、系统测试，性能测试等，发现、定位缺陷，回归测试，做好测试结果分析，测试报告的编写，协助做好内部验收和外部验收等工作，等等。在测试过程中，及时反馈遇到的问题，识别影响测试进度、结果的风险，并积极参与问题的解决，风险的规避措施。

1、确定自己喜欢的是什么，钻研业务？钻研技术？2、业务测试具有一定的局限性，以后的工作可能基本限制在你说接触的业务知识里，跳槽什么的也类似这一个道理。其他不同的业务又需要重新去学习。但行行出状元，做好了就是某个业务的业务测试专家。3、是否喜欢研究技术，是否对代码敏感，学技术是个痛苦漫长的过程，需要坚持，更加需要承受打击。技术性的测试不受业务的影响，只看单位需要什么能力，而自己是否已经掌握、熟能生巧。用所学的技术发现问题，解决问题。提高产品质量、提高工作效率。

测试新人最容易出现此类思想，认为测试就应该发现所有bug，生产环境出现bug就是测试的锅。这种想法不能说完全错误，相反，包括很多不懂行的领导认为这相当正确。但我们要正确看待bug，已有大量论证说明测试是不能发现软件中所有bug的，而测试人员的职责是尽可能地规避、发现bug，控制项目风险。每次在线上遇到bug，我们应该去分析成因，以后如何去规避此类bug的出现，这才是测试员更应该做的。遇到bug不可怕，尤其作为新人，只要每次带着问题“如何从测试方面去规避此类bug？

测试工程师是谷歌产品团队中的一部分。他们拥护用户，提供全面的测试解决方案，在创造成功、可靠的产品中，发挥着关键作用。在谷歌，测试工程师不是手工工作者；他们是技术工作者，他们工作的重点是，促使产品更加卓越，提高工程生产率。简而言之，他们就是很 COOL。谷歌测试工程师前进的动力就是持续学习。他们从整体上理解软件的架构关系，代码覆盖率情况，及需要完成的测试内容。这些产品知识使他们成为测试专家。他们从项目初始阶段就与开发工程师密切合作，在功能实现之前，已经和开发讨论代码的。

相信大家都在网上看到过各种吐槽程序员不解风情的段子，开怀大笑之余深思，作为一个测试工程师又何尝不是如此？通常沟通技能成为横亘在测试工程师与其他合作部门之间的万丈鸿沟，也成为测试工程师成长的最大瓶颈。如此种种，某测试工程师已经哭晕在角落。面对这些或明或暗的丛林法则，我们怎样做到适者生存呢？一个优秀的游戏测试工程师要解决非常多的测试工作之外的困难，而沟通则是首要解决的。

如果有机会能够进入大厂工作，还是作为一个首选项。毕竟大厂对于测试的岗位划分比较详细，可以在工作中学到很多的东西，而且有了大厂的经验之后，跳槽去其他的公司也是一个很好的工作背景。当然不是说其它小公司不好，只是有机会的话，可以优先考虑而已。总之，每个工作岗位都有无法避免的“陷阱”，软件测试工作也是如此，最好的办法就是多来提升自己的能力，那么在未来的测试职业生涯中才会越来越好。

一谈到进阶，大部分文章，包括前面一些文章也会写到职级如何从初级、中级、高级，一直进阶到专家级，然后写上每个级别所需要的知识技能。然而，我们掌握了这些所谓初、中、高的知识和技能，真的就能成为测试专家了吗？对于这个问题，大部分人应该都带着疑惑或茫然。因为这些知识和技能随着时间是在不断变迁和迭代的，大家会发现高级测试工程师的知识技能要求今年是这样，明年是那样，最终充满迷茫：见鬼，我到底该如何进阶？所以，这里结合自身的职业发展和国外大咖的观点，探究下测试员的进阶之路。理论是基础，总有人忽视。

有没有觉得自己每天的工作千篇一律，每天一上班就盼着下班？一个月似乎能令自己开心的时间也就是发工资的那一天？自己的工作生活总感觉被人牵着走，兜兜转转过了一年又一年？测试员的工作性质决定了与重复、枯燥和乏味沾边，令人沮丧，而你一边抱怨着要改变一边又日复一日地重复上演。然而，一个有灵魂的测试员，也许如女生般一个月总有那么几天，但大部分时间都带着猎奇、探索的心态开展测试工作。面对一团乱麻的业务场景，通过我们抽丝剥茧般捋顺，通过测试努力让整个业务流秩序井然，这当然值得肯定。

架构师来自于建筑学，英文是Architect。建筑工程中的架构师是负责整体建筑的架构设计。因此从宏观上看，软件行业的架构师也类似，是在软件工程中架构师是一个团队的技术的领头者。主要工作内容除去对项目的整体设计和规划外，也会参与一些实际技术问题的解决和探讨，攻克技术难关，趟平技术线上的坑，使得工程在软件生命周期过程中平稳顺利完成。在研发领域有各式各样各司其职架构师，负责系统业务的业务架构师、负责基础设备和设施的基础设施架构师，负责公共组件和平台的中间件架构师。在测试领域只有一个，测试架构师。

2023年，IT行业出现空前的萧条，首先是年初一开始各大厂像着了魔似的不约而同的纷纷裁员、降薪、奖金包缩水，随之而来的是需求萎缩，HC减少或封锁等等。而有幸未被列入裁员名单的在职人员，庆幸之余也心有余悸，伴随着恐慌，说不定哪天裁员就轮到了自己。同时，由于人员的减少，手头上的工作的不断加重，又进入了另一种高压状态。那些被毕业或主动毕业的同学就要加入找工作的队伍，一时间找工作的队伍就像潮水一般汹涌而来，卷入了求职市场。招聘单位发出一个岗位瞬间收到的简历是往年的几倍，甚至几十倍。

从去年决定跳出舒适区，应聘大厂，截止到目前已经将近一年，值此之际，总结下自己近一年在大厂的经历。希望通过我的感触，能够帮助你们进一步了解大厂的测试工作。在大厂，人际关系非常重要！为什么要把它放在第一位，是因为在大厂里做测试的时候，所涉及的系统错综复杂，种类繁多，经常要进行上下游的联调测试。

常常在思考：同样背景，同样学历的人，为什么有的人路越走越宽，而有的人路越走越窄？不能简单归结于性格和运气，看似偶然实则必然。学习才能使我们内心强壮，充满自信。然而，不仅需要学习，还得善于学习，才能让我们自信常在。何为善于学习？这是一门大学问，简单来说就是有一套适合自己的高效学习方式方法，能去芜存菁，举一反三，并把知识转化为能力。在这十多年，我接触过几个从小学、初中就出来混社会，但做到公司副总裁，公司CEO，自主创业的同事和朋友。

首先自查，为什么自身&组织在团队中的地位没那么高、影响力没那么大。在一个项目团队中，每一个角色都是不可或缺的，若出现某一个角色地位比较低、不被信任，那这个角色就要检查自己了。从测试的角度来看，如果一个开发同学经常犯错，开发出来的程序bug率偏高、bug修了一遍又一遍修不好，那这个开发同学对测试的印象就会不好，甚至会被你拉入黑名单，遇到他的项目，你会格外的小心。从开发同学的角度来看，若测试同学经常漏测、同一类问题多次提bug、同一个原因提了多个bug等低级性错误，那这个测试同学对开发同学的印象就会不太好。

软件测试架构师在实际工作中，都做哪些事情呢？测试架构师会关注整个团队的技术提升，包括技术难题的攻关，团队遇到的技术难题，你能够做到 90% 的解决率。关注软件的可测试性，作为测试 leader、项目负责人或者测试架构师需要深入参与技术架构的选型，包括前期的概要设计，给出建议。比如说60～70人以上测试团队做接口测试，接口测试工具很多，我们需要做技术选型或二次开发，让团队使用统一的工具；比如说关于专项测试或者日常管理，我们可以做一个统一的平台实现可视化管理。

其实总体的方向就这么多，刚入行的时候机会多，可以多个角度去试试自己的可能性与感兴趣的方向，去挑选一个最适合自己的。互联网行业没有春秋大梦，需要转换自身价值换取的，努力在中前期去学习，去工作中探索实践，只有价值提升了，收入才能支撑年龄的增长。建议在前期，参加软考评测师，不说这个证书有没有用，在学习的过程中，你会补充很多知识，让你更了解测试。

1、互联网是否会持续恶化这个话题无法预测，很多人都说23年是发展经济的一年，很多人看好24年老美不加息后全球热钱就会加速流动，也有人说全球经济会持续衰退，这些都是猜测，我们无法预期，大叔希望经济持续向好，也觉得应该会比前3年稍微好一些。

软件测试架构师在实际工作中，都做哪些事情呢？测试架构师会关注整个团队的技术提升，包括技术难题的攻关，团队遇到的技术难题，你能够做到 90% 的解决率。关注软件的可测试性，作为测试 leader、项目负责人或者测试架构师需要深入参与技术架构的选型，包括前期的概要设计，给出建议。比如说60～70人以上测试团队做接口测试，接口测试工具很多，我们需要做技术选型或二次开发，让团队使用统一的工具；比如说关于专项测试或者日常管理，我们可以做一个统一的平台实现可视化管理。

提起H5性能测试，可能许多同学有所耳闻，但是不知道该如何对H5做性能测试，或者不知道H5应该关注哪些性能指标。今天我们就来看下，希望阅读本文后，能够有所了解。影响H5性能有这几个因素：网络带宽、DNS解析、服务器处理能力等。目前开源的免费的工具很多了，可以根据自己的需要来选用。WebPageTest是一个免费开源的在线性能评测工具；其使用真正的浏览器(IE和Chrome等)与真实的消费者连接速度，可以从全球多个地点运行免费网站速度测试；

本篇带你了解了日志在日常软件服务中常见的问题，以及对应的解决方法。切记，简单的东西 + 高并发 = 不简单！要对生产保持敬畏之心！

系统模型中相关的组件描述如下表所示：组件描述网络分发网络分发是高速发展的互联网时代常用的降低网络拥塞，快速响应用户请求的一种技术手段，最常用的网络分发就是CDN（Content Delivery Network，即内容分发网络），依靠部署在世界各地的边缘服务器，通过中心平台的负载均衡、源服务器内容分发、调度等功能模块，使世界各地用户就近获取所需内容，而不用每次都到中心平台的源服务器获取响应结果，比如南京的用户直接访问部署在南京的边缘服务器，而不需要访问部署在遥远的北方的北京的服务器Web服务器。

性能测试的结果需要进行细致的解读和分析，以便找出系统的瓶颈和问题，并提出改进建议。：响应时间是指系统处理请求所需的时间，通常以平均响应时间、最大响应时间、95%响应时间等指标来衡量。较长的响应时间可能意味着系统存在瓶颈或性能问题，需要进一步分析。：吞吐量是指系统在单位时间内处理的请求数量，通常以每秒请求数（QPS）来衡量。较低的吞吐量可能意味着系统存在瓶颈或性能问题，需要进一步分析。：错误率是指系统在处理请求时出现错误的比例，通常以百分比来衡量。

因为这里测试网站所采用为边下载边播放的方式。所以网络视频播放的性能主要由以下因素决定：视频码率，网络带宽，在线视频播放人数，视频帧率，关键帧等有关。因为我们视频帧率、关键帧固定，这里不做分析。码率会直接影响网络传输的性能。根据码率定义，视频码率=（视频文件大小/视频播放时间）*8。因为测试网站采用边下载边播放的方式，如果要使视频流畅播放，就应该下载速度大于每秒需要播放的视频文件大小（视频码率/8）。

如果你如我昨天谈到的客户一样，花费了24到48个小时用于每个负载测试环境的搭建，那你的测试及构建部署能力绝对是受限的。搭建一个仿真测试环境对于做好负载测试非常重要，同时它也是一个非常具有挑战性的任务，需要考虑技术解决、组织和安全问题等。本文可作为一个更快更有效部署负载测试环境的路线图，以便你更快的进行安装部署。是的，这作为第一条是有点尴尬，因为这很少行的通。你的生产环境同是做测试的理想环境，这没必要重复，里面包涵了经常被忽略的影响性能的后台进程和环境变量。

在计算并发用户数之前，需要先了解2个概念。：指的是现实系统中同时操作业务的用户，在性能测试工具中一般称为虚拟用户。并发用户这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。：每秒事务数，每秒钟系统能够处理的交易或事务的数量每秒事务数,是衡量系统性能的一个重要指标。而性能测试过程中，不是发起的并发用数越多，系统能够支撑从而说明性能就越好。

当应用实现了新功能后，准备发布版本前，必须进行性能测试以确定没有性能问题，内存使用情况便是其中必须要测试的性能之一。由于内存组成的复杂性，并没有简单通用的方法能够发现所有的内存问题。有时候因为问题比较明显，就真的发现了问题，但是对于较为成熟的软件，并不是那么容易发现内存问题。现在从内存测试流程、内存测试方法、内存占用的评判建议三个方面总结如下，希望能提升内存测试的有效性。1）：保证没有附加多余的Log和调试用组件。2）

响应、内存、CPU、FPS、GPU渲染、电量以及流量。响应时间和响应速度直接影响到用户的体验度，进而影响到产品的日活、留存。应用程序的响应时间包括安装、卸载、启动、切换各功能页面的耗时。1、冷启动：首次启动app的时间间隔（只是启动时间，不包括页面加载）2、热启动：非首次启动app的时间间隔（只是启动时间，不包括页面加载）3、完全启动：从启动到首页完全加载出来的时间间隔在项目中，主要测试关注点是冷启动，热启动。

如果你如我昨天谈到的客户一样，花费了24到48个小时用于每个负载测试环境的搭建，那你的测试及构建部署能力绝对是受限的。搭建一个仿真测试环境对于做好负载测试非常重要，同时它也是一个非常具有挑战性的任务，需要考虑技术解决、组织和安全问题等。本文可作为一个更快更有效部署负载测试环境的路线图，以便你更快的进行安装部署。是的，这作为第一条是有点尴尬，因为这很少行的通。你的生产环境同是做测试的理想环境，这没必要重复，里面包涵了经常被忽略的影响性能的后台进程和环境变量。