此文是我个人对测试的看法，文章内容仅仅代表我个人观点，如有雷同便是共鸣。

　　测试工作的目标是质量和效率

　　在说测试工作的目标前，先看看软件测试的定义。下面是IEEE对软件测试的定义：

　　Software testing is the process of analyzing a software item to detect the differences between existing an d required conditions (that is, bugs) an d to evaluate the features of the software item.

　　从定义可以看出，测试工作是按照需求，发现软件中的缺陷。

　　既然是发现软件中的缺陷，那就是说测试工作的首要目标就是质量，使用各种方法保证软件的质量。但是如果为了保证质量，花上100人日的时间来测试一个10人日就开发完成的软件显然是不合理的，所以在保证软件质量的同时也应该保证效率。

　　甲方乙方

　　在整个软件生命周期里，应该分清甲方和乙方。我们一般的甲方就是客户，或者说是需求方，软件研发是乙方，或者说是需求实现方。那乙方的工作和甲方的工作应该有很明显的区别，甲方定义需求，乙方实现需求。

　　可见，需求出现问题并不应该由开发负责，更不应该有测试负责，乙方仅仅算

　　那测试显然属于乙方。举个简单的例子，中国电信（甲方）需要一款计费系统，有某软件开发商（乙方）负责开发，那么由中国电信出需求说明书，软件开发商负责需求细化和开发，乙方要做的就是把需求说明书中的需求全部实现，至于这个计费软件的计费策略是否合理，那就是由甲方来决定了，即使错了，也是由甲方承担后果。

　　那么，互联行业并没有真正的甲方，由乙方直接面对客户，那么PD这个职位就应该是甲方，需求出了问题也是PD承担后果，如果我们质疑PD的需求并拒绝开发的话，按照上面的例子，软件开发商对中国电信说：你这个需求有问题，我们不开发。好吧，那这个软件开发商离关门不远了。

　　也许你要说：“我们是站在整个产品角度思考”。这句话没有错，站在产品角度思考也没有问题，承担甲方工作也没有问题，但是前提是你的乙方工作已经做得足够好了，如果你的乙方工作还一团糟或者还是研发流程中的瓶颈，而你要去做甲方的事情，那我只能说你是“吃地沟油的命，操中南海的心”。

　　可能又要说“站在客户角度思考”，站在客户角度思考的前提是有客户的思想，了解客户要什么，而且是了解大部分客户人群普遍要什么，也许你是客户之一，但仅仅是之一，不一定能代表大部分人。所以如果你没经过科学的客户调研就说自己要站在客户角度思考，你Linus大神的一句话来说，你不过是“自慰的猴子”而已。

　　解决质量和效率问题的“铜弹”

　　先说下高级一点的“银弹”是什么，就是“大招”，绝世武功，一招致命，即使对方不死也能使其半残。那测试里面究竟是否有“银弹”来同时解决质量和效率问题呢，显然没有，如果有“银弹”的话，测试行业已经消失了。

　　虽然没有“银弹”，但是“铜弹”还是有的。一套完整的持续交付体系就是“铜弹”，完善从需求评审、软件设计、软件开发、软件测试、软件部署的全过程，使其流程固定、自动化实现、可复用。每个环节都全部打通，建立持续交付的流水线，让机器尽可能代替人工作。

　　持续交付流水线可以让从开发到最终部署，甚至是不同环境部署都做到一键式操作，各环节信息自动反馈，包括测试失败、部署失败、配置变更等都可以实时通知到所有相关人员，最终提高发布效率。

　　这里肯定会有人质疑说：“我们的系统比较特殊，不适用”，那我想问一下，“你究竟尝试过吗？还只是你拍着脑袋凭空想象的？或者你只是根据自己那些不知深浅的经验而推断的呢？”，另外再说两句，一是“你的系统和业务不是全地球上最特殊的”，二是“如果你不愿尝试是因为害怕失败的话，那就请该行吧”。

　　另外，如果你说：“流程改造和完善是SQA的事情”，那我要告诉你：“完善和分析需求还是PD的事情呢，还不是很多人一样在做”，这样看来，SQA和我们工作更贴进，我们更应该去做。

　　业务不是救命草，也不是上吊绳

　　我们总说“业务测试”、“中间件测试”、“数据库测试”等等，我们自己把测试分为三六九等，并且自己内心深处也认为所谓的“业务测试”是最没技术含量的，那就来说说“业务测试”中的这个“业务”。

　　“业务”这个东西其实是比较抽象的，以一个电信计费软件为例，我想所谓的“业务”就是只这个软件是具备哪些计费功能，类似按照时间段计费、按照套餐计费、中间再穿插一些类似费用优惠的功能，这可能就是所谓的“业务”。那“中间件测试”、“数据库测试”就没业务吗？如果这样推理，Oracle、IBM这些公司就有很多“无业务”的部门了，这推理是不是很可笑？所以这样看来，所谓的“中间件测试”、“数据库测试”也是“业务测试”。

　　可见，但凡是个测试都有其业务。那“工具开发”呢？很多人认为“工具开发”是个怪胎，因为有“开发”两个字，那只是我们悲哀的组织架构带来的误区。那“测试工具开发”应该被如何看待，后面我会说到的。

　　既然大家都有业务，那谁也不比谁矮一节，但是谁也不比谁的业务更“值钱”，公司层面会重视一些产品，但是并不是重视你的工作，不要做“一人得道，鸡犬升天”的事情，业务是要搞，但是不能过，保证了质量、提高了效率，把“乙方”的工作做到无可改进了，再去做“甲方”，业务不是你的“救命草”，抱住是没用的。

