qileilove

　　天顺：

　　这个问题仿佛就是问我的一般。先说说我自己。

　　我毕业后从事了相当一段时间软件测试的工作，最高做到高级测试工程师，带部门2/3的测试工程师，负责公司大多数项目的测试管理。在做测试的过程中，我渐渐对产品经理这个工作产生了兴趣。

　　每当研发和测试为了功能点吵得不可开交的时候，最经常听到的一句话是：别烦了！问产品经理不就知道了！

　　每当项目上线后，技术的同事们都相当盼望着知道项目的结果（别说技术同胞们是死脑筋只会写代码，项目给公司带来利润多少，是否成功，是很多技术同事非常关心的，成就感这东西不是简单用钱能衡量的），大家第一个想到的就是去问产品经理（公司2，没有独立的运营岗）。

　　每当业务讨论时想不出为何要这么做的时候，也都会去问产品经理。

　 　毫不夸张的说，在当初我们这些“土鳖”技术眼里，产品经理是能写代码、能找BUG、对内能说清业务，对外能忽悠客户的一群人。当时我希望成为产品经理， 一来是希望自己在业务上能有所进步，成为行业内业务的专家；二来是希望在薪水待遇上有所提升，获得一个更为广阔的职业发展平台（我也不避讳，在当时的公 司，随便找一个产品经理的薪水，都是和部门主管水平相近的，而测试在公司是不受重视没有前途的）。其实从现在来看，当时的我挺可笑的，但已经走了这么一条 路，只有继续好好走下去了。

　　OK，扯了那么多有的没的，LZ问的问题还是没回答，我当时怎么做的呢？我后来也想了一下，有几个方面导致了后面能顺利内部转岗成为产品经理：

　　1、产品部同事的认可（人和）

　 　当时作为测试负责人，在项目过程中与产品经理有相当多的接触。在产品部门这边，有很多欣赏我的同事。有些同事在产品经理职位有缺口的时候，向产品总监推 荐我内部转岗。而我又是与产品部总监以及高级产品经理同坐一部公交车回家，路上碰到的机会相当多，自然就熟悉了，为后期转岗打下了人脉的基础。

　　2、相对其他技术同事，我接触公司业务机会更多（地利）

　　因为公司测试部门刚起步，人员不够，所以没有将人员很机械地划分到对应的业务线，作为测试这边的项目负责人，我可以接触到公司各式各样的项目，这些项目丰富了我对支付业务的认识，为日后成为产品经理打下了业务基础。

　　3、最重要的是运气（天时）

　　这个看似很扯淡，不是吗？LZ问的是如何能成为，而我强调的居然是运气。

　　事实上，当初如果不是因为测试主管欣赏我，提拔我做高工，管理项目，我没有那么多机会接触公司方方面面的各类业务，就无法从各个角度了解公司业务，就不具备当时公司对产品经理的基本要求。

　　如果当初公司产品经理职位没有空缺，而我与产品总监完全不认识，我就根本没有机会转岗。

　　如果当时部门主管心眼小，知我想转作产品时，横加阻拦，给我穿小鞋或者拒不放行，我亦没有机会。

　　所以我后来反反复复分析自己当时转岗的过程，也觉得自己实在是运气很好。

　　4、自我积累

　　在正式提出转岗做产品前，我请教了很多产品经理，向他们咨询看法。平时工作中也渐渐关注产品经理们经常使用的工具，经常关注的问题。不懈地学习业务知识，积累自己对行业的了解，积累同事们的口碑。

　　总结一下就是，积累必要的业务基础，人脉，等待最好的时机。

　　以上，其实每个人的路途都不尽相同，别人的过去只能给你当做参考。倒是LZ不妨多想想自己究竟为什么希望成为产品经理。

　　成为产品经理后，以下是我经常反思的：

　　1、如果抛开薪资待遇，产品经理工作是否就比当时做测试更让我喜欢，更容易让我充满激情地工作。

　　2、如果当时没有转岗成为产品经理，是否意味着我的职业平台将狭小很多，测试工作是否真的像我当初所认为的“没有发展前途”？

　　3、成为产品经理后，如何更好地利用过去测试时积累的经验，将这份新工作做好？是否有能力改变公司里对测试有偏见的氛围？

　　最后，泼些凉水。

　　产品经理在很多公司，并不像很多人想象的这般风光无限。很多时候，他的标签包括带不限于：“备胎测试”、“备胎架构师”、“备胎项目经理”、“备胎运营”、“写文档的”、“写会议纪要的”、“背黑锅的”。

　　产品规划？那是老板的事。

　　方案的确定？那是总监的事。

　　页面图标用什么配色？那是UED的事。

　　项目进度运筹帷幄？那是项目经理的事。

　　别人不想干的事？没错，多半是你的。

　　所有和产品有关的事，都是产品经理的事。

　　这句话听上去很拽不是么，翻译一下很有可能变成：这个事情太烦了，不搞了，反正到最后没人弄，产品经理也会想办法的。

　　这不是开玩笑，而是时时刻刻发生在全国各地，各类行业，各种产品经理身上的真实场景。产品经理，互联网产品经理，尤其是目前中国的互联网产品经理，绝大多数不是外人所想象的风光角色！

　　任何人都可以抛弃产品，拍拍屁股走人或者捣糨糊，但产品经理不可以。关于产品的任何细枝末节都是产品经理的工作范围，任何对产品有影响的工作，产品经理都要过问并清楚。产品进度慢了、产品方案改了、产品上线出BUG了，没错，有人要承担责任，产品经理一定是其中之一。

　　做产品经理意味着你选择了一条操心劳累，可能会没日没夜，可能会鞠躬尽瘁的道路，如果没有这个觉悟，还是再想想，再想想。

　　龚博致：

　　产品经理其实是没有标准的，只有一些大致的指导方向。在各个公司各个部门各个阶段，它的职责侧重都可能有不同。按我的理解，大概有：

　　1、产品型产品经理。这个是最正统的，他的重点职责就是向协同部门（如运营）收集需求，设计产品，和开发沟通跟进进度，上线后跟踪，总结。

　　2、商业型产品经理。也可能叫运营型。贴近运营侧，直接接触用户，从反馈中总结/提取需求，偏重于用现有方案/产品解决问题。

　　3、技术型产品经理。分析已有产品，推动整合、打通、改造。产品发展久了，业务变化下就会出现功能重复、业务分裂等问题，需要改版重构，这个时 候涉及多个系统打通，甚至需要把底层平台当成一个产品来打造，然后再支持原有产品的做法。所以这时候重点在于了解各个产品底层需求，了解技术背景，提供严 谨的功能文档（因为涉及的功能太多）

　　所以对于转产品经理需要做什么准备，其实主要还是需要看你们老板想要什么样的产品经理，部门有什么资源来帮你分担职责，以及你想成为什么样的产品经理。例如：

　　● 如果部门有项目经理，项目管理可以先不看。

