测试工程师之管理及软件质量控制培训课件-孙老师

1、 测试工程师培训讲师：孙老师（北风网 )-测试过程管理及质量控制课程大纲第一章 软件测试管理概述1.1 测试管理的相关内容 1.1.1 软件测试流程及规范 1.1.2软件测试相关的配置管理 1.1.3软件测试组织的结构 1.1.4软件测试人员岗位要求及职业发展 1.1.5软件测试的度量方法 1.1.6软件测试管理体系1.2 测试管理要素1.2.1测试过程1.2.2测试团队的建设与管理1.2.3测试工作产品1.3 测试管理方法1.3.1测试人员的绩效考核课程大纲第二章 测试预备管理2.1 测试策略2.2 测试规划及执行2.3 测试配置管理2.4 人员的选择2.5 人员的培训第三章 测试准备过程

2、3.1 测试计划 3.2 测试设计 3.3 测试开发第四章 测试执行过程 4.1 测试执行 4.1.1 概述 4.1.2 记录结果 4.1.3 分析结果 4.1.4 问题跟踪 4.2 人员激励课程大纲第五章 测试分析过程 5.1 概述 5.2 问题分析 5.3 覆盖分析 5.4 测试总结第六章 软件测试质量管理体系 6.1 ISO 9001的过程描述 6.2 CMM能力成熟度模型 6.3 CMM与ISO9001的比较 6.4 软件企业建立质量管理体系要解决的主要问题 6.5 项目测试成功的关键因素第一章 软件测试管理概述本章学习目标 1. 掌握测试管理的相关内容 2. 理解测试管理要素 3.

3、掌握测试管理的方法测试管理的相关内容软件测试流程及规范软件测试相关的配置管理软件测试组织的结构软件测试人员岗位要求及职业发展软件测试的度量方法软件测试管理体系1.软件测试流程及规范1.1测试流程图完整开发流程 测试流程计划与设计阶段实施测试阶段测试总结阶段1.2计划与设计阶段立项会议需求评审测试工作启动测试设计阶段设计测试计划设计测试用例设计内容评审1.软件测试流程及规范1.3实施测试阶段测试交接实施测试 实施测试提交阶段性报回归测试同行审查1.4总结阶段测试总结报告测试验收测试归档测试工作总结完整开发流程测试流程1.1.2.1 计划与设计阶段1.1.2 测试流程1.1.2.2 实施测试阶段1

4、.1.2 测试流程1.1.2.3 测试总结过程要点详细说明输入条件立项会议工作内容项目（产品）可行性分析。项目经理的确定.根据项目信息，测试经理确定测试组长。退出标准测试组长确定责任人测试经理（确定测试组长）1.2计划与设计阶段1.2.1 立项会议由工程技术委员会召开立项会议，会议主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。1.2计划与设计阶段1.2.2 需求评审注： 1需求定义基本完成，此时应在评审会议召开之前发给测试团队，预留时间给测试相关人员熟悉、理解。 2测试部参与人员由测试部经理指定，主要由测试组长、测试设计等人员组成（还应包括配置管理人员、质量保证人员）。过程要点详

5、细说明输入条件需求定义完成工作内容测试团队成员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题，相关人员解答并确认。退出标准所有人员对需求无异议参与人员需求调研人员，工程技术委员会，开发组，测试部责任人工程技术委员会 过程要点详细说明输入条件项目（产品）开发计划完成工作内容1项目/产品经理邮件通知测试组长正式测试交接时间，测试规模预估等，同时提交相关最新项目资料：项目需求及软件规格定义文档项目开发计划开发设计过程中提供概要设计、详细设计文档。其他相关资料2组建测试小组，确定小组成员。并指定测试设计工程师及测试实施工程师。3召开测试启动会议，开发团队提供需求规格说明书和开发计划，确认开发组

6、与测试组对需要交接的测试内容、测试目标达成一致，统一项目组的目标和测试的工作重点。 退出标准测试小组成立，双方对测试目标及内容达成一致。责任人产品（项目）经理，测试组长1.2计划与设计阶段1.2.3 测试工作启动在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试小组成员可预先熟悉必要的项目（产品）资料。过程要点详细说明输入条件项目需求文档建立，项目开发计划完成工作内容根据项目的需求文档、设计文档，按照测试计划文档

7、模板编写测试计划。测试计划中应该至少包括以下关键内容：依据项目背景及要求，确定测试环境。测试需求需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级测试策略确定项目的测试计划内容，整体测试的测试方法和每个测试需求的测试方法，同时做好测试进度安排及人员调整。测试资源本次测试所需要用到的人力、硬件、软件、技术的资源测试组角色明确测试组内各个成员的角色和相关责任可交付工件在测试组的工作中必须向项目组提交的产物，包括测试计划、测试报告等等风险管理列举出测试工作所可能出现的风险测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审。退出标准测试计划由项目组评

8、审并通过.在项目开发过程中，要适时的对测试计划进行跟踪，以及评估此计划的完整性、可行性，在项目结束时还要最后评估一下测试计划的质量责任人测试设计工程师 1.2计划与设计阶段1.2.4测试设计阶段1.2.4.1 设计测试计划针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。过程要点详细说明输入条件测试需求明确，测试计划明确工作内容根据测试计划设计测试用例，设计参考原则：等价类划分边界值分析错误推测等业务知识及相关流程退出标准测试用例需要覆盖所有的测试需求测试用例集需进行评审并

