前段时间在思考有关如何提高软件产品质量的时候对软件测试产生了一种很强烈的质疑：软件行业根本不需要软件测试！在软件测试本身不做任何创造性劳动的情况下，如果我们说软件测试本身并不能保证产品的质量，那就更加深了我对软件测试的否定。软件既服务，当我们对我们所服务的对象都没有吃透的情况下就开展软件开发、当我们开发过程中没有遵循质量优先的原则就要将代码提交测试、当测试人员都未真正了解业务的情况下就将工作开展、当一次次的重写、重构、优化仍然没有达到我们的目的的时候，那所有测试工作都将是徒劳，软件测试也将永远摆脱不了出力不讨好、不受人尊重的命运。在这样的情况下，再谈软件测试的需求市场有多大、开发测试人员比例是多少、软件测试行业多么黄金、软件测试培训、软件测试外包多么火热，都是闲扯淡！试问，步入软件测试行业的你，是不是因为测试行业门槛低才进入的？是不是因为找工作的时候迷茫不知所错瞎猫撞着死老鼠才进入的？是不是在步入此行业之前连软件测试做什么、什么是测试用例都不了解？是不是被那些个为捞钱而作做软件测试培训的大忽悠忽悠进来的？有几个，是因为实在热衷于在这个行业、做了很多年的开发或业务研究又想在测试行业打拼一番、有志于为提高软件质量而奋斗才步入软件测试行业的？很少吧，但这些少数才是真正的精英！但精英实在太少了。一开始大忽悠们把测试定位成一个很容易介入的行业本身就已将其打入了谷底，进而形成恶性循环。软件测试外包很流行么，还不是咱们的人力成本低么，人力成本低人家能把核心的东西给这些人么？

   写到这里，应该有人开骂了，丫头是不是受了什么刺激或者是委屈，还挺愤青，什么低低高高，自己不重视自己那还能得到别人的尊重？好，那就说点积极的啦，如果软件开发流程能像一个厨艺非常娴熟的厨师做菜的流程一样，那软件测试本身就失去了它存在的意义，就像厨师做完菜之后根本不需要品尝、质检，直接就放到客户的餐桌上了。但毕竟软件开发流程没有那么规范、也没有那么成熟，更不像做一道宫保鸡丁那样简单，而且软件服务的行业和不同的软件企业需要的开发模式也千差万别，在这样的情况下，测试还是必不可少的。那测试既不能保证产品质量、也不参与产品的创造，又想得到其他人的尊重和敬仰，那它应该做什么、怎么做，我们又如何给软件测试行业定位呢？好，那就是接下来我们要说的软件测试的未来。

   1、软件测试仅需要少数精英。你我都赞同当任务压过来的时候，不应去靠人海战术去拼去补。而应该采用高精尖的'武器'(工具)和’思想‘(方法论)去吓倒（预防）bug或消灭(快速修复)bug。少数精英就是这些高精尖武器和思想的缔造者，他们或许是业务专家、或许是质量顾问、或许是高级工具开发人员。

   2、软件测试在软件业务研究及孵化阶段既开始介入。你我都知道软件缺陷越早发现或越早预防越好，那为什么测试到中后期才开始介入并放在一个非常被动的位置呢？测试应该及早介入，做什么呢？业务分析、业务测试、业务案例的编写及可测试性需求分析,那么在这个阶段，测试充当的角色和需求人员相似，并肩负监督需求合理性、正确性、完整性的责任，既，是一个复合型人才。
  
   3、软件测试人员在开发初期帮助开发人员围绕软件业务开展工作，同时开发过程中开发根据可测试性需求为测试提供接口。同时围绕软件辅助自动化工具开发、脚本编写，这里提到了自动化，是的，自动化本身不单单是测试人员的事，而是开发和测试共同的事情，工具测试软件，工具本身离不开软件，自然离不开软件为其提供的接口（代码及人）。

   4、软件测试系统的诞生（平台/架构/流程），涵盖流程管理、人员管理、bug管理、用例管理、自动化管理、机器管理。
  
   5、软件测试晚上进行、持续运行。测试机器人（自动化系统）将代替繁复或简单重复的人工劳动，不分昼夜发挥老黄牛精神地干活！
  
   6、QA、软件测试职责分清，即使你我不会混淆质量保证与软件测试的概念，但实际的情况下，大多数QA都在做质量监督的活，却极少能做到质量保证，而且大多数人都会觉得质量保证应该靠测试人员。那既然QA起不到质量保证的作用，那就少点投入，监督一下即可。
  
   7、软件测试需复合型人才，而非专业人才。第一点也提到了，测试人员既是业务专家或是质量专家或是出身软件开发，但又不单专注于业务及技术，所以复合一词出。所以软件测试与开发需求的界定会比较模糊，软件测试将与需求、开发一道开发高质量的产品。

   8、测试部门演化为质量部门，测试部不再单单是为了提Bug、写测试用例、制定测试方案而存在，而是演化为围绕提高产品质量进行质量提升方案改进、开发流程优化、持续过程改进、质量保证、质量监督、软件测试等一系列活动的质量部门。质量部门成员组成：质量总监、QA、测试系统及自动化系统开发技术人员、业务测试专家及普通测试人员

   9、最后，提起软件测试，嗯，终于可以扬眉吐气了！