　　● 如果可以的话，熟悉一下产品的文档/流程，然后结合测试经历提出自己的想法，自己实践一下来证明给老板看，再推广

　　● 如果是想做线上产品，那一般是要赶紧补运营课，了解产品的指标，定计划/里程碑/KPI

　　如果没有概念，那最简单了——全都做，多看多听多想。

　　产品经理是个“多面手”，意思就是你什么事情都要做得要多——多找人沟通，设计的时候多想一想，文档多描述清楚一下，上线后多跟进一下……（其实这些标准所有岗位都一样：D）

　　所以任何一个方面的提升都是提升，多交流，多看书，多看帖，多参加分享，然后你会接触到很多相互冲突的理念——别纠结，不用全学。多思考，然后吸取你觉得适合你的那部分就行了，此之甘露，彼之砒霜。

　　设计是用户需求到编码实现的必经阶段，软件项目在设计阶段的禀赋决定了软件项目的资质。好的软件设计不是软件项目成功的唯一条件，但是没有好的设计软件项目肯定无法做好。

　　一、软件设计的重要性体现在以下几个方面：

　　1、软件设计在整个软件项目的建设中起着承上启下的重要作用。

　　从整个软件项目开发阶段来看，软件项目可以分为需求、设计、编码、验证四个阶段。设计承接需求分析，基于准确的需求分析，对项目目标进行结构化搭建。设计阶段产生的设计说明书以及设计规范是编码阶段的作业指导，也是测试人员开发测试用例的指导书。

　　2、软件设计是对软件项目质量进行保障的关键步骤。

　 　软件项目的质量与需求分析、设计、编码、验证段这四个阶段的质量之间的关系，可以用C语言表达为：最终的软件质量 = 需求分析质量 && 设计质量 && 编码质量 && 验证质量，这种“与”的关系表明任何一个阶段出现质量纰漏，软件项目的最终质量都无法保障。

　　3、设计阶段提供的软件表示，使软件项目质量的评价成为可能。

　 　反映软件设计质量的要素有：准确性、稳健性、安全性、通信有效性、处理有效性、可操作性、完备性、一致性、可追踪性、可见性、可扩充性、复用性、模块 性、清晰性、自描述性、简单性、结构性、硬件系统无关性、软件系统无关性、文档完备性等。通过这些考核要素对设计阶段质量进行控制，从而达到从项目前端控 制软件质量的效果。同时该阶段的设计规范也是进行软件质量评价的参照标准与基本要求。

　　因此，想做好整个软件项目的质量保障，必须充分重视设计阶段的质量保障工作。山东省软件评测中心作为国内最早一批获得国家实验室认可并取得政府授权的中立的第三方机构，在十余年的软件项目质量服务过程中发现：

　　二、设计阶段经常出现的质量问题从大的方面看有以下几种原因：

　　1、需求分析阶段工作不充分

　 　好的软件设计必然基于准确的需求分析，离开正确的需求分析，软件设计就是做得再好，在源头上也是错误的，更无任何意义，有时甚至是南辕北辙。有些软件项 目因为工期紧张或乙方软件企业管理不规范，甲方用户人员技术受限或配合不到位或承建方需求分析人员业务、技术经验不足等这样那样的原因，需求调研没有做 透，更有甚者基本的业务逻辑还没有完全理清，就匆匆开始需求分析然后又囫囵吞枣的进行自我想象中的架构设计，结果可想而知。

　　2、设计不充分

　 　有许多软件企业不重视设计阶段的工作，或者略掉设计直接进行编码。这样必然把许多的问题遗留给编码阶段，等写了一部分代码后再后头看，错了，返工……另 外，设计人员由于技术欠缺或经验不足，或者对业务理解不够深入，未能充分考虑后期需求变动对设计的影响也是造成设计不充分的一类重要原因。

　　设计不充分往往导致频繁变更与诸多性能、安全方面的漏洞。在软件项目里，越是在项目前期发现问题，解决成本越低。据相关机构统计，在设计阶段发现偏差比在需求分析阶段发现并修正要高出5 倍，在编码阶段觉察偏差则会提高到10倍，而如果延续到单元测试或系统测试阶段发现设计缺陷修正成本则会提高到20倍。另外，设计人员由于技术欠缺或经验不足，或者对业务理解不够深入，未能充分考虑后期需求变动对设计的影响也是造成设计不充分的一类重要原因。

　　3、过度设计

　 　与设计不充分相对应的一种情况是设计过度，过度设计一般是由于设计人员在做项目分析设计时，过分的考虑潜在的、未来的以及准备扩展等因素，过度的抽象， 过多思考封装、分离解耦，导致太多颗粒单位，太多插件等等，给设计资源造成不必要的浪费，并且可能导致原本可以简单实现的逻辑变复杂，造成系统整体性能的 下降与维护成本的上升等等，以至于影响到用户体验或者简直没法用。

　　上述情况都会造成软件设计质量的下降，那么我们应该如何做好设计阶段的质量保障工作？

　　三、如何才能做好软件项目设计阶段的质量保障

　　1、思想上重视

　　充分认识设计阶段的重要性，从思想上强调设计阶段质量保障工作的必要性与重要性。关于软件设计的重要性前文已从几个方面作了总结，不再赘述。项目团队成员与甲方都要充分理解并一致认同设计规范与设计评审等质量管理措施对整个项目的意义与重要性。

　　2、选用合适的设计思想、设计方法

　　设计开始，在充分了解需求与项目背景的前提下，结合项目情况采用恰当的设计思想与设计方法，从设计的指导思想与方法上避免设计阶段的质量瑕疵。 我们在做软件设计时还要根据项目的具体情况与应用场景选用合适的设计思想作指导，选用合适的建模方法帮我们尽快理清系统的业务逻辑并理出思路。

　　从方法学的角度来讲，软件的设计与开发从最初的机器语言-汇编语言发展到面向过程的结构化设计方法，到现在应用较多的面向对象、面向组件发展到面向服务，每一步都体现了不断抽象、更加贴近业务实务的发展趋势。

　　不管采用什么样的设计方法进行架构设计，设计都需要以充分满足项目需求为目的，任何分析与设计方法只有针对具体问题才有实际意义。另一方面要考虑的是，采用的方法要侧重满足项目或产品的质量需求，也就是非功能性需求。确保设计阶段的质量无忧。

　　3、项目管理上避免

　　项目管理是贯穿整个项目生命周期的，80%的软件项目质量问题是由项目管理造成的。软件设计阶段作为软件项目的一个重要环节，要做好质量保障自 然离不开好的项目管理。从设计团队组建到角色分工与权责确定，到设计规范的制定与流程梳理，所有这些工作都需要一个好的团队负责人去把控。设计团队负责人 还要重视设计评审，通过设计评审不断发现问题，逐步完善细化设计架构与详细设计说明书，作为后期代码实现与测试用例编写的指导。要重视项目经理的作用，项 目经理的职责是进行沟通，促进沟通并建立沟通的渠道。只有通过沟通才能在项目成员间建立起认同与理解，从而将设计思路有效实现。

