2017年4月10日，就是我33岁生日了，同时在测试这个行业快10年了，在项目中做测试，在公司的质量通道的职级评审中，评审别人也被别人评审，在Qcon做分享，见识过失败的项目、成功的项目，有不少人心怀怨念离开测试这个行业，也有不少人借测试职位为踏板，转行去做产品和开发，当然也有人一直在测试行业中辛勤劳动，当中也有不少有换个公司之后，所谓的测试经验一文不值。
做测试没前途、没积累、没技术含量
可真的是这样么？
是的，确实就是这样。
不然也不会有10年工作经验的测试，离职后却找不到工作的凄美故事
在我看来，最简单的体现就是是个人都可以对测试指指点点。可以被指指点点的事情证明什么？不专业嘛。别人的不说，我举个自己团队的例子，那天团队中，在跟开发沟通AR红包的性能指标，因为跟游戏更接近，所以我们参考了互娱对游戏的性能指标，但整个讨论的过程让我痛苦难言，因为大家都似乎在等着别人的答案，作为测试心里觉得什么指标才是正确的，完全不知道；哪怕有想法，也不敢说；哪怕敢说，在讨论之前也没有准备任何支撑的证据。
要知道，开发那么主动说要制定性能指标，那肯定是拿产品经理和设计师没办法了，他们内心已经在恐慌，恐慌这样提无法无天的需求和一直恶化的性能。他们祈求有个专业，严谨的角色，限制这一切，哪怕受伤的可能是开发自己。对专业，严谨，测试其中一个专业性就是来自严谨的逻辑，有想法，有证据，有思路。当开发们被产品老大压迫得大脑发热发昏的时候，连续加班被疲劳蒙蔽双眼的时候，是要冷眼旁观、等答案；还是耻笑开发不靠谱；还是用你的冷静严谨的专业素养帮大家一把呢？
我记得前一阵过年的红包项目，快发布，但当连续加班的开发发现莫名其妙的文件丢失做成了莫名其妙的CRASH。那时大脑就开始发热，想来个全文件夹扫描。当时找我的一个测试同事说要凌晨加班测试这个大需求，当时他了解事实，翻阅svn记录，冷静分析原因，说很有可能是清理工具导致的，而且刚好有个跟这问题相关的放置位置改变的svn记录。最终想到了真正的解决办法。这就叫专业嘛。
在这里，测试行业中让人感受到的没前途、没积累、没技术含量，都是自己的不专业做成的。大家不想再被指指点点，想自己更有前途，更多积累，关键在于专业。
更多的关于专业：测试策略
说到这里，测试同行们，我不得不提，前一阵我上github，看到有人留言问我。主要是针对我们很久远之前写的一本书里面尽是关于测试的案例和技术，却半字不提测试中如何设计测试方案。其实这个问题正正问的就是测试的其中一个专业素养：测试策略。当是举个栗子也好，当是补充我们将要出版的《Android移动性能实践》(开始预售啦！）也好，趁着这篇文章，我也认真回答一下：
这里我们把这些性能专项介入的需求分为两类，
第一类就是性能优化类
这些需求产生的原因很简单，大部分时候都是因为要解决或者进一步优化某个性能点，简单的bugfix已经不行了，要对局部的架构伤筋动骨了。这里肯定需要先了解需求和优化方法。然后
要关注性能的此消彼长，例如为了在网络性能上，提升消息的发送速度和成功率，我们可以有更多冗余包，更多重试，但是却会带来耗电和流量问题。对，往往性能优化都不是单目标的，需要决策的。这里测试要测，考虑全面的。
但是更重要的是要补充对应的外网监控，最终的决策用数据来说话。例如消息成功率提升10%，耗电恶化1%，还是成功率提升10%，耗电恶化20%，这里的性价比，自然可以体现出来。
第二类就是普通功能类
同样，要了解需求本身和概要设计。要关注三点，除了刚刚说的监控之外。我们可以先按照这个普通功能是app本身的核心功能还是附加功能。
核心体验依赖核心性能，如果它是核心功能，那就意味着核心体验。那就要评估它是否对性能有强烈的依赖。例如查看并发图片，对发送速度有依赖，发送速度对图片的压缩率有依赖，对过程中的CPU和内存消耗有依赖，这些功能，性能就是它的基础功能的显著一部分，甚至可以直接跟产品讨论这里需要订立的交互类性能的关键指标，如流畅度、启动速度、响应延时等。
影响核心体验，如果它不是核心功能，那就意味着它最大且最容易被忽略的风险是，它透过内存，磁盘，网络，CPU资源的抢占，影响了核心功能的体验。例如在手机QQ中某些功能的预启动，就很有可能会导致大量GC，抢占CPU，导致并发I/O，导致如聊天之类的核心体验被影响。又例如某功能导致大量缓存产生，让app直接OOM之类。
这里就是简单描述下，关于测试策略，说起来有点虚。就像打仗，游击战就是策略的一种，飞机大炮，地面推进也是一种，合适的时候选择合适的策略就是这个意思。但是话说回来，如果不懂磁盘I／O的原理，不明白I／O是会有冲突的；如果不明白各个资源类性能指标是如何影响流畅度的（如内存耗尽时GC for alloc会增加，进而导致stop-the-world会经常触发，再进一步导致卡顿问题），那么我相信也不存在制定什么好的测试策略。这里就要“掏出来”我的第二点了，测试技术。
更多关于专业：测试技术
有点很奇怪，谈起策略和技术，就犹如金庸小说中华山派的剑宗和气宗，总是似乎水火不容。策略婊的观点，策略是测试的核心竞争力呀，技术是开发的核心竞争力，过分强调技术，简直舍本逐末。技术婊的观点呢？原本测试的技术就应该比开发好，不然有什么资格和能力找开发的错误。可怜的我即将出一本团队用业余时间写了两年的书-《Android移动性能实战》，里面好死不死，基本上没有谈什么策略，只谈技术，基本上就是技术婊的节奏，这里也就不谈太多技术了，倒是要跟大伙说说，为什么我会选择当一个技术婊呢？原因有三
1. 因为行业中确实缺乏技术婊，准确来说是深挖技术，用技术解决问题的技术婊，而介绍测试策略的书其实并不缺乏。就像行业中谈自动化测试的，都在谈在什么场景下落地，而避开不谈自动化测试在技术上要如何解决它的天然困难，因此就有了我简书的文章《狠狠地聊一下UI自动化测试》。而行业中没有深挖的原因很简单，因为技术不够，策略来补，这很容易成为一个冠冕堂皇的“借口”。遥想那些年，共军引以为豪的游击战，让多少装备技术精良的敌对势力也苦不堪然，这就是技术不够，策略来补的威力。所以这个“策略”没有没错，但是倘若过分依赖，就会让测试技术一直无法成长，这就是我看到的一部分现状。而且，我相信卓越的策略来自好的技术。
2. 专项测试技术墙高。当然包括其中的专项性能，它的技术墙确实比较高。需要跨过去，就需要从性能专项的整个体系出发，在交互类性能和资源类性能之中，通过通俗易懂的原理，分场景的实用工具和有血有肉的案例来武装自己，这就形成了这本书的内容。
3. 技术是测试和开发沟通的一条桥梁，可以相互理解的实质。不知道大家有没有想过，为什么自己想不出leakcanery这种工具？从我的经验看来，我们类似的内存分析云就是开发和测试在技术这条桥上产生的果实。
自己和心愿
说到这一步，我不太清楚有多少对错，大家也不要麻木相信我。但我还是要说，大家身处的测试行业之中，会听到很多埋冤与失望，比起这些，我的愿望是身体力行来改变一点点，这些改变，包括简书的文章，包括我带的团队，包括那本快出版的书，还包括在今年的QCon 2017北京站还有我的一个专题：
说来可惜，其中有个跟后台自动化压测和分析的分享，PPT的内容绝对干货十足，但最后这几天因为讲师临时有急事，她也就遗憾地没有办法来了。而我就只能在这个极短时间里面，迫使Qcon的Kitty“就范”，让她相信听众只会想“干货”、“干货”、“干货”
，而不会理会什么专题中第三个腾讯的讲师会不会有广告的嫌疑，况且我这么短时间，我准备得很痛苦的，哪怕因此我也有了一次，谈谈iOS的专项测试的机会，让大家看看这个封闭的ios系统下的专项性能能玩出什么花来。
最后想说说，最近有句话让我感触良多，也时刻警惕自己，不要看高自己，也不要看低自己，要学会正视自己。测试也同样。
不要看高，行业发展很快，没有永远的大牛，什么测试架构师，高级测试工程师，很多事情穿过测试策略&测试技术，也许你已经被各种OTT了也不自觉，没有与时俱进的技术，你也会想不出什么好策略去测试音视频，AI人工智能，大数据，AR／VR等等。
不要看低，不要觉得测试是很low的工作，只想逃避。相信测试的专业能力是开发无可替代的，这份专业包括你的技术，策略和严谨的逻辑。
要正视，测试两大职责，提升研发效率，提升产品质量。归根结底关键在解决问题，无论是技术还是策略，归根结底是解决问题的能力。不断提升自己的能力，做专业的测试才是王道。
本文有三个疑似广告，一本书，一场峰会和我的生日，来祝18岁的我生日快乐，33岁了～！！！！！