那么，有预想就有方法，如何让软件测试的未来来的更快呢？

   1、不转变对软件测试职业的思想是不行的
  
   2、仅招廉价的劳动力而不考虑对复合型人才的培养是不行的、舍不得孩子是套不着狼的
 
   3、理不顺自己要做什么、应该做什么是不行的

   总之，理不顺这个思路，会觉得很难。但如果您觉得值，用心做，有权做，理顺了，不难。

   This is the future,not a dream!  

注：以上纯属个人唠叨，也许会招来民“粪”；但愿不会对有志于从事软件测试或正迷茫于自己是否适合做软件测试的小弟小妹们造成打击！不过，目的还是好的，为了更好的做软件嘛，呵呵

主题一、我们可以参考的东软及金蝶软件质量过程管理

1、  东软质量过程改进体系:

   优秀的人才要发挥最大的潜能需要有正确的过程。过程决定质量，通过对过程进行持续改进，实现向客户交付高质量软件产品。什么是软件过程改进？下面供参考：软件过程也就是软件产品的生产过程，也包括软件维护之类的维护过程，而对于其他的过程并不关注。

对于软件企业来说，软件过程是整个企业最复杂、最重要的业务流程，软件产品就是软件企业的生命，改进整个企业的业务流程，最重要的还是要改进它的软件过程。要想高效率、高质量和低成本地开发软件，必须以改善软件生产过程为中心，全面开展软件工程和质量管理手段。有些软件企业之所以落后，不是因为技术落后，而是对软件生产的管理落后。对软件生产过程的管理在整个软件企业的管理中起了决定性作用。

提高软件质量的几个点：全程监控，系统支持，持续改善，不间断的投入

东软软件过程改进参考：

（1）    有专门的质量体系，有公司级、事业部级、项目级的质量改善中心，有成熟的过程体系管理框架，并提供培训、咨询   整个过程改善中心有156人，均有3年及以上的开发、管理经验

（2）       有专门的质量总监

（3）       进行项目监控，会列用于缺陷预防的checklist,同时还定期召开缺陷原因分析会议，找到问题的根本原因并给予解决

（4）       对外宣扬通过CMMI(V1.2) Level5级认证，这容易让人觉得表面功夫做得很足，但东软还是有很好的内部评估机制的，比如在不同部门间进行评估、检查质量体系的执行情况、根据以往的经验及检查结果识别一些新的质量过程改进机会、收集优秀事迹，通过面谈、访谈等形式检查过程改进的落实情况，光检查项就有100多项

（5）       过程财富的收集及共享：总结、推荐、质量月报、专门的共享交流平台、过程改善沙龙、每年两次的质量总结会议

（6）       东软过程管理历程：打基础――质量体系固化――深入展开――成熟、快速复制

（7）       发现的缺陷按阶段进行划分，实行过程改进前后，2000年和2007年进行对比：

2000年：

l  系统测试之前发现的缺陷：30％

l  系统测试时发现的缺陷：67％

l  客户反馈的缺陷：5％

2007年：

l  系统测试之前发现的缺陷：71％

l  系统测试时发现的缺陷：28％

l  客户反馈的缺陷：0.～％

有一个问题我没有搞清楚，不知道东软系统测试之前发现的缺陷是如何衡量计算的？

（9）缺陷密度，实行过程改进前后，缺陷密度减少90％。有关缺陷密度，请参考以下解释：缺陷密度=已知缺陷(Number of known defects)/软件规模（size），已知缺陷可以是软件开发周期各个阶段发现的缺陷，如需求评审中的缺陷，代码评审中发现的缺陷，单元测试中发现的缺陷，集成测试中发现的缺陷等。软件规模就是软件的大小，目前一般有两种度量方法，用功能点（FP）表示或者用千行代码（Kloc）表示。利用缺陷密度可以比较不同的软件模块的缺陷密度，从而判断问题集中的模块，根据80/20法则解决问题；利用软件不同版本的缺陷密度也可以判断软件的质量，预期软件的发布。

2、  金蝶

（1）       金蝶软件开发模式采用IPD，质量管理体系持续改进，不单单像CMMI那样仅仅指软件研发过程，而是跟市场、业务联系很紧密，貌似跟我们公司采用的NPD是一样的.

（2）       敏捷开发的模式，老话题了，主要是为了需求的不失真，实现效率提升、快速迭代，避免实际结果和客户想要的偏离，核心理念为适应而非预测；强调以人为本，注重人的智慧、创造力。

