高楼访谈——软件测试魅力何在（转）

  高楼，ID Zee，曾经作为性能测试、性能调优高级工程师和性能测试项目经理参与过多个大型企业及机构的测试服务、咨询和管理工作，提供专业的测试支持和服务。曾编写大量性能测试理论及实践相关文档，曾编写一些完整的测试案例，并对性能测试原理、性能测试实施和项目实施管理有非常深入的看法。

　　采访内容如下：

　　问题：能否先简单谈谈您在测试领域的从业经验，和您对此领域的理解？

　　高楼：我刚毕业时是做路由器的软件测试，那时是对着一堆的路由器跳来跳去的，这个过程对我挺重要的，让我理解了网络中的一些比较关键的知识点。后来的工作就转向应用层的性能测试领域，这是我自己的选择，我比较喜欢应用级的性能测试，这个阶段让我对应用性能的认识提升比较快，也让我慢慢的关心应用的逻辑实现，关心上层语言的性能优化。以后的工作经历几乎都在应用层的性能测试方面，不仅做一些具体的性能测试实施、分析优化的工作，也带领团队做性能测试服务。

　　从我做这些年的测试经历来看，当前的测试领域可谓五花八门，它没有软件开发那么长的历史，纵然有些测试的理论已逐渐成型，但是这个行业的从业人员技术参差不齐。有些初找工作的人因为不喜欢编码而走向测试，其实测试领域要求的技能并不比开发人员少。市场上一些利润导向的误导，也会导致从业人员技能差距较大。但是不管怎么说，测试行业在慢慢的成长、成熟。不管有多少负面的看法，都不能阻止这个行业的进步。

　　问题：软件测试的魅力何在？您为什么选择测试一行而不做开发？

　　高楼：这个问题乍一看不好回答，因为有好多人是因为不喜欢写代码才选择了测试行业。

　　其实我想反问一句：开发的魅力何在？为什么要选择开发？我想可能会有如下答案：开发是在创造东西，有成就感；开发代表着深入的技术，等等。首先，我觉得软件测试需要的代码功底并不弱，这一点在实际的工作中会有比较深刻的体会，之所以有些人觉得软件测试不需要代码功底，实际上那些做的都是基于业务需求的测试，了解业务是一个重要的方面，这是软件测试行业中的一个细分，那属于业务测试工程师。

　　我想带领大家看一下软件测试行业中的技能要求。在测试行业中，对一些基于业务的测试，要求一些测试用例的设计方法和策略，这方面也是测试人员的基础技能。并且业务测试要求对业务的熟悉度很高。自动化功能测试，要求有代码功底，并且对代码的要求一点也不比开发人员低。性能测试、性能分析职位，不仅对代码有要求，还对系统中涉及到的所有技术节点有要求，并不是说性能测试职位上的人可以把一个系统中所有的技术都干得下来，但是至少能把系统中的各节点能串起来，并且可以在某些细节上和相应的工程师沟通；当然性能测试的职位也是有细分的，所以还要看一个细分的职位是什么，还会有更细的要求，这个话题要说的比较多，这里只是说个大概。

　　所以如果想掌握深入的技术，做测试也是一个很好的选择。当然测试不能创造最终用户使用的产品，测试总是要有一个测试目标。如果你就是喜欢创造最终用户使用的产品，那选择开发当然更理智。这是方向上的不同，不是技术上的不同。但是如果想做好测试，我个人认为要求的综合素质要比开发高得多，在我的从业经验中，我认为写代码是一种能力而不是一种经历。也就是说，确定一个系统的正常运行比

　　创造出这个系统来可能更复杂。开发人员写了100行的代码，可能需要测试人员写1000行的代码去测试，这也是常见的事情。

　　我选择测试，应该说我选择的是一条挑战自己的路，我觉得这条路上，我可以有更高、更快的提升。基于这一目标，我不会局限在手工的业务测试上，我在不断的寻找被虐的机会，希望能成长的更快。

　　问题：有人说“开发人员在创造世界，测试人员在拯救世界”，在您眼中开发与测试是怎样的关系？

　　高楼：我从来没觉得开发人员创造世界，就算是说创造产品，我都觉得不正确。确切的说，我觉得产品经理创造产品，而开发只是其中的一小部分，测试也是其中的一小部分。所以，我觉得开发和测试是相辅相成的，他们共同努力把一个产品变得可用、好用、生存周期更长。当然现在业内有开发和测试对立的情况存在，我只能说对立的开发和测试都眼光浅薄了，对立只能相互消耗。开发不好，测试也不好，反之亦然。一个最实际的情况就是，生产环境出现问题，大家都会觉得不好，不可能是测试是成功的，开发是失败的，反之亦然。

　　开发人员在根据需求写产品，测试人员在努力让产品做得更好，如此而已。要说拯救，我觉得运维更像是拯救的角色，毕竟他们面对着最直接的崩溃的用户。

　　问题：在您眼中，一名出色的测试人员，需要具备素质与知识？