9、通过项目进行过程中，适时的根据需求变更来对测试用例进行维护责任人测试组成员1.2计划与设计阶段1.2.4测试设计阶段1.2.4.1 设计测试用例在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。在用例的编写过程中，具体的任务和责任人如下：过程要点详细说明输入条件测试计划、测试用例集完成工作内容评审测试计划内容的正确性及合理性：测试环境、测试资源；测试需求范围，各个测试需求的优先级；测试策略及风险管理等；评审测试用例集：测试用例优先级测试用例集基于需求的覆盖程度退出标准测试计划及测试用例集评审通过责任人同行测试组，项目经理，1.2计划

10、与设计阶段1.2.5设计内容评审测试计划及测试用例的设计工作完成后，需通知项目组相关成员召开评审会议。在这之前需要将待评审的内容发给相关人员熟悉和理解。过程要点详细说明输入条件测试设计内容评审完毕，开发团队编码工作完成，并已完成内部测试；工作内容开发组根据测试启动会上所规定的内容，填写送测单，向测试组提交测试内容。测试小组检查提交部件的完整性和可测性：检查接收的测试内容（按照测试启动会上所规定的交接内容）；检查程序是否有病毒；能否正确安装/卸载；检查送测的软件是否完整，能否进行测试；退出标准提交部件经测试组检验通过责任人产品（项目）经理，测试组长1.3实施测试阶段1.3.1测试交接过程要点详细

11、描述输入条件测试组长于前一工作日定出当日的测试计划，确定可用的测试用例。工作内容测试实施工程师根据测试计划中分配给自己的测试任务和提供的测试用例，实施相应的测试用例。记录实施用例的结果，提交当日测试纪录。提交缺陷。退出标准测试用例中的所有任务被执行，结果被记录。责任人测试组成员1.3实施测试阶段1.3.2实施测试 1.3.2.1 实施测试实施测试用例将花费测试组大部分时间，这些工作都是建立在前期很多计划工作的基础上。过程要点详细描述输入条件测试组完成了预定周期的测试任务工作内容测试组长根据此轮测试的结果，编写阶段性测试报告（参考测试阶段性报告模板），主要应包含以下内容：测试报告的版本测试的人员

12、和时间测试所覆盖的缺陷测试组在这轮测试中所有处理的缺陷，报告测试组长处理的缺陷和实施工程师验证的缺陷。不仅要写出覆盖缺陷的总数，还要写明这些缺陷的去向测试新发现的缺陷数量上一版本活动缺陷的数量经过此轮测试，所有活动缺陷的数量及其状态分类测试评估写明在这一版本中，那些功能被实现了，那些还没有实现，这里只需写明和上一版本不同之处即可急待解决的问题写明当前项目组中面临的最优先的问题，可以重复提出退出标准在每轮测试结束之后应尽快将符合标准的测试报告发给全项目组责任人测试组长1.3实施测试阶段1.3.2实施测试 1.3.2.1 提交阶段性报告在约定的测试周期完成之后，测试组长需要总结此次测试的结果，编写

13、阶段性测试报告。过程要点详细描述输入条件在每轮测试中，按照现有的测试用例没有新的缺陷被发现，测试报告中全部的活动缺陷都被解决。工作内容测试组将按照测试计划中对于回归测试的策略对产品进行回归测试，回归测试的用例属于测试用例的一部分或者是全部测试用例，但不能超出原先预定的测试用例的范围。记录用例实施结果，提交回归测试记录。退出标准回归测试所运行的用例全部通过缺陷经过验证所有缺陷都被指明处理方式责任人测试实施工程师 1.3实施测试阶段1.3.3回归测试在每轮测试结束之后，由测试组重新拷贝修改后的最新版本，进行回归测试。过程要点详细描述输入条件回归测试结束，所有缺陷都被关闭。工作内容1.进行对测试组所

14、测试项目或产品的测试审查工作.基本原则:不依据所设计测试用例,进行自由测试.测试时间保持在3个正常工作日以内.如发现严重缺陷,则一轮测试结束后,更新版本,执行回归测试.2.提交当日测试纪录.3.编写同行审查总结报告(报告以简单为好).退出标准同行审查没有新的缺陷或没有严重缺陷产生.责任人同行测试组1.3实施测试阶段1.3.4同行审查过程要点详细描述输入条件测试组完成了所有的测试实施工作,同行审查结束.工作内容测试组长根据测试的结果，按照测试总结报告的文档模板编写测试报告（参考测试总结报告模板），测试报告必须包含以下重要内容：测试资源概述多少人、多长时间。测试结果摘要分别描述各个测试需求的测试结

15、果，产品实现了哪些功能点，哪些还没有实现缺陷分析按照缺陷的属性分类进行分析测试需求覆盖率原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明测试评估从总体对项目质量进行评估测试组建议从测试组的角度为项目组提出工作建议退出标准测试组长完成了符合标准的测试报告，发送给全项目组。责任人测试组长1.4总结阶段1.4.1测试总结报告在回归测试结束之后，测试组长将要编写测试总结报告，对测试进行总结，并且提交给全体项目组，为产品的后续工作提供重要的信息支持。过程要点详细描述输入条件测试组完成了所有的测试实施工作，测试组长完成符合标准的测试总结文档工作内容

