读《聊一聊职业发展》有感

MilgGtery

古语云

读万卷书不如行万里路
行万里路不如名师指路

sky大佬把自身的经验和心得分享给大家，那作为读者的我们，如何从中去学习，转换，效益最大化呢？这里来举个列子说明：
《Push后台的测试》

• 最初测试用开发搭建好的网站填写下发push的标题，跳转url等信息，然后在终端上查看是否收到push，展示是否正常，点击是否跳转。
• 半年后开始用jmeter测push的接口，关注接口调用
• 之后开始用代码测接口，
• 之后开始关注push的通道，比如APNS等，
• 之后开始梳理后台架构和push业务流。
  

大概经历了这个几个阶段，当时的我觉得自信满满，那读了这篇文章，现在如果继续去负责，我还可以关注哪些呢？

• 代码走读：关注后台的代码编写（java），使用的框架（spring），消息中间件（rabitmq），架构（mvc）
• 到达率： 比如后台对1W台设备下发push，到达率数据
• 预警机制： 比如测试/运营同学误操作，下发错的信息，如何预警及时中止push队列下发
• 覆盖率：版本改动很小/底层重构，评估影响范围
• 重复造轮子：写个min的push后台，客户端写个demo，模仿学习
• 后台性能：压测，评估性能瓶颈
• 客户端性能： 安卓的push需要集成第三方sdk，apk安装包大小，耗电量，流量，内存，cpu
• 链路监控：涉及到业务方调用，push未下发，链路监控
• 数据分析：push点击量，曝光量
• 沟通协作： 这里涉及多方业务同学沟通，以及流程推动
• 异常处理：如果后台下发字段未空，参数异常，客户端如何兼容
  

好这里是基于初读文章的引发的一下想法，那如何让自己显的更专业呢，需要SMART一下，这里拿客户端性能举个列子：
《评估集成sdk对客户端性能产生的影响》

• ——S代表具体(Specific)：哪些性能指标：比如只看内存
• ——M代表可度量(Measurable):是否出现内存泄漏，内存增量超过40m是否合理，内存占用80%以上，
• ——A代表可实现(Attainable)：可以通过Android Studio/instrument/ADB命令测试内存，
• ——R代表相关性(Relevant）：前后版本内存数据对比，投入产出如何
• ——T代表有时限(Time-bound)：第一个月预期熟悉工具使用，第二个月熟悉内存原理，第二个月开始结合业务场景使用
  

细化的过程其实就是思考的过程，从一个好的想法，一点点去构思整个项目实践，投入实践，产出效果，再经过无数次练习，那么恭喜你，具备可培养性！

多想一步

笔者尝试用自己的一个列子来说明读文章的收获，思路是这样的：从面到点，来尝试继续回归到面上来，这里在举个列子：
做了2年成了测试组长，带了2个小伙伴继续测push后台系统，

• 组员定位：一位技术，一位业务
• 版本节奏：学会关注版本节奏，哪个阶段需要哪些角色来配合完成哪些事情
• 学会沟通：对上沟通，对下管理，跟研发/pm/产品/运营保持沟通
• 技术能力：没有比通过测试技术提升效率或者保障质量更能获得研发测/下属的尊重啦
• 学会合作：寻求项目组内不同角色的质量需求，比如设计同学的视觉还原，比如产品同学需求及时上线
  

稍微总结一下：经历以上几个从 面>>点>>面，这里客观感受下，其实一般大厂的优秀的同学多能做到，那既然如此，我们还能做哪些呢？

培养核心竞争力

师傅经常跟我说的话：业务和技术你要只选一个，要么业务，要么技术，如果2个多做反而一个多做不好。那再顺着上面的列子来讲下：
《深入性能内存测试》

• 学会基础工具的使用，梳理工具原理
• 掌握内存原理，比如oc的引用计数
• 掌握常见引发内存的原因：比如循环引用，NSTimer内存泄漏
• 如何转型自动化获取性能
• 如何搭建性能监控预警
• 对于常见的代码语法导致的性能问题如何提前发现：比如静态扫描
• 如何收集外网的性能数据
• 分析经典的性能Bug，积累经验
  

在观察下，身边很多同学，要么很努力，要么学习能力很强，要么很聪明，当你身边的人多很强的时候，要怎么去竞争，这里我也还在思考中～

总结

以上是第二次读sky大佬的文章，引发的一些思考，在今天这个特殊的日子，愿自己坚持梦想，既然选择了测试行业，就一定要做的专业，毕竟还有这么多大佬一直在鼓励，引导我们这些小菜鸟，加油！