　　高楼：首先，测试技能方面的基础知识，像用例设计方法、测试设计方法、测试流程、测试策略、测试工具等这些基本的要求，我就不强调了，这是必备的。测试人员要看具体的工作职位和工作性质，如果是公司内部的测试人员，那就要了解公司的产品；如果是项目中的测试人员，就要了解业务需求，根据客户需求来设计测试案例。更细的技能要求，就要根据产品或项目中涉及到的具体技术说了，举个例子，如果是一个weblogic+oracle的应用，那做功能测试的，至少要知道如何查看这两个产品和业务的日志，能定位出一个功能出现问题的时候，问题是出在哪里。类似这些具体的知识的要求，都要根据具体的项目或产品涉及到的技术来要求。

　　至于素质，像细心、工作态度认真负责、专注、奉献精神、专业、学习能力强、沟通能力、耐心等等，这些都是基本的要求。不过其他行业也一样，这些素质同样要求，所以这个不能算做测试人员特有的素质要求。我倒是想另外说一点：测试人员不要看扁自己工作的价值。因为我发现有些初中级的测试人员经常会说自己干的事情一点意义也没有，我非常想对这类人说，意义是靠自己努力提高自己再反馈到工作中体现出来的，抱怨会让人疲倦。执行一万个用例都没有bug能说没有意义吗？不执行怎么知道？所以这些工作有意义，只是有些烦琐。谁都能替代的重复的工作也是有意义的，要是觉得做没人能替代的工作才有意义，那就先练内功吧

　　问题：自动化测试到底是不是银弹？您怎样看待自动化测试？

　　高楼：我不认为自动化测试是银弹。这个问题应该和产品或项目的要求、自动化测试的代价联系起来。只要可以让一个团队很快的完成测试，那就是有价值的自动化测试。和手工测试相比起来，自动化测试要真的能节省成本、减少时间。如果这两个条件达不到，自动化测试就不值得推行。

　　我认为自动化测试在需求不停在变的产品或项目中是需要仔细考量的，在确定了自动化测试真的能达到节省成本、减少时间的前提下才去推行，否则，就是自找苦吃。因为对自动化测试维护的成本高于手工执行测试的成本，那将完全不值得做。

　　问题：有工程师期望打造强悍的小团队，包揽开发和测试的工作，您认为这样可行吗？

　　高楼：不是不可行，而是对这个小团队的要求很高。对一个有着丰富经验的工程师团队来说，这是完全有可能的。但是职位的减少并不意味着工作的减少，只是说这些团队中的强人们把其他职位上的工作一块做了，如果说开发写了几千行代码，试都不用试就可以拿出去给客户用，并且不出问题，我觉得那是神人，值得膜拜之。如果开发的功底强，做出的产品很稳定，并且有历史的数据可以证明只要少量的业务流程测试即可，那倒是没有必要非要留着闲置的测试人员，大可以砍掉。现在之所以测试的工作价值被弱化，一方面是测试人员能力有限，没有体现出自己的价值，一方面是需求变化快让测试人员措手不及。测试过的产品和不测试的产品到客户手里出现数量级相当的缺陷，那就足以证明这个测试团队没有存在的价值。

　　另外，打造什么样的团队和公司的性质有关，并不是从技术角度来看觉得这样的团队好就这么做。就像之前我参加一个活动，有人说测试人员很重要，发现了很多有可能引起宕机的严重问题；也有人说测试人员根本不重要，因为测试之后上线依旧问题汹涌。从资金投入、时间投入、团队成果的角度来分析一个团队应该如何构建，我觉得更有意义，而不是靠着技术人员的偏执。

　　问题：测试领域在2012年有哪些值得记录的进展？

　　高楼：2012年，其实并没有太大的进展，都是之前的一些理念的推进。像探索性测试、敏捷测试等都在推进，至于测试技术本身，我觉得没有值得记录的进展。

　　当然在大家成长的同时，也有更多的新人涌进这个行业，并且有些人为了利润而不惜一切代价把自己并不成熟的技术误导式地教给新人，也导致了行业更为混乱，这是要注意的。希望行业中的人更沉稳、理智地去做对行业有利的事情。

　　问题：您认为测试在未来会有怎样的发展趋势？

　　高楼：以后的测试发展，我希望能很快的好起来，但是这也要看这个行业的人有没有在认真的做事情，靠着吹嘘出来的市场繁荣不可能有太好的发展。

　　在测试人员方面，以后的要求会更明确，技能要求更高；在业务方面，现在各企业对测试的认识正在慢慢形成，所以市场的需求量也会越来越大。当然最重要的是高端的技术人员需求量会更大，现在高端的技术人员需求量已经是瓶颈了。

　　在业务方面，不仅金融、互联网、保险、电信等企业有更多的业务机会，其他的传统行业也会有更多的业务机会。

　　问题：谢谢接受我们的采访，最后再问两个轻松的问题：长期从事软件测试，会有职业病吗？

　　高楼：我觉得职业做长了，总会有些职业的影子，这没办法磨灭。就像看到我之前在地铁上看到画面出现异常，就会想是什么原因，这也是正常的。但是思维观念上有多少的影响，我并不确定。更多的思维观念，我觉得来自于性格。

　　至少我觉得我现在还没有职业病吧，因为我腰间盘没有突出，生活中也没有体现出我的工作思维来。

　　问题：如果不做IT行业，您会考虑做什么工作？

　　高楼：拍电影呀。往那一戳，挤两个表情，摆两个姿势就赚钱，并且赚的还比做IT的多，多好。

（转自：http://www.51testing.com/html/14/n-841914.html）