16、由测启会上约定的验收组成员，对本次测试收进行验收，验收内容包括：测试效果验收测试是否达到预期目的测试文档验收测试过程文档是否齐全，可信，符合标准测试评估从总体对测试的质量进行评估测试建议对本次测试工作指出不足，需要在以后工作中改进的地方宣布测试结束测试验收组成员签字宣布本次测试结束退出标准测试验收通过，测试验收会议记录整理完毕参与人员验收组人员，测试经理，测试组长，产品（项目）经理1.4总结阶段1.4.2测试验收测试验收工作是在以上工作全部结束后，对测试的过程，效果进行验收，宣布测试结束。过程要点详细描述输入条件测试验收通过工作内容归类、存档测试过程涉及到的文档，主要包括以下文档（必须）测试任

17、务书测试计划书测试用例书阶段性测试报告测试总结报告测试验收会议记录退出标准全部文档归类完毕，版本号封存责任人测试组长1.4总结阶段1.4.3测试归档测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档。过程要点详细描述输入条件项目验收工作完成。工作内容由质控部经理，测试组长召开项目测试工作总结会议，会议内容主要为：测试组长对项目期间的整个测试组的工作情况进行总结，指出测试工作中存在的问题，同时也对工作中表现好的地方给与肯定。（具体包括整个测试情况、流程实施、人员安排、测试方法等）参与本次项目测试工作的所有成员个人体会和建议。讨论测试工作中出现的问题，寻

18、求更好的解决办法。宣布解散测试小组。退出标准所提问题寻求到较好解决方式，测试小组解散参与人员测试部所有成员1.4总结阶段1.4.4测试工作总结测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归类，存档。产品基本情况测试需求说明测试策略和记录测试资源配置计划表问题跟踪报告测试计划的评审和结果测试计划测试策略是制定测试计划的重要参考依据目的：如何以最少的人力、物力和时间等资源投入来达到最佳测试效果的综合方法。影响因素： 测试完成的标准资源状况针对需求定义测试类型、方法及工具等测试策略代表性、典型性正确和错误的或者异常的输入多考虑用户实际使用场景避免含糊的测试用例

19、（三种状态）尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例测试用例设计考虑因素及基本原则标识符 identification测试项 test item测试环境要求 test environment输入标准 input criteria输出标准 output criteria测试用例之间的关联测试用例书写标准例如，执行一轮测试中，需要跟踪总共执行了多少测试用例，每个人员平均每天使用多少测试用例，测试用例中通过、未通过以及未使用的占多少，未使用的原因是多少测试用例覆盖率的跟踪测试跟踪表跟踪测试用例先前的测试用例设计不全面或不准确部分严重的软件错误未在测试用例中覆盖新的版本有新

20、功能的需求或改动编写的测试用例不规范或者语句错误旧的测试用例不再适用维护测试用例单元测试程序系统中的最小单元模块UT的测试用例针对的是被测单元的具体功能。集成测试：IT的测试用例关注的是模块间的接口，接口间的数据传递关系，单元组合后是否实现预计的功能。系统测试：验证系统各部件是否都能正常工作并完成所赋予的任务。压力测试、容量测试、性能测试、安全测试、容错测试验收测试验证系统是否达到了用户需求规格说明书（项目和产品验收准则）中的要求，希望尽可能地发现软件中存留的缺陷，保证系统或软件产品最终被用户接受。测试阶段分类一个简单的缺陷报告缺陷报告的描述缺陷的严重性和优先级缺陷的类型和来源缺陷分布完整的缺

21、陷信息列表如何有效的报告缺陷有效的缺陷带来的益处有效报告缺陷软件缺陷的跟踪和处理软件缺陷的生命周期缺陷的跟踪处理缺陷状态缺陷跟踪系统测试管理之缺陷管理一个简单的缺陷报告严重性 ：武二线对软件产品使用的影响程度优先级： 缺陷必须被修复的紧急程度缺陷越严重，越要优先得到修正，缺陷严重等级和缺陷优先级相关性很强有例外？缺陷的严重性和优先级有，如有些缺陷比较严重由于级数的 限制或第3方产品的限制，暂时没办法修正，其优先级就会低缺陷的严重性和优先级 具体说明弄清楚缺陷的来源，有助于分清责任、权力，有利于缺陷的修正缺陷类型可以分为业务逻辑、数据处理、接口、UI、性能、安全性、兼容性、配置、文档等缺陷来源，

22、如需求说明书、涉及规格说明书、代码、用户手册缺陷关联的模块名、缺陷来自于产品的特定的模块的名称缺陷发生的阶段，例如需求、系统架构设计、详细设计、编码等缺陷的类型和来源一张图能胜过千言万语Log file工具捕捉的其他数据文件缺陷分布 完整的缺陷信息列表容易再现所报告的问题，加快缺陷的修正提高工作效率提高测试人员的信任度，有利于开发团队和测试团队之间的沟通和合作客观、准确的产品质量评估预防缺陷有效的缺陷描述所带来的益处单一准确 每个报告只针对一个软件缺陷可以再现 不要忽视或省略任何一项操作步骤，特别是关键性的操作一定要描述清楚，确保开发人员照所述的步骤可以再现缺陷完整统一 提供完整的缺陷描述信息

