谨以此文纪念我的第一份工作。基于保密需要，有各种省略
我都在做些什么？
我是做的产品通信协议这一块的测试工作，具体一点的就是和各种仪表打交道，在看护某些特性，保障产品质量的基础上，进一步做自动化提升效率。
这里的仪表指的是内场模拟基站小区信号啥的，与之相对的还有外场，那就是真的拿着手机等设备在真实环境下跑了，总之挺苦逼的。而仪表这个词听着挺low，实际上还蛮金贵的，总资产价值怕不是有9位数。
那么，我平时具体都干些什么呢？
- 首先，先说一下首要的工作目标。
我这边是靠产品吃饭的，产品没出去可以怼着开发各种diao，可要是出厂有些问题，那就是测试的锅了。而这边产品的测试大致有两种分法。- 一是某些通用的最最基础的功能，即使是不同运营商也在大体上一致，遵守协议规范。这些通信方面被“专家”分了很多特性，与之相对的对应到每个人有每个人的责任田，诸如IMS、搜网、功耗等等。 接下来来了某款产品测就是了，总之内外场协调，力保不出事故。
- 二是针对某些重要的运营商，它有特殊的个性化需求，并且要求产品在入网前需要通过它或它指定的第三方机构的测试。这种情况下，视市场的重要程度会投入相当之多的人力，特殊时期的优先级可以长期占据top1。
- 这两者归到我这儿，就是用仪器进行各种测试，在产品出去之前及时发现问题，并把问题描述、分析以及数据丢给开发，让开发解决。确保特性不出问题，或者在运营商入网认证的时候不捅娄子了。量化下来的绩效指标，那就是事故率低（发现的问题多），测试效率高（无效测试少、测试出来的“非问题”少）， 测试周期短（人力、设备等资源调度以及自动化），人力投入少（自动化率高）
都有啥好吐槽的？
- 长期不受重视
- 协议测试这个东西，有很多是没有技术含量的体力活儿，因而有很大一部分交给了合作方。
- 而体力活儿啥意思？
先前说的内外场测试，内场先不说，外场到处拿着手机逛，跑“场景”，这个应该很好体会。内场也差不多，只不过换成了操作仪表来模拟。
但内外场终究是不同的，外场只需要采集数据，抓取log；而内场还要在此基础上分析，确保模拟的小区行为与协议或者预期一致，信号良好且不受干扰、操控手机的时机或时序正确等等，这是需要一定行业经验和通信基础的。从这个角度上来说，我对没有技术含量的体力活儿这个论断不太认同。 当然，在理想情况下，只要产品测试不出问题，或者能够100%保证测试结果的可靠性，这确实是个体力活。但这个可靠性怎么说呢？某款产品某特性给了50%的非问题指标，非问题是啥，就是开发分析定位下来不是产品的问题。意思就是你测试提出问题给开发去解，到最后只要有一半真正的问题就合格了。这还是测试这边已经过滤过一遍的结果。
也有过要求90%的情况，但那只是追求面上好看，说到底还是加班加点多次反复验证测试结果，私底下协调开发分析，实际情况还是那回事儿。 但这种话，抱怨可以，说是没法说的。毕竟在这边儿，加班是不算人力的。 - 为啥我要扯这么远呢？因为测试这个工作，并不止我们这一个地域，是很多地域一起搞的。其它地方都是特性负责人一肩挑；但因为新产品新特性先放在我们这儿，兼之仪表最多最全，这边便建了个仪表能力中心，架构有所变化，成了合作方-仪表负责人-特性负责人。我所做的工作，就是中间那个。也就是说，在领导眼中，也就自动化有点含量，其它外包都能干了。
- 安排也确实照这个思路来的，原来这一块除了我还算是有两个正式员工，一个负责合作方的管理还有项目，另一个针对具体场景需求在仪表上编写脚本进行实现。后来慢慢的前者项目管理转移给合作方，后者投到5G那边，到我走后，也就没有正式员工了。
- （某部仪表侧）技术积累约等于无
- 这边的外包人员流动性很大，我刚来的时候，认识的二十来号人，到一年后，已经基本上都离开，只剩一个了。为什么说这个，因为心里苦哦。
最开始的时候没有正式员工带啊，也没有系统性的资料，是跟着外包员工熟悉各种仪表，而且只是操作性的东西，具体的通信协议也没个底。后来还是自己琢磨+实战跟着开发混才明白个一二。而且跟过几个师傅，除了两个合作方员工，更多的还是跟着厂家的技术支持在学。听人说xx的甲方真是呵呵哒，各种操作反复问反复教。 这还不算什么，关键我应届就职的一年多（刨去入职培训你懂的）前前后后可以算是带过八个徒弟，能力先不说，特么这还不算绩效，无法写进PBC也没法统入官方数据，这些个人力就有点坑了。而这些仪表少说也要几个星期来熟悉，但是项目交付也就至多一两周的样子，这也是非问题比例没法下去的一个原因。
- 这边的外包人员流动性很大，我刚来的时候，认识的二十来号人，到一年后，已经基本上都离开，只剩一个了。为什么说这个，因为心里苦哦。
- 任务计划不切实际
- 测试这边排计划都很激进，有很多都是拍脑袋决定的。这个怎么说呢？
-
比如，某些新特性或新市场，有些东西开发那边还没有合入，这边就已经开测了，这就是所谓的“测试驱动开发”了。其实到最后还是得再测一遍，但这已经是计划节点之后的事情了，在这之前已经完成了一轮的测试。
其实这还没什么，虽然浪费了测试的资源，但毕竟从KPI的角度来说还增加了测试方面的问题发现率。但没有这么好的事啊，开发那边不干哦，于是有了一大堆的扯皮的破事。这个版本要测哪些，那个版本哪些不测，但协议是个整体的东西哪那么容易扯得清，而且都整的是自己那一亩三分地，真要说全懂的专家估计也没几个，于是各种开会拉通。
这个还好，毕竟在问题抛出去之前和开发沟通一下就好了。但问题是这种问题回归复测是不占多少计划时间的，因为都已经测完一轮了，又会有其它产品过来，你跟别人说这个怕是不合适，也没人会理解。 - 再比如，上个产品测试周期xx天，那么这个产品要求自动化提升xx%，测试周期缩短xx；要是个新的东西，那就得真的是拍脑袋咯。当然，从某个角度上来说，这样子做理所当然，没毛病。
但是打野心里苦啊，没人带只能一点点摸索熟悉仪表。而且自动化其实已经到了一个瓶颈，容易的都已经做都做了。测产品和搞自动化真心只能二保一，因为人只有我一个、仪表资源也很紧张。
最最关键的是，不仅仅测试脚本和相应的自动化可能有问题，仪表系统不稳定、环境不稳定（受其它测试仪表干扰）、测试产品也可能有毛病。Debug是一个非常耗时耗精力的事情，有时甚至零散加起来的时间怕不是有一两天，但这没法跟人说啊。
最痛苦的是有时为了保进度先人工测试，最后为了拿数据挤了空闲时间挂测，出来的结果不对头，要是再挤不出另一个空闲时间再来一遍，那真真就sun了dog。
- 各种打扰无法屏蔽，突发事故扰乱计划
- 这边的工作有点复杂，简单可以这样理解，人理清头绪要个一两分钟，真正进入工作状态差不多要有个五分钟，这个是不宜打扰的；仪表的预启动+测试的前期准备也要个三四分钟，这个是不宜长期打扰或事务插队的。
但是，这种拉会无法避免。抛出去的问题不得不跟开发各种沟通，为了保持良好关系还得抽空验证解决的Patch。Welcome to join the conference真的很烦。
还有各种进度会、早会，不得不一遍遍解释延迟的原因，可惜我不会甩锅额。
- 这边的工作有点复杂，简单可以这样理解，人理清头绪要个一两分钟，真正进入工作状态差不多要有个五分钟，这个是不宜打扰的；仪表的预启动+测试的前期准备也要个三四分钟，这个是不宜长期打扰或事务插队的。
- 未完待续。。。