有种感觉叫做相见恨晚，读了 sky《聊一聊职业发展》这篇文章更加突出，笔者毕业三年，测试四年，职场之路也还挺顺顺利利，换做他人的角度：具备可培养性，也一直在思考，怎么走的更高，更远～

古语云

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

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 大佬的文章，引发的一些思考，在今天这个特殊的日子，愿自己坚持梦想，既然选择了测试行业，就一定要做的专业，毕竟还有这么多大佬一直在鼓励，引导我们这些小菜鸟，加油！