先说一个故事。

　　接手一个小项目，是因为之前的项目经理被调走了。当时跟我介绍项目情况的时候，这牛人项目经理说，项目完全没问题，功能就那么一点点，很容易搞定的。我随口问了一句，有测试人员吗?答曰，这么简单的小项目，还需要测试人员吗?我茫然。

　　这牛人于是就介绍完了，把这个当时运行很流畅的项目组交给我。每个人都把客户需要的功能做出来了，也已经拼接好了，好像我接手就是来拿做好的成果一样。

　　忘了介绍这牛人了。这牛人为什么叫牛人，是因为特能加班。每每在项目交货的时候，跟客户耗上那么几个通宵。并且，还带着整个项目组去耗。我自认没有他那么牛。

　　接手项目，并不是马上就插手乱指挥，这是我的原则。但是还有2周就要交付了，我也没有太多时间去慢慢了解项目。于是，在项目的第二天，我就去找部门要测试人员了。问我理由，答曰，没有理由，就是要2个测试人员。

　　很容易的就要到了两个PLMM。看着MM我就心里舒坦。而且两个MM之前还没测过手机项目。没关系，有测试就行。

　　熟悉了一天之后，PLMM们第二天就发现了一个很简单的BUG。简单的说，就是ListView的数据，在一些操作之后，就乱套了。本以为很简单的BUG，也就没多问了。

　　第三天，项目组成员们很紧张的忙着。第四天，还在忙。我有点坐不住了，去看了一圈代码，感觉有点晕乎。再看，猛然发现，这些代码的数据结构就不对，需要重做!

　　我的乖乖啊。这是神马啊。如果我放任这情况下去，在项目交货的时候，我也要被逼做牛人了啊!

　　还好测试人员进入的早，这BUG带来的影响，在重构代码后，终于平息下来。我们在交付的时候，没有为业务逻辑而通宵。当然，客户的硬件和框架着实让我们牛了一回。我们只是晚上在等客户解决问题的时候，打打牌而已，没有被客户追着改BUG。

　　故事说完了。“故”表示已经发生，“事”表示有这么一个经过。

　　我不禁要问，难道有那么多人，认为手机项目，就真的不要测试了吗?

　　传统业务领域，测试人员的重要性已经被大家所接受。我在做项目经理的时候，一般是偏袒测试的，因为我对他们的支持，他们才可以放心的发表不同的意见，才能把问题尽早的暴露出来。当然，也因为我的支持，测试人员经常犯错，把一些正确的当作不对的。不过，我宁愿测试人员犯错，也不希望BUG和问题隐藏到最后，到最后客户发现了，那就非要“牛”不可了。

　　测试人员 ，在传统业务领域，做的几个验证工作，可以用一个V字模型来说明。

　　1， 单元测试，是对编码的验证，保证编码无误，也就是保证某个单元(可以是页面，可以是某个流程等等)被正确的编码。

　　2， 结合测试，是对详细设计的验证，保证各个单元串起来之后，能够完成基本的业务流转。

　　3， 功能测试，是对功能设计的验证，保证系统的各个大功能得以正常流转。

　　4， 用户体验，是对需求分析的验证，保证系统就是用户想要的东西。

　　左边的开发流程，在手机项目中，因为项目的短平快，导致了很多缺失。简单的和客户沟通之后，客户可能只是给了一个大致的描述，几张效果图。开发组立即就对这些客户给的资料进行设计，这个设计就把功能设计、框架设计、详细设计、程序设计等等都包括了进去。以至于，只有开发人员才知道客户的需求。

　　在这种情况下，整个项目组对测试人员是排斥的。而且测试人员对项目组也是排斥的。测试人员拿不到测试的依据和准绳，对测试无从下手。开发人员不愿意再去复述客户的需求，也不愿意再去整理各种设计，因为他们觉得代码就是一切，设计都是为了代码而做的。现在代码已经有了，还要再去整理设计干什么。

　　因为手机不如PC的屏幕大，所以很多人认为手机操作比PC程序简单，逻辑也相对简单，所以没必要加入测试人员。开发人员自己跑跑就行了。

　　以上的各种理由，都造成了短平快的Android项目排斥测试人员。甚至大型的Android项目也对测试不重视，认为有就行了，比没有好。

　　我在项目做完之后，认真的思考了测试人员在Android项目中，可以并且应该起到的作用。

　　1. 用户需求的理解

　　现在讲究的是用户体验。对于开发人员来说，天生的自信往往让他们以技术的角度去想问题。技术越牛，往往越会有这种倾向：这个技术多先进啊，用上去之后肯定是好东西。慢着，技术先进就是用户的需求吗?所以，我们需要测试人员去理解用户需求，真正把握用户希望要的东西。因为测试人员的独立性，他们不会被技术细节所蒙蔽。

　　2. 系统的整理操作流程

　　手机因为屏幕小，操作少，所以操作流程往往被忽视。其实，手机程序一点不比PC程序简单。大量的关联操作，将极大的考验我们程序的健壮性。可以这么说，相对PC程序，手机程序的大段的逻辑不多，但是逻辑分支却比PC程序更多。也就是说，手机程序有更多的路径需要覆盖。

　　这些操作流程，在缺少设计的情况下，由测试人员来整理，肯定比开发人员整理要专业。测试人员可以只凭用户的一些简单信息，例如客户给的效果图、客户口述等，就把一份大而全的Case分支给整理出来。当然有些是无法走到的，那个不会有太多影响，最多浪费点验证和思考的时间，但是不会把一些细小的分支给漏了。

　　手机程序必须比PC程序健壮。手机程序会经受用户的各种操作，正常的和异常的。毕竟手里拿着手机，很可能突然朋友吓一跳，就不小心按到了某个键。所以说，缜密的操作流程，需要测试人员来整理。

　　3. 细致的回归测试

　　为什么我跳过测试，直接就说回归测试呢?因为测试工作本身，不值得一提。那是测试人员的基本工作，就像开发人员写if - else 一样。而且，很多人都认为，手机测试，开发人员互相测试也是可以的。但是回归测试不同。开发人员没有大量的时间去做测试。哪怕有这个时间，开发人员也不会有足够的耐心去走回头路。放心，我们的测试人员有，他们耐心细致的工作，会告诉那些不小心犯错的开发人员，你们要当心了……

       4、跟踪BUG的解决

　　手机项目因为人员少，所以很多人改问题都是自发的。一个开发人员，很可能早上自测的时候发现了3个问题，但是当他改完第二个问题的时候，就不记得第3个问题是什么了。而专门的测试人员，记录、跟踪BUG的解决，是他们的基本素质。我们可不希望项目在交付给客户的时候，客户发现了一个问题，然后我们的牛人说，啊这个问题啊，我以前碰到过的，但是忘记改了。

　　5、调节项目组气氛

　　呵呵。一般测试组的美女多么。这条可是最重要的一条哦，别小看了小伙子们的肾上腺素，那可是天然的兴奋剂啊。

　　以上说的这几条之外，还有很多测试人员的好处啦。所以，千万不要以为手机项目小，项目简单就忽视了测试人员的重要性。

　　是不是有人说，哪里有那么多人给你啊，开发人员都不够，哪里来的测试人员。

　　我的想法是，哪怕你现在手上只有5个开发人员，没有测试人员了，你也要从这5个开发人员里面，挑出一个最合适的人来，做一个专职的测试人员。别怕项目紧张，因为在交付的时候发现致命问题，会比你在前期辛苦的加班晚一点，更好控制。你说是不是呢？