23、短小精炼 如使用业务关键词特定条件 必须注明缺陷发生的特定条件不做评价 客观描述有效报告缺陷软件缺陷生命周期软件缺陷的生命周期密切跟踪缺陷状态的变化，及时处理缺陷，使项目按预定的计划进行动态报表，及时更新数据自动邮件机制缺陷的跟踪处理缺陷状态不仅可以统一数据格式、完成数据校验，而且确保每一个缺陷不会被忽视，使开发人员的注意力保持在那些必须尽快修复的高优先级的缺陷上可以随时简历符合各种需求的查询条件，而且有利于建立各种动态的数据报表，用于项目状态报告和缺陷数据统计分析可以随时得到最新的缺陷状况大家活得一致又准确的信息，掌握相同的实际情况，消除沟通上的障碍可以将缺陷和测试用例、需求等关联起来，完成

24、更深度的分析，有利于产品的质量改进等。缺陷数据库所带来的益处软件配置管理原因：开发过程中，软件变更是不可避免,如果不能有效控制变更，将会造成软件开发的混乱 现代软件开发复杂度高、众多的开发人员、文件及相关资源多种多样、 多个发布版本、多种平台、软件在不同地点开发定义：是一种标识、组织和控制修改的技术，它作用于整个软件生命周期。目的：使错误达到最小并最有效地提高生产率软件配置管理包含为两部分：配置管理变更控制管理(参见变更管理)配置管理活动中的重要概念Version 版本配置项基线配置库版本号(Version number)项目版本号主版本号:整数次版本号:整数DEMO_V1.0_立项评审报告_

25、已完成版本号版本号(Version number)项目版本号项目版本号配置项版本号主版本号:整数次版本号:整数DEMO_V1.0_项目开发计划_V1.0_已完成主版本号:整数次版本号:整数配置项配置项(Configuration Item, CI ) 凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢

26、失。配置项及其历史记录反映了软件的演化过程。配置项状态(Configuration Item state, CIS)1.已完成 2.待评审 3.待测试 4.通过测试 5.通过评审DEMO_V1.0_项目开发计划V1.0_已完成配置项状态配置项标识配置项标识以项目名称+_+项目版本号+_+配置项名称+_+配置项版本号+配置项状态。例如： DEMO_V1.0_项目开发计划_V1.0_已完成基线基线(Baseline ) 基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milesto

27、ne），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。 基线名称(Baseline-name)基线名称以“项目名称+_+基线英文+_+标识生成日期“标识，例如： DEMO _REQBaseline_20060606 配置管理活动的流程进入准则及退出准则进入准则：项目立项退出准则：项目验收通过或项目终止、暂停流程中的角色配置管理员 配置管理员负责为产品开发团队提供全面的配置管理基础设施和环境，负责制定配置管理计划，负责对文档类的配置项建立基线。集成员（现阶段项

28、目经理负责） 集成员负责制定集成计划，建立代码类基线。任意角色 提交配置项。CCB 审批基线。计划配置管理角色：配置管理员 何时写配置计划 配置计划与项目开发计划同时产出或者在项目开发计划出来后2个工作日完成如何确定配置项 配置项与项目开发计划中的产出物相对应如何确定基线 基线一般与项目开发计划中的里程碑相对应。创建配置管理环境角色：配置管理员依据配置管理计划，建立配置管理库。根据项目组成员的情况，提供配置管理的理论及工具操作培训。通过创建并维护数据储存库建立一个环境，在此环境中可以对整个产品进行开发、构建，而且具有可重用性或可维护性。实现此目的有一个条件，即确保各私有和公有工作区中的开发人员

29、和集成员只要有需要就能使用关键工件，而且这些工件充分建立了基线，并被存储以备将来重复使用。设置 CM 环境时涉及到创建产品目录结构、储存库、工作区（开发人员和集成）以及分配计算机资源（服务器和磁盘空间）。配置项标识角色：配置管理员依据配置计划对文档类的配置项及程序(coding、模型)类的配置项进行的标识。参见软件开发文档命名约定建立基线角色：配置管理员、集成员、CCB集成员根据配置管理计划进行集成。当达到某一预定的基线特征时，集成员应向配置管理员报告。（标识基线）。 配置管理员对集成员报告的基线配置项进行审核，经确认无误后，配置管理员通知CCB评审已建立的基线。（审批基线） 配置管理员将通过

30、评审的基线向相关人员发布。（发布基线） 确保当子系统达到指定的成熟度后为其建立基线，然后就可进行发布或在随后的项目迭代和/或其他项目中重复使用。 在配置管理计划中对发布频率和形式予以说明。集成员需确保从开发人员工作区交付的工件已经过充分测试，以便可以将其并入可测试的工作版本中。集成员需熟悉项目 CM 策略以及具体测试操作。报告配置状态角色：配置管理员根据配置管理计划，收集配置活动数据，编写配置状态报告。 通过缺陷追踪和报告活动来辅助产品复审。 确保为追踪进展和趋势而“积累”数据并报告数据。执行配置审计角色：配置管理员配置审计在每个阶段结束后（通常是一个基线结束）由配置管理员进行一次配置审计工作

31、。配置审计主要对配置库中配置项的审计，审计产品目录结构与实际配置项是否一致，是否按照配置管理计划纳入了配置项，有无多余的或漏掉的配置项。 根据审计结果，编写配置审计报告,并将报告发布项目经理及相关人员。 对审计中发现的问题，应与项目经理及相关人员协商解决办法。并对不能解决的问题进行上报。 确定产品满足需求。 确定工件存储在受控制的库中。 确保工件和基线可用。输出工件输出名称输出描述参考配置管理计划CM 计划说明要在项目生命周期过程中执行的所有配置和变更控制管理活动。说明了活动时间表、指定的职责和需要的资源（包括人员、工具和计算机设备）。 配置管理计划模板配置状态报告主要报告变更请求情况，当前的

