业务测试人员少的情况下，测开主要的输出是用自动化扩大覆盖范围，承担更多的测试结果输出的工作。也相当于节省人力的做法，毕竟同等自动化测试任务交给手工测试做的话，会占用更多的人，人不够则拖长了测试周期，都是项目成本。

测试部门是花钱的部门（做toB测试服务的除外），站在用户角度做质量把控的角色，在业务流程管理评估质量风险中配合输出决策用的报告和数据。对测试开发本质需求就是为测试执行过程省钱和同等开销下扩大测试覆盖范围。

业务层面上讲，技术上是要掌握解决具体需求的自动化落地方案，进阶需求是能优化出最优的省钱方案用在业务上。

个人发展角度上讲，挑个竞争人数还算少的领域，积累点解决需求的方案套路，让就业层面更占优势。

我的看法是：服务于测试执行效率提高及内部质量流程的效率提高，直接产出价值是测试任务效率提升及人员投入的节省。

测试开发人员个体上讲是服务于测试开发组团队的，团队组成可以是互补形式支撑业务需求的。

开发工程师转测试开发或手工测试转测试开发各有优势，手工测试转的更能理解测试执行的痛点且可以快速分解具体的自动化需求；开发人员转的往往偏被动，等着需求分过来进行实现，而且实现过程中很少去构思多个方案择优实施，而是找个自己最方便的实现。

最简单的测试设备连接路由器，路由器断外网。

可以先把需要用的数据一次性收齐，定义好存储方式和格式，呈现方式和把控线可陆续加。也可以用highcharts一类的框架做交互图。有几个点得想清楚解决办法，收数据的形式，如果是后台进程得做防后台查杀；收数据间隔，避免影响结果；引导优化落地点在哪，最终产出毕竟不应仅仅是评价，还要落地到和研发优化的对接。

看统计数据和dumpsys gfxinfo 包名 framestats 的统计信息很像，看个平均值还可以。具体要落地到优化点有些不够，需要分维度抓优化方向。顺时卡顿，平均帧率提升，低配手机SurfaceFlinger的绘制效率，用户体验层面优化目标。

严格的需求管理和代码审查是必要的。之前工作中听过一个真实的事情，之前同事的同学做过的一个事。他在项目代码中的一个正常逻辑不可能执行到的判定逻辑写了行：“如果看到这行内容就说明你见鬼了”。之后很久也没什么事，偶然一天半夜雷雨跳闸重启，显示屏跳出了这行文本，结果把保安吓得不轻。

开发人员头脑一热写的无厘头彩蛋还是得代码提交审查来控制。还有一类之前见过的就是往debug版本app中加开发人员名单/合照的菜单，见过三次。

哎，是多说了些，其实无非是压了很久的看法，一次性小爆发了下。

只是对测试行业的浮躁氛围有很多看法，虽然自己也改变不了什么，表达下自己的看法和谈谈自己的经验总结。能做的只是管好自己，也就是和自己手下的人沟通这些看法，看是否有共识。再有就是和同样有实际解决问题想法的人去聊解决方案的设计。

其实测试技术成长，很大原因是自己逼迫自己去思考，去尝试解决，去扩展知识面带来的。给自己设定要解决的问题，持续尝试不同方案去提高效率和实用性。去主动在项目中依据测试结果传递自己的分析判定，并去推动高风险问题的及时解决。去尝试和研发人员在逻辑实现层面的对等沟通，并主动提供bug疑似问题点的思路，哪怕是判断错了，沟通中也可以从研发牛人那得到正确的回复，这都是一步步的积累。带团队就迫使自己多承担些，想想如何控制团队资源的产出成果的关系，毕竟同样的成果低于管理人员的预期资源使用量，可以积累良好评价和信任度。

在面试一些人的时候及私下沟通时，听到过很多声音，几个典型的问题，我是一直在问自己和反思这些问题

1、工作几年了，我要级别提高，我要涨薪。
问题是：你要这些是凭什么？
引申出的问题是：为了要到这些我要有哪些积累呢？

2、手工测试没意思，我要做自动化，我要学编程。
问题是：转自动化要凭借什么呢？对比下已经在自动化的人及懂编程语言的应届毕业生，竞争力在哪呢？

