微软软件测试质量体系最佳实践培训总结

微软软件测试质量体系最佳实践培训总结（共2篇）

篇1：微软软件测试质量体系最佳实践培训总结

微软软件测试质量体系最佳实践培训总结

一．培训的总体情况

这2天培训整体情况感觉挺好的。讲师陆宏杰有丰富的软件开发，软件测试，团队管理经验。并且在自动化测试技术和测试管理方面积累了大量的实际项目的经验。对于各种测试方法的重点，难点和实施技巧有深入的研究。在培训的过程中充分体现出来。讲师是提前收集了大家的问题，然后在讲课的过程中穿插讲解对这些问题的看法和解决办法。

讲课的内容很紧凑，讲课比较有技巧，容易理解。特别是针对有管理经验的测试人员。

培训第一天主要围绕如何对缺陷进行预防展开，提出开发，测试可以并行进行的想法，后又讲解了缺陷的统计（性能，安全的柱形图）大家一起分析，来体现缺陷统计对实际工作的推进作用。接着又讲到站在测试的角度如何对项目产生影响和起到引导作用。需要测试推进，建立一套质量保证体系，使得项目按照既定的方向和标准前进。后面提到测试计划，需要跟需求和设计严重相关，所以对于需求和设计的评审尤为重要。提到发布指标，是对开发和测试共同有效，2个角色应该站在项目效率的角度来考虑问题。提到测试用例的有效性（需要建立公共素材库，提炼并自动化），提到白盒测试（需要有用程序读程序的方式，前提是高质量的需求文档，和设计文档），等开发代码写完的同时，测试也完成了case的编写（自动化程序），开发来执行case。培训第二天主要围绕测试度量体系的建立和测试方法和技巧，最后将了测试管理。测试度量体系构成要素，目前大部分企业缺的是高效的工作流程，数据统计和数据挖掘，缺陷追踪体系，科学的测试管理。高效的工作流程需要工具来支撑。对测试用例的评判，可以通过需求覆盖率，代码覆盖率来分析。测试用例执行率是项目执行情况的一个指标。他们有个bug driver的角色，开发经理，测试经理共同关注缺陷。对缺陷的等级，分类，和解决优先级进行评审和安排。测试人员验证的详细程度也是代表一个测试人员的功力。手动测试和自动测试的区别，手工测试需要精妙的测试思想，行业和领域专家，自动测试需要比较高的coding水平。手工测试和自动化测试相辅相成，手工测试的人员的思想沉淀，和指导作用，自动化测试人员把这些想法工具化。性能测试的重点，测试人员如何进行分析和定位。好的环境文化滋生出好的创新，但是也要让员工保持积极的态度。需要员工去挖掘，创造，驱动一些可以改进效率事情。测试人员对多元的测试，测试是否存在hard code。并讲了具体的实例来启发大家。关于团队的管理，提出对于员工的职业发展，应该是协助员工进行发展，协助员工思考自己的长处和优点，并给自己一个目标，想成为哪一方面的第一，例如性能测试第一，缺陷数第一，行业专家，安全专家，工具专家等。主要看个人的兴趣。后又讲了一个bug bash的竞赛。测试的手段，内容不限，看哪个团队能找出最多的缺陷，并评选出最严重bug，最酷bug，最有力度bug等。二．培训对目前个人的影响 1．管理的认识

A．对团队建设和员工管理的认识

目前自己对团队建设的管理比较薄弱，后续将不断改进工作。例如对于缺陷数每个月小于10个的员工进行谈话。对员工的职业发展做协助，协助组员分析目前的兴趣和想做哪方面的第一，也是物尽其用人尽其才的思想。对团队氛围的创造，希望创造一种积极向上的气氛，关键自己也要实时抱持一种积极向上的状态，对表现不佳的人员及时提出意见。同时对于沟通方式进行改进。

B．对流程管理的认识

目前的流程管理存在一定的弊端，例如缺陷的管理，无法真正起到缺陷跟踪体系的作用。2.测试发展方向的认识

测试发展方向之前的认识也比较模糊，现在是认为只要能一起协助开发或需求来共同提高项目的效率，在这过程中对于每个出现的问题，大家觉得繁琐的地方多进行思考，并用工具来改进效率，应该就是好的工作。关键是要做个有思想的执行者，而不管是做测试或者其他岗位。