（3）       公司有专门的创新实验室、软件工程过程组

（4）       作为辅助工具，有专门的研发管理平台，它是一个协同工作平台，可以对项目中的每项工作，如需求、开发、测试计划、设计、代码、缺陷等及角色，如项目经理、开发及测试人员、需求进行管理、分析，可以从各种指标上对产品进行质量评估、数据收集分析，还可以计算每个人的绩效及奖金；不过它仅仅是一个量化工具，缺点是不容易激发人的创造力。

（5）       软件质量分析的几个维度：功能性、可靠性、支持性、性能、可用性

主题二、软件测试相关

1、  判断测试结束的两个点：缺陷收敛；遗留问题有后续的解决办法

2、  目标决定过程，过程决定质量，我们的关注点：高效的测试及提高测试覆盖度

3、  如何提高效率：

（1）       提高测试资源复用率

（2）       提高有效测试工时率

（3）       与开发人员配合：记录和开发协作点的数量，提高协作点的正确率，一个协作点比如，开发承诺几点编译一个版本，那么我们可以到那个时间点检查是否编译成功

（4）       测试进度与项目实际进度贴合度好，可以检查工期贴合率、项目变化率

（5）       自动化

4、  有效度量测试用例覆盖度的几个条件：

（1）       定义基线，对现有用例进行有效管理

（2）       定义单位：明确测试用例的粒度

（3）       确定最小测试范围

（4）       更好的设计测试用例，如何合理的覆盖多个功能点？

（5）  每轮新增测试用例量

主题三、其他

（1）       质量改进不能一蹴而就，对软件进行更细的分析

（2）       质量的提高需要领导的重视

个人感觉上述一些点仅供参考，不同的公司有不同的情况，比如我们如果照抄人家进行大跃进，成立专门的软件过程改进中心，可能实际条件不允许，但首先要有提升软件质量的决心。从意识和觉悟入手。对于一个做产品的公司来讲，根据自己的软件开发成熟度进行有效的分析、形成一套成熟的属于自己的软件过程体系框架、还是很有必要的，不过这是个长期的过程。

再比如如果我们照抄人家开发一套项目管理的工具，那在现有条件下与提升产品质量相比，提升产品质量可能优先级更高一些。

同时，软件质量的度量伴随着软件过程（质量）改进也是一项很复杂的过程。

转载请保留：本文出自baihui2005的51Testing软件测试博客：http://www.51testing.com/?75270

     乍一看，好大的一个话题，而且被N多的质量大师、软件××师嚼过N次了...那这里再嚼一遍也不算多吧。

     项目上你也倡导我也倡导质量是关键。质量优先，进度靠后。但当市场上告诉你产品再不出来我们的客户就丢了，当项目经理告诉你我们已经进度拖延了，××时就是我们的deadline，要是再拖，汗，奖金就泡汤啦。于是，苦命Coding哥哥们加班啊加班，挑剔的testing妹妹们提bug啊提Bug，最后bug满天飞，哥哥妹妹们都围绕bug转去了，进度还是拖了，质量还是没上去。于是，客户没满意，我们要重构，我们要重写，我们要重测。OK，若干有些小想法的人开始思考了，老路不能再走一遍，一定要变革。

     于是，

     妹妹：哥哥啊，质量很关键，一定要自测，一定要写单元测试代码，一定要学习好业务，一定要开发出高质量的产品。

     哥哥：妹妹你不知道我的苦，我也不想让你们给提bug，多丢人啊，我也想写高质量的代码。可是，我代码还没到炉火纯青的地步，我天天加班天天加班也没时间学习，我进度安排得很紧，大家都在赶，我再不赶，本月绩效就完蛋啦。

     好复杂的一个话题。我们很多时候在讨论如何做需求管理，如何尽量少的变更，如何提高开发人员的质量意识，如何提高测试人员的技术水平，但从另一个角度讲，当你所在的公司文化中不含倡导质量的字眼时，这些底层的工程师是没有办法的。有关上面的谈话，显然参与讨论的人的身份还承担不起这么大的一个话题。一棵大树顶上的一两片叶子就是再摇晃再随风招展也不能让一棵大树动一动啊。

     怎么办？先分析产品开发的这根链条。市场管理－市场－－产品管理－－产品－－需求管理－需求－项目管理－－开发－－测试。链条的末端再动也没用。市场是龙头，龙头牵着整个链条走，方向正确了好办，方向错了－－难办。对一个很重视市场的公司来讲，如果单单重市场而忽略研发，那质量－－难办。由于才识较浅，目前关于这个也继续说不出什么道道来。但有一点，如果软件企业一开始就将质量放到一个比较高的位置，那我们就不信凭大家这些智慧的头脑和70、80后年轻人的吃苦劲头搞不定一个“质量”！

   上个月参加MS技术大会，有关自动化系统的建立有些感想一直没有写出来，在这里和大家sharing下，共同提高吧。不过，下面的一些想法仅适合有自动化基础且需要深入发展的项目。

   有关软件测试的自动化，大家是不是很快能想到,哇噻，这个工具很火那个工具很棒，这个数据驱动那个关键字驱动，这类适合公司自主研发那个适合直接购买？但当我们把工具的事儿搞定之后，除了培训倡导大家好好学习，天天用工具，竭力提高利用率覆盖率普及率之外，下一步应该怎么做，大家想透彻了吗？我们的自动化发展方向是什么？

   无疑，自动化测试系统。偶不是拿MS的成果上来赚口水，而是结合项目目前的现状，的却需要这样，但不严格照搬别人的，自己开发的自动化工具，同时也有自己的特点，那就自己再想辙呗。

   自动化测试系统是什么，包括哪些方面？在说这个之前，我先分析下自己所在项目上有关自动化测试方面的问题吧。

   1、无专门的脚本管理工具，svn?css?不失一个好办法，但要运行脚本还得再启用一个工具,我们暂且临时写几条命令然后加到任务计划吧

   2、脚本谁写的？什么时候写的？什么时候维护过？要在哪台机器上跑？什么时候跑？跑多长时间？报告怎么发，发给谁？发哪些内容？不同的项目总有不同吧。ok,简单的工具能做到吗？写几行命令？谁写？谁来维护命令行？

   3、脚本运行失败了怎么办，如何错误恢复？如何恢复干净的测试环境？如何重现错误？

   4、自动化工具有人维护吗？谁维护过？实行版本控制了吗？有专门的自动化需求人员吗？有专门的开发和维护人员吗？兼容性做得怎么样？性能如何？还有没有改进的地方？谁有这个权利管？

   5、脚本可以给开发人员做自测用吗？哪些适合给非测试人员用？

   6、有没有脚本管理规范？脚本设计规范？脚本参考的案例设计规范？脚本编制规范？工具管理规范？自动化管理规范？机器管理规范？有没有自动化测试实验室？自动化环境配置方案？