3、工作环境不好，没人做测试技术，没人教自动化测试。
问题是：作为个打工的，只是指着用人单位及其他同事教怎么干活？为了提高自己的测试技术能力，自己能做什么呢？

4、现在的测试没什么技术含量，就是点点点，干了几年也没技术提高。
问题是：就算是点点点，你能比别人快速发现严重问题？
你能比别人发现更多的问题？
你能自己决定哪些必须测、哪些要优先测、哪些可以不测试？
你能基于有限的测试结果判断是否能发布？
能把对测试结果的风险情况清晰的传递给项目组？
引申出的问题：为了能做到这些，日常工作中要有意识的关注和总结哪些信息呢？

等等，大量吐槽声音后带来的问题思考

主要是在测试行业内这么久，体会很深的是：
1、有想法踏实做事的人相对很少，听安排做执行的人居多。
2、有责任担当的人少，怕担风险、担责任安排全覆盖测试耗测试资源的人多。
3、以自己作为出发点思考解决问题办法的少，从其他人和工作环境找原因的多。

分享下我自己在测试工作经历中的做法，我是这么去思考问题和持续积累的，换工作时有些可说的。

1、做手工测试时：我会记住严重bug的复现逻辑，有条件情况下会和研发沟通bug产生的原因及解决的方式（逻辑层面的，不是代码细节），这些就成为了之后测试时优先测试范围决策的依据。也能看到哪些开发人员不靠谱，严重bug多，粗心引起的小bug多。哪些研发bug少且能主动自测。这样系统测试时，根据开发人员的历史情况也能决策哪些模块要重点关注。

招人面试手工测试人员时，只要是有几年工作经验的人，我都会问道：工作中你遇到过的严重bug，举个例子说下。
可很少有人快速的把一个bug的完整信息及解决方式，很兴奋的说清楚。反而是要想很久去找个bug应付下回答。我接触过的手工测试的牛人，都是可以津津乐道的把严重的bug以及最终的解决方式讲清楚。

2、带组做执行测试时：拿到版本后，我会用一小时，自己过一遍重点的部分，之后才安排测试工作及有选择的安排重点测试。当别的组在催着加班完成所有测试时，我会通过经验和对用户场景重要性的判断，将不重要的部分在之后的迭代中安排周期性增量覆盖测试，从而减少加班。决定转型自动化后，手工执行效率低，重复操作多的，不靠别人，自己设计自动化方案尝试降低人力需求。

3、到后来的带基础体验团队，可以让自己通过经验及对用户使用场景的分析，控制测试范围和节奏，减少加班。当然自己要承担少测部分的漏测风险。使自己的团队是加班需求最少的。当然逼着自己去实现专项自动化比例是重要的条件。

说这么多，主要是建议想想这个问题：
做为测试工作从业者，自己的竞争力在哪。面对一年年的应届毕业生，一批批大公司出来的人员，一年年的过去，自己相对于他们的优势在哪？怎么能让自己的工作很难被替代。

这个问题我目前的想法是：要让自己积累的解决问题套路在工作中持续可复用；要想办法让同样的工作自己比别人的做法省资源出成果；要让自己在项目中展示自己工作成果的价值，得到其他人的认可；要让自己能在工作中担住更多的责任，能扛住的需求和责任多了，与项目中其他部门的沟通也就越有话语权，因为历史成果积累了信任度。

经历过了就多说了点，希望可以帮到些要在测试工作上走的更远的人少走些弯路，有没有用自己体会吧。

说到业务知识点积累及解决问题的经验积累，建议尽可以的熟悉了解业务，了解需求的细节，了解可被利用的数据来源和开源方案。要实践对比优劣，设想适用场景，组织利用形式。这其中就是要多想，多了解，多尝试。不过有很多人在做的事情就是了解为主，别纠结太多了。比如UI自动化测试，大多数人在做方案的“红海”不好出有个人特色的解决方案，大多是一层层的依赖包装，且同类“竞品”太多。找找“蓝海”构思下其他人没在尝试的事情。

我的看法测试人员应该是个“杂家”，各方面都要有些积累，至少做到了解，这样设计解决思路才有资源可以组织。而且项目中可以和各部门聊需求。除了业务自动化，测试流程自动化对接，解决评审流程效率等方面还有更大的空间。

我习惯于目标需求倒推实现思路，多积累实现思路让自己在构思方案时有多条路可以选。