　　4、引入专业的第三方质量保障服务机构指导

　　一般的项目建设，乙方自己充当质量保障的角色，部分软件企业为了降低成本，尽可能的减少质量保障环节的资源支出，致使设计质量无法保障，即使有 部分软件企业视质量为生命，建立了良好的质量管理体系，但是囿于精力所限或赶工期或质量保障经验上的限制，设计质量也是不能令人满意。而从甲方看，一般囿 于人员、技术、精力的限制，甲方很难有精力或技术能力去对项目的质量进行深入的关注。更何况软件本身并不可见，充满复杂的逻辑关系，模块之间的耦合关联度 不易把握。第三方质量保障服务机构靠技术与服务来赢得客户信任，因而更加重视项目的质量与最终用户体验。从而会更加专业的对待项目过程中的质量管理。

　　综上，算是抛砖引玉，欢迎探讨！

　　Q（ amandating ）：

　　看着大家丰富的阅历和工作履历，以及职业前景的广阔，不禁想起自己可怜的履历。

　　没有开发背景的硕士（还不是computer专业而是communication专业），工作直接做了测试，接着做QA，现在兼职做EGP成员。

　　想问问专家，指点一下，最佳发展道路是？难道一直做QA？

　　同时说明一下发展道路上所需的资质，多谢了

　　A（ lilyli ）：

　　我的学历不及lz，但是工作经历上多了开发和项目管理两个阶段，这两个阶段的工作经历对于我做QA的帮助还是很大的，因为我可以结合我的项目经历，站在PM的角度和开发工程师的角度看问题，开展符合项目情况的质量管理活动。

　　个人认为QA是比较富于挑战性的工作，具备了项目开发知识还不够，还需要在软件工程、沟通能力、工作方式方法上做提高，才能帮助QA工作更好的开展。

　　发展的道路没有最好的，只有最适合的。如果你喜欢QA工作，那就做下去，兴趣会使工作变的更愉快

　　A（steplv）：

　　关于楼主问的问题，我略谈一下自己的浅见。

　　你问的是QA的职业发展道路与所具备的资质，在这里，我不想扯远，就这两点，我大体谈谈自己的看法。

　　1、一直走QA这条路

　　如果单纯要走QA这一条路，要具备什么素质，我曾经写过一篇文章《浅谈QA所应该具备的知识》（在本网站中的地址是：http://www.51testing.com/html/32/n-78432.html）， 这里面有详细叙述，这里不再多说。但如果说QA这一条路的发展，个人认为，随着中国软件企业越来越多的走出去（做外包或者其他），势必需要具备国际认可的 标准与规范，就跟“Made in China”这个品牌一样，需要接受国际环境的挑战，那么， 作 为行业的发展，QA将来一定会有所作为的，就跟现在PM的价值一样，只是体现方式不同而已。所以，一定要相信，QA这个行业在将来一定会有所发展并初具规 范与规模，当初本人选择这个行业也是在无形中看到了这点。毕竟社会是进步发展的，QA这个行业也是一样，需要发展，可能只因我们现在处于初级阶段，所以会 存在太多的困扰，但正因为有这些困扰，所以才需要我们去解决。

　　2、走向QA管理

　　我这里所指的管理，是指QM（质量管理），逐渐上升成为QML。这个过程需要大量QA经验、项目开发与管理经验、甚至软件配置、软件测试等经验的积累，也许过程比较长，也许比较短，一看机遇，二看自身能力。需要具备的资质还是包括“第1条、一直做QA这条路”中的内容，只是要求更精，而且此阶段尤其突出沟通能力、协调能力，并要注意培养自己的情商、逆商。

　　3、走向高级管理

　 　这里所说的管理，是指总监这一级别，也就是所谓的质量总监（或分管质量管理副总），如果真正走到这一步，那是相当的牛气了。这个阶段，专业知识体系不在 话下，更多的是侧重于对于整个企业质量管理体系的建立与优化、维护，企业的研发流程管理优化与维护，以及质量战略的制订、统筹企业管理。具备的素质我也不 知道，呵呵

　　Q（ amandating ）：

　　在我们这里，好像QA唯一有前途的发展道路就是做咨询了。你们怎么看呢？

　　A（ lilyli ）：

　　我觉得QA转管理的可行性是比较高的。我的分析主要基于这么几个方面：

　　1、QA需要具备很强的沟通能力，这点也是作为管理者的基本要求。

　　2、QA要有发现问题、分析问题并解决问题的能力，从组织的日常工作中发现可以改进的地方，并执行改进。这个能力也是作为管理人员的基本要求，管理就是发现问题、分析问题并解决问题嘛。

　　3、QA工作可以涉及到组织工作的方方面面，大处着眼小处着手，很锻炼人的。真要练成了一定的功力，转管理是自然而然的事。

　　当然，还得看组织只否具有这种竞争管理职位的机会哦

　　A（ grace ）：

　　还有一种和QA差不多的职位，是项目监理

　　A（tyrone）：

　　呵呵，其实我觉得这样的讨论会让人很泄气呢。因为 QA 原本是一项过程，后来因为资源管理的需要，把技术特性类似的工作集合在一起，发展成为一个部门。 QA 其实是公司里每一个人的责任，但是现在误打误撞成了一项看似专业又不像是专业的领域。不过，最好是成立这种部门的公司，人力资源管理单位，能够为这些人发 展一个职涯流路，或者在社会上，有系统地成立 QA 的专业协会，利用群体的力量，建立专业知识技能认证体系，并透过立法的方式，真正形成 QA 专业，让软件或产品的开发制程中，一定要有 QA 专业人员的参与，就如同盖房子要有建筑师及鉴测专业人员的参与，而且这些人一定要专业执照才行。

　　QA 人员如果没有项目管理与产品开发经验，一定要设法申请去参与，那怕是一年两年的时间，这些经验对于未来职涯会有非常大的帮助。

　　一个公司的 QA 部门如果非常强的话，就可以做很多事情，例如去承揽其它公司的 QA 、测试的工作，这样公司的 QA 部门可以从成本中心变成利润中心，或者到达某一个规模的时候，又可以把这个部门独立成为一个子公司，除了承揽母公司的 QA 与测试的工作外，更可以对外做更多 QA 、测试、审计、项目监理、第三方验证与确认、质量保证咨询等等服务的业务，不断培养自己的专业领域，例如专门在飞航控制或交通方面的软件测评、核电厂控制 系统的软件测评、汽车电子自动控制类软件的测评、银行金融系统软件的测评 ……. ，看来钱景不错呢，因为中国的内需市场够大。