3.对测试技术的扩充

理论知识并不完全可靠，但是理论知识要拿来灵活应用于实际的测试，例如可以用单元测试的思想来进行系统测试。所谓的黑盒，白盒，也都是纯理论，针对工作应该是结合理论来形成一套自己的测试标准，而不管他应该叫什么。4.对测试管理的激情被激发

现在觉得测试管理要做的事情太多了，而且工作中需要改进的地方也很多，希望后续慢慢的改进，并提高整体测试人员的水平，通过给开发定位问题，甚至协助开发解决问题（虽然不是测试人员的职责，但是如果有能力在有时间的情况下可以进行），或者在需求评审和设计评审的时候能够提供有效的意见等等。

三．通过培训并根据项目组的具体情况，对目前的流程提出一些改进意见

1.可以把性能指标的收集进行推广，实现常态化的进行。后续将陆续安排收集测试环境bssp请求脚本的编写，和发起工具的编写。并定期进行性能指标的收集分析。

2.开发在修改报告中需要体现各个分支的情况，循环的情况，条件的情况，有效路径的情况。以便测试人员进行各个分支的测试用例的编写。

3.目前项目组在需求分析和架构建设（新业务部分，大部分都是为了临时满足需求而在原先的代码上改动的程序）这块，还是比较弱。测试人员应该站在可测试和可维护性方面对需求和架构提出自己的建议。

4.对缺陷跟踪系统的优化

A．对缺陷分类的改变，功能问题，性能问题，架构问题，扩展问题，可测性问题，安全问题。这样可以对测试人员的测试方向做引导，而不仅仅是站在功能测试的角度进行。B．对缺陷流程的增加，项目经理，测试经理定期对缺陷的等级，解决优先级，缺陷类型进行评审。以便后序工作的安排和数据的有效性。对于未按期关闭的缺陷进行自动统计，并邮件通知。

5.后续考虑搭建一个独立的build的环境，测试人员需要研究代码的情况下，可以进行加入调试语句，以便进行分析和定位。这些代码不入库。目的仅仅是为了提高测试人员定位问题和分析问题的能力。并安排相关的培训。不需要完全懂得怎么写，只要知道调试信息怎么加，如何关联查看代码。

6.关于测试环境管理的工具化，这块后续也将考虑，看下是否可以在统一部署工具中实现，抽取下需要展现的指标，在界面进行统计和管理。例如各个主机，各个程序目前的版本情况，各个主机的cpu，空间，内存情况查看。自动部署程序的研究等等。

篇2：软件质量管理6大最佳实践

全面管理，塑造质量文化

全面质量管理即为全员、全过程、全方位的质量管理，它具有以下基本特点:

1．全员:质量控制从少数质量保证人员扩展到企业的所有人员。质量控制管理不是质量保证部门一个部门的事情，需要全员的大力支持、准确理解、精确执行。

2．全过程:将质量控制、质量检验、质量统计延伸扩展到整个产品生命周期。

3．全方位：全面运用一切有效方法，全面控制质量因素，如软件开发成本、进度、可靠性、安全性等。

全面质量管理可以归纳为两大基本原则: 首先是以满足顾客需求为导向，不断改善，最终实现顾客的全面满足；其次是以全员参与为基础，进行全过程的质量控制。质量管理理论认为，“质量出自计划，而非出自检查”。软件前期的质量保证主要依靠设计、生产、研发，后期的质量保证则主要依靠测试、完善、改进。全过程的质量保证依靠行之有效的管理体系。这种观点强调运用确定性、过程化的管理制度、程序、体制来控制管理潜在诸多不确定性、多变性因素的软件质量品质。事实上，影响软件项目进度、成本、质量的三大因素分别是人、过程、技术，人永远是第一位的，人永远比过程更重要，人是影响质量的最关键因素，只有在软件质量管理过程中坚持“以人为本”，强调人与过程的和谐，塑造以人为核心的质量管理文化，才能让质量管理的成效得到淋漓尽致的发挥。

分级管理，把握

质量目标的层次性