32、软件工作版本以及版本说明。配置状态报告模板配置审计报告对配置审计进行描述。配置审计报告模板3、变更控制管理提交变更申请评估实施拒绝变更管理流程4.讲解配置管理活动规范及模板配置计划模板及范例VSS系统的基线、配置项、配置库设置情况1.2 软件测试管理软件测试管理实践软件测试管理概述软件测试组织管理软件测试人员管理软件测试进度管理软件测试沟通管理软件测试环境管理缺陷管理和分析软件测试风险管理软件测试完成标准软件测试管理软件测试管理概述软件测试管理要素软件测试管理的系统方法软件测试管理目标软件测试管理内容软件测试常见风险测试管理概述软件测试管理要素测试人员及组织测试过程技术过程、管理过程、支持过程

33、测试工作产品测试计划、测试说明书、测试脚本测试案例、测试数据、测试报告、缺陷报告测试计划测试管理概述软件测试管理的系统方法以系统观点看待软件测试管理，它是软件项目管理这个大系统中的一个子系统；关注子系统中人员、过程、产品三要素的互动与变化；关注子系统内部各过程的相互关联、相互作用；关注测试管理子系统与开发管理子系统的相互关联、相互作用；达到系统目标整体作用大于部分作用之和。软件测试管理的内容（一）测试计划的管理测试估计确定切实可行的测试目标制订合理的测试计划控制测试计划的执行测试工作产品的管理检查和评审测试工作产品测量和分析测试对象开发的软件产品，收集质量分析和产品放行决策所需要的数据测试配置

34、管理软件测试管理的内容（二）测试过程的管理定义和定制所需要的测试过程满足测试过程所需要的资源和条件实施确定的测试过程测量和分析测试过程的有效性和效率进行基于度量的测试过程的持续改进软件测试管理的内容（三）测试人员及组织的管理选择合适的测试人员使测试人员能够按测试计划完成测试任务与相关方进行沟通，协同工作建立有效的软件测试团队软件测试管理下面我们学习软件测试组织管理：以开发为主的组织模型以项目为主的组织模型测试独立的组织模型软件测试组织模型以开发为主的组织模型软件测试组织模型以项目为主的组织模型软件测试组织模型测试独立的组织模型（一）软件测试组织模型测试独立的组织模型（二）软件测试组织模型测试独

35、立的组织模型（三）软件测试组织测试组规模（建议）产品类型开发组规模比例测试组规模商业软件产品（大市场）203:213商业软件产品（小市场）203:17单机应用206:13政府信息系统205:14企业信息系统204:15软件测试组织（例子）微软人员结构总体情况：项目经理5%，开发人员31%，测试人员64%1 : 6.2 : 12.8Exchange 2000 项目项目经理25 人开发人员140 人测试人员350 人2.5 倍软件测试管理下面我们学习软件测试人员管理：人员的选择人员的激励职业发展计划人员的培训测试能力的度量方法测试能力与人员能力、过程能力的关系C = a*X + b*YC 表示测试

36、能力X 表示人员能力Y 表示过程能力a, b 是加权系数测试能力随着人员能力和过程能力增强而提升软件测试人员的选择考察的方面：计算机技能测试能力测试经验产品经验开发经验职业素质软件测试人员的选择合适的人员特征不合适的人员特征愿以测试作为自己的职业轻视测试工作，愿以开发工作为职业职业悲观主义者（产品负面）容易妥协，害怕争论愿意承担繁重的测试工作不愿做艰苦的测试工作善于观察，能识别细微的差别粗心大意，忽视一些差别逻辑性强，思维缜密，表达清晰思维粗糙、不周全，不能清楚表达自我管理能力，不偏离工作主线不能把握工作重点，陷于枝微末节掌握必要的技术背景及技能技术背景弱测试工程师要求（质量保证协会）一般能力

37、表达、交流、协调、管理、质量意识、过程方法、软件工程等测试技能及方法测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等测试工程师要求（质量保证协会）测试规划能力风险分析及防范、软件放行/接收准则制订、测试目标及计划、测试计划和设计的评审方法等测试执行能力测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具测试分析、报告和改进能力测试度量、统计技术、测试报告、过程监测及持续改进测试人员的激励测试工作的快乐哲学选择自己的态度把工作当作游戏让别人快乐全身心投入工作需要的层次（Maslow 模型）测试人员的激励测试工作的7 条效率原则主动思考，积极行动一开始就牢记目标，不迷失

38、方向重要的事情放在首位（但常常把紧急的事情.）先理解人，后被人理解寻求双赢互相合作，追求1+12终生学习，自我更新，不断进步测试人员职业发展初级测试工程师具备必要的计算机知识和技能掌握测试技能及方法，具有测试实施/执行能力中级测试工程师初级测试工程师一年以上经验具有测试设计能力，能够指导初级测试工程师工作高级测试工程师中级测试工程师一年以上经验具有测试规划及管理能力、测试分析及报告能力、测试过程设计及改进能力可以指导中级测试工程师工作软件测试人员的培训软件测试人员的培训测试基础知识和技能培训测试设计培训测试工具培训测试对象软件产品的培训测试过程培训测试管理培训软件测试管理下面我们学习软件测试进