　　QA 人员的发展方向，并不会是 EPG 而已，而是其它的相关事业，例如，软件测评中心、产品开发维护项目监理公司 （ 职司开发与维护的验证与确认 ） 、质量管理咨询公司等等，在这类的公司里，所有的管理技能都会被需要，可以有各种职务分工，包括测试、模拟、评估、验证与确认、审计等等服务的专业了，在 这些公司里，也可以导入 CMMI（ 未来还有 CMMI-SVC 呢 ） ，想当 EPG 的机会多得很。而在这类公司里，又有总经理、技术总监、测试工程师、项目经理、质量保证人员 ……. 等等职务，从这些角度去看，其实不管是那一类人都有很好的发展呢。

　　在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的 11 点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖 ： ）

　　我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把 “三范式” 当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。

　　大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下 11 点是我在数据库设计时最优先考虑的规则。

　　◆ 规则1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？

　 　当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是 “事务处理型”（Transactional） 的还是 “分析型” （Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户 定制化的问题当中。正如前面所说的，这里有两种应用程序类型， “基于事务处理” 和 “基于分析”，下面让我们来了解一下这两种类型究竟说的是什么意思。

　　事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是 “OLTP” 。

　　分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的 “插入” 和 “更新” 操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是 “OLAP” 。

　　那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。

　　以下这个简单的图表显示了像左边 Names 和 Address 这样的简单规范化的表，怎么通过应用不规范化结构来创建一个扁平的表结构。

　　◆ 规则2：将你的数据按照逻辑意义分成不同的块，让事情做起来更简单

　　这个规则其实就是 “三范式” 中的第一范式。违反这条规则的一个标志就是，你的查询使用了很多字符串解析函数

　　例如 substring、charindex 等等。若真如此，那就需要应用这条规则了。

　　比如你看到的下面图片上有一个有学生名字的表，如果你想要查询学生名字中包含“Koirala”，但不包含“Harisingh”的记录，你可以想象一下你将会得到什么样的结果。

　　所以更好的做法是将这个字段拆分为更深层次的逻辑分块，以便我们的表数据写起来更干净，以及优化查询。

　　开发者都是一群很可爱的生物。如果你告诉他们这是一条解决问题的正路，他们就会一直这么做下去，做到过了头导致了一些不必要的后果。这也可以应 用于我们刚刚在前面提到的规则2。当你考虑字段分解时，先暂停一下，并且问问你自己是否真的需要这么做。正如所说的，分解应该是要符合逻辑的。

　　例如，你可以看到电话号码这个字段，你很少会把电话号码的 ISD 代码单独分开来操作（除非你的应用程序要求这么做）。所以一个很明智的决定就是让它保持原样，否则这会带来更多的问题。

　　◆ 规则4：把重复、不统一的数据当成你最大的敌人来对待

　　集中那些重复的数据然后重构它们。我个人更加担心的是这些重复数据带来的混乱而不是它们占用了多少磁盘空间。

　　例如下面这个图表，你可以看到 “5th Standard” 和 “Fifth standard” 是一样的意思，它们是重复数据。现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验证程序没有拦住，让这些重复的数据进入到了你的系统。 现在，如果你想导出一份将原本在用户眼里十分困惑的数据显示为不同实体数据的报告，该怎么做呢？

　　解决方法之一是将这些数据完整地移到另外一个主表，然后通过外键引用过来。在下面这个图表中你可以看到我们是如何创建一个名为 “Standards”（课程级别） 的主表，然后同样地使用简单的外键连接过去。

　　◆ 规则5：当心被分隔符分割的数据，它们违反了“字段不可再分”

　　前面的规则 2 即“第一范式”说的是避免 “重复组” 。下面这个图表作为其中的一个例子解释了 “重复组”是什么样子的。如果你仔细的观察 syllabus（课程） 这个字段，会发现在这一个字段里实在是填充了太多的数据了。像这些字段就被称为 “重复组” 了。如果我们又得必须使用这些数据，那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。

　　这些被塞满了分隔符的数据列需要特别注意，并且一个较好的办法是将这些字段移到另外一个表中，使用外键连接过去，同样地以便于更好的管理。

　　那么，让我们现在就应用规则2（第一范式） “避免重复组” 吧。你可以看到上面这个图表，我创建了一个单独的 syllabus（课程） 表，然后使用 “多对多” 关系将它与 subject（科目） 表关联起来。

　　通过这个方法，主表（student 表）的 syllabus（课程） 字段就不再有重复数据和分隔符了。

　　◆ 规则6：当心那些仅仅部分依赖主键的列

　　留心注意那些仅仅部分依赖主键的列。例如上面这个图表，我们可以看到这个表的主键是 Roll No.+Standard。现在请仔细观察 syllabus 字段，可以看到 syllabus（课程） 字段仅仅关联（依赖） Standard（课程级别） 字段而不是直接地关联（依赖）某个学生（Roll No. 字段）。

　　Syllabus（课程） 字段关联的是学生正在学习的哪个课程级别（Standard 字段）而不是直接关联到学生本身。那如果明天我们要更新教学大纲（课程）的话还要痛苦地为每个同学也修改一下，这明显是不符合逻辑的（不正常的做法）。更 有意义的做法是将这些字段从这个表移到另外一个表，然后将它们与 Standard（课程级别）表关联起来。

　　你可以看到我们是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。

　　这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部分依赖”。

　　◆ 规则7：仔细地选择派生列

　　如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派生字段就有必要存在了。

　　通过上面的这个图表，你可以看到 Average 字段是如何依赖 Marks 和 Subjects 字段的。这也是冗余的一种形式。因此对于这样的由其他字段得到的字段，需要思考一下它们是否真的有必要存在。

　　这个规则也被称为 “三范式” 里的第三条：“不应该有依赖于非主键的列”。我的个人看法是不要盲目地运用这条规则，应该要看实际情况，冗余数据并不总是坏的。如果冗余数据是计算出来的，看看实际情况再来决定是否应用这第三范式。

　　◆ 规则8：如果性能是关键，不要固执地去避免冗余

　　不要把 “避免冗余” 当作是一条绝对的规则去遵循。如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会大大地降低性能的。

　　◆ 规则9：多维数据是各种不同数据的聚合

　　OLAP 项目主要是解决多维数据问题。比如你可以看看下面这个图表，你会想拿到每个国家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的交叉。

　　为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。

　　◆ 规则10：将那些具有“名值表”特点的表统一起来设计

　　很多次我都遇到过这种 “名值表” 。 “名值表” 意味着它有一些键，这些键被其他数据关联着。比如下面这个图表，你可以看到我们有 Currency（货币型）和 Country（国家）这两张表。如果你仔细观察你会发现实际上这些表都只有键和值。

　　对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会更有意义。

　　◆ 规则11：无限分级结构的数据，引用自己的主键作为外键

　　我们会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售方案的情况，一个销售人员之下可以 有多个销售人员。注意到都是 “销售人员” 。也就是说数据本身都是一种。但是层级不同。这时候我们可以引用自己的主键作为外键来表达这种层级关系，从而达成目的。

　　这篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根据你的项目性质和需要处理的数据类型来做出正确的选择。