ISO9001体系认为，建立质量方针、质量目标是实施质量管理的必经之路。事实上，现代软件的架构是层次化的，这一点尤其重要，软件质量也应按照层次从里到外、功能由轻到重、地位从低到高因地制宜、区别对待，对于不同的软件层面和需求制定不同的质量目标。例如:对于一个大型网络游戏而言，大气炫丽、细腻仿真的3D动画操作界面是非常必要的；但对于一个小型超市仓库管理软件而言，只要能满足出库、入库、损益、盘点的基本需求就可以了,简单粗糙的操作界面反而更容易上手。

在进行软件工程的质量控制时，应把握关键层面，抓住质量控制的瓶颈。一般来说，越是靠近底层、核心区域（如平台、框架、引擎、关键业务等）的代码质量要求越高，开发人员的素质要求越高，质量检测及保证工作代价开销越大。精益求精只适用于靠近核心的代码层；而对于外围代码层, 可酌情适当降低代码质量，放松测试条件。

验证确认，全程质量控制

质量控制是确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。质量控制的主要手段是验证与确认:验证是从开发者的视角来检查是否正确地构造了产品，而确认则是以用户的视角来检查是否构造了正确的产品。

事实证明，具有清晰开发模式及过程管理规范的软件产品，在质量上要明显超过那些没有明确过程模型及规范指导的软件产品。软件工程理论提出了诸多开发模型，如瀑布模型、喷泉模型、增量模型、快速原型模型、螺旋模型、迭代模型等，当前最常用的大型软件开发模式是螺旋式的增量开发方式（如图1所示）。

图中1〜7 是各阶段的输出点，也是质量控制点，有相应的输出文档和阶段性成果，均需要得到质量保证部门的确认。软件项目中最常用的质量控制工具手段，包括评审（技术评审、代码评审、设计评审、同行评审等）、审查、测试验证（黑盒测试、白盒测试、单元测试、集成测试、确认测试等）、抽查、调查、走查、旁站、缺陷跟踪等。

技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的，分为正式技术评审（FTR）和非正式技术评审（ITR）两种，该方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。需要重点指出的是，同行评审是一种特殊类型的技术评审,由与产品开发人员具有同等背景和能力的人员对产品进行技术评审，非常有利于发现产品中潜在的问题。成功的同行评审是提高质量和生产率的重要手段，评审的对象应该包括所有软件开发的中间和最终工作产品。

引入工具，复用成功模式

质量管理是可以通过信息化手段量化的，采用先进的质量管理工具可以极大地提高质量管理水平。例如：Bugzilla是Mozilla公司提供的一个开源的缺陷跟踪工具，在全世界拥有大量用户。它能够为软件组织建立一个完善的缺陷跟踪体系，包括报告缺陷、查询缺陷记录并产生报表、处理解决缺陷等。

质量和缺陷是一对无法化解的矛盾,想要提高质量必须千方百计地减少缺陷。有三种方法可以减少缺陷产生的频率、数量、规模等级。

1.事前预防：在开发过程中始终要考虑工作成果可能产生缺陷，将高质量内建于开发过程之中。主要措施包括提高技术水平和规范化水平，也就是练内功，通称为“软件过程改进”。

2.事中控制：及时对各个阶段的工作成果进行质量检查，找出并消除其中的缺陷。这种方式实践效果较好，已经被企业广泛采用，主要措施是技术评审、软件测试和过程检查。

3.事后补救：当软件产品正式交付到用户手中投入生产经营时发现了重大缺陷（如系统常常崩溃、运行速度极慢、报表统计错误等），然后再进行修改维护。这实质上反映出软件项目管理中存在较大的缺失和漏洞，建设单位、承建单位、监理单位三方都有不可推卸的责任，应规避这类水平低级、后果严重、影响恶劣的失误再次发生。

复用是在软件开发领域提高软件质量的重要方法之一。被复用的对象往往是经过反复使用验证的，自身具有较高的质量，因此，合理化复用有利于提高质量、提高生产率和降低成本，技术开发活动与管理活动中的任何成果都应尽量被复用，如思想方法、经验、程序、文档等。软件质量管理的最终目的除了能够不断持续改进之外，还在于形成有特色、有成效、可操作的质量管理模式，并最大程度地复用。