ok,暂且这些问题吧，显然，仅凭一个自动化工具没法做到，要真正的把自动化用好，需要涉及到什么？人、脚本、邮件、网络、工具、机器、环境等等，那我们需不需要一个系统将这些统一管理起来，而不是零零散散，随随便便？这就是自动化测试系统了。

    怎么做？舍不得孩子套不着狼，一个公司的自动化仅靠俩技术牛人几个有点小智慧的测试人员就搞定了？仅靠几台2G的机器就搞定了？

    关键是想法，是正确的方法论，是有决策能力的人的认可。但不可随便就行动，因为毕竟目前阶段大部分软件公司推行自动化就是高风险的东东，如果没有合理的分析、设计、验证，更重要的是没有实际的自动化基础就投入，必然是失败的。

    做适合自己的自动化测试系统，跟软件开发一样，前期工作很重要、很重要。

   昨天一个在去参加面试路上的姐们儿打电话让我赶快帮她上网查些资料，一向不习惯在公司处理个人事情也不怎么在公司上网同时还正在处理N个“紧急”但可以快速完成的工作的我脑子一下蒙了，两种都很“紧急”，先做哪个？切～，这么简单的事情，还思考？切～。

    是的，我思考了，一直到晚上回家的公车上我都在思考，我很忙，我一天一天的都很忙，忙到帮N久不会找我帮忙一次的好姐们儿几分钟的时间都不能立马抽出来，我从不闲聊天从不上闲网，我在忙什么呢？关键的还有一我不是CXO二我不是万人迷三我没在开重要会议四我就是一个普通的做测试的，我在忙什么？想来想去，嗯，大多半由紧急不重要的事情给耗去了，以至于每天做总结的时候都总结不出收获来。汗。

    那就把紧急不重要的事情拆解下呗，嗯，首先是盯着dailybuild然后是盯着bug库再就是盯着outlook还有是盯着每个人手里的任务最后是大领导小领导非领导这个建议那个问题，大半的时间都在“盯”了，工作是追求产出的，盯不出产出来当然没什么收获啦。时间都花费在这上面了，自己的那个“大”计划那个“大”变革当然就被一拖再拖啦！

    还有一点，当在一个大家经验学识并无大差的项目组里，如果其他人都不是那么的忙而只有一两个人貌似每天都很忙的样子，是不是有什么问题呢？当然有问题，第一就是让人很反感，你那么忙那么有责任心岂不衬托的大家活少或者责任心不够么？第二就是既然大家经验差不多，为什么不均衡些，把手头大家都可以处理的工作分出去呢？大家一块儿做效果岂不是更好，有加班的那个闲功夫还不如看本书做个coding给自己充下电呢。

    嗯，看来思考还是有用的，“为了买房子嫁他 为了我的大创意 为了我以后出生的宝贝 为了俺爹俺娘过上好日子 为了童年的梦想 为了永不言败 为了超过比尔盖茨 为了爱 为了从头再来 为了能在这个城市站住脚”，广告词挺好的，大哥大姐妹们儿，你真的很忙吗？做重要不紧急的事吧，那样重要紧急的事儿就少了，紧急不重要的事儿交给大家一块儿或用工具处理吧。

   扯，扯吧，是不是扯到时间管理的精髓上啦？