　　案例中的情况，实际上就是为了赶进度而不进行测试，如果第一版进行规范的测试，后面那些“救火”英雄肯定会少些，同时也会得到客户对公司更大的认可。很多公司尽管对这个道理已经耳熟能详，但接下来如何进一步落实到行动中却是不容乐观的问题。

　　树立提高质量就是尊重客户的思想。

　　作者注意到目前不少公司存在着“愚弄客户”的嫌疑。不管是有心的还是无意的，很多公司认为只要能拿到“钱”就已经达到目的了，因此也不在乎是否 掩盖缺陷和敷衍客户。案例中的做法肯定是不尊重客户的，因为没有产品可以安装时，不说明实情，反而提供一个“满目疮痍”的产品来临时应付客户，甚至最后安 排实施人员“硬撑”半年。

　　生活中大家都讨厌假冒伪劣产品，但是软件行业从业者的却很少意识到质量不好的软件也是假冒伪劣产品。对客户负责，就是对公司负责。“树立客户是 上帝”的思想，一定要把重视质量落实到行动中，这样我们就不至于拼命的去生产那些“假冒伪劣”软件，最后被市场淘汰。在软件产业发达的今天，已经是客户的 买方市场，客户永远会选择质量好的、服务好的产品来满足自己的需求，只有质量好的产品，才可以不断的向前发展。

　　建立规范的测试体系和质量保证体系，逐步使软件开发进入良性循环状态。

　　在没有开发规范的前提下，软件团队是很少能开发出高质量的软件。因此软件团队一定要建立规范的测试体系和质量保证体系，同时把规范体系逐步落实 到工作中。案例中的公司就是没有“开发法律”的小软件作坊，所以才倒行逆施。不但做了很多浪费人力、物力的无谓工作，还给客户留下了不好的印象，造成了不 良后果。类似案例中这样的开发团队在现实中很多，都是处于混乱的开发状态。解决的根本办法就是逐步规范测试体系，进而建立全面管理的质量管理系统，最终形 成一个良好的开发体系。在好的开发体系下，片面重视进度的情况是不容易发生的。

　　2、缺陷反复出现，谁的责任？

　　下面的案例取材自某公司产品开发部开发某网络教育平台软件的工程过程。本产品在历时一年半的研发后开始投入测试。测试工作允许的时间为7个工作日。

　　测试工作过程记录如下

　　经过7个工作日的测试，得出结果，此系统不可用，需做重大修改。系统经过重新设计，保留了部分原有业务功能和业务逻辑之后重新开发，并进行了测试。测试工作允许的时间为三个月。

　　测试工作过程记录如下

　　在最后的系统测试结束后，对测试结果进行了分析，发现如下现象：

　　第二版中的4000个多缺陷基本包含了第一版发现的600多个缺陷；

　　相似缺陷较多，例如：如果一个程序员写的模块中发现某个页面邮件输入格式没有校验，那么他写的所有页面中包含邮件数据项的内容都不会校验；

　　数据校验遗漏较多：如果在一个系统输入了不合法的数据项，那么，整个系统中就会出现几十个数据项合法校验遗漏；

　　细节错误较多，例如：页面Title不对应的错误在系统中有600多个；

　　程序设计风格不统一。相同的功能点，如分页、翻页处理，做得五花八门，并且以测试人员的理解来判断是否为缺陷，导致某些功能点在不同页面就能发现个3到5个缺陷。

　　通过上面的案例信息，可以看出这个产品的开发过程本身就是不规范的，而且测试工作介入的太晚，同时在软件产品设计、过程管理、文档评审等诸多方 面均存在问题。产品开发工作和项目开发工作相比，一般进度压力较小。但是产品要进行商业化最终转化为通用的商品软件，质量方面的要求要比项目成果高很多。 缺陷反复出现几乎是软件产品开发的一个常见现象，要想解决这个问题，作者建议整个团队要从下面几个方面入手：

　　规范化产品开发流程：产品开发是应该遵循软件工程规范的，开发过程不应该跳过必要的环节。例如这个案例中的产品，无疑就是开始系统设计和评审工作没有做好，才导致二次开发，并且还有一个严重的遗漏就是首次开发忽略了测试工作。测试、质量保证等相关工作应该从立项开始就同步启动。

　　需求分析要明确：如果开发人员都不知道完成的内容是否正确，而是由测试人员来判断是否符合要求，那简直是需求分析的的巨大“失误”。用户或者设计者想要达到什么目标一定要清晰的描述出来，模棱两可的需求是没有办法设计测试用例的，更不用说进行测试了。

　　开发人员的调试一定要到位：开发人员一定要认真调试代码，至少要把自己负责的部分和其它模块的接口部分进行 详细的测试。这项由开发人员进行的基础测试是不可缺少的。目标就是把尽可能多的缺陷消灭在开发阶段，这也无疑是最节约成本的。现代软件系统十分复杂，程序 员写了程序不仔细检查代码，大多会有很多缺陷存在。如果凭着侥幸心里把所有的测试工作都交给测试工程师来完成，那只能适得其反。这些本来在开发阶段解决的 缺陷由测试人员来发现会有如下的后果：

　　耽误进度——首先，缺陷要经过一定的测试流程。例如上面的案例中，网页的Title写错这样的缺陷折腾了两个部门，简直是“劳民伤财”。

　　转移测试人员注意力——大量的低级缺陷使测试工程师无法进行更加深入的测试。测试工程师的注意力分散在对于开发工程师来说“无关痛痒”的缺陷上，使得更深层次的缺陷隐藏起来。

　　降低开发人员斗志——尽管这些缺陷是开发人员自己“制造”的，但是一看到上百、上千个缺陷，无疑会影响心情，降低效率。

　　当然，增大开发人员测试力度会带来一定的投入，因此需要在项目初期进行合理的规划，否则开发工程师就会拼命赶进度，自然把测试工作“寄厚望”于测试工程师。

　　加强缺陷管理：缺陷管理在这个案例的前期做的不好。在缺陷管理中，我们不但应该把缺陷修改工作能否一次通过 作为考核开发师的标准之一，更应该把一些常见的缺陷是否存在作为考核开发工程师的标准。在经过一定的积累后，开发团队应该形成一些常见的程序缺陷列表，以 引起开发组成员注意。在此基础上，还需要做到下面几个要求来提高质量：

　　修改缺陷要彻底——彻底不单单是要修改好测试人员提交的缺陷，还要争取不带来新的缺陷、这就要求开发工程师修改缺陷时要对相关联的部分进行检查。

　　低级缺陷不存在——常见缺陷列表中的错误尽量不应该由测试工程师发现并提出。

　　3、产品发布后，缺陷谁来负责？

　　本案例发生在一个正在建设测试团队的组织中，这个研发团队有独立的测试小组，但不是独立的测试部门，产品部经理兼任测试经理。在产品提交给代理商后，代理商发现了一个严重的缺陷，并对其进行了投诉，最终的结果是公司领导层对开发队伍的相关人员进行了一系列惩罚。