协同合作，三权分立

由于软件质量管理的专业性和复杂性，软件项目组织建设上应实行“设计、检验、监管”三权分离、鼎足而立的原则：设计部门专攻软件需求分析、规划设计、系统研发工作;检验部门从事系统测试（性能测试、回归测试等）；质量监管部门制定质量管理工作计划，对各部门的质量管理工作提出指导建议，跟踪、内审、改进质量体系的运行。

技术评审、测试和质量保证是提高软件质量的三个重要法宝，但三者在作用上各不相同。技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。技术评审和测试能弥补质量保证的不足，三者是相辅相承的质量管理方法。我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。建议让质量保证人员参加并监督重要的技术评审和测试工作（大约占其工作量的30％左右），只有这样他们才能更深入地了解软件的质量问题，把三者有机地结合起来，做到三位一体，全方位堵住质量缺陷的漏洞。在部门职能规划上，质量保证部门具有充分的权力，可以对质量不合格的工作成果做出处理，只有这样质量保证工作才不会被轻视，才更有助于加强全员的质量意识(质量保证过程域的主要活动如下图2所示)。

和谐管理，做好一把手工程

当前很多软件企业都组建了质量保证部门，出台了质量保证制度，然而软件质量并未得到实质性突破，质量保证人员也没有发挥预期的效果，造成这种情况的常见原因有两个:一是软件开发团队管理过程不够规范；二是企业领导者,尤其是最高领导者（即“一把手”）重视程度不足，措施不到位。

调查结果表明，在软件项目中，质量保证人员往往是最“吃力不讨好”的一族，通常没有实质性权力，项目成功功劳属于别人，自己缺乏成就感，项目失败却担负最多的责任。鉴于这种情况，领导层一定要从根本上重视、爱护、支持质量保证工作，充分发挥组织协调作用，体现人文关怀，运用管理艺术，构建和谐团队，让每一个项目组成员都树立较强的责任感、归属感和大局意识。事实上，软件开发工程是典型的“全员参与工程”、“一把手工程”，没有企业“一把手”的知情、重视、认可和支持，软件项目顺利实施和取得实效根本无从谈起。有时候企业领导层对于软件质量保证的作用往往是决定性的，这是任何技术手段都无法替代的。

链接

软件质量管理常见误区

误区一:软件质量是可以精确测量的。

软件的质量属性很多，如正确性、健壮性、可靠性等，但在大多数用户看来，实用、适用、好用的软件就是成功的。成功的软件通常都会在功能、性能、界面、操作等方面，以最简捷有效的方式满足用户的最紧迫、最直接的需求。质量是一个相对的概念，软件产品质量没有国际通用的评价标准，质量目标的弹性较大，没有绝对合格或不合格的界限，软件不可能做到“零缺陷”，有缺陷的软件仍然可以使用。

误区二:企业软件的质量越高越好，最好是“零缺陷”。

商业目标决定了软件的质量目标。软件的质量评价也不能从纯粹的软件工程、软件商品、软件技术的角度去考量。理想的软件质量目标不是“零缺陷”，而是恰好能够满足应用需求、生存发展、市场竞争需要，并且将提高质量所付出的代价控制在预算之内。一味追求高质量代码，把质量目标凌驾于赢利目标之上，是多数技术人员所犯的常见错误。

误区三:通过ISO9001、CMM3级认证就意味着软件质量一定有保证。

当前很多通过CMM3或者ISO9001质量认证的软件企业在软件项目管理上的确更加规范了，但代表核心竞争力的软件质量驾驭能力并未得到实质性的提升。产品生产过程与产品质量存在一定的因果关系，通常好的过程产生好的产品，而差的过程将产生差的产品。实践证明，软件质量保证并不能绝对保证软件质量，质量保证只能检测出哪些不符合既定程序规范、肤浅的软件缺陷，对于潜藏在软件深处符合既定设计规范的缺陷却显得无能为力。仅靠制度、规范、流程是无法全面识别出软件中的潜在缺陷的，质量保证对于保证质量而言只是必要的手段，而不是充分的手段。

误区四:拥有充足的人力资源，软件质量就有保障。