性能监控提供了一种非常简单的方式来收集单个SQL Server上的宏观性能统计参数。如果用户报告说发现SQL Server存在问题，性能监视器就可以用来判断SQL Server相对于基线的运行情况。所以，在每次系统发生修改(硬件、软件等)之后，或者至少是每三个月都获取相对最新的基线数据就是至关重要的。以下推荐的10个性能监视计数器都可以帮助你捕获基线，并且在你寻找系统问题的时候用来进行比较。　　推荐的性能监视基线计数器
1 CPU -- %处理器时间 用来处理用户或者系统事务的处理器时间，与CPU空闲时间的百分比。 CPU利用率越高，用来处理用户或者系统事务的CPU时间越多
2 系统——处理器队列长度 等待CPU的线程的数量 队列长度越长，等待CPU处理的CPU指令的线程越多
3 内存——页/秒 从内存中读写的页面数量 内存利用率越高，处理器访问内存越多。
4 内存分页文件占总体的--%利用率 正在使用的所有页面的百分比 分页文件利用率越高，系统就需要在服务器上有越多的物理内存之外的内存
5 物理磁盘—平均磁盘队列长度 等待物理磁盘子系统的队列中读写请求的数量 平均磁盘队列长度越长，完成前面的请求等待所需的资源就越多。
6 SQL Server：一般统计数字——用户连接数 系统上的用户数量 用户数量越低，显示服务器所能支持的系统负载越小
7 网络接口字节总数/每秒 通过一个网卡发送和接收的字节数 判断一个网卡是否发生了网络拥塞，或者系统是否发生了与SQL Server无关的问题，而不是网络通信量
8 SQL Server：锁—等待锁/每秒—总数 每秒需要等待锁的请求 判断是否发生了过量的锁定限制了用户访问系统的资源。
9 系统—线程 计算机上线程的数量 判断线程的数量是否大大超过一般的基线，这意味着系统上产生的进程多了
10 系统—上下文切换/秒 每秒需要更改线程的进程的数量 上下文切换的越多，服务器的压力越大

本次在组内实施Bug bash比较成功，特将方案跟大家共享:)

Bug Bash（大扫除）实施方案

一、      bug bash说明（参考）

    Bug bash（Bug大扫除）来源于微软，通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：

1、        尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益。

2、        要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug。

3、        为调动积极性，增强趣味性，可以适当引入竞争机制，给以物质和精神奖励。

二、      本次Bug Bash背景

1、        **重构接近发布Beta版本，开发已经不会在当前版本上进行重构，版本逐渐趋于稳定

2、         目前的Bug数目从2.9开始呈现收敛趋势，希望通过bug bash出现一个bug反弹，之后再经过封版前后的阶段测试使得版本满足发版的要求。

三、      目的

1、         调动全组积极性，换一种思维和方式执行测试

（1） 市场和需求人员从用户的角度分析，会发现一些测试人员想不到的问题；

（2） 开发人员知道从代码、白盒的角度分析问题会发现测试人员想不到的问题；

2、提早发现bug，降低软件风险

3、在大家共同测试的过程中顺便就进行了团队建设

4、长期的测试容易使得测试人员形成思维定式或疲惫，通过这个小活动增加软件测试的趣味性和新鲜感

5、 树立开发人员、市场人员的软件测试意识，了解测试人员的工作

四、      时间

周一至周三（2009.2.16-2009.2.18）

五、      地点

1210室、1211室

六、      参与人员

1、         测试人员(全程参与)

2、         产品及需求人员（插空）

3、         开发人员（插空）

4、         管理人员（插空）

七、      激励措施

        说明：每日汇总一次，评出每日bug英雄3名，每人奖励**(还没定)

1、         奖励措施：

2、         每天评出最高深bug奖、最牛bug奖、最严重Bug奖，数量不限，由大家共同讨论决定，奖品为**

八、      总支出资金预算：

九、      风险及成败关键因素

1、         大家的积极性是否被调动，方法就是通过激励以及趣味（实时播报、买水果之类的激励），也要强调活动的必要性

2、         除了测试人员的时间可以保证外，其他人员的时间无法保证，其他人员不能为了提Bug而耽误了自己的本职工作，提倡工作之余或晚上测试

3、         版本的稳定性，如果版本不稳定，会影响到bug bash的进展，所以一定要保证bug bash之前有稳定的版本

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

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的机器就搞定了？

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

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

原始链接: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、工具

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

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