　　测试过程简要记录：

　　在代理商验收测试进行的第三天，测试人员发现了一个严重缺陷——“流转后的文档无法正常归档”。代理商立刻向公司的客户服务部进行了投诉。在此之后的10多天里，代理商的测试人员又陆续发现了近30个缺陷。

　　公司对产品的质量十分“震怒”，详细调查后，发现了这个问题产生的过程如下：

　　这个缺陷实际发现过一次，开发人员进行修改时，发现难度较大，决定暂停修改，得到了测试人员的认可；

　　接着大家忙于新的测试和修改工作；

　　产品发布前，开发工程师进行了修改，然后直接发布，在开发环境下问题确实得到了解决；

　　最后公司对相关人员进行了连带惩罚：

　　产品部经理、项目经理、开发工程师本季度绩效考核降为最低，即下个季度每个月份都要扣除一定比例的工资；

　　测试工程师绩效考核降为最低，同样扣除了工资。

　　上面案例的执行过程中，有几处显而易见的不合理的地方：

　　缺少文档，尤其是需求文档。文档是测试的主要依据。如果交给测试组仅仅是一个软件系统，然后告诉他“你们来测试吧，发现缺陷就提交”，我相信提交缺陷后开发与测试双方几乎会陷入喋喋不休的争吵状态。

　　测试介入太晚。只在系统测试阶段才安排测试人员进行测试，实际上质量已经失控了。尤其是没有文档，测试人员 无疑会把一些“缺陷”认为是合理的，而开发人员通常会自信地人为自己的开发工作是正确的。这样，一些问题是否是缺陷就会最终交给客户来完成。质量控制和测 试的相关工作没有按照合理的流程进行必然会产生这种结果。要改变这种现状测试工作就应该尽早地介入整个产品的开发流程。

　　回归测试做的不合理。案例中在回归测试时，“开发工程师修改完最后的缺陷后，把所有的模块打包，发送给客户”，这里明显还缺少一次测试。所有的缺陷应该经过修改验证后才可以发布产品，最后阶段发现的缺陷也不应例外。必须经过这道工序才可以发布产品，因为修改可能会带来新的缺陷。

　　产品发布的出口不对。案例中的产品最后是由开发人员发布的，这是十分不合理的。这些产品来自于开发环境，众 所周知，很多缺陷在开发环境下运行时是不出现的。产品在经过最后的回归测试并且确定可以发布后，应该把经过测试的产品而不是来自于开发环境的产品纳入配置 管理基线库，最后发布的产品应该从配置管理库中提取的。

　　缺陷流程不合理。这个带来严重后果的缺陷其实就是从不规范的流程“空隙”中逃脱的，原因主要如下：

　　缺陷的用户权限控制不严。开发工程师无权决定是否延期或者暂时停止修改某一缺陷。案例中开发工程师自己决定延期修改，测试工程师也进行了认可，这是不合理的做法。

　　没有对每个缺陷进行全程跟踪。测试工程师应该跟踪每一条缺陷，并确定修改后才可以进行关闭操作，而不是发现缺陷就完成了任务。

　　缺少了缺陷审核步骤。产品发布前，项目经理应该对产品发现的缺陷进行审核，根据修改状况来决定是否可以发 布。产品带着缺陷发布也是正常的行为，例如微软的大多数产品都是带着缺陷发布的。重要的是对最后未关闭的缺陷进行合理的处理。这些缺陷要由项目经理甚至是 技术总监进行审核签字后确定不进行修改后，才可以转入产品发布。本案例中如果事先对缺陷做过审核并确认，就可以规避风险。

　　上面的诸多原因，必然导致了产品会遗漏很多缺陷。实际也是如此。开始发现的这个“严重缺陷”只是个开端，后面陆续发现的30多个缺陷才是上面这 些原因的“所以”。如果这30多个缺陷都要进行惩罚，公司可以收入一大笔。虽然公司根本目的是想把产品质量做好，并不希望处罚大家，可是找不出提高质量的 根本方法，只能出此下策以儆效尤。

　　产品发布后的责任究竟应该由谁来承担？作者认为，应该根据具体的问题来决定。首先要意识到产品带着一些缺陷是正常现象。如果纯属个人原因造成， 个人是应当承担责任的，惩罚永远不是最有效的办法。实际上，本案例中的开发工程师在不到20天就提出了辞职并离开公司，给公司的产品开发带来更大的损失。 提高质量必须从提高项目管理水平处入手，同时加强质量控制来避免类似问题发生。

　　4、小结

　　通过对上面三个案例进行分析，我们应该已经意识到质量、进度、成本是相辅相成、同等重要的，决不可以忽略任何一个方面。尤其是软件质量，决不要 因为它是非硬性指标就敷衍了事。此外，软件测试作为质量控制的最重要手段，必须引起足够的重视。本文所讨论的案例，都是直接从实践中来的，且具有相当的代 表性。那么，为什么为数不少的软件企业会陷入上述“怪圈”呢？归根结底就是短期利益心理在作怪。希望企业能够通过本文的案例剖析，意识到问题产生的原因的 所在，进而提高软件质量管理水平，建立合理的质量管理体系。

　　自动化测试的优点在于快速、可靠、可重复、可重用、无疲劳，是对繁重的手工测试的一次解放，适用于回归测试。自动化还有一个特点是无人值守，测试人员要做的是通过看

　　REPORT

　　ER来判断系统是否存在缺陷。当然，脚本执行的过程中或多或少会出现ERROR，由于无人值守的特点，接下来的脚本就会不能运行，这也是为什么在自动化脚本中弹出框要用POP函数的原因。QTP提供的场景恢复可以解决这个问题，我将自己学习实践的过程与大家分享，有不合适的地方请大家指正。

　 　场景恢复可以看做一种嵌入式机制，是QTP脚本的一个可安装可拆卸零部件，这个零部件的作用就是在机器出现的问题的时候根据我们的指示执行指定的命令， 记录案发现场，等脚本跑完的时候递出报告，供我们分析。我们来看看怎么制造这个零件，我分享一个出错时调用函数截图的场景恢复。我使用的版本是 QTP10.00

　　一、设置

　　1、新建Recovery Scenario

　　首先我们打开Resouces--Recovery Scenario Manager窗口。

　　点击新建场景恢复图标，开始新建一个Recovery Scenario。

　　2、选择触发方式

　　场景恢复机制提供了四种类型的触发事件，分别用来识别：弹出对话框、对象的特殊属性值、运行错误、应用程序失败。我这里选择Test run error触发方式。

　　Error选择Any error，这样出现任何错误都能触发恢复场景。

　　3、设置恢复时操作，这里我们选择调用函数。

　　点击下一步，选择编辑好的函数，我的恢复操作函数如下，函数的作用是将出错页面截屏打印到REPORTER。

　　点击下一步，将add another recovery operations选项取消。

