第一部分：移动app测试内容

先贴一张图，虽然觉得可能没有人转，但是转图注明出处阿喂。

两年时间不长，还经历了不少项目，大多夭折。详细见第一部分-第1章：项目储备篇（暂不对外开放）。

抓耳挠腮总结出了上面那张图。两个维度。

第一个维度：分层。分层的概念在好多文章里都挺常见的。我个人觉得分层的好处在于清晰你的测试逻辑，明确各自分工的准入准出，还能让测试更加深入。

所谓的对接接口是我自己意淫出来的。既然服务端要做接口测试，那我们的也要来个对接接口的测试吧，主要是验证第一部分-第2章--如何美丽的对接接口 ，这个也后面细说。

接着是第一部分-第3章--UI功能测试，现在大多数同学都在这一层。虽然都说小白没有技术含量。但是还是有一点料的。

接着是组件测试，目前的app是由很多组件配置、拼接起来的。目前这个层面主要还是使用功能进行覆盖。这个部分主要讲一些配置、资源、组件依赖的测试技巧。

然后是sdk测试，这个部分主要是我们组的测试开发再做。主要说明我们如何测试底层提供给别人的sdk测试。我仅知一点皮毛。正在学习中就被项目变更掐断了。希望回来的时候还能跟上移动互联网的节奏。写的时候估计要找外援。

第三方依赖测试，这个其实现在基本没做。是最近开发优化了一个第三方依赖库折腾了所有QA一圈后，让我想起来这个测试的必要性。

第二个维度：分业务。个人觉得业务这个东西很玄幻，可能还没有熟练到家。大概分为基础业务和对外业务。这两者的测试重点不大一样。

第二部分：测试流程&方案

记在这里提醒自己写一下每个流程可以解决的问题和必要性。

这个流程一部分是意淫，一部分是小组现在确实在实施的。一步一步优化起来的。在里面踩了无数坑以后凝结的血泪。流程的优化也提醒着我们在进步。

再贴一张图，虽然觉得可能没有人转，但是转图注明出处阿喂。

由于我太懒。所以采用了这么挫的拼接方式。已经知错，坚决不改，给钱除外！

所谓需求评审阶段指在接收策划案到开发开始开发之前做的事情，主要指对策划的案子召集各个角色坐在一起商讨案子的合理性。并从各位专业的角度来评估案子提出疑问甚至否决。很多时候QA会被遗忘邀请(没错，是我)大家一定要增强自己的存在感，挤进去。

开发设计阶段，这个阶段在很多QA那里都仅仅停留在用例设计。在这个阶段做的更好是有难度的，需要QA具备一定开发层面的认知，还要有底气。。这条路目前在小组这边还没有走完。。不过这条路走完，用领导的话来说，就会变成开发GG的贴心小棉袄。

测试阶段。大家很熟悉了。每天都在这个阶段绝望。《业务建模》《测试方案》

发布阶段。加班的阶段，如果你不想加班，认真阅读本部分并参见前几个。

发布后。挨骂的阶段，如果你不想挨骂，认真阅读本部分并参见前几个。

总结这个部分的时候才发现这两年掌握的工具好少啊，好多问题都是通过流程和抓耳挠腮的自研来解决的。找现成的工具才是懒人的出路啊。

主要分成了业务和专项两个方向来区分。业务可能的在很多小白看来是小白的能力。个人觉得业务能力也是很珍贵的，业务能力的成长有时和经验不可分割。业务~时间。那是我的青春~

其他工具在网上找下资料基本几天就可以初步掌握了，当然要用的66的，你也要付出666.详细后面说

写在尾巴：

1、以上内容小组成员共同经历，有些内容在成员基础上做的增加与扩展。

2、后面写的内容很多是网上大佬们那里学来加项目沉淀的。如果侵权请提醒我（然后我也不知道要怎么处理，那就删掉好了）

3、资历尚浅，希望各位大佬提点。有则不改。无则改之。

想要了解更多，欢迎关注我的软件测试小巨匠专栏~

文章导读：

1、基于移动端测试系列知识沉淀-向导篇

第一部分：

第一部分-第1章：项目储备篇（暂不对外开放）

第一部分-第2章：如何美丽的对接接口（基于移动端测试系列知识沉淀）

第一部分-第3章：UI功能测试（基于移动端测试系列知识沉淀）

第二部分：

第一章-测试人员如何在需求评审阶段体现价值

第二章-开发设计方案评审

第三章-业务建模

第四章-用例设计-建模与封装