很久没有在简书上写文章了，但是每次进简书都能有一些小惊喜：喜欢和赞，评论、关注上总会有一些新的消息提醒，新的数字变化~
让我欣喜万分，有了一丝满足。但是也开始了反思，之前给定的10天写一篇文章的计划去哪儿了？哎！懒~
今天是结合自己的经验和看的一些资料，反思一下自己自己工作了这么些年头怎么就停滞不前了，可以做哪些方面的提升。所以有了这一篇《移动端测试提升-思想篇》。
我是13年大学毕业，步入测试行业的，如今已经有4个半年头了。
其中包括1年的引擎测试经验，和3年半的移动端测试经验
对于测试这个行业而言，我也在反思几个问题。
一、我是真的在测试，还是只是验收？
我有几次面试别人，面试的本来是旅游专业，或者文科专业，跟计算机根本不沾边的人。都是通过一些IT培训后，选择测试这个行业的。其实至今都有很多人觉得测试门槛低，测试比开发简单、测试不用写代码，才选择这个行业。
测试真的是这样吗？我先来说说，我对测试这个行业的初体验，我大三那年的暑假，来到一家做云计算的小公司实习，当时的老板是一对夫妻，分别是从微软、谷歌辞职办企业的，当时我很懵懂（只是考试了一个计算机四级软件测试工程师，学了c语言、数据结构、数据库等，其他一无所知），于是老板开始拉着我聊天，告诉我JavaScript可以前端后端统一编程语言，web自动化有selenium这个框架（那时候还是1.0版本，国内很少人用）、告诉我微软的测试开发比是1：1，测试人员是需要很懂代码的，测试人员的资历比开发老。
这就是我对测试最初的认知。
所以我一直对测试工程师有莫名的憧憬。
对我而言，我想改变别人对测试行业的认知，而且更要改变测试行业内部人员对测试行业的认知。
有很多公司从领导层面就不重视测试。其实纠其根本，是测试人员发挥的价值低。只是停留在验收的层次。
我们现在的工作都是根据需求、交互设计、视觉设计，编写一些测试用例，然后来检查是否与设计一致。其实本质就是在做比验收人员更加仔细一点的验收而已，根本没有达到测试这个层次。
比如，新的需求为：a页面新增一个显示块。
验收人员关注的只是整体样式、内容是否符合需求；而测试人员要做的更多，需要在不同的测试阶段要做更多的探索性工作。可能是在性能、接口、网络、安全等各个层面。
二、为了做好测试工作，我还要学习哪些知识？
移动端测试入门需要哪些知识呢？随便翻开一个招聘的要求，都能看到很多类似的要求，比如，任职要求（网上百度随便找的）：
1、计算机相关专业大专及以上学历；
2、2年以上Android/iOS手机软件开发或测试经验；
3、能够独立完成测试用例设计、测试环境的搭建、实施测试、分析与定位测试发现的问题；
4、熟悉软件测试流程，较强的分析&理解问题的能力，善于跟开发沟通并挖掘出代码的详细逻辑原理；
5、熟练掌握Android和iOS 操作系统，熟悉Android和iOS常用的测试工具；
6、熟悉Charles、Fiddler、Postman等测试工具；
7、熟练使用adb命令 及 Jira、禅道等bug管理系统；
8、工作有激情，有责任心，良好的沟通和团队合作能力，有良好的自我管理和自我驱动力。
1、2都是属于硬件条件，2、3、4、5、6、7属于要掌握的技能，8属于每个岗位都需要的一项必备能力。刚开始进入这个行业的我，只是用过android手机，有个软件测试的几个证书，其实离入门很远。
那么现在呢？要入门至少每个方面得略知一二，比如上面提到的熟悉你测试操作系统，怎么算熟悉呢？个人觉得，需要到官方文档中提到的测试工具和IDE以及测试框架都要会使用。熟悉Android，iOS平台的基础开发，写过基础的应用。另外还有一些跟操作系统相关的工具比如adb，至少会使用Appium，Robotium，uiautomator，XCUITest等UI基础框架并知道它们的区别。
然后你测app，总得知道一个交互的来龙去脉吧，所以就还需要掌握charles等抓包工具，这些工具会让你对app的测试层级更加深入，如果足够了解，测试页面UI的时候可以用这些工具模拟接口返回结果，达到测试的目的，还可以直观判断问题的原因，比如是接口传错了参数等等。
测试基础层面而言那就更多了，包括测试用例设计方法，测试这个岗位与开发的区别，测试可能在未来用到的一些理论等等。现在大家都追求自动化测试、性能测试。因为感觉拿的薪水比较高，就一味的去学习各种框架各种技术，以为学到了一招两招就是高级、资深测试了。然而却也不知道测试的本质到底是什么。
三、你是怎么样做测试计划的？
不同的测试人员，在测试同一个项目的时候，测试质量的好与坏一个分水岭其实就是制定测试计划？
我以前在公司每个项目都会有很详细的测试计划，现在因为项目迭代紧张，往往都会忽略测试计划，移动端测试计划要包含什么呢？其实测试计划就是为后面的测试工作做一个规划，规划这件事情怎么做，规划一些资源怎么分配。所谓磨刀不误砍柴工，做好测试计划的效果跟没做其实是有很大差别的。
另外制定测试计划，其实是一项高级的工作，一般由测试组长或主管来完成，因为相对来说比较复杂。一般来说编写测试计划有6个要素。
1、why—为什么要进行这些测试；
2、what—测试哪些方面，不同阶段的工作内容；
3、when—测试不同阶段的起止时间；
4、where—相应文档，缺陷的存放位置，测试环境等；
5、who—项目有关人员组成，安排哪些测试人员进行测试
6、how—如何去做，使用哪些测试工具以及测试方法进行测试。
各种资源的分配和衡量都是需要考虑投入产出比的，我觉得我以前在的公司有个比较好的做法就是会设置里程碑，并且有专门的监督部门打分，对于项目的效率都有比较大的作用。
现在我已经很久很久没有做测试计划了。
但是也由于保持了以前的习惯，心中总会给自己设deadline，会早早的把各种准备、资源协调做好。久而久之发现，这样还是远远不够，没有做完整的测试计划，总会手忙脚乱。测试计划这是一门长久的功课，还需继续努力。
四、测试执行，你做了哪些事情？
测试执行，是测试过程中耗时最长，最繁琐的一步。很多工作一两年的测试，可能在测试执行过程中就会觉得无聊，觉得无聊的测试执行，提bug、验bug没有发展的前景，其实不然，你真正了解你做的和真正的测试大牛做的，差距有多大，你就不会这样觉得了。
这里我不在赘述，知乎上看到一个非常好的回答，摘给大家看看。作者：陈甫鸼 链接：https://www.zhihu.com/question/20269633/answer/14809471
————————————————————————————
另一个问题是关于测试的工作方式的。就像开发一样，有经验和没有经验的测试在团队起到的作用是很不一样的。从测试中遇到问题采取的行动来看，我观察到的测试人员能达到的层次大概有这么几个级别：
- 开一个bug；
- 查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；
- 对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；
- 尝试通过研究代码确认问题所在；
- 尝试给出一个fix；
- 对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；
- 能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。
那么作为一个测试人员，我们的目标是什么？我对自己的目标是能对我控管的所有的bug从1做到4，在至少两个例子中我甚至能做到级别6。我在微软六年多，在很多部门都见到过可以见到可以总是做到级别7的测试，能做到这个状态的测试，没有人敢说他们技术不行。对于开发人员来说，如果你身边有一位能对大部分bug做到级别4的测试，我相信开发的工作也会轻松很多。
即使是抓bug也分很多种。抓一群猴子来随便在键盘上胡点两下算是测试，认认真真地一步步通过各种技术手段（代码覆盖、压力测试、安全分析等等）来步步推进也是测试。作为技术人员，你信任哪一种？我想多数人都会选择后者，但我要说的是在实践中很多测试团队都会不知不觉地变成前一种。为什么？因为测试对产品的设计不了解，所以本能地会选择最容易做的，可问起他们：你们测了多少？信心多高？他们就都傻掉了。我不是说猴子测试没意义：恰恰相反，它可以抓到我们思维上的许多盲点。但如果你的整个团队完全靠猴子测试过日子，那绝对不可能给你一个可信任的结果。
那么看官们必然会问，这种大牛测试和大牛团队有多少？很不幸，就我个人的经验来说，事实是在我遇到的测试人员中，最多只能做到级别1的测试人员并不罕见，能做到3的测试人员就被很多人认为相当不错了，至于团队中存在多个大牛测试的队伍则真的很少见（微软总部的比例高很多）。是的，别惊讶，这就是我工作中遇到的情况。但是请注意，这不是说公司在花钱养废物，而是说在没有专业测试教育的情况下在入行初期必然会导致的现状。我们所有人都是从这个状态开始的，也都需要时间来让自己进步。
也许还会有人问：这不是跟开发抢活儿干么？是的，没错。但为什么不能抢呢？我们的目的是什么？是开bug还是做更好的产品？如果你的全部目的只是多开bug，那真的很简单。真实的例子，我曾经见过有同事将测试自动化代码的bug开成产品bug的，他的理论就是不管bug是什么，先开出来再说，至于它是产品问题还是测试代码的问题甚至是环境的故障都可以缓一缓，反正他不负责指出原因。我知道要求一个同事干这个干那个很不礼貌，但这种什么都不做就先开了bug再说的做事风格是在耽误所有同事的工作。作为团队的一分子，测试在产品上多花一分时间，有时候能省下开发几天的工作量，因为测试是最熟悉这个bug的人，而开发则需要从头开始分析。
————————————————————————————
五、你了解你测的功能吗？
测试一个功能，就拿移动app的测试来讲，功能测试按照我的理解分成这样几个level。
1、根据产品需求、设计来测试功能路径；
2、在这些功能背后，你所看到的界面是用什么控件组成，你的操作触发了哪些代码，触发了哪些API；
3、API背后，当一个接口工作的时候，后端集群是怎么为此服务的，顺序是怎么样的；
4、对整体的业务由全局的认知，梳理清楚前端架构与后端架构的关系，某个功能业务架构与整体的业务的关系；
那你在测试一个功能的时候，你能做到几。如果依据这个来衡量的话，大部分的测试都是停留在1，并且工作n年之后依然停留在1。那你工作n年之后，跟刚毕业的人有什么差别呢？这是我们应该强烈反思的。
基于以上的思考，那测试怎么更加深入的理解一个项目呢？
对于有着良好的开发测试体系的团队，测试人员可以很早的介入从需求讨论、到概要设计、详细设计的各个流程中。对于另外一些团队可能就没有这么顺畅，但是不管早介入还是晚介入，测试人员还是要多下功夫，正确的理解业务、需求。
在了解的过程中多多思考如下问题，比如：业务的整体框架是什么？为什么要做这个功能，原始需求来自哪里？当然，不能只站在测试角度思考，还需站在业务需求本身或者用户的角度理解分支细节，并且和整体框架联系起来，梳理自己的认知，如果觉得不理解或者不适合的地方，多跟需求方、开发人员讨论，多多碰撞火花。
除了对需求的理解，还有对概要设计、详细设计的深入了解，其实很多团队都没有诸如此类的文档，那测试人员就要多花时间去跟开发人员交流，达到对每个要测试的功能都有详细的认知的目的。
总而言之，了解你要测试的功能是非常重要的一件事情。测试介入整个项目的时间越早、越深入越好，包含需求的吸收，了解需求最好是占长一点时间比较好，了解的越透彻，对项目的理解越深，发现的问题也能更加深入，测试的覆盖度也能更加全面。
六、测试的价值体现在哪儿?
个人认为测试的价值体现在尽可能的在早期发现并提出问题，一个bug，发现的越晚，修复的代价越高。那为了更早的发现问题，我们需要做如下三点：
1、提升测试质量
2、提升测试效率
3、拥有测试思维
测试质量和测试效率的提升都是需要一点一滴地努力的，为了提高测试质量，你需要更了解你测试的功能，用测试的方法论来实践，来提高测试覆盖度。
另外为了更早的测试出问题，测试效率就同样重要，首先要有良好的工作习惯，不会丢三落四找不到东西，因为你的工作习惯不好，测试的进度随之缓慢下来。另外还可以把重复的繁琐的工作就可以自动化或者提炼出关键步骤，都是提高测试效率的方法。
最后一点，也是很重要的一点，测试的思维很重要，站在用户的角度、产品的角度、开发的角度，正向思考+逆向思考，感染整个团队的人，从而让产品更加丰满。