　　4、设置脚本恢复运行时的操作，这里处理下一个Action或者组件中的下一个迭代。

　　到这里，这个调用函数的场景恢复设置就基本完成了，下一步是给场景恢复取名并保存。

　　可以选择将新建的场景恢复添加到当前的TEST或者将其视为默认设置。

　　5、关联场景恢复文件

　　在file>setting>recovery选项中，可以选择添加或者删除场景设置，就跟resources中国添加关联函数是一个道理。

　　在test setting里可以看到我们新建的场景设置已经与当前TEST关联。

　　二、运行

　　批量运行脚本实验场景恢复的作用。

　　在前面的脚本执行出错时不影响下一个脚本的执行，也即是场景恢复起到了作用，如果没有这个设置，我们批量运行脚本时就会中断在出错的位置，没有起到自动化应有的作用。我们来看一下运行的报告。

　　SKIP ITERATION，我们设置的恢复操作，执行下一个迭代。

　　这个是出错的截屏，这里我将密码设置错误触发了场景恢复。

　　谢谢大家，有不正确的请指正。

　　前一篇：浅析SQL Server查询优化器的工作原理

　 　为了得到最好的计划，查询优化器必须在某些条件的限制下，尽可能多的创建和评估大量的候选执行计划。看到这里，就有一点需要注意了“查询优化器是尽可能 多的创建候选执行计划”，而不是为一个查询产生所有的执行计划。在SQL Server中，我们把一个查询产生的候选执行计划的集合称之为“搜索空间（search space）”。很显然，搜索空间中的所有的执行计划都返回相同的结果。

　　给一张示意图，让大家更好理解一点，如下所示：

注：图中的Search Space中的曲线代表执行计划

　 　从理论上说，为了找到最佳的执行计划的查询，基于成本的查询优化器应该生成搜索空间中存在的所有可能的执行计划，并正确估计每个计划的成本。然而，一些 复杂的查询可能有成千上万，或者甚至数百万可能的执行计划，查询优化器不可能去产生并评估一个查询的每一个候选的执行计划，如果那样，评估所有计划的时间 会非常的长，并且严重影响查询的整体的执行时间。

　　查询优化器必须优化的时间和执行计划的质量之间取得平衡。 例如，如果查询优化器花1秒钟的时间找到了一个比较好的执行计划，并且这个计划的执行时间是1分钟，那么这个时候，就没有必要再去花费5分钟的时间去为这 个查询找更优的执行计划。因此SQL Server不会做一个详尽的全部查找，而是尽快找到一个合适的有效的计划。由于查询优化器是有时间限制的，那么就可能选择的计划可能是最优方案，也有可 能只是一些接近最优的方案。

　　候选的执行计划是在查询优化器的内部通过使用转换规则，启发式算法产生的。候选 的执行计划在优化过程中一直保存在称之为“Memo（中文翻译可能为“备忘录”，以后我们就直接使用英文名称，很多的技术术语翻译过来之后就变味了）”的 内存组件中。从这里我们就可以知道：如果为了复杂的查询产生所有的候选执行计划势必会占用大量的内存。

　　我们这里只是简单的介绍一下候选执行计划的产生，后面我们会对每一个步骤进行详细的分析。

　　执行计划成本估算

　 　查询优化器需要为产生的候选的执行计划进行成本的估算，从而选择一个成本最低的。为了估算一个计划的成本，查询优化器会使用一些成本估算的公式来计算一 个计划的成本，这些成本估算公式会考虑很多资源的使用，例如CPU，I/O，内存等。成本估算主要是取决于算法中采用的物理操和估算的将要处理的数据记录 的量（估算数据记录的量也被称之为“基数估算”）。

　　为了便于进行基数估算，SQL Server会使用并且维护统计数据（statistics），统计数据描述了表中数据的值的分布情况，或者简单的理解为“元数据-描述数据的数据”。一 旦采用基数估算得出了吗，每个操作的成本和对资源的要求，那么查询优化器就会将这个成本数值进行累计，从而得出整个就会的成本。我们这里不会讨论过多与统 计数据相关的知识，在后面中会详细的讲述。

　　在下一篇文章中，我们会讲述计划的执行与缓存，以及与Hint相关的话题。

　　软件测试是对开发人员已经发布出来的软件进行验证和测试，以保证软件的质量。和其他工作一样，也需要相应的工作人员实现已规划好的测试计划。

　　本文将从测试人才招聘、测试人才的应用、绩效考核和职业规划几个方面对软件测试中的人才培养进行描述。

　　1、测试人才招聘

　 　招聘是为已经确定的工作岗位物色适合的人选的过程。在这个过程中，首先需要明确职位描述、技术知识能力要求、完成这份工作所需要具备的基本素质和其他具 体的特殊的要求。职位描述包括岗位职责和将来的工作任务。技术、知识和能力要求是必须掌握了相应的技术，知识和能力才能胜任该份工作的需求。基本素质是除 了技术、知识和能力必须具备的基本素质。下面将以初级测试人员为例，明确招聘需求：

　　明确需求之后是具体的面试。面试是一个双方初步观察，判断和选择的过程。面试前可以根据职位的描述和要求，设计相应的问题和题目，从各个方面对应试人员进行观察，判断其是否符合相应的要求。

　　2、人才的使用

　　当选中相应的测试人员之后，则需要进行试用。试用是面试的延续，是对其能力进行进一步的验证和观察。

　 　测试人员入职后，除了参加公司组织的入职培训，也需要进行项目入职培训。对于新员工的培训，可以根据积累的经验，建立新员工项目培训体系，以帮助新员工 尽快了解当前的项目基本状况。新员工培训结束后，则测试人员应该已经掌握了当前项目的基本知识，可以尝试安排其进行简单的工作。随着测试人员对项目的了解 程度增加，则应该逐步增加工作量和工作难度，直到其应该做的工作。

　　转正是双方经过观察，建立了信任，并愿意进行长期合作的标志。一方面是公司对测试人员试用期内的能力和表示认可，认为其可以胜任当前的工作，并愿意提供其展现才华的平台。另一方面，是测试人员对公司的认可，也一起共同发展。

　　在日常工作中，一方面给各个员工能力相当的工作量，另一方面也需要对测试人员实际的工作结果进行考核。同时及时调动测试人员的积极性和团队整体士气，给团队营造一种和谐，相互交流的平台。

　　3、绩效考评

　　绩效考评对许多软件公司来讲是很头痛的事，对于测试人员进行绩效考核也存在同样的问题，这里给大家一些建议：测试人员的绩效考核和其他工作考评一样，测试经理应该做到客观、公正和公平。那么，如何针对测试人员建立考评？

