1、前言
进入公司半年有余，接触公司的开发项目至今，对公司的情况有了更深的了解。在此提出一些建议，希望可以对部门组建测试团队起到贡献微薄之力。
1.1 开发部现状
目前开发部完成或未完成的项目基本存在如下情况：
● 软件交付迟迟不能按照计划时间如期交付关闭；
● 大项目合同金额小，加之开发部人力资源有限，导致项目不赚钱或赔钱；
● 需求随着开发的深入不断的新增或更改；
● 外包人员的开发能力、对项目不够负责的态度等问题，不仅导致项目质量的低下，间接导致后续交付的种种问题；
● 测试团队依旧没有雏形，测试人员利用率低下或高投入低产出；
上述的几个问题体现出开发部的人力资源、管理体系和组织机构不够完善，仍需要管理阶层花些心进行规划完善。
2、测试人员在软件开发各阶段任务
表1：软件测试流程
软件测试流程如表1，包括测试计划、测试设计、测试执行及测试总结，测试人员的主要任务：
● 尽早的发现问题，尽可能的发现软件程序、系统和产品的问题；
● 针对问题进行分析、分类总结和跟踪；
● 督促开发人员尽快解决程序中的缺陷；
● 帮助项目管理人员制定合理的开发计划；
● 帮助改善开发流程、提高产品开发效率；
2.1 设计
设计包括需求设计、概要设计和详细设计，目前开发部的需求设计似乎涵盖了3种设计；测试人员在该阶段需要做的就是：熟悉需求，对需求的熟悉程度应该高于一般的开发人员；
2.1.1 现状
深分开发部二次开发项目周期短，项目需求不尽相同，测试人员未参加需求调研和设计，很大程度上是个人对文档的理解或同项目经理、需求人员的确认。
影响：
1、对需求理解肤浅不够深刻；
2、部分需求印象不深或毫无印象，导致需求遗漏；
3、刻意遵守文档内容或开发人员的设计，缺少个人观点；
4、编写测试用例产生该覆盖的需求没有涉及，不用验证的却编写了测试用例；
每一轮测试结束进行缺陷分析是必不可少的，关于缺陷分析和预防的一些方法可以参考：http://www.cnblogs.com/Jackc/archive/2009/02/18/1392657.html；链接中的一些方法讲的有些笼统和理论化，下面主要结合自己的项目测试经验做下简单的总结。
《软件质量管理实践--软件缺陷预防、清除、管理实用方法》这本书中介绍的缺陷度量元感觉很有用处，可以结合一下度量目标以及实际的项目确定适当的度量元。例如，可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。
在我们给出的测试报告中可以结合以上各度量元给出相应的缺陷分析，以此来判断被测产品的质量情况以及缺陷趋势。
作为测试人员也应该在分析指标、统计数据的基础上，对软件缺陷状况进行定性分析，发现问题，并向项目负责人和测试负责人汇报相关情况，以此优化测试流程。
……………………
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
回归测试中发现开发人员修改bug引进的新bug，针对这个问题要引起测试人员的重视，如果是开发人员技术和态度问题，那么一个项目多轮次测试时只进行主要功能测试和验证性测试是存在一定的风险。针对测试过程中发现开发人员所犯的一些低级错误，如打包错误，缺陷reopen等等，对于这些问题每轮测试结束时要收集上报给项目经理和测试负责人，力求开发人员作出相应的改进。
通过缺陷分析也可以发现一些其它的问题：测试用例执行情况、测试人员态度、缺陷遗漏、测试方法改进等等。
这里举个简单的例子，一个项目多Build测试，我们分析缺陷：
是否有些缺陷执行测试用例本应该在前期发现，但是实际在后几轮才发现？（当然，这个可能与测试策略也有一定的关系，这个也有可能是有些测试人员本没有执行测试用例，但是测试报告上填写执行）
是否存在Not A Bug的缺陷？（分析是开发人员问题，还是测试人员问题）
是否有些缺陷一个人执行测试用例时没有发现但是另一个人执行却发现了（可能与测试用例编写不明确有关系）
是否有些缺陷是在交叉测试时发现的，而这些缺陷测试用例又覆盖不到？
是否有些缺陷是有些同事不断的引入新的测试方法，测试技术以及测试工具发现的？
分析其它组的缺陷，是否有好的测试方法和测试思路引进？
----------------------------
作为测试人员我们要不断的从缺陷中分析，为自己测试改进提供参考，找出自己测试思路的短板和盲点，不断优化测试过程，提高测试质量和效率。
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
本文收录于《51测试天地》电子杂志第二十九期。
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第二十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
1、测试团队绩效考核
绩效评估的的客体：是个体成员还是整个团队。
● Pascerellayer认为，团队绩效评价应以成员个人完成工作的状况为基本依据，理由是激励只能作用于个人而不是群体；技能的提高和行为的改进最终必须落实到个人。若仅考核团队绩效，个体的努力得不到充分的肯定，就容易造成社会懒散现象，即个体由于参加团队工作，其工作效率比自己单独工作时的效率反而大大降低。此现象一旦在组织中蔓延开来，不仅会影响组织绩效，还会毒害组织文化。同时，由于绩效考核与薪酬及个人价值的实现相联系，因此，在团队中，能力高的成员倾向于对个人绩效的考核，从而得到更高的认可和报酬。
● Zingheim和Schuster则认为对个人的考评应考虑团队的整体绩效，因为团队的成功很大程度上依赖于团队成员间的团结合作，理解支持，若评估集中于个体层面，会导致个人主义盛行，忽视团队的协作精神，阻碍信息、技能的共享和绩效的提高，降低团队工作的优势。
● 因此在实际操作中，企业往往采取一种折中的方法，即按一定比例兼顾团队和个人两个层面的绩效考核。从目前的研究来看，还没有一种很好的办法可以科学地确定这个比例。但是，如果从团队性质的差异、团队所处的阶段等方面来考虑，那么至少可以确定考核的天平是更向个体的一极偏还是更向团体的一极偏。
绩效考核的内容：结果、行为还是能力。对于绩效内涵存在着三种不同的观点，即“绩效是结果”、“绩效是行为”和“绩效是能力”。Bernardin将绩效定义为“在特定的时间内，由特定的工作职能活动产生的产出记录，工作绩效的总和相当于关键和必要工作职能中等绩效的总和（或平均值）”，这是“绩效是结果”的典型观点。 Murphy等人将绩效定义为“一套与组织或个体所工作的组织单位的目标相关的行为”。近年来，以能力作为绩效的观点得到了广泛的使用，这是以评估个体所拥有的完成某项工作所具备的知识和能力的方式。伴随着这三种观点的诞生和发展，绩效考核大致经历了基于结果、基于行为以及基于能力的三个考核发展过程。？虽然这三种观点相互区别，且都是在否定前者的基础之上产生的，但是，如果不带入特定的环境，特定的组织，及组织发展的特定时期，那么三者之间并不存在绝对的优劣。如果组织下达的目标非常清晰，基于结果的绩效考核是最容易实施，也最有效；相反，如果目标模糊，无法准确衡量其结果，这种考核方式就会失效。基于能力的考核方式理论上是从战略管理的角度出发，最具有激励效果和长期效应，最有利于组织不断发展，但在实际操作中却很难达到效果。因为能力是无形的，它依附于个体，既受主观因素的控制，也受各方面客观因素的影响，很难用标准化的方法衡量个体的能力，即使是方法对组织期望成员所具有的能力和特质作出了解释，但这些解释仍是描述性模糊语言，在实际操作中仍然难以做到真正的科学公正。基于行为的绩效考核方法通过考核员工为实现既定的结果所必须做出的行为来实现对结果的控制，由于行为必然是建立在某种能力基础之上的，并且行为比能力更具有外显性和可测性，因此一定程度上，该方法兼顾了组织目标和个人能力。但是，绩效考核中容易出现目标置换的现象，一味对行为测评会导致成员将行为作为目标，进而影响实际目标的实现。因此，无论哪种考核方式，都有其适用的条件和要求，不存在一种绝对好的方法。
基于项目团队生命周期的绩效考核：
● 孵化诞生期：这是指团队形成前到团队正式形成的一个阶段，是选择合适的项目成员组成团队的时期。
→ 考核的客体是个人。团队的首要任务是筛选项目组成员，根据项目目标的要求，选择最为合适的人选组成团队，所以考核的对象是个人。
→ 考核的重点是能力。从项目团队成立的目的来看，它一般是为了开发一种新产品或者提供一项新的服务，因此对成员的知识技能要求较高，需要成员具有较高的技术水平和知识储备以及不断学习和创新的能力。同时，成立项目团队，意在发挥团队快速响应和凝聚集体智慧的优势，更加需要团队成员间的相互合作相互支持，所以需要较为系统地考核成员的协调合作能力，包括，对团队其它成员工作任务的认识、口头交流、个人成长、问题解决、责任承担、领导技能等等。因此，在选择项目团队成员的时候，通过对被选者专业技能、基本素质当然也包括过去的工作经历和背景等各方面的考核，最终确定较为合适的人选。
● 成长期：这是团队正式形成之后，团队工作逐渐步入正轨，团队成员开始通过个人努力和彼此的合作共同在所研究的项目上获得初步的成就。
→ 考核的客体是团队。团队成立之初，成员合作的意识还没有形成，工作的独立性较强，此时的工作重点应该是营造一种信任、关怀、相互支持的合作氛围。同时，项目也刚刚起步，没有取得实质性的进展，个人的贡献还无法准确衡量，在这种情况下，如果过多地衡量个人绩效，特别是个人产出绩效，不仅不利于合作精神的培养，也会由于准确性不高而使成员产生不公平感，从而对团队工作形成抵触情绪。注重团队整体绩效的考核，可以向整个团队成员传递这样一个信息，即必须注重团队的整体效率，共同开发团队能力。同时，对团队绩效的考核还可以提高团队成员对自己团队的自豪感和所有感，并不断提高其认同感和归属感。
→ 考核的重点是行为。刚刚进入一个新的团队，如果此前没有进行过合作，成员之间会由于陌生感而信任度较低，彼此在沟通和交流上存在困难，需要相当一段时间的磨合，工作进度也很缓慢。如果不通过有意识的加强合作意识的培养，难么磨合期就会较长，从而影响目标的实现。因此在项目团队进入成长期时，绩效考核的重点应该放在对团队成员行为的考核之上。绩效考核不仅仅是一种过程的监督和事后的衡量，更是一种对员工行为进行引导的方式。作为一种信息的传播途径，通过评估的本身，反馈以及与薪酬的联系，以直接或间接的方式告诉被考核者，组织鼓励什么样的行为、反对什么样的行为，从而引导和鼓励成员采用更加积极的态度和行为，主动参与团队工作，加强团队成员之间的合作和学习，使项目团队尽快度过磨合期，向着一个良性的方向发展。
● 成熟期：进入成熟期，团队工作进展顺利，项目取得关键性的突破，团队成员自由沟通，合作意识加强。
→ 考核的客体是个人。此时应该加大对个人绩效考核的比重。因为项目已经取得一定的突破，目标接近实现，团队成员的成果和贡献相对比较清晰，可以较为准确的衡量，需要对其加以肯定。如果仍然只是停留于对团队绩效的整体考核，并以此为基础进行利益分配，个体会逐渐产生不公平感，因为随着项目工作的深入开展和目标的逐步实现，个人由于态度、能力、技术支持等诸多方面的差异，贡献度的差距会逐步扩大，客观上会有成员的贡献大于其它人，如果不及时加以肯定和认可，那么就会挫伤这一部分核心成员的积极性。
→ 考核的重点是结果。成熟期的团队首要任务是推动工作进展，以保证最终成果的实现。由于既有的工作方式已经基本形成，合作沟通的氛围已经建立，如果仍然强调对个体行为的考核，会使成员将大部分的注意力投入到日常的工作行为和方式之上。事实上，鼓励行为的本身并不是目的，关键是行为带来的结果，合作和交流是团队的基本工作手段，但手段不能代替目的，项目及时高效地完成才是项目团队的存在目的。如果不以任务为导向而长期进行行为考核，容易使个体忽视目标和结果，影响工作的效率，例如，过分的注重沟通和交流，造成决策时议而不决，贻误时机，或者意见趋中，成员过分尊重群体意见，不愿表达自己突破性的想法和思路。
● 衰退期：项目目标已经基本实现，团队即将解散，此时需要对整个项目团队作一个综合的评估。
→ 考核的客体兼顾个人和团队。进入衰退期，绩效考核一方面需要通过对项目团队的整体绩效作出评估，以考核项目的完成情况；另一方面，也需要对团队成员绩效作出公正科学的总结，这不仅决定成员能否取得公平的报酬，也是其进入另一个团队的基础。
→ 考核的重点主要是个人的综合绩效以及团队的产出。项目团队任务明确，业绩是团队成立的最终目的，因此在项目团队解散之际，需要对目标的实现情况作一个综合评估，以此判断项目的成功与否。对个人也需要做一个总体的评价，尤其是产出和能力的评估，组织需要对此进行备案，成为以后的项目团队选择成员的重要根据。
2、测试人员绩效考核
考核基于测试过程进行，因此必须在过程结束之后才能进行。由于工程是分布提交测试的，每月可以根据实际情况进行月考核，工程结束后或任务结束后再统一考核。按照传统测试周期，测试过程分为：测试计划、测试设计和测试执行三个方面进行。测试计划属于测试经理的范畴。测试人员主要是测试设计和测试执行。
测试人员的绩效考核包括多个方面：
● 工作态度。包括工作责任心和工作积极性。
● 工作职责与期望达成度(注意：在工作安排前需求明确对应测试工程师的工作职责和对测试工程师的期望值，这里的工作职责一般是和管理相关的工作职责内容)。
● 工作内容考核。
→ 参与软件开发过程的工作内容考核，比如参与需求和设计的评审，就需要对需求的理解上，对需求提出问题的质量上等作出评价。
→ 参与测试文档的准备工作，如测试用例等，需要通过评审测试文档来考核测试人员的能力。如评审测试用例的质量，对需求的覆盖程度，可理解和执行等方面来判段测试人员的能力。
→ 执行测试的工作，需要从测试人员所发现的问题对测试人员进行评价。包括发现问题是复杂的还是简单的，是隐藏较深的，还是一些表面的问题。包括问题的书写上进行评价，问题的书写是否详细清晰，开发人员可以再现，还是含糊其词，不明所以。一个问题是否写多遍等。
→ 测试结果缺陷残留，对于已经发布的产品，从用户反馈问题考核测试人员的绩效，但是这个可能需要的时间比较长；对于不同版本的测试，可从版本的漏检进行统计。
→ 测试人员的沟通能力考核，包括缺陷在开发工程师中沟通的达成率和拒绝率。
● 工作效率与工作质量考核。
→ 测试设计中工作效率相关指标：
△ 文档产出率：这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小。
公式：∑测试用例文档页数（页）/∑编写测试用例文档有效时间（小时）
参考指标：根据项目汇总得出平均在 1.14 页 / 小时左右，高于此值为优，低于此值为差。
△ 用例产出率：这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。
公式：∑测试用例数（个） / ∑编写测试用例文档有效时间（小时）
参考指标：平均 4.21 个用例 / 小时
● 测试设计中工作质量相关指标：
→ 需求覆盖率：计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。
公式：∑测试用例数（个） / ∑功能点（个）
参考指标：100％。如果连功能指标都不能满足 100 ％覆盖，起码说明测试不充分。这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。注意：有的功能是难于测试的，那么未能覆盖到的需求要综合分析，明确是测试人员遗漏？还是无法测试？这需要放入问题跟踪表中进行后续跟踪；另外，有的功能点包含的信息较多或者有的用例包含几个功能点，这时只能把重复的功能点或重复用例按一个计，难于区分的要做说明。
→ 文档质量：测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。
公式：∑缺陷数（评审和同行评审）（个） / ∑测试用例文档页数（页）
参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。
→ 文档有效率：使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。用于考察文档是由有效的指导了测试工作。
公式：∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页）
参考指标：平均 2.18 个缺陷 / 页
注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。
→ 用例有效率：使用测试用例发现的全部缺陷除于测试用例数总和。这一指标是上一指标的补充指标，用于考察用例质量是否较高
公式：∑缺陷数（系统测试）（个） / ∑测试用例数（个）
参考指标：平均 0.59 个缺陷 / 用例，也就是说，每执行两个用例才得到 1 个缺陷，各工程有所不同，可以自己实践一下
→ 评审问题数：是否存在对需求理解、系统架构设计、系统设计等方面引起争议的问题。体现出测试人员发现问题的深入层次，有利于产品质量的提高。
● 测试执行中工作效率相关指标：
→ 执行效率：利用测试用例文档页数除于此次系统测试执行的时间总和（不包含用例文档编写时间）。补充指标方法是用例的个数除于此次系统测试的时间总和。用于获得工作中测试人员每小时执行测试的速度。
公式：∑测试用例文档页数（页） / ∑执行系统测试的有效时间（小时）
∑测试用例数（个） / ∑执行系统测试的有效时间（小时）
参考指标：平均 0.53 页 / 小时， 1.95 个用例 / 小时。即测试人员每小时执行半页测试用例或者每小时执行 2 个测试用例。通过横向比较，容易知道那位成员的执行效率较高。注意：执行效率高的不代表测试质量也高，甚至执行效率和测试质量成反比，所以后面工作质量的指标会补充这一部分的偏离。实际结果表明，用例执行效率高的成员，其缺陷发现率往往偏低，考核如果不将此纳入进来也可以将其作为测试改进的一项重要数据进行收集。
→ 进度偏离度：检查计划时间和实际时间的进度，方法是计划时间差额减去实际时间差额除于实际工时总和，用于考察测试人员进度情况，监控测试是否按照日程进行，是否满足了工程的进度要求。
公式：∑（计划开始时间 - 实际开始时间）＋∑（计划结束时间 - 实际结束时间） / 总工时
参考指标：15％ 进度偏离是个相对的指标，可能偏离了 20 个工作日，但是对于一个长达半年时间的测试而言偏离天数比上整体测试所需天数不足 15 ％，可能偏离了 3 个工作日，但是对于一个只有 1 星期时间的测试已经超过了整个测试阶段所需天数的 60 ％。
注意：计算时分子分母要保持一致，即开始或结束时间已经去除了非工作日时间，则总工时也要去除非工作日时间。因为制定计划时是根据每个公司的工作日来制定的，也就是说，考虑了非正常工作日的日程。
测试进度也是考核很重要的一步，如果没有进度保证，所有的测试都存在风险，第一种方法是测试人员可以采用自下而上的方式向测试经理报告计划用时，这种方式风险比较少，个人根据自己能力大小确定，但是缺点是存在测试人员虚报可能性。另一种方法是测试经理进行估算后分配工作日程，这时估算是很重要的前提，除了依赖于测试经理的经验外，对评估结果进行同行评审是很客观可取的方法。
→ 缺陷发现率：测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，你的工作可以通过这项指标得到反馈。
公式：∑缺陷数（系统测试）（个） / ∑执行系统测试的有效时间（小时）
参考指标：平均 1.1 个缺陷 / 小时 假使有位测试人员没有达到 1 小时发现 1 个缺陷，那么，除非产品质量高、模块较小，否则，就是他的缺陷发现能力不如其他测试人员。当然，详细分类中可以根据发现重要缺陷的多少来定义缺陷发现能力。
● 测试执行中工作质量相关指标：
→ 缺陷数：为了更客观度量，考虑到bug的严重性、技术难度、产品类型、模块稳定性等因素影响，不是用“所发现的bug数量”，而是用“所获得的bug value (缺陷值)”来度量，公式被定义为：
Bug_value=（P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt
其中：P0_Bug_Number：致命的（fatal）缺陷数量；P1_Bug_Number：严重的（critical）缺陷数量；P2_Bug_Number：一般的（major/normal）缺陷数量；P3_Bug_Number：次要的（minor）缺陷数量
Wd：技术难度系数，如Database， Enterprise Server， Java难度系数大，发现Bug不容易，Wd可以定在1.5 – 5.0
Ws：稳定性系数，全新模块，Bug比较多，发现缺陷比较容易；版本越高，越稳定。Ws可以定在0.5 – 1.0， 假如以version 10.0为1.0， Version 1.0 = 1/100， Version 2.0 = 4/10， Version 3.0 = 9/100， …， ， Version 8.0 = 64/100， Version 8.0 = 81/100
Wt：产品类型系数，可根据实际情况和历史数据来判断。Wt也可以和Wd合并为一个系数。
→ 有效缺陷数/率：被拒绝和删除的缺陷数总和，或者被拒绝和删除的缺陷数总和除于缺陷总数。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越低测试质量越高。
公式：∑缺陷数（系统测试中被拒绝和删除的）（个）
∑缺陷数（系统测试中被拒绝和删除的）（个） / ∑缺陷数（系统测试）（个）
参考指标：平均 21.9 ％（测试人员发现的每 100 个缺陷中平均有 22 个缺陷不被开发组确认、认为不是“缺陷”或者错误录入缺陷）。有效缺陷比率容易给出，但是有效缺陷数具体数据要根据项目情况，无法给出可参考的数值。
注意：这项指标可能有不正确的情况，假使缺陷被拒绝和被删除的原因不是因为测试人员误操作和需求理解等自身错误引起，而是系统本身不能实现或者数据错误引起的，那么就要考虑剔除这部分。对于测试人员发现系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布从而拒绝或删除的缺陷，应给予此测试人员奖励。
→ 严重缺陷率：这个比例用于弥补缺陷发现率的不足。主要是根据严重程度分类的缺陷数比全部缺陷或者有效缺陷数。一般而言，每个公司基本把缺陷严重程度分为严重、一般和微小，或者更细（通常等级数为奇数）。另外，可以对缺陷严重程度进行折算（严重：一般：微小 =1 ： 3 ： 5 ）通过折算可以得出权重，然后在计算测试人员分值。
公式：∑严重 / 一般 / 微小 / ∑缺陷数
∑严重 / 一般 / 微小 / ∑有效缺陷数
参考指标：严重 ~10% 一般 ~70% 微小 ~20% 。当测试人员发现的缺陷中严重错误比率越高，说明测试质量相对就好，通常严重程度缺陷数的分布呈正态分布。
→ 模块缺陷率：这个指标主要是根据一个单独测试模块的缺陷数除于模块本身功能点数得出来的。假使一个模块是单独测试的话，很容易可以和其他模块进行指标横向对比，参照对应的测试人员，得出所测试模块的缺陷数，可以考察测试人员测试水平，也为开发考核提供数据。
公式：∑缺陷数（系统测试（个） / 功能点（个）
∑缺陷数（系统测试（个） / 子功能点（个）
参考指标 平均 3.74 个缺陷 / 功能点 1 个缺陷 / 子功能点
注意：有些功能点没有子功能点，计算子功能点时要进行说明。
→ 遗漏缺陷率：发布后的线上故障，现阶段测试相关的故障主要都是因为测试遗漏，有遗漏就说明我们的测试还是效率不高，可以改进。
公式：∑遗漏缺陷数 / (∑遗漏缺陷数 + ∑遗漏版本发现缺陷数)
→ Bug发现的时间点，bug曲线的收敛性，理想的效率高的模式应该是前多后少，慢慢收敛的，如果前期bug非常少，后期却发现大量bug，那我们的前期效率就有问题。
→ 缺陷定位和可读性： 可读性内容包括Bug描述的规范性，分优秀、良好、普通与不合格，描述是否清晰，问题定位的附件是否完备等。如果一个测试人员只会通过页面将现象表达出来，而无法定位这种现象是有什么引起的，或者无法定位该缺陷到底错在何处，那么可以判定测试人员只是做了简单的表面测试，并没有对所发现问题进行分析定位。
● 对技术组(性能自动化和环境)测试人员效率的度量：
→ 自动化测试的引入和使用是否合理，不是每个项目都适合做自动化的，自动化并不能保证效率的提高，用5个小时开发的自动化脚本来替代3个小时的手工测试并不合算，自动化测试需要评审，按照项目的大小不同，必要的情况下才引入自动化测试。
→ 自动化测试，特别是性能测试结束之后，我们要分析部分测试结果，测试结果的分析水平，也可以作为衡量测试效率的一个指标。
● 对测试项目负责人的效率的度量：
→ 测试是否提早介入项目，例如FRD阶段就介入，越早介入，越有利于测试，使测试人员更加熟悉整个项目，使问题早暴露，提高整体效率。
→ 开发提交测试的时候，标准是否合理，把关是否严格，如果开发的质量不行，坚决要退回，不然会影响测试的效率和进度。
→ 测试计划阶段，评价测试计划的合理性，包括任务细化，细化的程度是否合理，任务顺序，资源安排，任务分配合理，风险预估等等。
→ 项目结束后，评价项目进行阶段中负责人的跟进情况，特殊情况处理，风险触发之后的处理，资源协调，信息收集，共享，沟通，配合等等。
● 测试管理。
→ 计划质量：测试计划的评审缺陷数或比率，可以与其他同类型项目或数据库平均指标进行对比。
∑缺陷数（评审和同行评审）（个） / ∑测试计划文档页数（页）
→ 成本质量：成本度量主要放在工作量这块。因为无论涉及工资还是奖金，都要和工作量挂上关系。成本质量主要是对测试活动的计划工作量总和比上实际的工作量数值总和。对测试人员考核的进度偏离已经考虑了进度因素，而工作量涉及的是成本因素。
公式：∑测试活动计划工作量（估算人日） / ∑测试活动的实际工作量（人日）
参考指标：原则上不能偏离计划的 ± 15 ％～ ± 20 ％。实际上，这个指标是对成本的一种度量。对于一个大的项目来说，估算值往往差距非常大，阶段统计时可能有± 500 ％！！这时调整计划是很必要的，在最终阶段取考虑计算平均估算值。一个测试经理必须对完成任务的成本进行有效控制。这两项指标是相对容易量化的部分，而需要添加其他量化指标需要综合考虑由项目经理和测试部部门经理给出标准，例如管理用时比率（整个项目测试期间管理时间占整个项目测试总时间）、系统整体缺陷数与其他同类型项目或数据库平均指标进行对比等等。
● 考核具体方法：
→ 将各项指标进行汇总分析，得出总和表格，根据测试人员各项指标大小进行排行榜制作，如列出 1 、 2 、3、4 名。
→ 确定阶段涉及的权重。例如将测试设计和测试执行权重各为 50 ％。其中，工作效率占 40 ％（即占所在阶段 20 ％），工作质量占 60 ％（即占所在阶段 30 ％）。
→ 确定每类指标的分值，然后每类指标达到平均标准给 100 ％，达不到或者超过根据 80 ％ ~120 ％比率给分。
→ 将比分统计出来后进行综合评定，必要的话增加一些调整系数。
→ 最好将定性分析纳入进来，采用问卷调查和项目经理评分制度给出定性指标分数，建议这部分权重不要超过 10 ％～ 15 ％以保证测试考核的可度量性。
→ 当所有考核分数给出之后，提醒一点的是，既然做了考核，就必须公开这些结果，而且考核具有导向型，不要让考核误导了对质量工作的追求才是最重要的。
● 考核注意事项：
→ 项目并不是一个月就能完成的，如每月进行，要考虑“可考核部分”为那些，挑选那些指标能够横向对比，然后分阶段、分任务评定。
→ 参与测试的时间长短也要给予重视，除了上述量化指标外，测试人员整体投入时间长短也是很重要的，加班也要作为特殊考虑因素，也许某个测试人员只参加了测试执行 3 小时，各项指标都是良好的，但是不可能给他比其他参与时间更长的人员更多的分数。这部分就是增加调整系数的原因。
→ 测试经理的测试设计和执行部分和项目测试人员一起考核，但是测试管理工作要单独考核，作为另外的加分，或者如文章前面所述纳入项目组给予考核。因为测试经理在项目测试中起着管理者和质量保证负责人的角色，不要把他和其他测试工程师平等对待。
→ 考核前要考虑项目的实际情况，不要盲目的轻易承诺测试组人员考核会和薪金或者淘汰机制挂钩，否则考核会起到反效果。
→ 作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
△ 测试团队发现的bug和所有bug之间的比例
△ spec设计造成的bug
△ 重复或者误提交的bug所占的比例
△ 每周发现的bug的趋势图
△ Bug严重等级的构成比例
△ Bug从提交到解决的平均需要时间
△ Bug从解决到关闭的平均需要时间
项目组测试人员考核的主要目的是在于激励测试组测试人员工作，鼓励能者，鞭策落后；另外，还可以起到发现人才和查找不足的作用。考核中即要体现多劳多得的原则，也要体现公正性和合理性原则，奖罚分明才能有效促使质量管理工作的进步。要想考核得到满意的效果，上述方法的重要的前提条件是：必须要在项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工作日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从谈起。
3、测试人员工作度量
测试度量主要从3部分开展工作： 一个是缺陷数据的统计分析，第二个是工作量的统计分析，第三个是测试工作量的估算。
● 缺陷的统计分析。主要是从缺陷严重性、优先级、模块缺陷的分布、缺陷的收敛情况、缺陷的修复情况进行统计，并根据统计结果，进行一定的分析。
● 工作量的统计分析。
→ 日常工作量的记录，这个由团队成员自己编写。在填写工作记录时，需要为每个工作记录选择相应的任务类型，并且工作任务持续时间最长不超过4小时。
→ 每星期统计本周团队成员在各个项目中的投入情况。不仅让自己了清楚，也让上司了解测试部对于项目的支持情况。
→ 每半个月统计整个团队的工作分配情况(但是数据是每周都填写的)统计每个人在各个项目的工作量分配情况。这个和上面那个统计表的侧重点不一样，上面这个统计表侧重在部门整体，现在这个表侧重于个体。
→ 定期(如每周或半个月)将团队成员在项目中的工作量投入情况记录到项目工作量投入表中。这个表格主要用于统计具体每个项目的测试工作投入情况，及作为后续测试工作量估算的原始数据。
→ 在项目到达一个阶段后，将项目测试收集的数据进行汇总、统计。收集的数据除项目基本信息外，还包括工作量、测试投入成本、项目规模、项目总成本、项目总工作量。主要分析测试在项目中的投入情况、成本情况、各个测试任务的分配情况等。
● 最后，根据对几个项目的工作量、成本以及测试任务占项目总测试投入的比例分析后，得到测试团队测试工作量估算的简易公式。可以根据这个简易的公式进行测试的估算，方便测试计划中关于工作量估算部分的编写，避免在估算工作量时缺乏依据。估算内容主要包括：测试总人力成本占项目总人力成本的比例及各项测试任务的工作量分配比例。
4、效率提高
● 测试负责人与开发负责人共同对项目进度进行商讨分析，作出合理的测试计划，并在测试执行过程中严格按照测试计划的进度和测试策略进行。
● 测试人员尽早的进入需求理解阶段，充分理解需求文档。
● 必要时做跟进测试，提高需求理解深度，可间接提高测试执行的效率；跟进测试，即系统测试之前的草稿版测试，需要与开发方沟通，让其协助来执行。跟进测试的目的不是发现bug，而是熟悉系统环境，助于需求理解和测试设计。
● 尽量避免失败的接收测试。一次版本无法接收，会浪费很多人力和时间，还会影响测试人员的测试热情。
● 任务分配合理化。测试负责人应根据项目组成员的经验和能力能个人因素，合理的分配测试任务，并将测试任务的模块和时间详细化，这样有助于提高整个项目的测试效率。
● 测试工作从某种角度看，会很容易掺杂个人主观意见，测试质量也受测试人员的责任感的因素影响，所以，培养良好的测试风格，提高测试人员的责任感，也能间接提高项目的测试效率。
● 慎重安排员工职务。管理者应该充分了解员工的特点，能力特长，个人气质，以让这些特质和分配的工作最佳配合，从而能够达到更好的效果。这样，员工也容易从高效的工作种找到乐趣，满足感，成就感，得到锻炼，同时很好地完成工作任务。
● 设定高绩效工作标准：
→ 给员工制定一个一般人都很容易达到的“低标准”，让员工觉得，你认为他能力不强，即使他努力达到了标准，也很难从工作中得到满足感，因为这个工作标准其它人也很容易就达到。
→ 低的工作标准，让大家很难打起精神努力工作，因为这很容易让人觉得，这个事情根本不重要，它对公司，对部门重要性不够，所以他们也不会将很大的精力投入到管理层认为不重要的工作中去，即使做好了，也是多余，因为这项工作本身部要求那么好。
→ 很多员工时间长了，很容易在潜意识中觉得，你分配给他的工作不重要，那么就意味着，他对这个团队，对这个部门也不重要，他大好的青春应该能够创造不俗的成绩，产生希望寻求实现自己价值的团队。本来最求成功的好员工，在这个的低标准工作中被浪费了，可惜。
● 提供员工自我控制方面的信息。这里的信息是指：让员工知道自己所负责的工作，对公司，对团队成功具有哪方面的意义。如果做砸了，对公司的损失是什么，对团队影响有多坏。这样，很容易让员工对工作产生很强的责任感。
还有，这项工作达到何种程度可以认为完成出色，这样，他可以自行按照高要求高效完成工作，以达到高绩效。这些信息确实是非常必要。
● 提供员工参与机会以培养管理者的愿景。要让员工具有和团队一起成功的自豪感，成就感，这样，他会站在团队集体利益的立场上看待自己的工作。那么如何赋予员工这种自豪感，成就感？当员工确实做了值得骄傲的时期是，他们才会觉得骄傲，否则就是不诚实，反而具有杀伤力。只有当员工确实有成就感时，他们才会有成就感，也只有当他们承担了重要的任务时，才会真正觉得自己对团队重要。真正的自豪感，成就感和受重视感是奠基于积极，负责地参与有关自己工作和团队管理的决策。让员工觉得团队的成功有他重要的贡献，如果他失败了，那么团队就会受牵连，他是团队成功不可缺少的一份子，他和团队是紧密联系在一起的，那么他就会对团队产生强烈的责任感，从而高绩效，高要求地完成自己的工作。
5、测试团队评估
测试团队评估目标： 高效的提高软件测试用例的覆盖率。高效提高软件测试用例的覆盖度可分解为三个指标：
● 通过测试用例的复用。
● 以数据驱动的形式自动化测试用例。
● 通过有效的测试用例设计方法扩大覆盖率。
软件测试用例覆盖率提高判断条件：
● 现有测试用例进行了有效的管理，建立测试用例基线。
● 明确测试用例编写的颗粒度，测试用例颗粒度可以跟代码行数对应，可以跟功能点对应，组织内部测试用例颗粒度要统一，保证所有人员大致是一致的。
● 单个功能点都进行了有效的规整，确定最小测试范围。保证单一个功能点进行了规整。
● 提高的方式放在功能点的组合和测试数据的增加上。
第3章 移动到云端：TiP的演化——在线的持续回归测试
Ken Johnston
Felix Deschamps
来自微软公司的Ken Johnston和 Felix Deschamps讲述了他们是如何通过在云端实施自动化测试，从而将基于产品的自动化测试变更为基于服务的自动化测试的。微软的邮件服务产品Microsoft Exchange Server中绝大多数的测试已经实施自动化了，而且其中大量的自动化是可以重用的。大多数测试人员对于“在线测试”（Testing in Production, TiP）这个概念还比较陌生，但是这一章解释了为什么进行持续监测是必要且有益的，同时为那些也正在考虑这么做的人提供了一些非常有用的小窍门。案例发生在美国，经历了3年多的时间，毫无疑问，使用到了微软公司的一些工具，如表3-1所示。
表3-1 案例研究特征
3.1 本案例研究的背景
你会将一个价值十亿美元的业务作为赌注放在云端吗？
Exchange 2007的发布对我们团队来说是非常令人振奋的。在刚推出这款产品的时候，我们已经成功地对产品架构进行重新设计，以使它能在本地的.Net平台上运行，从而转化到通过“角色”（role）来支持服务器管理，把64位机器作为目标平台，采用Windows PowerShell作为自动化服务器管理的工具箱。我们已经做好了迎接下一个挑战的准备！
那时，微软的总架构师Ray Ozzie正准备构建微软云计算未来的发展蓝图。我们都很清楚，云计算将会越来越重要，而正好Exchange产品也在寻求这种百年一遇的重大商机。通过云计算，我们可以在为客户降低成本的同时，给他们提供更好的服务，同时，我们也可以将Exchange产品中的业务发展壮大。
实施云计算这一举措也为我们引入了更多的问题。我们如何构建一组特性来吸引IT专业人员升级到Wave 14 （发布名称为Microsoft Exchange Server 2010）版本，同时又能以某一服务作为目标呢？我们又该如何对产品架构重新进行设计，以使它能够在运行遍布全球的服务前提下实现规模经济效益呢？何况现在我们不仅仅需要构建所需的软件，而且还要构建数据中心，这从何做起？
我们进入到完整的原型和发现模式。我们学习了很多新的web服务概念，以便通过冗余将服务进行纵向和横向扩展：
我们需要对多租户进行架构设计，这样单个服务实例就能服务于多个客户组织（租户）。
我们将为了满足某个功能的一组逻辑上的机器确定为不同的单元（有时称为小群组），这样有利于规划所获取的单元。
服务必须是遍布全球的，以支持业务连续性规划（Business Continuance Planning，BCP），并通过区域市场减少延迟。
我们学习了如何使服务成为一种业务，以及为什么必须对固定资产费（Capital Expenditure, CAPEX，如购买新的服务器开销等）、运营费用（Operational Expenditure，OPEX，比如给经营服务的员工发放工资等）以及总销货成本（Cost Of Goods Sold，COGS）进行管理。懂得了服务器并不是像变魔法似的出现在数据中心，恰恰相反，我们必须提前一年就拟定采购计划，同时，对整个数据中心的空间大小、供电和网络配置也要进行安排。对于那些曾经从事过一段时间的服务工作的人来说，这听起来都是些基本的知识，但是我们想让整个团队的人员都清楚这些服务理念，并真正懂得我们将服务业务实施云策略的意义。
受到以上学习过程的启发，我们决定使用以下的一组原理来推动Wave 14的发布：
复用和扩展现有的基础设施。
Exchange将保留一个代码库。
我们的团队是一个整体，不会分裂为服务工程团队和服务运营团队两个独立的团队。
3.2 将测试移到云端
作为专业的测试团队，我们很容易厘清该如何同时地测试一台服务器和一项服务。但是如何将现有的自动化测试丰富的资产应用到服务空间？最终的答案是：在线测试（Testing in Production, TiP），在当时看来这是我们之前决不会做的事情。我们的起点是一些现有的工具和资产，如表3-2所示。
表3-2 Exchange产品测试的现有工具和资产
① 用于描述软件公司使用自己的产品这种情况。
因为Exchange是世界上功能最复杂的产品之一，所以我们已经建了一个庞大的工程流水线来开发和测试我们的产品。其中仅测试实验室就有大约5000台机器用于运行日常的测试和预检入（pre-check-in）的测试。在这些机器模拟测试场景（如具有多级动态目录的网站、不同的故障转移配置、多角色配置等）的复杂拓扑结构中，我们每周对Exchange的80 000次自动部署进行相关测试。到2007年年末，我们已经编写了将近70 000个自动化测试用例来对产品进行验证，我们每天都运行这些自动化测试用例，且每次提交代码之前必须运行其中的某些测试用例。我们使用Microsoft Visual Studio作为我们自动化测试工具的开发环境，大部分是使用C#语言进行开发的，但也有少部分是使用JavaScript和C++语言进行开发。
与大多数微软的产品研发团队一样，我们要吃自己的狗食。在很多文章和博客上都谈到“如何把产品当狗食来吃”的概念。在这里，指整个Exchange团队将他们的邮箱装在团队的dog food（beta版）环境中或者基于云端的dog food环境中，为了增加复杂性，我们让两个dog food环境无缝地协同工作，即便每两周都要升级到最新版本，也是如此。
这一级别的自动化允许我们建立单一的主代码分支，并使之在多个产品单元之间具有一致的文件版本。这是通过维护一定数量的编译错误（构建过程中断）和最小范围的回归来完成的。在dog food中有了自己的邮箱，可以允许我们很快地找出被测试忽略的功能问题，并能增强对正在构建的产品性能的自信心。因为我们正转向基于服务的自动化，所以继续获得这种自信是非常重要的。我们采用的新工具和模型如表3-3所示。
表3-3 新的工具和模型
我们的每一个新工具和过程都吸取了推出Exchange Server产品时的经验。对于我们来说，解决如何与别的服务进行集成，以及如何在产品数据中心进行传统的测试活动，是一个新的转折点。
3.2.1 TiP测试策略的目标
我们设定的TiP测试策略目标是：
积极主动地发现产品线所存在的问题；
积极测试服务dog food；
验证新的产品上线；
确认配置变更或升级不会导致任何中断；
通过我们的附属服务进行合作方注销测试，如Windows Live ID；
衡量并帮助提高现有的系统中心运行管理器（system center operations manager，SCOM）监控方案；
发现潜在的缺陷；
工程团队可以使用这些测试来了解产品试验。
有了适当的目标之后，就要将它们作为测试——尤其是TiP测试的指导原则，并保证它们与整个Exchange项目的目标是一致的。我们最终选中了一组专注于效率和重用的原则。效率原则是指在复杂度最低的环境中用最快的速度找出正确的bug集合，OneBox是最主要的资产。另外，我们还选择将许多OneBox测试环境搭建在数据中心。使用以上方法时，会出现很多因数据中心网络和安全设置所产生的额外bug。重用变得至关重要，因为它意味着将现有的资产和过程扩展到数据中心和产品中，用于更快地产生好的测试结果。
3.2.2 指导原则
我们使用以下原则来指导我们的开发：
没有独立的团队，现有功能的测试团队都要参与。
产品中同样的代码库意味着我们应该尝试着复用整个产品和测试资产（自动化测试、测试装置、测试工具和流程），但是现在就在产品线上。
在实验室完成功能测试，意味着我们要在产品线上做进一步的测试，通过扮演客户的角色来验证用户体验。一些TiP方法利用可测试性特性深入到在线网站的堆栈中去，但是在最初实施时，我们坚持使用模拟终端用户进行黑盒测试的方法。
对测试场景的设计应该考虑其测试的广度，而非深度（即尽可能多地描述测试场景的覆盖面，同时测试场景的执行尽可能地快）
【真知灼见】
明确自己的目标，并为自动化测试设计可以实现的指导原则。
3.3 如何实施TiP
第一步是让测试经理也支持这些指导原则，然后再与团队的资深成员紧密合作，并根据所有主要功能区对原则进行评审。这一过程保证了我们之间没有隔阂，并且能够很好地在不同领域利用测试人员的专业技术知识。这个虚拟团队定义了40多个场景，这些场景代表了视为最重要的功能的宽度。
【真知灼见】
避免白费力气做重复的工作；尽可能地复用现有的自动化测试件。
第二步是决定如何将上面的40多个场景在整个产品系统中具体实施。如前所述，我们要尽可能地重用已有的资产，所以我们集中精力尽快定义和开发出所需的测试。最初实施时，我们决定使用现有的测试执行框架来运行测试，那样的话，就可以重用现有的测试报告工具、机器管理等，这也使得我们可以利用现有的自动化测试库。
我们的第一次实施的具体结构见图3-1。每小时执行引擎都会自动部署一台新机器，并安装相应的客户库、工具和测试，也安装一个“云定义”文件，该文件以一种通用方法描述了目标环境。测试本身并不知道目标环境的任何信息，通过这种抽象的方法我们可以指向某个数据中心、某个逻辑单元或者某台特定的机器（实际上现在是在预检入工作流中完成的）。
【小窍门】
另一种级别的抽象：将测试从机器和它们所运行的环境中分离出来。
图3-1是TiP系统拓扑结构的第一个版本，具有如下特点：
1）部署一台自动化测试主机，在特定的数据中心运行测试。
2）将测试结果发送到Focus测试执行（Focus Test Execution, FTE）服务器上，它将对测试结果进行处理（Focus是工具的名称）。
3）结果将保存到一个公用数据库上。
4）在运行过程中，TiP诊断服务周期性地对结果进行收集。
5）收集的结果会返回给数据库。
6）遇到问题时，产品bug会自动显示出来。
7）诊断服务给管理区发送一个请求信息，包含分页调度和报警信号的逻辑信息。
8）请求信息被发送到SCOM根管理系统（Root Management System，RMS）进行处理。SCOM的警报解除了，同时启动相应的响应处理机制。
图3-1 Exchange TiP第一个版本的系统拓扑结构
最初，在将服务提供（为用户注册和新建邮箱）给新用户之前，我们通过测试来验证服务的新部署。后来我们发现，尽管如此，与传统的以软件为中心的世界中我们只需保证软件质量不同的是，我们现在所经营的服务是一直变化的。不仅配置（域名系统（Domain Name System, DNS）、补丁、新的租户等）经常发生变化，更新的变化也很多，这意味着随着时间的增长，可能会遇到没有测试过或预料到的更新或者小的配置变动。根据我们的经验，即便是对产品来说安全的改变也可能会使服务中断。这也是为什么我们决定采用连续运行测试的方式，而不仅仅只是在进行部署的时候运行一次。
TiP具有一点类似产品服务监控器的作用；然而，相比于传统的轻量级服务监控，我们所运行的测试集更深入，端到端（end-to-end）场景鲁棒性更强。同样，TiP测试就变成了煤矿中的金丝雀，能对潜在用户面临问题提供更早的警报。过去是使用其他构建在Microsoft System Center顶端的基于代理的监控解决方案，然而，这些代理只是停留在单机器层面。TiP测试作为最终用户来运行，并且当它们使用性能降低的时候，会发出警告。
【真知灼见】
不要仅仅通过一种途径来实施自动化，尽可能使用多种有用的方法。不同方法之间可以互补并且往往比单独使用一个方法更有效。
作为我们整个决策的一部分，我们决定停止使用第三方服务，像Gomez和Keynote。虽然在整个决策中非常重要，这种类型的监控关注的主要是一些比较片面的场景（比如登录）的服务可用性。与此同时，TiP场景的宽度比其他测试要小（高级测试只有40个测试用例，而实验室运行的端到端的场景中有70 000多个测试），所以比一般服务的深度肯定是要大些。
通过使用自己的基础设施，例如，我们可以很容易地给手机的ActiveSync协议添加新的验证信息，这在传统的黑盒监控环境中是很难做到的，因为协议具有复杂性。另一方面是敏捷度，根据产品环境和测试本身，在数据中心我们可以进行更改并对更改作出快速回应。因此，正如只关注单机器的SCOM监控基础设施一样，这些TiP测试对外部黑盒测试是一种补充，而不是取代它。
3.4 每月服务评审记分卡样例
每个月都会对总体的服务质量（Quality of Service, QoS）进行一次评审，同时，根据上个月的结果进行有针对性的改进也是要进行评审的。这种评审有利于持续改进总体服务，并帮助改进TiP套件。这种每月的评审是由经理发起的，并且他每个月都参与其中，推动问答(Q&A)环节的进行。这也是他每个月深入实况网站并对其进行改进的一次机会。经理的支持和带动作用对任何一个类似这样的项目都是至关重要的，而我们从一开始就很幸运。图3-2所示是一个记分卡的例子。
图3-2 调整记分卡中的事故和调整情况
3.4.1 阅读记分卡
当你看到TiP记分卡时，提出的第一个最典型的问题就是：怎么阅读记分卡？这是一个很好的问题。
首先需要注意的是，图3-2中所示的记分卡只是每月进行评审的幻灯片中的某一页。首先将每月的数据放到一个很大的Excel数据表格中，然后高级管理层和其他团队将Excel中的每项数据放到一页幻灯片中进行评审。
图3-3显示了将记分卡按不同的区域进行分解后的情况。区域1提供了指向Excel表格中具体行的标记。因为幻灯片中空间有限，所以只显示了最近3个月的数据，但事实上，Excel电子表格包含的不仅仅只是这3个月的数据。在评审过程中，每个人都有这个Excel电子表格的一份副本，并通过在自己的笔记本电脑上进行评审来对幻灯片的内容进行更新。
区域2是细分（drill-down）后的区域的名字。在给出的例子中该区域的名称是“事故及调整情况”。
区域3是从Excel表格报表中拉出的数据。包括度量的名称以及最近3个月的数据。在图3-3所示的样例中，数据根据事故数量和服务组件，按月显示。当整个Exchange 云端服务的某个组件发生了一次故障，并需要人工干预来进行解决，则称为一次事故（incident）。通过最近3个月的数据，即便在已经达到每月目标的前提下，还可以帮助我们确认服务的发展趋势是好是坏。
图3-3 事故记分卡区域中的事故和调整
区域4是整个记分卡最重要的部分。在每个月评审之前还有一个预评审，是由负责改进该区域服务的工程师进行的。在遇到事故和调整的情况下，测试、开发和运营团队中的成员都会派代表参与预评审。他们分析数据，找出异常值和负面走向线。风险区域和关注区域分别用绿色和红色的圆点标记。在图3-2中，黑色的实心圆点代表红色，或者是PPT幻灯片中应关注的区域。有时候他们知道某一个度量的趋势走向不好的具体原因，但是更多的时候，他们只能进行猜测。此时就要依靠虚拟小组的成员来找出负面走向度量和异常值的根本原因。上述调查的结果就是图3-3中记分卡区域4的内容。通常，如果造成负面走向的根本原因是已知的，那么区域4中的内容就是一些总结性的建议补救方法。
【真知灼见】
对报表进行裁剪，使它仅提供你所需要的有用信息。
3.4.2 对事故和调整报表的处理
根据事故和调整记分卡，可以分析各个方面引起的事故。引起事故的原因包括SCOM服务器级别的监控器、TiP服务级别的监控器，以及与第三方监控一起运行的一些监控器，旨在保证我们与全球市场都有联系。影响我们减少用户方面bug的能力的两个主要因素是：一是监控过程中遗漏的真正问题的数量和严重性，另一个是等待时间(Time To Engage, TTE)。在整个行业和微软公司内部都有很多计算TTE的公式。对于Exchange来说，TTE是指从产品事故开始到找到合适的工程师（开发人员或测试人员）着手修复该故障所花费的时间（以分钟计算）。一般来说，不管是在业务时间还是之外，导致TTE很慢的最典型的原因是监控器遗漏。这两个度量紧密相关，并且是每个月关注的重点之一。它们中只要有一个出现问题，我们就要考虑需要更新哪个监控方案（SCOM、TiP，或第三方监控），有时候会给这3种监控方案都增加监控器。
TiP功能可用性记分卡用来提供粒子级别上服务可用性指标。可用性是通过以下公式来计算的：
通过为每个特性运行TiP，我们可以发现非客户影响的小的服务中断的发生，如ActiveSync中断。子服务中这种短暂的中断可能并不会对客户产生影响，但是却代表了服务的风险和退化。间歇失效或者（挂起）队列，与服务提供一样，通常都是可以在这个记分卡上显示出来的，但是并不是在关注调整的那张记分卡上（见图3-4）。
图3-4 TiP 功能可用性记分卡
【真知灼见】
经常利用自动化测试生成的信息来监控服务的发展、寻求进一步提高、保持自动化优势的前景，这是非常重要的。
（未完待续...）
相关链接：
自动化测试最佳实践 连载一
自动化测试最佳实践 连载二
自动化测试最佳实践 连载三
自动化测试最佳实践 连载四
自动化测试最佳实践 连载五
自动化测试最佳实践 连载六
现在基本每个项目都开始或多或少的有自动化测试用例了，当然也就有了一些测试框架，还有一些比较有名的开源框架比如，selenium staf等等，如果目前项目中你要负责开发一款自动化测试框架呢，前段时间负责一款接口测试自动化测试框架的设计开发，它不同于以往我开发的测试框，他是和数据库打交道的，所以如何让准备数据更灵活更方便是我着重考虑的，目前开发已完成并且很好用。哈哈
正好在着说说测试框架设计
测试框架，目前业内来看就三种：
1、录制回放的框架
2、数据驱动的框架，这种框架又分为数据和用例分类和数据与用例为一体，当然他们各有利弊
3、关键字驱动的测试框架
总的来说，第一种最简单，但是缺点也很明显，不以维护，第二种和第三种不相伯仲，需要根据具体的问题具体分析，但是第三其实有一些人工智能的影子，可以代码生成代码，BDD测试（Behavior. Driven Development）框架，比如jbehave easyb其实就可以看做关键字驱动的测试框架
数据驱动的测试框架，在上个我负责的项目中，实际我也是使用这个方案的，数据驱动的框架中，数据时重点，如何让用户更容易的造数和是用他是你框架成功与否！这里大家简单来看其实就是一个三层结构，数据准备层，测试过程规范层，drive层，负责执行等等
这里的数据是否分离呢，其实这个问题是没有更好答案的，要具体问题具体分析，因为数据如果分离，以后的case变化可能只需要维护数据，case的代码是不用动的。当时你能控制的是数据块，可能是一个文件等等，不方便深入到数据的内部。如果不分离好处是，你在case中一眼能看到你的数据，你想测试的是什么，并且整个测试过程是你可见，测试数据完全可控制的，比如一个log，已\001分割，你可以完全控制log中分割的每个字段。但是会增加维护的成本，目前我刚开发完成的框架支持以上两种数据提供，测试人员根据具体情况使用
关键字驱动框架，如果需求是数据和业务case尽可能的分离，那第三种方式是比较适合的，它可以保证业务与实现分离，数据与业务分离，层次清晰，易于维护。
大家还可以尝试一下代码生成代码，在上个我写的框架中，就运用了这个方法，很多common的东西，有固定格式的项目的具体的代码文件都可以考虑用代码生成代码，能很大限度的提高效率。
版权声明：本文出自 shadowwalker 的51Testing软件测试博客：http://www.51testing.com/?622454
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
2.6 管理自动化测试
我们的测试过程在持续改进，并且我们为测试设计了一个可记录的生命周期，如图2-2所示。
测试被开发出来之后，会进行评审，如果审查通过，这个测试就会被包含到候选队列中（一个测试集合用来尝试是否应该包含到整个自动化套件中）。如果一个候选测试在一行中有4天都失败了，那么它会被提取出来重新进行开发。在测试本身没有任何失效一周之后，这个测试会设置为“有效”状态，并可以包含到每晚的或者每周的测试套件中。
图2-2 测试的生命周期
如果产品的功能改变了但是其测试没有更新，测试可以“挂起”。根据挂起的原因，测试将来可能会成为“有效”状态或者候选测试状态（故障的原因被修复之后）。
不同测试套件的内容会进行周期性分析。度量指标用来衡量运行这些特定测试的收益。根据这一过程的结果，一个测试可以从一个测试套件移到另一个测试套件（依据测试的运行频率），或者在某些情况下转移到“退出”状态。如果某一个测试可能不会再用到了，团队就会考虑删除它。
我们制定了很多度量标准，都使管理层非常满意，而且非常关注我们，并提高了团队的优先级。毫无疑问，相比于之前，他们对产品审批过程的信任有了大幅提升。
2.7 测试套件和类型
最后，我们用这个工具批准开发人员代码检入：在允许提交新的或者修改后的代码之前，他们必须在三个不同平台上运行一个最小的验收测试套件（Minimum Acceptance Test Suite, MATS）来测试其代码。通过实验，我们选择这些平台来发现特定的或者罕见的故障。这一步骤有利于在变更被引入源代码之前，减少回归测试和失效的数量。这些测试的运行时间被控制在最短时间内，所以这些测试是有用的，在时间上并没有成为影响进一步开发的障碍。
【真知灼见】
提供及时的反馈，并且将日常开支减少到最小，为开发人员提供最好的支持。
该工具用作夜间的回归测试，这样开发人员白天一上班就能获得关于他们代码变更的反馈信息。这个测试套件包括大部分运行时间稍短的回归测试，并运行在有限选择的平台上：一般是在3 ~ 5个平台，并且运行时间为将近12小时。
我们通常还在3个不同的平台上进行每周测试，每一个测试套件运行4 ~ 5天。
这些回归测试具有很高的优先级，并获得了管理层的大力支持。这里出现的故障必须尽快修复。
除了这些回归测试外，其他测试是在候选批次中运行的。这些测试，是对新版本中新功能或者已变更功能的典型测试，具有更低的优先级，因为它们往往是由负责的开发人员和测试开发人员进行监控的。候选批次也包括夜间和每周运行的批次。项目团队可以根据需要定义更适合自己团队需求的测试套件。
这些测试在我们的内部测试工具上运行，性能测试与它们并行运行，并且与基准线进行对比。由于它们对测试和结果的特殊需求，它们都有自己的框架。这些测试通常仅在一个平台上运行。 发布测试一般包含以上描述的所有类型的测试，但是在至多22个不同的平台上运行。如图2-3所示。
此外，发布测试还包括在测试工具上运行的其他非功能性测试，比如：
长时间测试：不同的场景下运行时间至少为10天的测试。
扩展性测试：通过增加硬件来减轻负荷的测试，一般采用24台服务器和12台客户机来运行测试。
图2-3 发布测试的内容
2.8 现状
该工具已经用于不同的数据库产品的测试当中，而且现在是一个开源工具，请参阅http: //kenai.com/projects/jet。
2.9 在经过一段很艰难的时光后才得到的经验教训
在过去的三四年里，我们遇到了无数的困难：
软件测试变得非常成熟，有时反而会使我们忽略一些最简单的测试。比如，我们往往测试了复杂的SQL查询语句，却忽略了对在用户组之外创建新用户这类简单操作的测试。事实上，这种语句是不允许出现的，因为可能会由于在用户组的权限设置中没有考虑到这种情况而导致重大的错误。
我们过于关注大规模的自动化测试中的变化，导致有些非功能性测试有时并未得到足够的重视。比如，用户可能会获得只有专业人员才能看懂的错误提示消息，软件产品中经常缺少帮助功能，这些都是软件设计和测试中存在的问题。
使用随机生成的输入数据来进行测试时，有时虽然发现了严重的缺陷，但是因为测试人员能力有限，不能再重新生成导致故障的数据，所以并不能对调试过程产生任何帮助。经常讨论上述这种测试，一般是从经济的角度：它们通常需要额外的资源来辅助进行分析，并且在大多数情况下，并不能通过它们找到产生bug的原因，因此，也不可能通过它们找到产生软件缺陷的根本原因。
对自动化投入的评估主要看ROI的效果。如果不在比较的过程中引入其他因素，很有可能得出错误的故障报告。比如，我们要仔细地对结果进行比较，考虑到地域因素，有时要先进行转换再进行比较等。例如，当你在比较一台位于挪威境内的PC上的日期和一台位于美国境内的PC上的日期的时候，不同的时间格式（挪威为“日/月”而美国境内为“月/日”）导致时间显示的结果也会不同。
有时候通过软件来模拟物理故障并不是很容易，并且要模拟这些故障在多台电脑上几乎同时发生也是很困难的。此外，通过软件来模拟的断电和断网情形与实际发生的断电和断网也可能并不一样。
有时候可能会发生结果误报问题，因为测试时，即便遇到一个或多个失效也可能报告正确的结果。对于那些长期使用都未出现过故障的测试用例，往往更容易忽略对其正确性的检查。但随着时间的流逝，这些测试可能会不断积累许多错误，因此在报告中要不定期地对其正确性进行检查。 如果一些优先级比较低的次要bug没有立即修复，那么它们可能会掩盖一些主要bug，而这些主要bug由于引入的时间太长，往往更难对其进行分析。
必须要插入和修改等待时间来保证在测试继续运行之前，前面的强制性过程已经完成了。用更新的硬件取代现有硬件通常意味着要对这一过程再一次进行同步。
【真知灼见】
预测可能会发生改变的事物，并使它们在必要的时候更容易改变（例如，保存同步时间的核心列表）。
在测试套件的某些部分中，期望结果模板用来与实际结果进行比较。由于这类模板需要大量的维护工作，因此我们试图将这些基于模板的测试改为基于断言的测试。
引入新的平台有时会产生一些问题，并需要大量的资源来解决这些问题。同时，对操作系统的监控力度也要加大。
对于基于Windows的测试，要关闭自动更新，并将更新放在等待队列中，在测试可以中断的那个时段之前，再运行这些更新。
我们要清楚正在运行测试的网络中所发生的一切。比如，每隔一个月午夜时候出现一些无法解释的故障，最后发现，故障是由前雇员的一台电脑上的夜间执行工作所导致的：这台电脑没有关闭，而是仍然非常活跃地向本地网络发送查询请求的垃圾邮件。
【小窍门】
回头看有些错误是非常显而易见的，但你如果没有想到，它们可能就会困扰你。
建议定期做探索性测试，你将会对所发现的问题感到非常惊奇，同时，有时候你还可以将这些经验用于新的自动化测试中。
2.10 如何使用自动化测试书中的建议
在开发自动化测试过程中，我们运用了《Software Test Automation》一书中许多有用的知识点：
在进行自动化测试工具开发之前，首先对工具进行需求分析并列出需求清单，我们对需求清单中的每一个需求进行讨论和评审，结果表明这是整个开发取得成功的坚实基础。在评审过程中，参与人员中有代表不同需求的关键人物：经理、IT运营商、发布工程师、测试经理、开发人员和测试人员。
测试自动化只是从以下几个方面来对测试进行自动化：测试的准备、执行、核对、清空、存档、生成报告和度量。而测试执行之前的过程，例如，测试用例的设计等，是没有进行自动化的。
我们得到了管理层的大力支持来实施这项自动化工作，并且他们有着切实的期望。
【真知灼见】
管理层的支持是至关重要的，但是他们的期望必须要符合实际。
如果没有来自不同领域的杰出专家，我们就不可能取得成功。整个实现过程和解决方案都很复杂并具有挑战性。
幸运的是，在大部分产品中都没有要求进行GUI测试，这使整个自动化过程不会显得很冗长。
数据库中的GUI测试属于可用性测试，识别这种测试类型使我们取得了很多重大的改进，并使可用性测试延期。到今天为止，可用性测试还没有完成，但是因为考虑到这点我们受益匪浅！
测试工具的大部分开发是集中在GUI部分的开发。然而，在后面，GUI几乎不会用到，因为所有的自动化都是通过命令行界面进行的。我们前期之所以会集中精力进行GUI的开发，可能是因为我们大脑中还存在进行手动测试的定势思维。 【小窍门】
工具中良好的用户界面可能在自动化项目的前期最有用。
经过本次自动化项目的实践，测试人员也学会了别的技术并在他们感兴趣的领域变得更加专业。有些测试人员更精通测试开发，有些则在测试的执行和生成报告方面更精通。
只有心中牢记不断取得进步这一目标，才能让我们大步前进。通过小组讨论来分析现有问题以及如何对其进行自动化，最终就会找到解决方案。
让所有的测试人员参加国际软件测试认证委员会（International Software Testiing Qualifications Board， ISTQB）的基础认证课程，这样有助于术语的统一使用和理解，从而有助于增进测试人员间的交流。
有时候项目中人员数量突然减少从某种程度上也可以促进自动化过程——使用更少人力资源的需求变得更为突出。
能详细地向整个项目中的其他成员介绍每一步是怎么实施的，很有用，因为相比于将它们整合到产品之后再进行测试，显然单个部分的测试更容易执行。
【真知灼见】
在走向成功时，步子要快，但也要稳。
通过自动化进行的测试是整个项目的核心过程，无论什么时候出现了故障，它们都会尽力地报告给整个部门的每个人。这可能会对开发产生负面影响，因为看到这些失效之后，开发人员在修改代码时会格外小心，虽然这种格外留心有助于提高产品质量，但他们可能要为此花费过多的精力和时间。对于软件产品来说，对于“怎样的质量才算足够好”是没有明确定义的，这可能会导致在开发中投入过多的精力。这仅仅只是我个人毫无根据的假设，并没有事实能证明这一观点，但是开发人员太关注质量这在软件行业里是不寻常的！
2.11 总结
刚开始的时候数据库产品和测试的质量都很差，但是在自动化测试开始之前都得到了显著提高。
接着开始了自动化测试工具的开发过程。首先，成立一个包含信息传递人员、专家和利益相关者的团队，进行需求定义。然后，用最专业的人员完成了开发，自动化测试也逐步实施，在这一过程中，每个参与人员都起到了非常重要的作用：工具开发人员、促变者、管理层、工具管理人员以及整个实施团队。
早期我们达到了开发这个工具的第一目标，然后随着时间的推移，完成了越来越多的目标。我们的效率至少提高了2400倍，并为公司开发了一款非常好的工具。在实施小的修复或者增强功能的时候，需要的维护工作量非常少，这也为我们的成功帮了不少忙。我们的硬件资源都达到了最合理的使用：大部分机器除了短暂的休息以外，都是24小时/天，7天/周地工作。
对我们来说，这就是最终的自动化测试。
2.12 致谢
首先，要感谢Yngve Svendsen和 J?rgen Austvik在我写这篇案例研究时提供了非常有用的建议和反馈信息。此外，还要感谢所有为这个项目的成功而努力的人们，尤其是William Franklin，感谢他对我们自动化测试的大力支持和鼓励。同时，也要感谢本书的两位作者，感谢他们给了我公布这个案例研究故事的机会。
（未完待续...）
相关链接：
自动化测试最佳实践 连载一
自动化测试最佳实践 连载二
自动化测试最佳实践 连载三
自动化测试最佳实践 连载四
自动化测试最佳实践 连载五
1、测试进度及时跟踪、及时调整
XX项目建立每日例会制度，测试组长每天早晨总结前一天工作进度；检查工作量统计表、问题单、测试过程跟踪表；测试组成员反馈问题；测试组组长根据进度状况、反馈的问题决定是否调整资源和进度安排。
2、做好资源的规划，降低风险
XX项目由于资源的原因，主要是计算机硬件资源的缘故，两次设备故障，导致进度拖延。资源不充分，导致测试执行工作不能并行完成。资源是测试组将要面临的风险，在测试规划中必须考虑，并制定对策。
3、测试环境一定要与需求规格相符
XX项目管理器的开发一直在WIN2000上开发，并且开发人员在向测试组发布之前做过充分的测试，但是测试环境严格依照规格，在WIN98环境测试，发现管理器安装运行出现严重问题。
4、测试版本要受控
在测试过程中出现发现的错误导致后续测试无法进行的情况，需要问题更改错误之后再进行测试。由于要保证三套测试环境的一致和测试结果的有效性，测试版本的更新由测试组长控制，避免随意的更新。也不允许开发组更改测试机上的测试版本。
5、测试例的完备需要时间和经验的积累
XX项目的测试例设计经过三次大的整改：第一次是解决测试例可执行性问题，细化测试例以及测试数据；第二次是在第一轮功能测试完毕，通过与开发组的集中讨论，增加了大量测试例；第三次是在第二轮功能测试完毕。
6、随时增加新的测试例
在测试执行过程中，有时发现使用测试例之外的方法会发现一些问题，因此必须及时记录下这些方法，并补充到测试例文档中。XX项目使用测试过程文档进行记录和跟踪。
7、经常与开发组沟通促进测试的深入
经常有组织的与开发组沟通讨论测试方案。
测试小组要养成沟通和讨论的习惯。
8、测试执行过程中对问题要及时记录
避免口头问题汇报，导致问题没有记录，而没有进行问题的回归测试。
9、养成记录和跟踪的习惯
对任何需要记录的事项进行记录。XX项目对每次例会需要跟踪的事项进行记录；每次讨论进行记录；同行检视结果进行记录；并对问题的解决结果进行跟踪。
10、测试程序的编制也是开发活动
测试程序也必须经过分析、设计、编码、测试的阶段才能用于测试。
测试程序也必须有设计文档和使用说明
11、测试程序的编制不要从头开始
测试程序往往可以通过修改开发代码生成，不必一切从头开始。
12、测试工作产品必须进行管理
测试组的文档、各种记录、问题单、工作量统计表、测试程序、测试数据等必须进行良好的管理，并且测试组所有成员能够方便的访问到这些工作产品。XX项目主要按照版本、功用和时间来划分测试工作产品的存放结构。
13、测试环境准备需要占用大量的时间
从XX项目的工作量分布数据看，测试环境的准备与测试例执行时间在整个测试执行阶段是1：1的比例。这种比例与预期的时间要高。因此测试环境在测试规划中是必须要考虑的风险 。
14、版本发布延迟对测试组的影响
XX项目向测试组发布版本的时间推迟了几天，为了保证后续的测试进度，测试组先使用了中间版本调试测试例、测试数据、脚本。版本发布延迟是测试组工作规划的风险之一，在规划中必须考虑并制定对策。
15、软件的可测试性对测试组的影响
–XX项目本身是一个产品框架，不是一个拿来就可以用的完整的产品，在实际交付用户使用时，还需要做很多客户化的工作，或称为二次开发，如配置交易脚本，开发实际对帐签到签退程序，开发系统函数库等，在测试的过程中，为了执行测试，需要做一部分客户化的工作，模拟一个实际环境；在模拟客户化的过程中出现错误，而测试中不知道是配置的问题还是软件本身的问题，会影响测试的结果。该问题可以通过开发者培训测试人员的方法部分解决。
–XX项目服务器上的各个模块关联性强，依赖性强，独立性不好，比如，有的模块依赖于别的模块初始化一些环境参数（共享内存中），才能够启动，测试时，必须先测初始化模块，测试中不易定位问题。
–XX项目有些模块虽然功能独立，但想通过手工模拟一些场景来单独测试非常困难，必须依赖别的模块来测试，比如P–CODE执行器模块，原计划单独测试，由于上述原因，最后将它放在交易处理模块中来测试，测试覆盖性无法保证。
- XX项目的配置参数很多，相互间有很多依赖关联关系，而配置操作界面上是分别独立配置的，没有体现逻辑关系，容易产生不一致性，对配置人员要求高。
16、团队合作精神
–人力资源的重新分配，工作任务的重新划分
–测试环境资源的协调利用
–沟通与协作
–集体奋斗
–测试组长的核心作用
后记：这是若干年前写的东西了，翻出来了。但愿还有启发作用。
版权声明：本文出自 shiningredstar 的51Testing软件测试博客：http://www.51testing.com/?7622
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
摘要：记录我从毕业到现在的软件测试成长之路，从初入测试之门，到深入了解测试，到现在的资深测试工程师，每个阶段的收获都有所不同，服役的每个公司学到的东西也不同。总之，都是一笔非常宝贵的财富吧
关键词：软件测试；测试职业发展；
引子
我03年毕业，刚毕业就进了一家国企，在综合信息室的网络中心工作，干了1年，觉得没多大前途，主要是感觉在那里学不到东西，大学学的东西根本用不上多少，上班也就是喝茶（我还没这个爱好）、看报，然后就是那个部门有了新邮件了就打电话过来，我给他们收收邮件，（因为我们单位是军工单位，有些牵扯到国家 保密的资料，所以没有上外网）。有时候哪个部门的电脑坏了，就打个报告让我们计算机小组去维修，如果维修不了就报废，我就签个字，其他的一概不管，去这个单位，我收获最大的就是给单位建了个企业网站，以前的网站太破了，刚进去，领导就给我分了这么个任务，以前没接触过这方面的东西，我也是边学边做，其间也是拖拖拉拉，反正厂里也不急，以前在学校学的都是些书本上的理论，真正用的上的也没多少，在此期间，自学了dreamweaver、photoshop、 flash，还会点CAD，可怜的我大学期间没有电脑，这些东西在大学就应该会的，我工作了才学。不过学了总比没有学好，和我一同进单位的还有20多个学生，他们整整半年也没干个啥，整天上班就是下车间实习，美其名曰：了解流程，但是他们在实习期间因为没有领导管，车间的工人也不怎么认识他们，所以上班期间经常窝在宿舍睡大觉或者集体玩游戏，那时候真羡慕那些下车间的同事，羡慕他们不用上班，现在想想其实那样也未必是好事。也因为我刚进去就有了要干的事情，所以年终给我发的奖金是我们那批学生中最多的，但是这样我还是感觉在那里真的很无聊，完成了单位的企业网站，我就没啥事情做了。春节过完后办公室搬了新楼，我们又为新楼的网络忙活了一阵子，测整个大楼的网络通不通，我们使用的是局域网，好几天都是在整个楼上跑上跑下，测试每个房间的网线通不通，这时候对硬件有一些了解了，忙完了这个后，我就已经觉得真的该跳槽了，否则我可能就要废了。6月底我就请假去西安找工作，听同学建议说我刚从国企出来，如果直接转做软件开发，可能不好入门，工作也不好找，做测试可能比较好点，运气还不错，很快我就找了份测试的工作，工作找好了先上了1周的班，感觉自己对这个工作还能应付得了，就回去辞职了，因为是没到合同规定的时间辞职，所以我还交了3000的违约金，那时候我一门心思的想跳出来。
初入测试门，对测试了解很浅显
我的测试生涯就是从04年7月份开始的，刚开始因为自己所在在得单位用到的开发语言是c++，可是我在大学就学了c语言，所以我打算利用闲暇时间自学c++， 每天都有要做的事情，我给自己订了个计划，每天做什么，看多少c++，学多少测试知识等等，虽然每次都没有按时完成（可能我这个人比较懒散吧），但是我每天都在学习，这点我比较欣慰。刚开始接触测试，感觉对测试理解的太浅了，觉得做测试太简单了，就是拿个软件随便在上面用鼠标点一点，没有逻辑性，刚开始也不会设计用例，后来随着测试经验的积累，感觉自己在测试行业还是个门外汉，很多知识需要加强，像配置管理，还有版本测试方面，我根本就不懂，有时候测试环境的搭建都要开发同事来帮忙完成，那时候感觉自己好笨，真想把什么都弄懂了，但是什么事情都不像自己想象的那么简单容易，做了2个大项目的测试，都感觉不怎么理想。有的项目在马上验收的时候才发现bug，所以开发人员只能加班加点的在修改，我知道这是我的失职，但是他们从来没埋怨过我一句，这让我很感动。我还有个缺点就是脸皮薄，刚开始遇到bug，觉得不好意思给别人提，这也是那个项目最后延期的一个原因，也是我在测试中对bug的定位不够导致，应该公私分明，是bug就是bug，不能因为觉得发现开发人员的bug了，就是得罪他了。另一个原因就是个测试人员介入项目的时间太晚了，我是项目开发后期才介入的，对项目的需求搞得不清楚，好多文档都没有，什么都要靠自己去琢磨，没有概要设计和详细设计说明书，以至于到项目后期，设计改了再改，而我这个测试人员有时候却不知情，测出来bug，提交给开发人员的时候，他们却说这个已经不是这样设计的了。搞得自己干的很吃力，也很没有成就感。到了第二年公司开发部经理打算实施 CMMII，全体员工都开始学习软件工程和RUP，RUP2000上面说的那些可能不适合我们这些小公司，开发部经理就让我们在一起讨论，看那些该删除，那些该修改，这样的活动我感觉真的很不错，每周都有讨论交流会，把上周自己学习到的东西或遇到的问题提出来交流，最后公司制定了一套软件开发管理制度，以后项目的开发管理都比较正规了，这也是我感到最高兴的事情，因为管理正规了，测试工作也好开展多了。在此期间，我还自学了Rational 那套自动化测试工具， 已经能使用Robot进行自动化测试了，但是仅限于GUI测试，VU测试还在摸索阶段。第二年3月底公司接了个项目，经理决定采用正规的开发流程，需求阶段测试人员就介入，需求说明、概要设计、详细设计和部署都要有详细的文档说明。详细设计规定的一些软件规约都要记录在案以备以后测试或者修改之需，这次测试我感觉做的比较理想，但是肯定还有很多不足之处，那就是版本控制不严格，还有软件的需求变更自己和开发人员沟通的不到位。现在我还在研究 ClearQuest，我想以后公司能够用ClearQuest来进行缺陷管理。
…………………… 3、测试计划
根据需求文档和设计文档，测试工程师准备测试计划。测试计划包括：相关文档链接（需求、设计）、被测系统功能逻辑概要、测试内容、测试环境、测试任务分配及测试进度安排、是否需要性能测试等
4、测试用例设计及测试用例实例化
5、测试用例评审
主要参与人为开发工程师、测试工程师。
6、测试执行
开发提测后，开始测试执行
7、测试完成准备上线
待所有bug都关闭测试完成后，测试提交测试总结报告，等待上线。
8、测试总结
总结这次测试做的好的地方，以及做的不好的地方，好的地方继续推广给大家，不好的地方寻找改进措施。避免下次出现类似问题。
性能测试
在这里我能接手性能测试，这让我对性能测试有了比较深入的了解。性能测试不论使用何种测试工具，基本测试思想是一样的。即通过对被测系统加压，寻找系统的最大压力下的服务状态。性能测试，首先是编写性能测试方案，根据性能测试方案来开展性能测试。
……………………
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
6、测试工具
列举出性能测试需要的工具，如http_load、loadrunner等。以及测试命令
7、测试数据
这部分很重要。性能测试根据不同的性能需求构造不同的测试数据，如查询流程为A-B，如果A-B无结果，走A-C，如果A-C还无结果则走A-D，这时候就要准备这些数据，而且分几种情况进行，根据线上数据分析，走各个分支的百分比，算出个百分数，然后准备各个分支的测试数据，最后再准备一份给系统带来最大查询压力下的A-D的测试数据。
8、测试方法
压力测试还是稳定性测试。
压力测试：加压条件，加压命令，每次加压多长时间，如何进行加压的（这时候网络拓扑图就有他的价值了，从图上可以看出是对那个模块加压的，是系统加压还是分模块加压）
稳定性测试：正常压力下，系统长时间运行，验证系统正常提供服务，内存正常，无coredump等。
9、测试任务划分以及进度
划分测试任务，谁来造数据、多久能造好、谁来部署环境、多久能部署好环境、谁来执行压力测试等
10、问题及风险
性能测试中可能遇到的问题，如性能差、测试时间短、测试工程师并行多个测试任务等，这些风险如何预防。
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
本文收录于《51测试天地》电子杂志第二十九期。
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第二十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
查看全文请点击下载：http://www.51testing.com/html/76/n-844176.html
测试更加深入
由于在上面一家公司的自动化测试基本已经非常成熟了，自己发挥的余地不多了，2年后，我又跳槽进入了互联网行业，这次跳槽，基本是从通讯行业到互联网行业的跨越，通讯行业的特点是被测系统很庞大，测试周期长，测试质量要求很高。而互联网行业的特点是被测系统不是很庞大，测试周期很短（为了适应市场快速发展的需求），测试质量要求没有通讯行业那么高。互联网行业，往往为了抢占市场先机，快速开发一个产品，测试只要没有太大的问题，就能快速上线，这里没有所谓的bug收敛度，也没有版本的概念，就是需求测试，新增需求或者修改需求。这里由于存在的变数比较多，所以很多东西都没有像上一家公司那么固化，有自己可以发挥的余地。比如测试自动化、测试策略等。每次接到新需求都和前一个需求存在很大的变数，比如你现在测的这个是使用c++实现的，下一个你要测的可能就是用java实现的，比如现在你接手的这个项目是搜索引擎测试，下一个你接手的项目可能就是离线任务计算的测试。所以需要不断的学习才能适应不断的变化。在这里也是非常锻炼人的。让你不断的学习，不断的接收新的东西，不断的有成就感。总的感觉是工作的很happy。
测试流程
这里说说互联网行业的测试流程。来了一个新需求后，下面的测试流程一般是必须有的
1、需求评审
产品经理、开发、测试一起来review下需求，确认该需求是否可实现，是接受还是拒绝
2、设计评审
需求评审通过后，开发开始根据需求进行设计，并进行设计评审，参与人：开发相关人员、测试人员
问题：测试时间不够的问题：
● 问题描述：项目计划中留给测试的时间不够，开发工作延后导致实际测试时间减少，无法保证测试质量。
● 参考意见：
一方面，跟项目经理沟通：
1）协商能否增加计划中的测试时间，
2）适当降低项目的质量目标，
3）适当增加测试人员；
另一方面，从内部着手：
1）尽早介入开始测试；
2）划分测试任务的优先级，先测试优先级高的。
3）调整测试策略，比如只进行正确性功能验证等；
4）采取多种测试手段和技术，提高测试效率；
问题：加班问题
● 问题描述：送测版本经常在下班后做好，要求测试组晚上通宵测试。
● 参考意见：
1、尽量把测试安排在正常的工作时间；
2、下班后送测的版本，第二天开始测试；
3、项目非常时期，需要经常通宵加班的，和项目经理协商，测试组和开发组轮流通宵；
问题：送测节奏问题
● 问题描述：送测版本太频繁，没有按照版本计划的节奏，经常每天送测一个版本，导致测试工作流于表面，无法深入开展
● 参考意见：
1、按照既定的版本计划节奏接收送测版本；
2、未经协商的临时版本不予接收；
3、确实需要的提前送测的，例如程序已较当前在测的版本有重大修改或重构，开发经理需要和测试经理提前协商；
问题：送测版本不达标问题
● 问题描述：送测的版本没有自测，或者自测效果差
● 参考意见：
1、帮助开发组建立自测流程；
2、帮助开发组确定自测内容；
3、自测完成须提交自测结果记录；
● 问题描述：没有送测清单，送测清单没有及时发出，送测清单没有准确反映版本修改情况
● 参考意见：
1、没有送测清单的版本，不予测试；等开发组补上；
2、和开发经理共同确定送测清单的模板；
3、送测清单没有准确反映版本修改情况时，和开发沟通，补充内容；
问题：测不下去的问题
● 问题描述：冒烟测试通过率低，出现致命问题
● 参考意见：
1、版本打回去，不进行后续功能测试；
2、如果经常出现，则分析具体原因，跟项目经理沟通寻求避免的办法。
问题：测试环境问题
● 问题描述：开发缺少独立的开发测试环境，占用测试组的环境调试程序，影响测试工作正常开展。
● 参考意见：跟项目经理明确，开发组不能使用测试环境。通过修改密码等方式控制。
问题：变更问题
● 问题描述：项目计划变更，需求变更，没有通知测试经理；
● 参考意见：
1、协商建立变更流程机制，并由专人负责跟踪执行情况；
2、测试经理经常主动去了解是否有变更；
问题：需求类问题
● 问题描述：没有需求文档；需求文档过于简单；系统实现和需求文档有偏差；
● 参考意见：
1、测试经理分析具体原因，向项目经理或高层经理反映，敦促问题解决；
2、采取灵活变通的措施，积极主动开展测试工作
a）协调安排开发组给测试人员培训，指导；
b）测试人员加强对需求的评审和理解；
c）编写简明的技术文档；
d）尝试开展随机测试等。
3、实现的和需求文档有偏差时，和项目经理确认以实现为准还是以需求为准；
问题：缺陷类问题
● 问题描述：开发组处理缺陷不及时
● 参考意见：测试经理定期发送缺陷状态统计表给项目经理，总监等。
● 问题描述：缺陷处理了，没有标明怎么处理的，测试无法覆盖全。
● 参考意见：在缺陷跟踪流程中明确定义缺陷处理的规则；提醒开发经理对缺陷的修复情况进行检查和确认。
问题：多测试任务并行的问题
● 问题描述：在一个项目里，存在多个版本分支（例如，不同地域上线版本），要求测试组并行开展测试，测试组忙不过来。
● 参考意见：
1、不同版本分支测试环境独立：维护多套测试环境；
2、按照任务的轻重缓急，分优先级开展测试工作；
3、考虑自动化测试，提高工作效率；
问题：测试组被要求做测试以外的事情
● 常见的测试以外的事情：
1、让测试人员帮助写需求文档，
2、让测试人员编写用户操作手册，
3、让测试人员负责对外技术支持等。
4、让测试组负责配置管理；
● 参考意见：测试组的主要工作是做好测试。测试组被分派测试之外的工作时，测试经理判断是否影响测试工作，如果影响，测试经理有权拒绝。
软件测试岗位同一个业务产品不知不觉已经经度过了4个多年头，也是自己现有唯一的工作经历。为自己负责，对4年光阴进行一下回顾总结：庆幸这4年多也不是一成不变，每年基本都螚有新的形式挑战。
算来也是经历了产品测试工作的几个时代吧，浅谈一下自己对几个时代的感受。（PS：按个人感觉分的时代有片面性，老了记忆也不太牢靠可能发生时空穿越，有不正确的地方还请大家见谅！！谢谢）
零时代：只有Dev无正式测试工作（没亲身经历过，列在这里算全面一点吧，呵呵）
● 【时代特征】软件开发的初期，只需要唯一的核心人员：Dev。 编码完成后，无专职Tester也没有正式的测试工作，Dev按照自己对软件功能要求，随便进行操作验证，觉得没问题后就算测试结束，即可软件发布。
● 【时代优势】自由开发自由测试，相信“自由”会让现在的很多Dev激动不已，呵呵。
● 【测试定位】 无
● 【不足困难】软件功能点多了后，为保证质量需要测试执行的功能点变大， Dev们自己负责会觉得浪费时间；没有正式测试计划的情况下也很难保证质量。 觉得还是需要专职的测试人员好了
时代一：纯手工测试（自己应该是抓住了这个时代的尾巴，开始工作时业务线组内很多人也是纯手工的）
● 【时代特征】
1、测试工作纯手工完成，能弥补零时代不足，即：释放Dev劳动力，让他们可以专心的开发； 保证测试质量，开展正式测试工作：测试设计+TC编写+测试执行+产 出测试报告。
2、测试工作门槛低，逻辑清晰的实习生稍微学习一下就能胜任。工作重心从用户需求角度出发，进行测试。
● 【时代优势】劳动分工Dev的效率提高了；专人负责测试工作产品质量更能得到保证。
● 【测试定位】
1、从产品需求出发开展测试工作，产品质量的守护神。 产品上线质量好就可得到PD（产品经理），Dev的肯定，实现价值。
2、守护神对质量要求高，一些需求小点也可以和Dev拉锯几天。
● 【不足之处】测试工作效率不高往往成为研发环节的瓶颈。面对互联网产品迭代开发的模式，重复工作量大，纯手工太累！需要需求方式提高测试工作效率。
时代二：尝试小部分自动化（准确的说我参加工作时，已经是这个时代了）
● 【时代特征】依然是手工测试为主，业务线团队中开始尝试页面自动化等。
● 【时代优势】脚本覆盖主要流程，可以逐渐替代之前每次发布前人工手工回归的工作。释放了测试人员部分机械的重复工作。
● 【测试定位】依然是产品的质量守护神，开始用技术手段提高工作效率。
● 【不足困难】自动化刚起步，需要进步提高自动化覆盖率
时代三：UI和API自动化搞起（自动化持续集成，成为发布前标准）
● 【时代特征】尝到自动化的甜头后，测试团队全员都开始投入自动化工作，UI和API全面开花。 建立自动化持续集成， 自动化成为发布前标准等。
● 【时代优势】自动化工作蓬勃发展，覆盖率大幅提高。自动化释放了很多手工测试工作。
● 【测试定位】手工向自动化测试转型，论证把尽可能多的工作用自动化手段实现。
● 【不足困难】
1、UI和API都是集成测试，覆盖率到达一定地步后，遇到瓶颈。对系统和外部交互较多的产品线， 例如：电子商务网站的交易业务产品要交互应用（用户，商品，物流，支付，优惠，各种交易模式涉及的应用，各种交易渠道涉及的应用，各种特殊服务涉及的应用等）会较多， 集成测试依赖真实外部环境，导致脚本维护确认成本大。
2、业务发展需要，系统承载业务功能点愈来愈额庞大，又需要较快速的响应多业务方在系统中的迭代开发。即要求：测试工作量变大情况下，更加高效率。面对瓶颈，测试不得不寻求新的突破点。
时代四：拉开发下水：质量不是测出来的，是开发出来的
● 【时代特征】测试退去质量守护神光环，拉开发下水：提倡开发自测，坚持提测标准，让开发开展UT。代码review，要求开发更精准的评估每次迭代。
● 【时代优势】测试对质量保证发现了一个新大陆，看到解决时代三矛盾体的希望了。
● 【测试定位】综合考虑质量成本效率，更多的关注系统持续迭代的质量；退去守护神光环，对一些小的业务需求点不会和开发死磕到底了。
● 【不足困难】Dev面对这些新的质量保证工作，时间成本个人情感什么也不一定能承受，几项工作开展的效果如何，就不能一概而论了。
时代五：测试深入系统，开发掌握测试工作
● 【时代特征】
1、三军整合：之前海陆空（UI，API，UT）各军都有一定发展基础，考虑效率成本等需要整合。
2、测试UIAPI和开发UT整合时，考虑资源统一协调，提倡大家熟悉系统。
● 【时代优势】对系统进行剖析，测试更加熟悉系统，开发也更加熟悉测试工作。
● 【测试定位】测试工作还是让熟悉系统代码的人负责协调，优势原因：熟悉系统能更好的协调3军，能更精准的评估每次迭代的影响范围保证质量。
● 【不足困难】测试工作向开发转移，但人力资源还没有跟上，Dever承受不了新增工作量。后续：希望开发/测试比提升，熟悉测试的人员向开发岗位转移。
时代N：歪歪未来时代，开发测试岗位更加融合？
● 测试同学都有开发技能，熟悉系统；开发同学都熟悉测试工作，能随时投入测试工作。资源统一协调， 根据研发的不同阶段，大家一起开展各项工作？