1、不清楚的地方不要假设

2、要及时做好工作汇报，告诉周围的人自己正在做什么、要做什么

3、人的付出包括在事情上的付出和在人身上的付出，如果片面的仅在事情上付出，将很痛苦，因为人有被需要和需要的天性

4、如果工作过程中有一些地方不如意，说明在自己身上是有问题的

5、不要太在意一些事情，如果你把它看得很淡，也许会更快乐些

6、冲动是魔鬼，也许我们无法克制自己不冲动，但起码要在之前好好的思考一下

7、过好每一天，每天学一首新歌或者看一篇好文章或者做一顿好饭或者写一段代码或者跟朋友聊聊天，跟工作无关、跟赚钱无关、跟一切纷争无关

8、平静平静再平静

9、静心养性；不见其增，日有所长。

原始链接:http://www.51testing.com/?161964/action_viewspace_itemid_90860.html

零缺陷管理的起源：

　　被誉为全球质量管理大师、"零缺陷"之父和伟大的管理思想家克劳士比，从60年代初提出"零缺陷"思想，并在美国推行零缺陷运动。后传至日本，在日本制造业中全面推广，使日本的制造业产品质量迅速提高，并且达到了世界级水平，继而扩大到工商业所有领域。

　　"零缺陷"又称无缺点ZD，零缺陷管理的思想主张企业发挥人的主观能动性来进行经营管理，生产者、工作者要努力使自己的产品、业务没有缺点，并向着高质量标准目标而奋斗。它要求生产工作者从一开始就本着严肃认真的态度把工作做得准确无误，在生产中从产品的质量、成本与消耗、交货期等方面的要求来合理安排，而不是依靠事后的检验来纠正。零缺陷强调预防系统控制和过程控制，第一次把事情做对并符合承诺的顾客要求。开展零缺陷运动可以提高全员对产品质量和业务质量的责任感，从而保证产品质量和工作质量。

　　克劳士比的质量管理四项基本原则：

　　原则一:什么是质量？

　　·质量即符合要求，而不是好。

　　质量的定义就是符合要求而不是好。"好、卓越"等描述都是主观和含糊的。

　　原则二:质量是怎样产生的？

　　·预防产生质量

　　·检验不能产生质量

　　产生质量的系统是预防，不是检验。检验是在过程结束后把不符合要求的挑选出来，而不是促进改进。

　　检验告知已发生的事情太迟、缺陷已经产生，不能产生符合项。预防发生在过程的设计阶段，包括沟通、计划、验证以及逐步消除出现不符合项的可能性。

　　通过预防产生质量，要求资源的配置能保证工作正确完成，而不是把资源浪费在问题的查找和补救上面。

　　原则三:什么是工作标准？

　　·零缺陷，而不是"差不多就好"

　　工作标准必须是零缺陷，而不是"差不多就好"，差不多就好是说，我们将在某些时候满足要求，或者是每次都符合大部分要求而已。而零缺陷的工作标准，则意味着我们每一次和任何时候都要满足工作过程的全部要求。它是一种认真地符合我们所同意的要求的个人承诺。如果我们要让工作具有质量，那么，我们决不向不符合要求的情形妥协，我们要极力预防错误的发生，而我们的顾客也就不会得到不符合要求的产品或服务了。这是"零缺陷"工作标准的重要意义。

　　零缺陷管理作为一种心态：事情第一次就做对；避免双重标准；决不允许有错误；非常重视预防；只有在符合全部要求时才行。

　　原则四:怎样衡量质量？

　　·不符合要求的代价(金钱)，而不是指数

　　质量是用不符合要求的代价来衡量的，而不是用指数。指数是一种把不符合项用相关的坏消息进行软处理的方法。不管怎样，如果我们软化了坏消息，那么管理者将永远不会采取行动。而通过展示不符合项的货币价值，我们就能够增加对问题的认识。

　　不符合要求的代价：当要求没有符合时产生的额外的费用。不符合要求的代价是浪费的代价：浪费时间、人力和物资。这是不必要的代价。

　　零缺陷与MQM、精益生产方式JIT、ISO 9000之间的关系：

　　底层是ISO 9000族质量保证体系，是支持MQM、零缺陷、及精益生产方式JIT的基本条件，它相当于汽车里的说明书，是指导性重要文件。

　　第二层是MQM(现代品质管理体系)。它是在ISO9000系列基础上，对生产型企业的品质管理进一步深化与控制，从经营的角度，创造各部门的品质控制与改善，是零缺陷的基础。