　　简单来讲，基本上分为两类，一类是可以量化的各种度量指标，如Bug的数量，Bug的类型，Bug的修复率，Case的覆盖率等等， 但bug数量一般不建议管理人员来作为考核的主要依据，因为数量多并不代表质量高等一些因素。另一类是不可量化的软指标，如工作积极性，工作的认真细致的 态度，合作态度等软指标，如果通过细分分级，也可以做到量化。还有一类是客户和开发人员的反馈，也作为绩效考核的一部分。另外，多数公司还将公司的总体经 营状况纳入绩效考核部分，加强员工的团队意识与责任感。

　　每个公司的状况和每个任务的难度和强度均不一样，那么具体的考评，则需要根据实际的情况进行设计。

　　无论什么样的绩效考核，应遵守基本原则：激励员工的工作积极性，提高团队意识，奖罚分明。

　　4、职业规划

　　当测试人员加入测试队伍之后，一方面是员工当前的工作，另一方面需要帮助其进行职业规划，以求得公司和个人能够双赢。

　　一个人是否能在工作岗位上做好，会有如下几个因素其比较大的影响：

　　● 个人兴趣爱好

　　● 技术能力

　　● 综合素质（包括逻辑思维和良好的工作习惯）

　　● 而这几个因素也会影响未来的职业发展。

　　一个人的职业规划，不单对测试人员非常重要的作用，对整个测试Team的规划发展也是非常重要的。

　　在日常工作中，需要和测试人员保持通畅的沟通，以聆听他们的愿望和希望，并且在日常工作中对每个测试人员的技能、性格、做事习惯、为人处世方式等等方面的观察，并结合其发展愿望，可以帮助测试人员分析、确定一个发展方向。

　　一般来讲，软件测试人员会有两个发展方向 – 资深的技术专家 和 测试管理人员。当然也有做SQA和项目经理的。这里我们就这两个发展方向给予讨论。这两类人员需要掌握不同的知识体系和相当有区别的性格特点，很难有人能 够同时兼顾。一般来讲，性格比较沉静，逻辑思维严密，喜欢钻研的人，发展为资深的技术专家比较合适，而相对比较外向，喜欢和各式各样的人相处的人，而且对 管理有兴趣的人，做管理科能比较合适，具体规划需要根据实际情况进行引导。

　　5、定期培训

　　根据测试的需求，结合各个测试人员的发展规划之后，可与公司的培训部门联系，为每个测试人员建立培训计划。可作Team的整体性的知识/技术普 及培训，也可结合实际的需求和个人发展规划，进行小规模的培训。最终的目的，就是提高个人的技术能力，同时也能提高团度的整体水平。

　　最后，软件测试人员的培训是一个系统的工程。应因人因地而宜，本文仅给出抛砖引玉的作用，大家不同建议或观点可与我联系。

　　单行函数和多行函数示意图：

　　单行函数分为五种类型：字符函数、数值函数、日期函数、转换函数、通用函数

　　单行函数：

--大小写控制函数
select lower('Hello World') 转小写, upper('Hello World') 转大写 from dual;
--initcap: 首字母大写
select initcap('hello world') 首字符大写 from dual;

--字符控制函数
-- concat: 字符连接函数, 等同于  ||
select concat('Hello',' World') from dual;
--substr:求母串中的某个子串
select substr('Hello World',3) from dual;
select substr('Hello World',3,4) from dual;
--length和lengthb: 字符数和字节数
select length('China') 字符数, lengthb('China') 字节数  from dual;
--instr:在母串中，查找子串的位置
select instr('Hello World','ll') from dual;
--lpad,rpad: 左右填充,将abcd用*填充到10位
select lpad('abcd',10,'*') 左填充, rpad('abcd',10,'*') 右填充 from dual;
--trim: 去掉字符串前后指定的字符
select trim('H' from 'Hello WorldH') from dual;
--replace:字符串替换函数
select replace('Hello Wordl','l','*') from dual;

--数字函数
select round(45.926,2) 四舍五入, trunc(45.926,2)  截断 ,mod(1600,300) 求于 from dual;
--ROUND函数
select round(45.923,0) 整数位, round(45.923,-1) 十位,round(45.923,-2) 百位 from dual;

--日期函数
--显示当前日期
select sysdate from dual;
--显示时间部分
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
--显示昨天，今天和明天，加减数字仍未日期
select sysdate-1 昨天, sysdate 今天, sysdate+1 明天 from dual;
--两个日期相减，结果为相差的天数，查询员工信息，显示员工工龄。两个日期不能相加
select empno,ename, sysdate-hiredate 天 from emp;
--查询员工信息，显示员工工龄,分别按照天，星期，月显示
select empno,ename,sysdate-hiredate 天,(sysdate-hiredate)/7 星期, (sysdate-hiredate)/30 月 from emp;
--months_between:两个日期相差的月数
select (sysdate-hiredate)/30 方式一, months_between(sysdate,hiredate) 方式二 from emp;
--add_months:在指定日期上加上若干个月
select add_months(sysdate,1)  下个月, add_months(sysdate,123) "123个月后" from dual
--last_day: 某个日期当月的最后一天
select last_day(sysdate) from dual;
--next_day:下周六
select next_day(sysdate,'星期五') from dual;
--对日期进行四舍五入
select round(sysdate,'MONTH')  月,round(sysdate,'YEAR') from dual; 
--对日期进行截断
select trunc(sysdate,'MONTH')  月,trunc(sysdate,'YEAR') from dual;
--日期格式
select * from emp where hiredate=to_date('1982-01-23','yyyy-mm-dd');
-- 查询当前日期：显示:  2011-09-17 15:12:15今天是星期六
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss"今天是"day') from dual;
--查询员工信息，显示员工的编号，姓名，月薪,要求有货币代码(L)，千位符(,)，小数点(.),
select empno,ename,to_char(sal,'L9,999.99') from emp;

--通用函数
--nvl(exp1,exp2):当exp1为空时，返回exp2
--nvl2(exp1,exp2,exp3):当exp1为空时，返回exp3；否则返回exp2
select ename,sal*12+nvl2(comm,comm,0) 年收入 from emp;
--NULLIF (expr1, expr2),如果expr1=expr2,返回null;否则,返回expr1
select nullif('abc','abc') from dual;
select nullif('abc','abcaa') from dual;
--COALESCE :找到参数列表中，第一个不为空的值
select ename,comm,sal,COALESCE(comm,sal) from emp;
--给员工涨工资,根据职位涨，总裁涨1000，经理涨600 其他人员涨400
select ename,job,sal 涨前工资, case job when 'PRESIDENT' then sal+1000
                                         when 'MANAGER'   then sal+600
                                         else sal+400
                                 end 涨后工资
from emp;

select ename,job,sal 涨前工资, decode(job,'PRESIDENT',sal+1000,
                                            'MANAGER',sal+600,
                                             sal+400) 涨后工资
from emp;

　　多行函数

　　和单行函数相比，oracle提供了丰富的基于组的，多行的函数。这些函数能在select或select的having子句中使用，当用于select子串时常常都和GROUP BY一起使用。多行函数分为接收多个输入，返回一个输出。

　　组函数：