　　还有一种说法是“测试向前走”，似乎也是告诉测试人员应该多去关注开发设计编码和需求定制分析，但是只是告诉测试要向前走，没有说“不回来”，所以测试的本质才是工作的重点，过分关注“业务”正确性和系统“设计”正确性只能使你慢慢偏离测试道路。

　　另外一种情况是，并不沉迷于“业务”，但是每天为了眼前的“质量”被“业务”搞得焦头烂额，因此而忽略了“效率”改进的话，其结果是让业务掐住自己的脖子，最终成为自己的“上吊绳”。

　　技术不分测试和开发

　　不知道从什么时候开始把技术分为测试技术和开发技术，这是一个奇怪的定义，何为测试技术？测试使用的技术称为测试技术，开发使用的技术称为开发技术？那SCM使用的技术是否要被定义为SCM技术？DBA使用的技术要被定义为DBA技术？还是这只是测试人员为了逃避自己技术弱的一块遮羞布？当别人说测试人员技术差时，可以很自豪的说：“我不是技术差，我的测试技术很好，开发技术差而已，我是测试人员，掌握测试技术就可以了。”

　　一个简单的例子，编程语言属于什么技术？开发天天用，难道测试不用，或者发明一个新词，称之为“开发测试通用技术”，显然是很可笑的。

　　开发工具不是目的

　　如果说保证效率是测试的目标之一，并且技术不分测试和开发的话，那开发工具也就无可厚非了。当然，为了做工具而做工具的动机肯定是值得怀疑的，“大跃进”式的工具开发只能说是*******而酿成的恶果。

　　要提高效率必须要用机器取代人来工作，如果让机器工作，那就是需要开发工具了，工具是提高效率的手段也是产物，但不是目的。不要条件反射式听到“测试工具”就联想到“开发技术”，进而联想到“无用”、“浪费”、“为了KPI”等词汇。当然，开发工具并不是唯一提高效率的方法，也可以通过创新出更具有效率的测试方法，如同“正交分析法”可以帮我我们不需要做全正交就可以测试到所有场景，从而简化测试工作。但是测试行业发展这么多年，也很难出现一个这样的方法，所以说开发测试工具是最直接也最容易提高测试效率的方法。

　　同时，一个成熟的工具相比人来说，犯错的概率几乎为零，而人是一个不可靠的东西，“今天失恋”、“明天腹泻”等各种因素都会影响人的判断，如果靠人来保证软件的质量，我相信一定是靠不住的，所以说开发工具也是保证质量的手段之一。这样看来，每个测试人员都应该学会工具开发，在需要的时候靠工具提升效率和质量。

　　如果上面的说明都不能让你信服开发工具的作用巨大，那持怀疑和否定态度的人，好好数数你的测试工作中到底用了多少测试工具。如果没有缺陷管理、用例管理这些工具，你现在还在用excel表格维护这些内容，你没有缺陷状态这个概念，你还在为开发修复缺陷的进度拼命发着邮件、打着电话；如果没有测试脚本运行平台，今天你享受不到自动化带来的便利，你还在为系统每天出现bug焦头烂额；如果没有静态扫描，你今天对安全漏洞还无从下手。如果你还反对测试工具开发，那请你回到原始状态，我“亲爱”的原始人。

　　测试开发比是自然提高的

　　总是有人谈测试开发比，似乎测试开发比的提高就是要立刻开除大部分测试，似乎自己的工作马上就要丢掉一样，于是像“坐到了刺猬上”一样跳起来，强调测试开发比是多么的没用，测试人员是多么的重要，测试人员的减少是多么的可怕。

　　但实际上，测试开发比只是一个度量手段，是测试效率提高后的结果，当测试的大部分工作被机器取代后，测试人员的数量当然可以减少，只要少部分人去维护测试系统即可。

　　但是，如果把测试开发比当作一种目的，并以此单纯减少测试人员还忽略测试效率提升的做法是无知且可怕的，无知在对测试认识如此浅薄，可怕在如此浅薄的人在左右着测试人员的命运。

　　永远不要试图成为Superman

　　不会有人包揽产品发展规划、需求挖掘与分析、系统设计和编码、系统测试这所有工作，也许这看起来让一个人来完成是件非常“酷”的事情，甚至可以“意淫”出其所带来的各种好处，但在目前看来，其实是个“愚蠢”的想法。即使是一个纯技术性的开源公共类库，其作者（们）也不能完全了解使用这个类库的都需要哪些功能，所以才会不断的完善和改进，不断发布新版本，甚至某些功能还会被使用者称之为“无法理解”的设计，这就是一个典型的需求、开发、测试于一身的典范，当然，作为类库开发者来说，随着和使用者的邮件沟通，可以慢慢把控需求，但终究是有限的，很难说在一段时间后被其他相似类库取代其地位。公共类库尚且如此，一个大型商业软件就更加不可能将多职位集于一身，这是其中一种“superman”。

　　另一种“superman”不是将所有职位集于一身，而是将软件的所有功能和系统架构的认知集于一身，这种“superman”也许存在，在软件的功能非常有限，系统非常简单的时候，随着软件功能的增多，系统复杂度增加，这几乎是件不可能的事情，谁能把“windows系统”了解的一清二楚呢？

　　软件研发是一个团体性的功能，要想有superman出现，我想那应该是“机器”而不是“人”。

　　没有极客思想的测试不是好测试

　　还是要说一次那句反复被提到的话，测试的目标是质量和效率，要提高质量和效率的方法前面也提到了，那么如果一个固步自封、不愿接受新事务、不愿意尝试新东西的人如何能找到好的方法提高质量和效率。要像极客那样敢于去“玩”一些酷的东西、使用“酷”的技术，也许创新就会出现。