　　第三层"零缺陷"运动，零缺陷不仅仅限于企业内部产品质量要求，对于其它工作业务、供应商同时提出零缺陷工作标准，强调预防过程管理。无论是企业内部过程还是外部过程都必须符合双方同意的承诺要求；重视预防系统和不符合要求的代价的计算分析，从而降低质量成本，提高产品质量和工作业务质量。

　　顶层是精益生产方式JIT。精益生产方式JIT是更为广阔的管理，其思想是以市场为导向，进行拉动式生产而实行资源整合全面管理，包括优化生产工作流程，减少多余的环节，推行零库存，降低采购成本，目的是提高生产工作效率，减少浪费，提高工作质量，使资源得到充分有效的利用。它涉及企业内部更多细化管理，如MRPII、ERP、供应链、价值链等管理思想，是一项更深层次、更广泛、更有效、更全面的管理。

　　不要持双重标准：

　　许多人总是认为工作中缺陷是不可能避免的，也习惯接受缺陷并容许其不断发生。但我们在个人生活中，却常常会坚持零缺陷的标准。我们会对饭店上菜的片刻延误而喋喋不休，会对汽车的污点而牢骚满腹，对服装的一处线头的外露不厌其烦地反复更换，会为工资奖金比同伴低一点点而心情不畅，我们会对小孩考试得99分而未得到满分而高声呵斥……。总之，生活中的一些细小的缺陷、错误，我们均不能容忍。

　　实际上我们大部分人一直坚持双重标准，一个是生活上追求完美无缺陷的零缺陷标准，一个是工作上马马虎虎、差不多就行的标准。如果我们在工作上也坚持零缺陷的标准，每个人都坚持第一次做对，不让缺陷发生或流至下道工序或其它岗位，那么我们的工作中就可以减少很多处理缺陷和失误造成的成本，工作质量和工作效率也可以大幅度提高，经济效益也会显著增长。

　　质量是芭蕾舞，而不是曲棍球：

　　克劳士比极富艺术性地提出：质量是芭蕾舞，而不是曲棍球。曲棍球是一种体育运动项目，曲棍球比赛时球员必须根据球场上瞬息万变的情况，判断如何进攻和防守，人们欣赏的是球员的激情"表演"，更多的是一种力量与速度的展示。在曲棍球比赛中，如果球员因失误被对方进一个球，他可以努力多进对方几个球，最终也许还会获胜。而芭蕾舞在演出前都经过设计、讨论、规划、检查以及详细节目安排。每一个布景道具的放置、每一段乐章的时间、每一段剧情的展开及每一个音乐的节拍，都经过周密的考虑和精心的策划。芭蕾舞演员追求的是一种零缺陷也就是完美的境界。因为任何一个细小环节的疏忽，都会影响最终的演出质量和观众(顾客)的美感。

　　审视我们的日常管理工作，我们的干部可能更象曲棍球型：到处不停地巡逻、查找、解决问题。争论、罚款、加班以及在现场马不停蹄地跑来跑去，似乎都已习以为常。而找出和解决的问题的多少，似乎已成为其成就的标志。如果我们仔细统计分析，将会发现其中大部分问题是惊人地相似，却日复一日地重复发生着，每发生一次就会重新再解决一次。而芭蕾舞型的管理人员则比较专注地向着既定的目标迈进，很少受到意外的干扰。解决问题常常斩草除根，不留后患。

　　如果采用人盯人的现场管理办法，在当今快节奏的生产下，是不可能实现零缺陷的。只有建立一个行之有效的质量管理体系规范，在内部形成一个质量持续改进的良性循环，才能实现零缺陷的目标。

   我们大家都清楚，100%的自动化测试是软件测试的共产主义。我们无法奢望工具完全代替人工的劳动去执行所有的测试。人的创造性思维任何工具都无法替代。除非给软件测试工具加入人工智能的算法，这是后话了。

   这里提出一个问题，当我们把过多的精力放在软件测试工具、软件管理工具的开发的同时，我们是否应该进行一下回归，回归到人，也就是我们的软件测试人员，回归到我们的软件测试人员的素质上来。软件产品的质量终究要靠我们这些测试人员来保证，产品优劣与否，工具无法也不应该承担任何责任。

   所以，提高软件测试效率，首先是提高软件测试人员的素质。

   优秀的软件测试人员需要具备的素质有哪些？

1、发现客户价值

2、更广泛的测试

3、态度：是做，还是要做得更好

4、耐心、细心、逆向思维等等

5、测试技能

   我们无法总是招到优秀的测试人员，所以要提高工作效率还需要自己培养。如何培养？

1、培训：

（1）软件业务培训

测试永远离不开对产品业务的深刻理解，对软件测试人员的培训，首先是对业务的深化及加强。那谁来培训？客户。我们采用什么样的方式？去现场。如果客户也不真正了解需求，或者我们无法安排所有的测试人员都去现场，怎么办？内部解决，回归到原始方式，发现组内精通业务的人员，对其他人员进行培训。

