1，测试的未来的职业生涯发展应该是怎样？

整个测试，跟其他的行业一样，都两条路可以走一条路叫做专业化，一条路叫做多元化。

先说专业化，最终造就的是测试技术专家，像是挖一口深井，例如邰晓梅。她的测试技能，测试策略，探索性测试上确实有不少思考和实践，并且也不断进行归纳总结，使她形成一套系统化的知识；又例如专项测试里面，安全专项测试也通常以技术专家的形态，像是USB一样，插入到系统中，帮助系统去解决安全的问题和风险。性能专项也一样，作为技术专家，利用自身的工具、平台、经验帮助产品快速定位，分析，解决，甚至维持专项性能，过程中不断总结归纳。这些技术专家，在我心中有点像麦肯锡里面的咨询师。

另外一种就是，多元化。首先测试这个职位不仅仅可以累计质量保障上的经验，因为测试在研发流程中，在每个环节都有参与，所以是有机会可以累积其他经验的。例如产品设计的经验，代码研发，持续集成的经验，但是接触最多，或者在互联网公司最可能接触到的经验，应该是效率提升的经验。如果把效率提升不要仅仅是放在测试，质量上，而是放在研发，运营的各个环节中，那就是多元化的思路了。这类角色最终可能会变成公司系统中的管理者的角色。

但是无论是专业还是多元，无非是经验累计的深度和广度问题，但有一点依旧是共通的，就是解决问题的能力。需要注意的是，经验并非等于解决问题的能力，就像有些人恋爱很多次，但是根本不懂爱一样。经验需要总结，归纳其成为系统化的知识，或者从系统化知识里面提取出来成为独立的知识，并重组。如何归纳总结知识？ 建议阅读《麦肯锡意识》，《金字塔原理》。

2，网络测试的工具和标准?

我们内部有分析云这些工具，不过说了大家也没有用。这里给大家介绍一些你们实际可用的，ARO AT＆T，很强大的测试工具，里面本身就有大量的网络方面的规则。在国内智测云也有类似的规则应用在里面。

当然这些规则是不是全部，能不能直接提单？

1.不是全部，例如网络中TCP分包和recevice buffer的合理控制， 例如弱网络中APP的处理方式，后发先致的问题。

2.不能直接提单。里面有些规则比较龟毛，所以请根据项目的痛点，对用户的影响程度来提单。

3，创业公司人力不够做测试和平台建设怎么办？更不够人力做专项测试？

我没在创业公司里面工作过，所以我的回答可能会有点站着说话不腰疼，请大家谅解。我认为创业公司能不能成功的关键点是时刻有有限的人力做最有价值的事情，测试如果定位在质量，平台建设如果定位在效率，那么问题是创业公司当时价值最大的事情是什么？痛点是什么？或者是大家是否真的认识到痛点和价值了。如果我们创业公司的产品，核心竞争力就是功能质量，安全性，像银行的产品，那必须要投入人力去做，如果没有，那就是老板有问题。 如果像最近爆火的产品FaceU那样，核心竞争力除了那可爱的兔子耳朵滤镜外，人脸识别和跟踪的速度最重要，那就是专项测试的问题了，哪怕这个能力不用自己开发，那总要选择合适的合作伙伴吧，这个时候难道就不用专项测试么？ 极端一点，如果产品的核心理念是idea本身，那把研发完全外包都可以。

归纳一下，这里的关键问题是把握到项目的痛点，有价值的点。这里推荐几个我认为最容易产生价值的东西：

1. 持续集成，build break是直接且严重影响研发效率的，而且它也是一切自动化测试的起点。所以对于研发来说，这有非常重要的价值。

2. 数据上报，无论是质量的上报，产品的上报，都是我们评估我们的产品的痛点和价值的关键点，抛开这个，而产品做成的，除非你老板是乔布斯。但是说真的老板是乔布斯，员工也不是，没有数据做依据，那产品经理们就是耍流氓了。