39、度管理：计划监控度量制定测试计划制定详细、可行的测试计划测试计划内容测试目标里程碑及进度计划测试组织及责任分配测试技术方法测试管理方法资源配置要求制定模板（测试计划样例）测试管理目标质量目标示例：单元测试目标在单元测试后发现的严重缺陷数少于30 个分支覆盖率达到100%基本路径覆盖率达到100%系统测试目标验收测试中发现的严重缺陷数小于9 个软件需求项覆盖率达到100%测试计划执行控制按照确定的报告周期，定期收集实际的进度和成本数据，提交状态报告/ 周期报告将发生的变更（范围、进度、预算）列入测试计划与计划进行比较，分析存在的偏差和原因确定需要采取的纠正措施，纳入测试计划更新测试计划（范围、进

40、度、预算）通过度量调整计划收集度量信息测试所发现的错误数每人所发现的错误的平均数千行代码缺陷率（每功能点缺陷率）缺陷修复率缺陷分布（级别、类型、模块、来源等）测试时间占比。根据度量数据信息判断测试效果，调整测试计划和策略。软件测试管理下面我们学习软件测试沟通管理：什么是沟通沟通模型测试沟通建立沟通机制沟通是和他人分享：讯息想法感觉的过程什么是沟通？沟通目标：及时而适当的创建、收集、发送、存储和处理项目的信息。沟通模型常见沟通模型链式环式全通道式轮式测试管理沟通项目经理测试经理测试人员开发人员建立沟通机制明确开发组和测试组的联系人；建立沟通渠道和方式；联系方式（QQ、电话、Email。）日志发送

41、和返回方式定义不可传递问题的解决机制；明确开发人员和测试人员的对应；确定重要问题的解决途径。建立沟通机制的方法沟通机制写入测试计划；定时开沟通会议；测试人员多参加项目会议，增进了解；一对一的定点沟通。软件测试管理下面我们学习软件测试环境管理：测试环境搭建测试环境更新更新依据测试环境搭建一般由开发组帮助搭建测试环境；测试环境一般包括：数据库服务器（包括基础数据）应用服务器（包括配置）中间件可运行程序其它各种服务等测试组应该有专人负责学会环境的搭建和维护。测试环境搭建测试环境应该独立于开发环境；数据库独立保护测试数据避免混淆带来发布的困难（数据库脚本维护）应用程序独立避免发现一些正在调试的错误避免

42、重复工作发布方便测试环境的更新更新原因有新版本发布时需要更新修复完bug后需要更新更新的频度不能过高，也不能过低根据测试阶段不同调整，前低后高根据项目特点和测试力度决定负责更新人员开发人员，测试人员，集成人员自动更新环境更新来源配置管理库源代码库发布版本库产品库建立适应的管理机制防止版本混乱防止发现“已修改“的错误防止发现不可重现的错误风险概念风险定义风险：遭受损失（loss）的可能性。风险管理：一种问题分析的手段，它采用风险概率去估计某情况下的风险，达到对所涉及风险更为精确的了解。风险管理包括风险识别、分析、优先级排序和控制。其它定义类型令人不快的事情发生的概率及其后果的严重性对项目产生负面

43、影响的不确定事件的累计效果暴露于糟糕后果之下的可能性危机管理救火型，当问题严重时才会应对事后补救当风险发生后能够快速做出反应风险缓解通过预先计划的方式描述当风险发生时的解决方法，但并未试图排除风险风险预防把实施风险计划作为项目的一部分，识别风险并防患于未然风险去除确认与排除可能造成风险的因素风险管理层次测试常见问题/风险（一）在软件测试方面培训不足，人员能力不足；开发人员与测试人员的对立情绪；测试人员“左右不是人”：因测试充分而找出太多缺陷，或因测试不足而遗漏重大缺陷；测试人员不愿意充当带来坏消息和说“不”的人；过分依赖软件测试；测试常见问题/风险（二）缺乏管理层对测试的理解和支持；客户/用户

44、参与不够；测试跟不上软件的快速变化；缺乏软件测试工具；用于软件测试的时间不够；缺乏完整的需求文档、设计文档；测试人员流失；。测试风险应对策略人员风险提高对测试的认识，加强培训；技术风险加强技术培训，选派懂技术人员做测试；进度风险加班，加人，选重点测试；文档不全多和开发人员沟通，帮助补文档；工具风险多熟悉，多实践。软件测试管理下面我们学习软件测试完成的准则软件测试完成准则几种观点永远也不可能完成软件测试，这个重担将从开发方转移到客户/用户的身上，用户的每一次使用就是一次测试“没有时间了，或没钱了”当用于软件测试的时间或资金不够用时，就完成了软件测试使用概率统计和软件可靠性理论建立软件故障模型，依

45、据模型确定什么时候完成测试达到公司要求了感觉没有问题了软件测试完成准则软件缺陷曲线累计报告的缺陷数、累计终结的缺陷数、Open 态、Verify 态缺陷数软件缺陷曲线呈现收敛状态公司自己制定的标准缺陷修复率达到要求千行代码出错率达到要求。软件测试完成准则系统测试的完成准则（一）所有系统测试案例已经运行所有的软件缺陷已经解决和终结对软件缺陷的所有修改都已进行了回归测试修改软件缺陷后，所有相关的软件文档的版本均已经更新（在配置管理之下）系统测试报告已经通过评审并获得批准软件测试完成准则系统测试的完成准则（二）一级错误修复率（100%）二级错误修复率（100%）三级错误修复率（100%）四级错误修复