（2）开发技能培训

如果测试人员对软件开发过程没有深刻理解，那么也就无法领会到软件测试的精髓，无法正确定位软件产品质量，无法定位BUG深度及影响范围，无法给自己的角色进行定位。还是培训，谁来培训？组内开发人员或者自己培养的测试开发人员。培训哪些内容？软件开发过程、软件性能瓶颈引起的原因、软件开发工具、软件开发平台、软件开发常用词汇。深度如何掌握？仅做到测试人员了解即可，有必要的话可以安排测试人员参与一段时间的软件开发

（3）测试技能培训：测试方法论

2、引导

思想导师曾经引导我说，一个人做得是否优秀在于她的意识还是她的脑袋是否聪明?答案当然是意识，无论是否毕业于名校，大家的智力水平都没有太大差异。要改变一个人的意识太难，我们可以控制机器，但我们无法控制人。怎么办？引导。怎么引导？用心，用心去引导，而不是教导，虽然自己不是领导，但发现失败的领导易犯的错误是把自己当成领导，高姿态就是让自己下不了台，以高人一等的姿态对人，不是会伤害到别人，而是自己很容易被伤害，不知是否有人与我同感。

3、时间管理

回归到提高测试工作效率的话题，无非就是在最短的时间内干更多更高质量的活。那当然离不开时间管理。个人观点，如果一个人早晨8：30来到工位上，第一件事情不是打开邮件看一下版本情况或者过滤一下自己的BUG，或者是思考一下今日工作目标等，而是首先打开网页看一下花边新闻或者打开一款游戏先放松一下，那么今天注定她的工作是被强制的，而不是自愿的（有强烈个人习惯的除外）。强制工作的效率可想而知。这还是意识问题，不是说不让人去上网，一点也不要去做与工作无关的事情，这样还是强制，没有人情味儿。虽然很多公司倡导加班文化。但我们没有必要，那么我们要倡导什么？不加班文化。也就是说不要倡导加班光荣。谁在最短的时间内高效高质的完成任务，那这个人就应该受到嘉奖。有了这种意识，相信每个人都有一套自己提高工作效率的方法。

4、自学及自律

5、工具

今天话题是提高软件测试人员的素质，而不是如何优化测试工具，另外，大家也都知道自动化测试工具、测试管理工具等的优势，那么这里就不强调了。

总之，测试改革即提高测试效率，更快更好更少成本的创造更多的价值，以人为本，从人开始，毋庸置疑。

  ‘自动回归测试所面临的最大问题就是退化和过早消亡’，当自动化测试在如火如荼的进行过程中，一个突如其来的软动件变更、重构、开发平台变更、开发工具变更、关键人员离职可能会导致整个自化测试流程的夭折。听起来有些耸人听闻，但当现实摆在面前的时候，我们不得不思考这样一个问题，如何防止这类现象的发生，当这种现象即将到来时，我们又应该怎样做呢？

   什么原因会导致自动化测试的退化和过早消亡？

1、未提前通知的软件变更：当我们已经积累了大量的自动化脚本，而且脚本中存在大量的被引用测试包，当发生的变更隐藏在某个或某些个被引用测试包的时候，测试人员并没有得到应得的提前通知，而是在发现自动化测试失效的时候才发现问题的严重性，随之带来的失效诊断、问题修复、脚本维护上的时间打断了我们目前的测试进程，为了不过多影响软件发布，项目组不得不采取手动替代的方案让大家继续测试，自动化测试被迫搁置一边；

2、软件重构：当产品进入市场，由于性能或其他问题并不被客户看好的时候，我们会考虑到软件的大规模重构，由此带来的未知的界面和业务变更会使得我们前期积累的大批量自动化测试脚本无法复用，除了一些文档、方法、策略，其他都成了明日黄花，同时，开发语言、开发工具、平台的变更同样会导致这类问题；

3、关键自动化测试人员的离职：当一些测试策略、文档、规范一直存放于一个或些个自动化测试人员的脑海、未被公布的测试机的某个路径下的时候，关键自动化测试人员的离职也会导致自动化测试的停滞不前、日益退化；

   如何应对与避免？

1、软件架构与设计阶段就应当考虑到自动化测试：软件测试并不仅仅是软件测试工程师自己的事情，需要架构师、需求人员、系统工程师、开发人员的协助，比如，在软件被开发出来之前就可以在软件原型上进行自动化测试设计、脚本编制等，这就要求原型开发人员、需求人员的大力支持，需求文档尽量精确详细，尽量避免变更，软件开发过程中，及时对原型进行维护等；

2、时刻考虑到维护：安排专门的自动化脚本维护工程师在特定的时间对脚本进行及时维护，而不是在发现测试大量失效的情况下再亡羊补牢；

