作者：陈晔,李柯泉,欧阳薇
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
移动APP应用实战(套装共2册)试读：
前言
之前，我大概谷歌了下前言应该写什么内容，接下来，我就说说这本书的目标群体，缘由以及想达到的目的。先来说说目标群体吧，免得很多人看完了说浪费他的时间。我并不想说本书所阐述的文字和观点多么的正确，但与测试行业的其他书籍有着天壤之别的地方就是书中阐述的都是一个一个非常真实的例子和项目。提示：有很多人听到我说正在写书会说“哇！好厉害！都能出书了！”，这反应就如同看到一个××大学毕业，在×××公司做了很多年，有着×××头衔的“大佬”后，发出的惊叹一样。但我想说的是，在发出惊叹之前，你们真的认识这个“大佬”吗？很熟吗？还是仅仅为这些头衔所忽悠了。现在这个社会里，出个书根本不是什么难事，关键在于出书的初衷是什么，是否真的有自己的想法。太多的“大佬”和“教授”出书和搞沙龙说白了就是为钱，谁都爱钱，但是为了钱扯淡忽悠就是你的不是了。综上所述，本书理论派和忽悠为生者勿扰即可，我在这里不多作解释，认识我的人都很清楚我指的是哪些人群。
说到写这本书的缘由是一个比较长的故事了，喜欢看故事的读者可以在本书的后记中读到，不喜欢的可以无视并直接挑选你喜欢的章节狠狠地给我提建议。
看这本书就像带你去品尝一顿由我精心制作的大餐。或许你第一次吃、或许你曾经吃过类似的食物，无论如何我相信你都会有全新的味觉体验。这套大餐分别由前菜、主菜、甜点和餐后水果组成。
前菜由第1～3组成，让大家品尝移动互联网测试行业面试、行业的现状以及特别需要关注的“用户体验测试”等菜色。● 测试面试——结合我经历过的面试（包括面试别人以及被别人
面试的经历）所看到的现象，从中抽取了部分具有代表性的例子
进行描述，也包括一些自己的感受。● 行业现状——相信品尝之后会有涩涩的味道，行业现状并没有
你看到或者想像的那么美好，但这就是事实（就如我之前说的，
我所描述的并非正确，但一定是事实。依然是那句话，一切眼见
为实，不要盲目的去相信任何人，尤其是自己为自己套上很多高
帽子的人。）● 用户体验——从Android和iOS两者的设计区别入手，让大家慢慢
地了解各种应用在用户体验上的细微差别。现在是大数据时代，
产品在用户体验上的设计进步，其背后依托的正是这些会说话的
数据。
无论你是否已经深陷移动互联网的泥潭，我相信前菜非常的可口的，大家可以像读故事一般获取第一手信息，就目前来看我觉得这些信息还是很新鲜（接地气）的。
接着介绍主菜，由第4～8章组成，让大家品尝到移动互联网测试行业中的应用功能测试要点、常用工具、常用框架、实际项目案例以及性能测试等菜色。● 功能测试要点——从移动应用测试的日常工作中总结出相对优
先级较高的测试切入点，用我的话来讲都是真正的经验之谈，没
啥技术含量。● 常用工具——介绍及实践日常工作中经常用到的移动应用测试
工具。品尝过后应属最美味的一道菜肴。● 常用框架——介绍及实践一些常用的框架，无论是分层测试还
是自动化测试都会涉及到对这些框架的检测。● 实际项目的案例——整个章节详细介绍了两个实际项目案例的
测试过程，属于对前面几章的综合实践。● 性能测试——介绍及实践移动应用的性能测试方法，包括工具
的使用以及一些测试思路，我对性能也了解有限，故味道应该很
淡。
如果你的牙口不好、肠胃不佳，主菜也许难以咀嚼或者一下子消化，这不是问题，可以慢慢品尝，不必急着一天拿下，不是么？
接下来是甜点时间，甜点是主菜之后的奖赏，可以使得吃的人放松，由附录A和附录B组成。先给大家祝兴添点“乐子”，对很多自称测试工程师却根本不知道什么是“测试”的朋友以及测试行业经常出现的问题进行吐槽（这不由得让我想到业内相当出名的槽神（@槽神刘叫兽））。吐槽本身是很轻松的事，小吐怡情，何乐而不为呢？之后，公平起见，大家再来吐槽我的观点。● 测试人员的自我修养——整篇吐槽不知道“测试”为何物的“测试人”，业界的“忽悠大佬们”就不用提了，他们已经没有任
何修养可言了。● 测试行业常见问题——整篇吐槽业内几乎每天都会出现的问
题。也许很多人会觉得这些问题都很初级，我可不这么看，俗话
说“大象怕老鼠”，多少人多少次倒霉就倒霉在这些初级问题上，
说谁谁知道。
我看到你一直在撇嘴，是不是感觉甜的要掉牙了或者都不屑于吐槽我了？这就差不多了，“不吐不快”嘛，吐净了就快入道了——我们需要不停地以人为鉴，反思自己，否则被人吐槽还是好的。
最后是餐后水果部分，附录C摘抄了我自己博客中觉得有价值的几篇，有助于饭后消化。
好吧，我还是说实话吧，其实甜点和水果并不在我最初的菜单中，只是这8个月的时间洋洋洒洒写下来，觉得有必要增加这样两章内容。也许你觉得是凑数的，但在我自己看来，这两章阐述的观点也是我心中认为本书原本就该拥有的部分。
最后说一下这本书的目的——让更多的人能够看到我分享的经验。
在编写本书过程中最大的难点有两个：第一点是撰写。我从2013年4月份开始撰写本书，女儿刚出生不到一个月，不得不说这一段日子非常难熬，拼的是体力和毅力。正因为处在这样一个特殊的时期，我更能自豪并负责地告诉大家，书中的每一个字都是自己三年多工作经验的真实提炼，为的只是让大家看到我的分享，将自己的所见所感传达给更多的人，并与行业其他忽悠扯淡的书划清界限。
第二点是审核。在这个行业中，技术大牛的人的确很多，但我思前想后最终没有找到适合审核全书的人，这一点大家浏览过全书后就会发现。不过，这里依然要感谢参与审核部分章节的朋友——张立华（@晋恒温）、谢琼（@谢小麦啊）、张昊翔（@美满的张昊翔）和胡明伟（@Mingway_Hu），他们分别从不同的角度做了审核。做过审核的同学都会知道，审核在某种意义上来讲比撰写更累人，在此非常感谢我的小伙伴们。
前言是在我写完整本书之后才回来补充的，这道大餐背后隐藏着太多的酸甜苦辣。或许你之前就认识我，或许你根本就不知道我是谁，又或许我已经被你归了“扯淡”的行列，但是，无论如何，我在这里恳请你能够读完整本书（包括后记），再来评价，至少在测试和原则上。如果你认同我的观点和原则，那么让我们一起为了测试行业的进步而奋斗吧！陈晔第1章移动互联网面试
可能很多人觉得可笑，为什么要花一章来讲面试？莫非是凑字数？面试这项活动成败与否不确定因素实在太多，需要一定的运气，也需要一定经验和技术积累。在我们长期稳定的工作中，面对的一直是同事、客户、老板这样一群固定的人。慢慢地，我们就失去了与陌生人打交道的能力，失去了结交新朋友的感觉。面试其实是一个长期行为，并非只是为了找工作才需要去面试。
面试从表面上来看是一个人在考核另外一个人，但是实质上，面试是一个非常复杂的过程。1.1 为什么要面试
面试是与陌生人打交道的过程，一般来说，人在世界上看到最多的生物就是人，而最难接触、最难相处的也是人。面试的时候，大多数人都会非常紧张，其中一部分原因就来自于坐在自己对面的是一个陌生人。紧张的情绪会让应聘者四肢冰冷，额头出汗，更多的是语无伦次，表达不清。从面试官角度来讲，他心里很清楚应聘者多少都会有紧张的情绪，但作为测试工程师这样一个职务，要求在将来的工作中更多的是必须和项目或者非项目的同事合作。一个与陌生人打交道非常紧张的人并不一定会影响到接下来的测试工作，但是一定会影响到沟通的效率，因此面试官自然会考察这一点。
面试是一个沟通的过程。面试的过程中会被问到很多问题，包括工作、生活、技术、人生等。如何快速、正确地理解面试官的问题以及简短、准确地描述自己的观点就变得极其重要。很多应聘者为了能在人群中脱颖而出故意表现自己的能说会道，这种行为往往适得其反。从心理学角度来讲，人在多说话的时候情绪容易亢奋，更不容易发现自己话中的错误。站在企业和面试官的立场，他们需要的是一个满足他们需求的人，而不是只会耍嘴皮子的人。应聘者的理解能力和表达能力将会大大影响以后和同事的合作关系以及个人发展。
面试是一个学习的过程。在这个过程中，无论应聘者成功与否，都能够发现自己的一些缺陷。这种缺陷可能是技术上的、思想上的、心理上的，等等。当然，这种学习并非在短短几个小时内就会完成，更多的是需要应聘者对每次面试进行总结，从而弥补自身不足之处。很多人经过多次面试后，发现自己总在某些方面栽跟头，其实就是自己每次面试后都持消极沮丧的态度，不去总结的后果。1.2 面试的流程
对测试人员的面试流程一般分成4部分。● 第1部分：大部分的外企在这一部分是让应聘者做笔试。笔试内
容一般都会包括编程类、算法类、软件工程类、数据库、翻译类、
智力问答类等等，可以说是应有尽有。● 第2部分：应聘者和面试官互相寒暄，应聘者做自我介绍。● 第3部分：回答面试官的问题，提问的点可能是根据应聘者的自
我介绍即兴提出，也可能是预先设定的面试问题等等。● 第4部分：应聘者和企业人事之间的交流。
一般流程不外乎以上的模式。应聘者往往最头疼的就是碰见笔试和面试车轮战。但是其实这种流程是存在很大的弊端，在后面的小节中会提到。1.3 面试的频率
读者也许会很奇怪，面试还有什么频率？难道不是为跳槽找工作才去面试吗？在其他行业可能是这样，但是在移动互联网做测试就得跳出这个固定模式。从移动互联网行业的发展来看，其运用到的技术以及思想在短短的几年内有了翻天覆地的变化。定期的面试能够让测试人员积累面试经验，变得不再害怕面试，也更能够抓准现在行业中企业真正关注应聘者的什么能力。当然，这里所指的定期面试不是唆使测试人员定期跳槽，而是抱着学习和积累经验的态度前往面试。1.4 面试实战
小陈同学是一名应届生，某天他拿着自己的简历前往某企业进行面试。我们先来看一下这位同学的简历。
面试正式开始了，下面模拟了一些可能出现的场景。面试官：小陈同学你好，请先自我介绍一下。小陈：您好，我叫小陈。我是xxx大学计算机专业毕业的学生。我在学校学了xx课程，担任了学校xx职务。我毕业之后想找一份和计算机有关的工作，但觉得自己实战经验可能不够，所以前往了xx培训了xx个月，目前已经毕业。主要学习的技术有软件测试的基础，设计方法以及各种编程语言。
分析面试官心理：
可能是：面试的常规流程应该从应聘者的自我介绍开始
可能是：我忘记看应聘者简历了，通过自我介绍我了解一下吧
可能是：从应聘者的自我介绍中观察应聘者对自身的了解，并了解应聘者以前的工作经历。
从面试官角度来讲，让应聘者自我介绍是一种缓和气氛、以便让应聘者逐步进入自己的最佳状态的一种手段。（当然，也许一些读者会觉得自己根本不会自我介绍，或者一开始自我介绍就紧张，这种情况的确很常见，但我只能说这是你一定要克服的问题。）
应聘者注意点：
小陈同学这里所作的自我介绍中规中矩，但没有什么特色。很多应聘者面试之所以失败往往从自我介绍就开始了。按照常规流程一般是姓名、所在企业、以前做过什么项目等等的介绍。这样并没有错，是一种很保守的介绍方式。在这里应聘者需要注意的是四个字“扬长避短”，不要为了让别人认为自己很能干、涉及面很广而夸大其词。应聘者要学会将自己的长处完完全全的体现在对方面前，并让对方跟着自己的思路。这样的话，面试官往往会问一些相关的问题，应聘者也能够因为有所准备而从容应对了。面试官：小陈同学，请问你是否了解Android，iOS或者其他平台的优缺点呢？请简单描述一下。小陈：您说的这些以前我都没有什么经验，刚刚毕业而已。
这里小陈犯了一个很大的错误，作为一个应届生来讲这样的回答等同于告诉面试官“我在学校除了上课都在浪费时间，我没有关心过任何相关的信息”。所以无论面试官问了什么，都不要这样去回答。面试官自然知道来面试的人是否刚刚毕业。他问一些问题主要是看应聘者以前有没有一些积累，从中看出这个人的习惯。所以，假设一个人在学校的时候就保持着自我学习和探索精神，那么这个习惯在工作中也会生效。反之，对于面试官来讲这只是一种推脱之词。
就这样，面试的一个小时结束了，其结果我想大家都心中有数：小陈同学没有通过这家企业的面试。不过小陈同学很不甘心，他决定工作几年之后再向这家企业发出挑战。以下是小陈同学2年后的简历。
面试又开始了，以下是模拟的场景：面试官：小陈，你对于移动互联网测试的自动化框架以及工具了解多少？请描述一下吧。小陈：我以前是做Android测试的，一直是手工测试。所以这方面可能了解不多。
可能广大的移动互联网测试人员看到小陈的描述会认为自己肯定不会这么说。但是从事实上来讲，的确有很大一部分的应聘者就是这样说的。原因出自两点：其一，自己说习惯了，事实也是一直在做功能测试；其二，自己内心的自卑或谦虚，加上面试的紧张，一时脱口而出。
小陈这样描述等于在告诉对方“我对此很没有自信”。试问自己对自己都没有足够的信心的话，如何让企业和面试官对你有信心呢？从另外一个角度来看，作为从事软件测试的人，不去涉猎一点自动化测试，这本身就是不够上进、满足现状、不爱学习的体现。软件测试是一个技术岗位，理应对行业的新技术有所涉猎才对。此外，应聘者如果这样描述，说明他作为一个软件测试人员根本没有了解到软件测试的核心。软件测试的核心是测试用例的设计，用例设计的好坏在一定程度上体现了一名测试人员的能力以及价值。而是否用手工或者别的方法来完成这些用例测试只是使用方法不同而已，所以千万不要因为手工测试而看低自己，觉得手工测试没有技术含量或者没有前途。要知道，软件测试具备的能力不是只有手工和自动化测试这两项，还有许许多多的东西需要我们去学习。这些在后面的章节会详细解释。面试官：能否描述一下Android SDK文档中提到的测试工具呢？在项目中你是怎么使用的？小陈：以前的工作忙于业务，并没有仔细看过相关的开源文档。面试官：从简历上看你有一定编程语言基础，请用你熟悉的语言写一个冒泡排序吧？小陈拿过纸笔，最终还是没有写下任何一行代码。
在实际的面试中，面试官更可能问一些具体的问题，比如：请问Monkey怎么使用？或者对instrumentation是否了解？……但就上面举的例子来说，很多测试人员并不知道该怎么回答。例如有的应聘者会说没有看过，或者说知道几个工具但是没怎么用过等等。
一般而言，测试人员不知道怎么回答的原因有3个：（1）完全不知道存在这份开源文档；（2）文档是英语编写的，看不懂；（3）自己所在的环境和项目根本用不到文档中提到的工具或技术。
无论出于哪种原因，结果只有一个，就是应聘者不够了解相关技术，并且从侧面也可以看出应聘者没有打破沙锅问到底的钻研精神，而这点对于一个测试人员来讲是致命的不足之处。如果你想学习移动互联网测试，如果你在工作的过程中对某些技术不了解，那么开源文档永远是你的不二选择。不仅仅Android如此，别的任何一项技术也是如此。
我就看到过许多应聘者在面试过程中不懂得扬长避短，应聘者在没有扎实的C++、Java功底或者Android软件测试经验的情况下，随意在简历或者面试中去夸大这些经验和技能，结果却偏偏暴露了自己的短板。这样的情况比比皆是，希望广大测试人员要实事求是。1.5 如何正确地招聘测试人员
前几个小节是写给应聘的测试人员看的，这一节是写给广大企业的面试官看的。
面试的时候应该怎样去考核一个测试人员呢？与考核一个开发人员一样吗？错！请丢弃那些无用的笔试题以及那些已经用烂了的技术开发题吧。你们需要从以下几点去了解应聘者，选出真正的人才。
第一，应聘者从事测试工作的原因。
每个选择软件测试这份职业的人都有自己的原因，这个原因在很大程度上决定着他可以做多久，是否蹋实。这样重要的问题在作者曾经经历的面试中几乎很少被问到，所以，当我在招聘测试人员的时候，首先就会询问该问题。得到的往往是以下几种答案：● 我只想做和计算机有关的工作。● 我其实是想做开发工程师的，但是一直通不过面试，所以选择做
测试工程师。● 我在×××培训机构培训的就是测试，我觉得自己很合适。● 我是一个女生，我觉得女生做测试比较合适。● ……
以上任何一个答案都不具说服力，希望广大的软件测试工程师们扪心自问：你们做这份工作的初衷到底是什么？为什么现在还在继续做？也许有人会觉得自己比较细心或者是女生就比较合适，从短期来看细心或许能够支撑一个人做一件事情，但要是做十年二十年甚至更久呢？试问细心等还算是支撑的理由吗？
第二，应聘者测试用例的设计能力。
很多面试官可能会问与此相关的问题，但是有的太专注业务方向，应聘者如果没有相关领域的经验恐怕很难设计出有深度的用例；有的却是太过于形式化，应聘者随意说了两个“等价类，边界值”就可以蒙混过关。用例设计的基础是无二义性以及具体的实现步骤，只有应聘者在面试过程中根据具体的问题写出具体用例的情况下才有考核的价值。
在我面试别人的过程中，往往会用以下几道题目来考核应聘者的设计以及思维能力，这里我想分享一下，先看第1题。
假设有如右图所示的这样一个登陆框，请问你该如何进行测试用例的设计？
回答此类问题的加分项有：● 进行需求的确认，包括输入框的输入类型或者长度限制等等。● 设计用例思路清晰有条理，而不是脱口而出、想到什么说什么。● 进行具体的用例设计，而不是简单地说“等价类”、“边界值”
等。● 从整体去考虑问题，比如单击按钮之后的反馈，程序所在的系统
有什么特性以及一些并发情况的发生。● 从用户体验角度出发，比如密码框输入之后是否为暗文显示以及
交互性是否友好等。
当然考核项不仅仅只有以上这些，但至少是我在面试中会评判应聘者的指标。下面我们看第2题。
假设有右图所示这样一个应用，共有3个输入框，该应用的功能是输出用户输入日期的下一天。
此类问题有一部分的考核点和第一题相似，不过也有特定的加分项：
1）遇到特殊年份的逻辑跳转，比如闰年。
2）遇到特殊月份的逻辑跳转，比如2月。
3）遇到日期跨月、跨年的逻辑跳转，比如7月31日跳转到8月1日，2000年12月31日跳转到2001年1月1日等。
4）当日期显示位数有变化时的逻辑跳转，比如月份从9变化成10的时候。
5）同样的，考核点不仅仅只有以上这些，但是这个问题相比第1题来讲，更多的是考察测试人员对于一个产品的理解力以及用例设计能力。
第3题是一道纯粹考核测试人员逻辑思维题，题目如下：
假设一共有25匹马，一个赛场。赛场有5个赛道，就是说最多同时可以容纳5匹马一起比赛。假设每匹马都跑得很稳定，不使用任何其他工具，只通过马与马之间的比赛，试问，最少得比多少场才能知道跑得最快的5匹马？
其实回答这道题目本身并不困难，重要的是考核思考的切入点。这里给出一个提示。
大家可自行解出答案。
我们可以将25匹马分成5组，分别如下所示：
假设我们将25匹马分成5组，经过5场比赛之后，假设第1组的排名是A1>A2>A3>A4>A5，其他几组依此类推。我们将每组的第1名组成一组再进行比赛，假设结果是A1>B1>C1>D1>E>，那么A1为第1名，第2名不是A2就是B1。大家可以按照这样的思路去思考。
第4题（一般也就是最后一题）虽然是道老掉牙的题目，但是同样能够看出测试人员的设计能力，题目如下：
假设让你去测试一部经常出现在地铁站或者企业中的那种投币自动售货机，怎么设计测试用例。
该题目考核点比较多，也很散，不过主要抓住以下几点就能加分：● 条理清晰，会通过正常情况、非正常情况详细地设计用例。● 能够考虑到各种特殊情况，包括断电、漏水、缺货等。● 能从用户体验角度考虑，比如出货的温度、时间、找零等。● 能够从用户群体考虑，比如小孩、残障人士等。
这道题目是十几年前面试常用的题型，我一直喜欢使用，因为这种题目有它开放性的一面，所以它的答案也很多样化，能够看出一个人对于一件事物是否有自己新的认识。
第三，考核应聘者作为测试人员的基本素质。
在面试的问答过程中很容易了解应聘者作为测试人员的基本素质。例如当应聘者面对一个问题的时候，是否会本能地问清楚问题的需求，沟通上是否存在障碍等等。
第四，考核应聘者的专业技术能力。
软件测试是一个技术职位，其技术考核自然不可缺少。面试官应该根据自己企业、自己团队的实际需要进行技术考核，不要以面盖点，从而错误的去认识应聘者的能力。
第五，考核应聘者的态度。
这里所指的不仅仅是工作态度，也包括生活态度、学习态度等等。这些态度可能不是通过问答能够考核的，更多的是贯穿在整个面试过程中，面试官对于应聘者的总体感觉。态度是一个测试人员能够在这个行业走多远、走多深的决定性因素。1.6 移动互联网测试招聘现状
这里所描述的现状，时间截至到作者写这本书为止。下面列出了一份我们常见的移动软件测试的JD：
职位职能：软件测试
职能描述：
1、指定、编写软件测试方案与计划；
2、按时完成软件测试工作任务；
3、编写测试文档、测试报告、提交测试结果；
4、改进软件测试流程、工具和质量；
5、参与测试结果评审。
岗位要求：
1、3年以上测试工作经验，有管理软件测试经验者优先；
2、熟悉JIRA、QC、LoadRunner等测试工具，有1年以上iOS或Android测试工作经验者优先；
3、能够熟练书写测试脚本、测试用例，熟练使用各种测试工具，具备软件测试环境搭建的能力；
4、了解软件工程思想和方法，了解基本数据库系统及网络知识；
5、较强的发现问题、分析问题的能力；较强的语言表达能力和文档撰写能力；
6、工作责任心强，细致，耐心。
整个移动互联网测试的就业现状出现了一种很奇特的现象：应聘需求量非常大，但是应聘者却不知道以什么样的技能和能力去应聘；相应的，招聘需求量也很大，但是从千篇一律的招聘简章（如上图）中看得出来，大部分的企业和面试官自己都不清楚自己需要什么样的测试人员。这种情况直接导致了面试过程的不规范性，面试官盲目地考核应聘者。很多企业面试测试人员仅仅就是面试编程和算法，而当应聘者问及自己到企业具体做什么的时候，也往往都得不到确切的答案。
曾经有一个刚面试完的测试从业人员问我一个问题：“我想找份自己理想的测试工作，但是经过几次面试之后，我迷茫了。你能否告诉我，我到底要学什么？”。其实我认识他也很久了，对他问出这样的问题我既感兴趣又觉得难过，问其原因，得到答案是这样的：“其实开始我觉得自己还清楚要学什么，但是经过几次面试，看到很长很长的笔试题以及各种和软件测试好像毫无关系的面试题之后，我开始觉得自己什么都欠缺，开始怀疑自己。”其实我听到这样的回答并不惊讶，因为自己看到过太多这样的情况。
我见过很多测试人员换工作的理由是一直做手工测试，想学习自动化测试（当然隐含着待遇差的意思）。从短期来看，换工作可能会解决他们的问题。但是从长远来看，到任何一家企业，只要时间够长，我们总会觉得到了一种学习上的瓶颈，觉得没有进步，都是自己熟悉到甚至有些厌烦的东西，所以换工作其实并不能真正解决问题。一名测试人员如果要想有长期和系统的提升，就必须不能被自己所在的企业、团队、项目等外在因素所制约，要学会自己定目标，不停地学习才是真正的解决之道。1.7 大公司和小公司
很多应届生或测试从业人员在面临这样的问题的时候往往不知道该怎么做：眼前放着一家知名大型企业和一家刚创业的小公司，那么你会选择哪一家？在我主持的面试中，遇见过大大小小的企业出来的测试人员，大家看了下面的故事之后，可能就会有自己的答案了。1.7.1 故事一
王小姐，所在企业：某知名互联网企业，职位：软件测试工程师
在我拿到她简历的时候其实心里还是很高兴的，因为看到简历上满满的项目经历，又是在知名互联网企业，对我自己所在的创业公司来讲是难能可贵的。所以我满心欢喜地开始了我的面试。部分对话如下：我：请问以前项目测试用例都是你们自己编写的吗？王小姐：由于我们公司人很多，项目环节分的很细，所以编写测试用例是由另外一个组的测试人员负责，不是我们自己写的。我：那么你们平时除了执行测试用例之外，还做点别的什么类型的测试吗？王小姐：使用一些工具进行自动化测试。我：这些工具你有没有了解过是怎么实现的，或者运行原理是什么呢？王小姐：没有关注，只是去使用，进行产品测试。我：你为什么离职呢？王小姐：主要觉得工作太枯燥，没有学习和进步空间，都做了好几年了。
从上面的对话当中不难看出，虽然王小姐有着不错的工作背景，但是其实虚的很，我想大多数的面试官无法接受她。移动互联网企业近几年开始越来越看重实际能力，学历或者企业背景已经没有以前那么大的比重了。自然，王小姐没有通过我的面试。
如果你有机会进入一家知名大企业工作，那么绝对是一个不错的机会。你可能能够加入一个很好的团队，参与一个很好的项目；可能有很积极的环境，认识很多技术厉害的同事等等。你得好好利用这些资源，这些都是能够让自己的能力在短时间内得到巨大的提升的机会。如果有这么好的环境，你还在混日子的话，那只能说你已经自我放弃了，更别提指望得到面试官的青睐了。1.7.2 故事二
张女士，所在企业：某移动互联网创业公司，职位：高级软件测试工程师
这份简历也是事先让我比较看好的，原因在于张女士的背景肯定能够让她更快地适应创业公司的氛围，并且从职位上来看能力应该也是不错的。于是我高兴地开始面试。部分对话如下：我：张女士，请问平时你怎么进行Android的测试呢？测试一个产品的周期大概需要多久呢？张女士：我以前在创业公司，公司就我一个测试人员。测试用例、文档都是我自己写的。平时主要都是功能测试，自动化测试自己也在研究。目前只是执行一下Android的MonkeyTest。测试产品的话一个月左右发布一次新版本。我：张女士，我想问一下，Monkey工具具体是怎么执行的？会加哪些参数？你是怎么学习的呢？张女士：就是一句脚本执行一下，每次执行几万次的样子，并没有增加什么特定的参数。我：请问是否仔细看过Google的Android开源文档呢？张女士：好像都是公司里的开发人员在看，我自己没有怎么仔细看，英语不是很好。
从上面的对话不难看出，张女士对于公司只有自己一个测试人员感到很是自豪，这点自信对于测试人员其实是难能可贵的。但是她却有点“闭门造车”，缺乏与其他测试人员以及同行的交流。在我看来，没有看过Android开源文档的测试和没有接触过Android测试之间可以划等号。所以张女士同样没有通过我的面试。
如果你有机会进入一家创业公司并且愿意接受挑战的话，那么这绝对是一个不错的机会。你可能有更大的机会接触到整个项目，你可能会远离办公室政治，远离大公司的那些条条框框，你可能能够全面发展自己的能力，而不仅限于测试。
我相信肯定有朋友觉得疑惑：上面说的都是进入两种不同企业的优势，但那么多的“可能”。我们怎么才能增加“确定”的概率呢？这需要正确地审视这家企业，审视自己。你需要在面试结束之后让自己清晰地了解以下几个问题：● 这家企业做什么产品，我是否有兴趣。● 这家企业目前有多少测试人员，分别是负责什么工作的，目前整
体的测试深度大概达到什么程度。● 自己进入这家企业具体要做什么测试：是功能测试，还是压力测
试，还是各种都会接触。企业管理层对于测试人员的职业规划以
及将来的发展是怎么考虑的。
可能有的朋友会说，我去面试，不见得所有的企业都会告诉我以上这些问题的答案。的确，作者也遇见过这样的企业。但是，试问如果在面试的时候企业都不能回答你这些问题，这样的公司你敢去吗？你真的愿意去吗？难道只是为了眼前许诺的那些薪资？希望大家好好思考一下。1.8 测试外包
如果你想找一份测试工作的话，那么对外包这个词绝对不会陌生。在业界，似乎测试和外包是双生儿，有测试的地方必有外包，而有外包的地方必有测试。国内外有名的外包公司都是以输出测试人才为主要业务的。我个人并不排斥外包这种形式，身边很多能力强的前辈都是外包出身。但是需要注意以下几点：● 要前往好的项目组工作。● 如公司内部没有很好的流程和技术积累，最好要外派性质。● 一般外包工作不要超过2年，但也不是绝对的，视具体情况而定。● 看清楚即将签的合同。
从行业普遍的情况来讲，外包性质的工作都是去条件相对较好的国内外大企业，并且入职要求比正式员工低很多，对于刚加入测试行业的朋友来讲是一个不错的选择。但是如果不仔细挑选的话，很容易成为廉价劳动力，工作也没有归属感。所以当你决定从事外包测试工作的时候，一定要慎重。1.9 小 结
本章介绍了我个人对面试的一些看法。也许现在看来已经有些老套了——当大家看到这本书的时候，移动互联网的发展又到了一个新的高度，无论测试还是技术都日新月异。对面试的革新也很快，要想抓住好的机会就得提前准备——提升自己的能力以及保持良好的心态。我相信你一定会进入想去的企业并最终获取成功！第2章病态的现状
随着移动互联网的快速发展，跻身移动互联网的企业也越来越多，移动应用产品更是百家争鸣、百花齐放。移动应用已融入并悄悄地改变着我们的生活：我们开始随处签到，随处拍照，随处发微博，上下班时在地铁上看到越来越多的人拿着手机玩游戏和看电影。有需求就会有供给，于是大量的从业人员或是应届生加入了这波移动互联网热潮，而各种风投和天使资金的流入也让移动互联网行业像打了激素一般飞速成长。但是任何行业或者领域如若发展不均衡，都会长成畸形。横观整个互联网行业，有人天天数钱，有人天天输钱；有人如沐春风，有人苦不堪言。病态，这就是现状。2.1 全民挖金
早在2009年初，国内只有极少数的创业公司想到了进入移动互联网做基于Android、iOS平台的应用产品。在当时，更多的应用是基于Symbian和j2me的平台的。到了2010年，随着国内使用智能机的用户比例直线上升，各个互联网巨头开始行动起来，纷纷招兵买马，在移动客户端上扩展自己的业务。随着“水果忍者”、Testin、Path靠着一个游戏或者仅凭一个新业务的想法就拿到了很多投资，越来越多的巨头和敏感人士觉得新一轮的淘金浪潮又要开始了。
在众多的故事中，Draw Something的一夜暴富更是激励了大众，新闻宣传扑天盖地。该企业一直在做游戏，连续做了多款但收入微薄，濒临破产之际愤力一博，作出了一款移动互联网产品，不但拯救了全公司，甚至还一跃成为“当下红人”。
但是随着时间的推移，更多的人发现貌似第一桶金来的也不那么容易了。这桶金的来源一般有以下几类（并非全部）：
1．企业自己出资
作为传统互联网的霸主，谨慎是他们的品质。他们不会轻易涉水移动互联网，但也不会轻易放弃移动互联网。所以在早期，这些巨头都拿出了一部分钱投在了移动客户端的项目上。当然，对开发移动客户端的团队来说这自然就是第一桶金。不过在这次浪潮中，很多团队发现这桶金是连响都没听到就打水漂了，更有甚者还影响到了企业原有的用户群。的确，早期移动互联网的试水鲜有成绩。
2．市场标价
这里所谓市场就是指Google Play（之前称为Google Market）和Apple Store。普通产品的标价一般最低是$0.99，而游戏的标价普遍偏高。比如最红火的“极品飞车”、“最终幻想”系列在高清移植到智能机上之后，高调标出了几十美元的价格。
在早期，企业或者个人靠市场标价还能有一笔不错的收入，但是随着时间的推移，免费应用越来越多。而iOS系统完美越狱的出现瞬间导致了市场上绝大部分的收费应用无钱可取，众多企业甚至关门大吉。直至今天，只有极少数的应用能够坚持收费并且继续发展。这里值得一提的是，随着移动互联网的发展，个人开发者越来越多地加入，但由于苹果高昂的手续费，黑卡盛行，再加上国内版权意识薄弱等因素的影响，可以说个人开发者想通过市场标价获得第一桶金已无可能。
3．天使&风险投资
这也是很多移动互联网企业最常见的一种资金来源。从2009年开始，不断地有传闻说，只要一个小小的想法就可以融资几百万甚至几千万！这让越来越多的人似乎发现新的致富之路，原来不买彩票也有机会变成百万富翁。创业热潮就这样开始了，他们三五成群开始了天马行空的想法，为的是拿到A轮投资。这些人中大多是很有想法，抱着远大理想的年轻人。他们以为只要有技术和好的想法就能够成功，殊不知创业远远比他们想像的艰难，而融资更是为别人做了嫁衣。
4．产品定制
这是我认为最稳妥的一种挖金方法，根据大公司的要求制作一些特定的应用，最好是智能机默认的应用。比如短信、输入法、联系人等强需求的软件。采用这种方式的前提是必须有能力足够好的销售人员去说服大公司，也需要有能力强的技术人员在客户要求的时间内完成产品开发。任何一个错误都有可能让一家创业公司失去生存的机会。
5．免费应用内部收费（in-app purchase）
事实上有个别企业因为此类收费模式赚到了很多钱。不知从什么时候开始，我们玩的一些免费游戏里除了成就系统之外，不知不觉就出现了“商店”这样一个概念，如果我们想要获得更高的游戏分数那么就需要购买收费道具。其中最杰出的必属于Clash Of Clans，该游戏让黑卡在淘宝上再次疯狂销售。接着，其他免费应用也出现了收费项目，比如微博的会员、拍照软件的收费滤镜等等。这类隐形收费的目的就是为了避免广大用户不会因为看到软件收费而连被下载使用的机会都没有了。但是由于Android太过开放、iOS系统越狱，大部分内部收费应用也是昙花一现。
6．广告
广告是一个在任何行业、任何模式下都不会消失的硬渠道。在移动互联网，广告更是猖獗。每次打开应用的等待时间、游戏娱乐、查看微博，都会出现它们的身影，有些甚至还有不知不觉帮助用户自动下载并安装广告软件。广告是一把双刃剑，广告的费用一直是非常昂贵的，投入得恰当可以带来更多的下载量和更大的影响力，反之则可能给自己带来毁灭性的打击。
从2011年开始，各个天使和风险投资的数量和数额都明显地呈下降趋势。即便如此，各行各业的人还是继续在移动互联网淘金，正式开启了全民淘金的时代。2.2 别人的嫁衣
许多年轻的创业者揣着自己琢磨了许久的想法去和投资人谈合作，拿到投资方的钱以为离自己梦想又近了一步，但实际上可能是离投资人的梦想又近了一步。
很多在创业公司工作的人都会感觉到流程混乱无序，这是因为创业者真的很忙。他们要忙着公司法律相关事务，忙着不停地抢注专利来保护自己的企业，还要忙着不停地忽悠投资人以求继续发展。我们常常说创业的人都需要有一技之长，看待产品的视角要远于常人，但是又经常感觉他们的想法一天一个样，有时候甚至背离最初的想法，这大概与投资人的加入有关。投资人觉得自己出了钱，那么这家公司的产品及其发展方向就得关心。随着时间的推移，想法还是创业者的想法，但是产品已经再不是当初创业者心中所想的产品了，而是变成了投资人手中如何快速赚钱的工具。
最近很多人和我提到自己是多么仰慕微信和张小龙。我个人对张小龙不做评价，但是我想将talkBox、米聊、飞信3个软件放在一起讨论。iOS版的微信1.0诞生于2011年1月21号，我们来看看这3款应用，不知道对于已经被微信洗脑的广大群众看来是什么感觉。2.2.1 TalkBox
我使用的第一个语音社交类产品就是TalkBox（也许关注此类产品的朋友还会想到kik）。Talkbox最初是由6人组成的创业团队，针对开车不方便接听电话的人以及盲人开发的全球第一款语音IM应用。于2011年1月上线，仅仅3天的时间，在App Store的下载量就达到了100万。在腾讯推出微信之后，TalkBox的占有量直线下降，最终TalkBox决定扭头转向海外市场。2.2.2 米聊
在使用TalkBox不久我便装上了米聊，纯粹是为了体验新产品。米聊比微信早一个月推出，其最初的用户增长量和媒体关注度远远超越微信。2011年5月10日，微信2.0版本发布。在此之前，米聊已先行一步推出语音对讲功能，用户反响强烈；TalkBox英文版也在国内拥有一批“高端粉丝”。之后，微信迅速推出了“摇一摇”和“朋友圈”的功能，从而奠定了胜利的基础。2.2.3 飞信
最后我们来说说飞信。我使用飞信主要是两大原因：其一是朋友们都在用，其二是可以用自己的移动号登陆并免费给其他号码发短信。
飞信Fetion是中国移动于2007年5月推出的“综合通信服务”，即融合语音（IVR）、GPRS、短信等多种通信方式，覆盖3种不同形态的客户通信需求，实现互联网和移动网间的无缝通信服务。飞信也许是移动做过的最大的、也是唯一的一个社交应用了。
不过说句实话，我个人觉得飞信的没落和微信关系不大，属于“自作孽”。
大家是不是对这段缠绵纠结的故事有一个大概的了解了？所以说，如果在那个时间段，有一家创业公司做一个产品叫做“微信”，那么现在的这个“微信”和上面那3者的下场也差不多。在我看来，最大的区别在于微信有着自己的产品定位和策划，并很好的利用了腾讯的用户群。现在米聊等产品已经是一个“四不像”产品了，也许一部分已经是投资人的了。
如果在读这本书的你正在为投资人做嫁衣的话，也不要气馁。因为在移动互联网实在有太多的人都挣扎着没有放弃自己的梦想，我衷心地为你们加油。2.3 超越光速的迭代
仅仅有想法是没用的，接下来就需要实现。就我目前的了解，移动互联网应用的平均迭代速度远远超过了传统互联网的任何一个产品，相比以前互联网的项目迭代速度真可以称之为“光速”。在移动互联网，一般项目的开发周期在1～2个月，而项目的版本甚至一天就会迭代好几次。同传统的软件开发相比，这种巨大的差距来自于移动互联网的特殊性。
1．创意高于一切
假设有一个应用项目，需求在2个月内完成20个功能。很有可能，在某一天熬夜写代码之后吃早餐刷微博的时候，发现另外一个有着相同创意的应用已经在市场发布了，并且在微博上已经有数万转发。那么在移动互联网会发生这样的举动：仅仅完成创意的功能，其余的可以全部不做，尽量赶在另外一个应用发布前发布，这就是现状。用户不会关心创意是谁的，先入为主很重要，在他们看来其余的都是抄袭第一个应用的。
2．成本低
在移动互联网，一个应用制作到发布的成本都很低，一两个开发人员就能够在短时间内做一个可发布的应用。对于企业来讲也是这样，要发布一个应用到网络市场是非常简单的事情。即使用户在使用应用中出现了任何严重的问题，企业也能够在很短的时间内快速修复问题再发布（当然要排除一些金融、医疗等行业的应用，由于行业关系，它们依然存在高风险性）。对用户而言，下载一个应用并安装使用的成本更低，毕竟人类是一种喜新厌旧的生物。
3．需求不明确
需求一般有3个来源。产品经理、客户和用户。● 用户永远不会满足于自己已经使用的应用，他们一直期盼软件更
新以满足更多的需求；● 客户一般是周期性地提出需求，虽然有时候会不明确，但不是最
终导致快速迭代的原因；● 剩下的就只有产品经理。团队获取需求的来源其实都是通过产品
经理，而大部分需求不明确的原因也是因为产品经理错误地理解
了用户和客户的需求。
谁的错？当然，也不能说都是产品经理的错，往往团队本身就缺乏一种很好的沟通流程来明确需求。此外，还有一部分原因是一些产品经理每天都有天马行空的想法。
在这样快速的迭代周期中，开发人员满足需求已是难事，事实上，能留给测试人员的时间是少之又少。目前，一般的app开发都会采取很多公司老板和员工自创的“敏捷模式”，其本质就是压榨程序人员：开发人员为新功能疲于奔命，测试人员既要测试新功能，又要做老功能的回归测试，这样一来必然纰漏百出。所以，更需要测试策略和高效的测试方法来支撑，相关内容会在之后几章详细介绍。2.4 可怜的测试团队
在IT行业内，有一个问题一直被讨论着：“在一家企业中，开发人员和测试人员的合理比例是多少？”。每当听到此类问题，总有人会说“微软公司的开发人员和测试人员比例是10：1”或者“将来没有测试人员了”。随着移动互联网产品越来越火，敏捷测试也跟着流行了起来。敏捷测试提倡“全民测试”，也就是企业内部无论什么职务的职工都是测试人员。那么，测试人员占全公司的比例应该是多少呢？
问大家一个问题，如果你要做一个移动应用，在如此快的迭代周期，处于如此激烈的竞争环境下，是先选择招聘开发人员还是测试人员呢？答案可想而知。无论是大公司还是创业公司，团队人员或是技术都是第一位的。那么，在一个团队中，测试人员的比例应该是多少，我想大家心里已经有答案了。不过，我还是提供一个实际的信息，在初创团队中很少看到测试工程师。创业者会告诉你，产品都还没有成型，没有必要去招测试工程师。在大公司中，往往几个产品多个平台并行开发，比如曾经有一家大型搜索公司，两个产品四个平台，功能测试和自动化测试工程师加在一起，也不过10人。
测试团队不但人数少，还被极大地压缩测试时间，这在移动互联网行业中已经见怪不怪了。也许有人会说很多团队就是要小而精的。那么接下来就说说团队质量如何。对于创业公司来说，虽说已拿到了投资，但毕竟都要用在刀刃上。团队中往往有几个资深的开发人员以保证产品的正常上线，测试人员则多数是由应届生和实习生组成的。大企业会组建一个测试团队，团队中的测试经理一般由企业内部转岗人员担任，其他成员则由应届生或是测试外包工程师组成。由此可以看出，移动互联网行业中大部分的测试团队不但人数比例小，而且平均测试技术也不强。2.5 敏捷中毒
无论项目团队是否实施敏捷，整个行业的节奏正逼迫着所有的团队在向敏捷靠拢。2001年提出的“敏捷宣言”是敏捷历史上的一个里程碑。敏捷宣言如下：
从敏捷宣言中不难看出，它并不否认传统项目开发中的很多内容，但更强调沟通，强调随机应变。由于现在大部分的企业和员工并不了解敏捷开发的实质，所以现状就演变成了：
很多测试工程师认为敏捷就是不再需要测试计划、测试用例，只要自由测试就可以了。恰巧在同一时期又出现一个新概念——“探索性测试”，这让测试工程师们更坚定了随机自由测试的谬论。敏捷和探索性测试的方法、流程不在本书探讨范围之内，感兴趣的读者可以自己了解。2.6 无力的测试
自Google公司的Android系统面世以来，机型层出不穷，各种各样的Rom也是铺天盖地。在短短4年的时间内Android从最早的1.0版升级到了现在的4.2版，升级速度实属罕见。为保证应用可运行在不同版本的Android系统下，就必须全面测试应用的兼容性，这样就大大增加了测试工程师的碎片化测试（直到我写这本书的今天，Android2.3依然拥有着一部分受众），这对于开发和测试都是极大的挑战。
相信所有Android的开发工程师都不会忘记，为了让应用能够在Android各个版本的智能机上获得更好的体验而一遍遍地进行适配的痛苦。而此时测试工程师们面对的是一个基本上无解的问题——Android智能机的适配测试该怎么做？在这个问题面前，任何精湛的测试技术都变得苍白无力。
相信很多做过Android应用测试的人都会有这样的经历：在公司内部做的测试已经自信满满地结束了，但是一经发布，到用户使用的时候，各种明显的缺陷报错瞬间可以淹没企业的通讯系统。我相信每个经历过的人都曾经为这样的情况而倍感无力。
此时有两个看似很不错的解决方案放在眼前：一是使用Android模拟器，二是使用Testin或MTC这样的兼容性测试平台。不过我可以很负责地告诉大家，截至到本书成书之时，这两者都是不可靠的。
Android模拟器的确可以模拟各种设备的分辨率以及各个版本的Android系统，但是，由于模拟器是Java虚拟机构成的，在任何配置的PC上其性能表现都很慢。就我两年测试国内外各个智能机的经验来讲，模拟器中的应用显示以及功能与实体机还是相差很远的，更不用说像小米或索尼爱立信这类定制的智能机。
Testin是一家我很看好的公司，在2012年12月我还有幸去该公司，学习他们如何做大量的智能机应用的自动化测试。但我前面说不可靠的原因基于两点：
其一，无论Testin还是MTC，目前的兼容性测试服务做的还不够成熟。使用过的人都知道，现在移动互联网兼容性测试平台已经能够很好地支持在各种智能机上面进行安装、卸载、打开、MonkeyTest等测试，但是仅仅这些测试并不能满足日常的测试要求。
其二，这类测试毕竟是借助第三方平台进行的测试，如果上司或客户让我给出一份产品的兼容性测试报告，我是无论如何都不可能将第三方平台的测试结果给他们看的。毕竟作为测试工程师，我只相信真正测试过的以及我所看到的，这类测试报告只能当作参考。提示：那么朋友们肯定要问：“我们测试工程师该怎么办？”对该问题的解答将在后面几章中介绍。
苹果的iOS在兼容性方面比Android出色得多，但是同样使测试工程师的测试感到非常的无力。兼容性好不等于不用测试，且苹果的iphone、ipad价格一直不低，一般企业管理层认为各有一台就足够了，这给苹果应用的兼容性测试带来了极大的困难。随着苹果iOS系统遭破解（也就是所谓的越狱），出现了很多系统插件，这类插件在某些情况下会非常大地破坏iOS原本的生态平衡，也使得原来能正常运行的软件变得不稳定，自此越狱系统也被纳入了不得不测试的范围。此外，苹果的app store审核机制对测试工程师来讲更是雪上加霜，苹果应用的审核一般要一周左右的时间（节假日不包括），意味着产品发布之后如果有严重的问题，不能马上用一个新的版本替换，只能先从市场上下架。所以iOS应用的测试工程师压力相比Android的只会更大。
那么移动互联网的测试工程师到底应该怎么做测试呢？如何改变这样的现状呢？本书的各个章节只是给出了一些引导方向，更多的还是需要大家根据公司、项目、人员等具体情况具体分析。2.7 浮躁的测试工程师们
本节仅仅写给测试业界里那些浮躁的测试工程师们，切勿对号入座。测试业界中除了一些技术牛人和一些会忽悠的“大佬”以外，剩下的工程师们大多挣扎在各个企业中。他们不仅要和开发做斗争，还需要和生活、和薪资做斗争。从长期来看，这些人大部分就是在浪费时间，不学无术，但他们自己却还觉得社会很不公平，各种委屈。我列出一些浮躁行为，大家切勿对号入座：2.7.1 社交中毒
我自己在刚学习测试的时候加过非常多的群，原以为能够在有问题的时候找到几个“高手”来解决问题。直到加了之后，我才发现几乎所有的群都是整天在聊天，无任何技术讨论话题。群中关心的问题无非是：● 薪资。别人拿多少钱，自己拿多少钱，然后开始讨论怎样才能够
拿到更多的钱。● 抱怨。抱怨团队，抱怨流程，抱怨老板。抱怨一切可以抱怨的事
情。● 公司。大家开始晒各自的公司，大公司的人就会受到很多人的敬
仰。● 求职。不停地销售自己。
QQ的确是一个好软件，在中国长期以来积累了大量用户并屹立不倒。但它就和毒品一样让人容易上瘾，在不知不觉中浪费了时间，也将全部整块的时间碎片化。现任豆瓣技术总监的段念曾经告诉我，不要企图在QQ群里得到很多核心的技术，那里更多的只是在浪费时间。我现在也越来越深地体会到这点。
我只想问那些在QQ里讨论以上几点的测试工程师们，你们与其在群里聊天，不如将这些时间用来学习，你们觉得这个解决方案怎么样？2.7.2 失去自理能力
在我长期QQ隐身在线期间，看到很多测试工程师作为一个健全的，甚至是一个技术人员，却完全不会自理。比如以下几个问题经常会连续的出现：● 我想学习MonkeyRunner，请问MonkeyRunner能做点什么？● MonkeyRunner环境已经配置好了，请问怎么写？有没有什么例
子？● 请问MonkeyRunner除了模拟用户操作还能做什么？● 有没有什么文档？● ……
这些问题不仅仅出现在移动互联网，只要这些测试工程师们不改变自己学习的态度和习惯，那么在任何一个领域、任何一个技术上他都会出现同样的问题。他们面对一个对他们而言未知的事物就完全丧失了自理能力。我能说的是，Android或者别的所有技术都能够在其开源文档或者WIKI找到很详细的描述，请自行学习。2.7.3 不能正确认识自己的价值
我在新浪微博上曾经发过以这样一段对话：A：“你好，你这边招聘测试工程师吗？薪资大概多少？”我：“你好，具体看应聘者的能力而定。”A：“我以前就是做Android的，有5年工作经验，很符合你们的要求。”A：“还在不在？我是本科毕业，做5年大概能拿多少钱？”A：“这个是我的简历，5年你差不多给个价就行了。”我：“……”
很多朋友肯定会觉得上面这个测试工程师怎么那么傻，自己肯定不是他这样的。不过从事实来看，测试业界的确还有不少这样的“工程师”。他们有几个特点：● 对别人的薪资很感兴趣。● 不务实，不知道如何自己解决问题。● 只从薪资、学历、工作年限来描述一个工程师。
一名测试工程师的价值到底是如何考核的？绝对不能仅凭学历、工作年限、薪资等来评价，关于这点在第1章已经详细叙述了。同样是测试工程师，有的人一边工作一边总结，同时和业界的其他工程师沟通交流，每天都有进步。而有的人仅仅是在劳作，每天做着重复的业务，工作十年二十年和工作头一年没有区别。我们需要正确地去评价和看待自己。2.8 测试沙龙和培训
相信测试业界的工程师们都有这样一个感觉，近几年来测试业界大大小小的沙龙越来越多。在国内，每人费用四千多的沙龙也有。大部分的沙龙做分享的人是学术派、理论派的所谓的“老师”，他们可能以前做过测试，只不过时间早了一点，但是长期脱离一线之后，他们剩下的其实也只有一些理念和经验罢了。有一部分前辈的确是想将测试做好，是想帮助更多的人。但另一部分人就纯粹是为了自己的利益，为了赚到更多的名声和金钱而在各个大小沙龙“扯淡”，很多没有分辨能力的人受迷惑也正中了他们的下怀。
那么，沙龙真的对我们没有帮助了吗？我们去参加一个沙龙活动，首先要想清楚自己去的目的：可能是为了解决某个具体的问题，可能纯粹是想了解一下别人使用的技术和流程，也可能是为了得到某些启发。无论是哪种，只要想清楚之后再参加沙龙，才会真正的有所收获。
我个人最喜欢的沙龙形式是互动的形式。站在台上的人不一定比台下的人都厉害，大家是平等的，可以非常自由地针对某个问题进行讨论。与其一味地灌输理念和方法，不如一起交流，去切实解决大家心中的疑问。沙龙的内容必须与时俱进，很多业界的前辈一直在说一些过时的理念和概念，而一说就是好几年。我个人认为这些人可以讲，可以分享，但适合以个人免费沙龙的形式开展，而不适合在大型的收费沙龙上去“扯淡”。
试读结束[说明：试读内容隐藏了图片]