46、率（90%）五级错误修复率（80%）软件测试完成准则单元测试的完成准则（一）所有单元测试案例已经运行所有的软件缺陷已经解决和终结对软件缺陷的所有修改都已进行了回归测试修改软件缺陷后，所有相关的软件文档、源代码的版本均已经更新（在配置管理之下）单元测试报告已经通过评审并获得批准软件测试完成准则单元测试的完成准则（二）代码覆盖率达到目标语句覆盖率（100%）分支覆盖率（100%）条件组合覆盖率（50%）基本路径覆盖率（100%）错误处理路径覆盖率（100%）对测试的误解如果发布出去的软件有质量问题，那是软件测试人员的错。软件测试技术要求不高，至少比编程容易多了。软件测试随便找一个能力差的人就能做。

47、 测试团队的建设讨论如何去组建测试团队？ 测试团队的建设人员高级测试工程师测试工程师安全测试专业家性能测试专业家系统测试工程师等等 测试团队的建设组织的类型-基于技能的组织 测试团队的建设组织的类型-基于项目的组织 测试团队的建设组织的建设-基于开发的一部分 测试团队的建设组织的建设-与开发平行 测试团队的建设组织的建设-独立测试 测试团队的建设如何建设高效的测试团队？俗话说“工欲善其事，必先利其器”，要做好测试工作，首先需要建立并维护一个高效的测试团队。 测试团队的建设如何建设高效的测试团队？第一步：招募测试人员 在国内的软件企业中有一种普遍做法，那就是把那些刚涉足软件行业的技术新手或业绩不

48、突出的开发人员安排去做测试工作。事实上，对一个系统进行有效测试所需要的技能绝对不比进行软件开发所需要的技能少，测试从业者甚至可能面对许多开发人员都不会遇到的技术难题。 测试团队的建设测试团队需要招募什么样的成员呢？ 首先，测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神。其中，沟通能力是指测试者必须能够同测试涉及到的所有人进行沟通，具有与技术人员（开发者）和非技术人员（客户、管理人员）进行交流的能力。自信心是指测试者必须对测试工作的价值具有足够信心，不会因开发者指责测试结果没有意义甚至反唇相讥而影响工作情绪。 测试团队的建设外交能力是指测试人员在与其他人员交流的时候，要注意

49、自己的辞令和行为方式，不要刻意夸大错误的严重性，也不要碍于面子替开发人员掩饰重大程序错误。迁移能力是指测试人员应能将以前曾经遇到过的类似错误从记忆中挖掘出来，并迁移到当前测试活动中。怀疑精神是指测试人员对任何可能出错的地方都亲自测试一番，不听信开发人员毫无意义的保证，坚持以事实说话的工作作风。 测试团队的建设测试团队需要招募什么样的成员呢？ 其次，测试组成员应具备良好的专业技能或者技术学习能力。 测试管理人员需要对测试管理工作的内容及相关辅助工具的使用胸有成竹 。自动化测试人员需要对相关自动化测试工具炉火纯青; 测试脚本撰写人员需要对脚本语言的领悟了然于胸; 测试团队的建设测测试团队需要招募什

50、么样的成员呢？ 其次，测试组成员应具备良好的专业技能或者技术学习能力。 手工测试人员应对相关测试中最易发现问题的地方如数家珍; 而测试团队负责人则必须既熟悉被测软件系统的概念模型、设计模型，又要掌握开发过程中涉及到的相关开发工具。 测试经理还必须深刻掌握测试流程的裁剪、测试环境的搭建、测试计划的撰写、测试活动的组织与开展以及测试效果的评价等必备技能。 测试团队的建设当然，新招募的测试人员不可能像上面说的那么理想。关键是他们是否热爱测试这项工作，对相关的工作内容是否感兴趣以及他们的学习能力如何。 挑选团队成员的做法开始挑人之前，我要细致分析岗位要求留心候选人的能力/成就/失败/依赖性，尤其是对待

51、工作/同事/顾客的态度听听他们在过去团队中的领导的意见向每个申请人描述工作职责及要达到的业绩标准，看看他的反映。 测试团队的建设如何建设高效的测试团队？第二步：测试团队制度建设 良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。相反,则很有可能导致人心涣散，滋长负面风气。 测试团队的建设 汇报制度 团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。工作总结制度 成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。 测试团队的建设奖惩制度 对于贡献突出的成员予以奖励，对于业绩差的

52、提出批评，有效地保持测试团队的工作热情。测试件审核制度 对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。 会议制度 定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习平台。 测试团队的建设 目前，已有不少软件企业推行给测试人员区分级别的制度，奖优罚劣。这无疑是一个好的做法，但成员业绩的具体考评办法，目前尚无可供参考的标准文件，所以我个人认为应尽量做到公正客观，以免挫伤团队成员的工作积极性。 测试团队的建设如何建设高效的测试团队？第三步：测试团队内部的职责分工确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较

53、短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学，真正做到“用其所长，避其所短” 测试团队的建设这里列出一种可行的测试团队内部职责分工方案，如表所示。 测试团队的建设如何建设高效的测试团队？第四步：测试流程建设 测试流程，通俗地讲是指测试团队按照什么样的流程和顺序组织开展软件测试活动。通常来说，测试流程如图所示。 测试团队的建设计划测试阶段是根据对测试需求的分析制定测试大纲、测试计划，并对具体要采用的测试技术做大致剪裁; 设计测试阶段是对测试大纲、测试计划作进一步细化，从而形成更为细致全面的测试用例集、具体测试活动安排以及相应的测试进度; 测试团队的建设执行测试阶