3、不要集权：自动化测试策略、自动化测试文档、资料等不要集中在一个人手中，要有特定的机器存放，自动化测试进行过程中积累的各种经验和教训要及时付诸文档，或者及时沟通与培训；

4、规范：有严格的自动化脚本编写规范、每个里程碑的自动化测试目标明确、每个里程碑的测试策略明确、脚本编制人、编制日期、测试功能点、期望结果等要清晰可辨，这些都是为了脚本的易维护性而考虑的；

5、摆脱被动：自动化测试不要做软件开发的附属物，而是要驱动和指引软件开发，当发现问题时决不手软，比如软件性能问题，不要到软件开发后期再考虑到性能测试，时刻积累数据，发现问题及时通知，而不是到了一定程度，忍无可忍时再去通知，当软件不得不进行重构时，发愁的不仅是开发，还有测试。

   总之，制定严格的自动化测试流程、提前考虑到各种风险、保持顺畅的沟通、考虑到维护、八方支援、层层把关，才能真正发挥自动化测试的功用，而不至于让大家失望。

   公司开发的产品专业性较强，测试人员需要有很强的专业知识，现在测试人员发展出现了一种测试管理者不愿意看到的景象：

1、开发技术较强的测试人员转向了软件开发（非测试工具开发）；

2、业务能力较强的测试人员转向了软件需求；

3、沟通能力较强专业能力较强的人员转向了软件实施；

   为什么不愿意看到呢，自己培养起来的优秀人员都为别的部门、别的公司干活去了，而测试这边永远都是新人，永远都是刚入门的测试工程师：开发水平一般、业务能力一般、沟通能力一般。而那些转行的测试同仁们，薪水并没有质的飞跃，到了‘那边’成绩平平，很快就被埋没了。这里当然要排除那些实在对开发、对业务、对实施非常感兴趣想在这些领域有所建树的狂热者们。问题就来了，那些人为什么要‘转业’呢？原因无外乎以下几点：

1、公司的软件测试没有技术含量，没有挑战性；

2、认为在公司能做到测试经理就已经是测试发展的最高境界了；

3、测试人员薪水较其他低；

4、想了解一下测试之外的其他岗位，丰富自己的阅历，为以后更好的做管理做准备。

    那么，公司的软件测试真的技术含量很低吗？工作效率已经达到最高了吗？真的不需要挑战吗？测试经理就没有高级和低级之分了吗？测试人员的薪水就不可以比开发人员高了吗？测试人员真的需要那么多吗？当然不是，也许很多年的‘旧路’不能靠自己改变，也许有人埋怨领导者们因循守旧、顽固不化，但没有人会阻挡我们去创新，去阻止我们探索新的模式、新的思路、新的工作方法去改变这种现状，没有公司是傻子，一个人的薪水和他体现出来的价值是成正比的。所以应该打破常规，去探索新的东西，这种创新不仅包括技术创新也包括管理创新。关于职业发展，仅根据公司的实际情况，和从大家那里得来的想法，谈一谈：

1、开发技能较强的测试人员可以转向自动化测试工具、测试管理工具的开发，这里不仅要求开发能力较强，还需要多了解第三方测试工具，挖掘测试组内测试人员的需求，了解业务；

2、业务能力较强的可以做测试（用例、计划）设计工程师，由于公司产品业务较强，需求人员仅能为测试人员提供需求文档，而究竟哪些是最重要的测试点，测试过程中采取什么样的测试方法能使得测试路径最短、覆盖率最全，这些都需要抓住软件业务的精髓

3、做到了测试经理，完全可以把管理再出神入化，每个人身上有什么特点，怎样能让每个组员的能力发挥到极致，怎么更好的争取测试人员的利益，怎样做到最好的资源调配，怎样让大家不再迷茫，另外，怎样提升自己的威信，提升执行力，领导力，怎样把管理做到让人啧啧，到了这种程度，通过横向和纵向对比，优势自然就出来了。

   另外，转做开发、需求、实施，然后又转回测试做管理，这种我是比较赞同的，但度不好掌握，而且如果自己的各方面技能过高，很可能会和公司测试部门的发展脱节、很多技能无法施展，进而产生英雄无用武之地的想法，很可能导致这类人的离职，所以个人的发展和公司测试部的发展一定得保持同步，谁都不能过快，步伐不一致的的两个人怎么能走在一条道上呢？所以在个人发展的情况下，关注公司总体测试发展，先认清两者的发展方向再去‘转业’未尝不可。

4、做到测试设计人员、自动化工具、管理工具开发人员就是极致了吗？当然不是，测试行业照样有咨询、有顾问、专家，测试管理做好了也可以去做项目经理、去做部门经理，实在不行，完全可以去创业嘛。

   总之，发展无极限，路是自己走出来的，不要只走别人踩出来的路。

   毕业已经一年，有关软件测试，大部分时间都是在学习、吸收，但也有一些点滴经验需要记录和分享，于是开通此空间，希望和大家共同学习，共同进步。