3. 用好现成的APM, 云服务，SDK。不要自己弄了，把精力放在有价值的地方吧。

4，要测试的网页和用例太多了，动不动就要全回归，怎么办?

这里有两个核心思路，一是减少测试用例，代表是精准测试，二是让更多成本更低的人帮助你测试，代表的是众测，AB测试，灰度测试。

先说精准测试，主要的思路就是通过知道变化来推论需要测试的功能，而变化本身按照粒度由大到小，可以分文件，模块，类与方法，代码行，而推论要测试功能，粒度由大到小，可以分为功能模块，界面，测试用例。 最简单的，肯定是粒度最粗的，通过SVN DIFF知道变化的文件，而文件配合开发和产品共同维护的与功能模块的映射，来知道需要测试什么功能模块。更难一点的，例如进一步自动分析SVN DIFF获取发生变化的函数和类，另一面，通过代码的静态分析，获取调用界面（如Activity）的函数调用关系链，得出变化的方法影响了那些界面。再进一步，想要有用例和函数的映射，那就通过动态注入或者静态注入的方式，获取当执行用例时候设计的函数，然后同样利用变化的函数和类对整合数据，知道变化函数影响的测试用例。然而这里对于创业公司来说，处理好测试与开发之间的关系，亲密无间，大家一起承担质量问题的意识培养，可能比方法和技术更重要。

再说众测，AB测试，灰度测试。总体的概念就是利用动态hook，插件更新，预埋功能，外部的众测公司等方式，通过完整的数据上报和用户反馈渠道，来为你的产品争取更多测试劳动力和热爱你产品的粉丝。例如facebook要测试短视频功能，要用exoplayer还是android原生的mediaplayer，他们就选择外网的AB测试，让小部分用户切换到exoplayer，去对比优化效果，通过数据上报得知exoplayer是否有crash等稳定性问题，视频在1s内播放的百分比，进而做出选择，逐步放开灰度用户。说到底，这是互联网公司能称之为互联网的根本。

5，SDK要怎么做测试?

我年轻的时候做过。第一步，了解SDK是干什么的，有什么应用场景。第二部，搭建jenkins持续集成，单元测试框架和代码覆盖率。 第三，逐步加用例，每天观察代码覆盖率，来定目标。第四，不断推进代码覆盖率，增加方法交互的场景，注意入参的边界值和错误情况，这些入参包括网络的入参，这是可能需要使用Mock等来处理。

最后提醒一点，把发现的BUG mark下来，有提单系统的提单。不要认为这些不是功能BUG,就不提。

6，产品技术重构后的测试策略?

正规来说，单元测试在此时应该是作为重要的测试策略。但是可惜，在国内这似乎是个不可能的事情， 所以更多是测试与开发成分沟通，了解重构后的架构，定制测试用例来测试。

7，兼容性测试怎么办

1. 利用Testin等云测平台做兼容性测试，缺点是产品界面太多就根本没法做， 但是可以配合数据上报和简单的DEMO，来验证一些有风险的API和系统能力的兼容性，例如视频播放的格式，摄像头调用方式等。

2. 利用我们优测平台， 提供兼容性静态检查。告诉你怎样写代码才没有兼容性问题。

3. 公司内部的测试，有几个需要去做的，识别有兼容性可能的风险，重点的功能，重点的场景，用户量大的机型和系统，去做兼容性测试。如果想测更多，那就要利用好众测和粉丝团了。

总结

那天晚饭，我们还讨论了许多关于成功产品的纸上谈兵的想法。这里也说一下，我认为产品经理最重要的技能是做减法，说着简单，却非常难，除了本身有想法，有思路，有情怀，这里还有公司环境，KPI下的压力，所以还要有魄力有手段。而回到测试领域中，创业公司里，相信减法更加重要，本身资源就有限，N个想做的需求，哪些需求能出彩，需求中什么东西最重要，是功能逻辑，网络性能，甚至是安装包大小，都要能识别的。