54、段是执行相关测试用例（包括自由测试），具体落实各项测试活动; 分析测试阶段是对计划测试、设计测试、执行测试阶段的工作做出评价，评估测试的有效性。以上是测试流程的大致组成，不同测试团队采用的测试流程在细节上可能会有出入 。 测试团队的建设可以通过以下步骤来建立适合本单位的测试流程： 1. 测试团队负责人员根据对公司现有测试状况的了解，及个人的测试经验，起草测试流程及相关的模板; 2. 通过一到两个项目的实践，记录测试流程草稿中的问题及不足之处; 3. 根据实施经验，完善测试流程，得到测试流程初稿，并起草相关实施指南; 测试团队的建设可以通过以下步骤来建立适合本单位的测试流程：4. 选择一个到多个

55、项目，实践上述测试流程初稿及实施指南，记录实践过程中出现的问题; 5. 根据上述实践工作的反馈，组织修改测试流程初稿及实施指南，并把修改后的测试流程继续应用到项目实践中去，根据反馈进一步完善成熟; 6. 测试流程及其相关文件基本趋于稳定状态时，可以考虑发布测试流程（含测试流程、模板、表格、指南），并在以后的实践中不断改进和完善。 测试团队的建设如何建设高效的测试团队？第五步：团队成员能力的逐步提高有了明确、合理的职责分工后，需要针对这些分工对团队成员进行有意识的引导，稳步提升团队成员的技能。 测试团队的建设监督和促进测试团队成员能力提高，主要做好如下三个方面的工作: 一是，提倡资深测试人员在测

56、试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。 测试团队的建设二是，测试团队应充分利用好测试件知识库，对于纳入到测试团队知识库的测试件应充分消化和学习，在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见。三是，测试人员除了需要注重自身的测试技能提升，在条件许可的情况还应适度开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。 测试团队的管理讨论如何管理测试团队，如何才能成为优秀的管理者？ 测试团队的管理以住管理者具备的素质 测试团队的管理21世纪管理者必须具备的素质 测试团队的管理团队领导的原则优秀

57、的团队领导： 1.使团队的目的、目标和方式密切相关，并且有意义 2.培养团队成员的责任感和信心 3.促进团队中各种技能的组合，并提高技术水平 4.搞好与外部人员关系，其中包括为团队的发展清除障碍 5.为团队中的其他成员创造机会 6.做实际工作正确传达命令意图：不要经常变更命令不要下一些过于抽象的命令不要为了证明自己的权威而下命令如何使部下积极接受命令：态度和善，用词礼貌让部下明白这件工作的重要性给部下更大的自主权共同探讨状况，提出对策让部下提出疑问 团队领导的方法A、与下属沟通 测试团队的管理赞扬和批评部下的方法赞美的态度要真诚赞美的内容要具体注意赞美的场合适当运用间接赞美的技巧以真诚的赞美做

58、开头要尊重客观事实指责时不要伤害部下的自尊与自信友好地结束批评选择适当的场所赞扬批评 测试团队的管理 测试团队的管理经理最烦的事情是什么？ 测试团队的管理员工最烦的问题是什么？ 测试团队的管理如何管好测试团队？1、作为一个团队的管理者，最起码的是要自己懂自己产品或项目的业务。第一这样有助自己分配工作给团队中的成员，要不然自己都搞不清楚业务难度和业量就分配工作给team member是件很让人难以接受的事情。第二，有助于自己和其它team或department的合作和沟通，不至于其它team提出的问题，自己还不清楚就答应或否定要做。 测试团队的管理如何管好测试团队？2、作为一个管理者，要懂更多的

59、技术，至少是了解更多的测试技术，要了解其工作原理 。有助于自己帮助团队成员research或者说技术的应用到实际的测试工作中来。也可以提高自己在测试团队中的威性，自己懂得多能让更多的同学认可和信服。 测试团队的管理如何管好测试团队？3、平衡按特长分配工作任务给team member。 对于senior的测试员我们分配更多的任务是designtestcase的，junior的测试员可能更多的是分配执行测试。分配工作也是看看哪位测试员的特长，有些测试员对GUI比较敏感，有些测试员对Logic比较关注，有些测试员对整个系统的流程更清楚，这些都是作为测试管理者分配任务的一个基线，这样可以更好地带好一个

60、团队，提高软件测试的水平和质量。 测试团队的管理如何管好测试团队？4、做好测试风险的管理 包括测试软件本身的风险，如缺陷过多，项目延期等。人员请假或离职，以及测试组人员的变动，还有测试人员情绪波动都会影响到测试质量风险的。 测试团队的管理如何管好测试团队？5、合理评估测或衡量测试人员的绩效和水平。这一点也是很难做到的一点，做得不好，不仅无法让整个团队好好工作，内部矛盾多，造成员工离职都会有，是让一个团队最头痛的事情，那么我们如何合理评估测试人员的工作呢？ 测试团队的管理首先我觉得公开硬性绩效标准，让大家都明白一个标准，也是团队共同发展的目的，这样做到公正，不会有私心。 我觉得我们可以从几个方面