软件测试过程培训

软件测试－过程培训2013年4月25日作者：刘晓斌1.目的2.角色与职责3.过程总体描述4.入口准则5.主要活动6.出口准则目录通过规范公司测试流程，确保测试工作的规范性和有效性，以验证产品的质量满足用户的需求。1、目的2、角色与职责角色职责项目经理提供项目测试资源；与测试负责人一起批准测试计划与测试用例；进行缺陷的分配工作，督促开发人员对缺陷的修改；监督测试计划的执行测试负责人全面负责组织测试的计划、设计、实施、执行、评估过程；检查项目测试工作完成和遗漏情况；对提交的缺陷进行有效性验证；及时汇报测试进展情况和存在的问题；负责组织对测试计划、测试用例、测试报告进行编写、修订等工作，并参与以上工作内容的评审；单元测试中测试负责人可以是项目经理或项目经理指定的负责人；项目中测试负责人对项目经理负责测试人员执行测试、缺陷提交、跟踪验证、回归关闭；完成测试负责人分配的相关工作。单元测试的测试人员可以由开发人员担任QA测试过程质量保证，参与测试相关工作产品的审查，统计缺陷，并参与计划、设计及执行结果评审配置管理员参与测试过程中工作产品的配置工作，对测试文档及代码等相关配置项进行配置管理，按组织的配置管理过程执行3、过程总体描述测试过程的目的是规范测试工作，为软件测试工作提供指引。以发现错误、度量软件质量为目的，提高组织内部软件测试的管理水平，确保组织中开发产品的质量。软件测试确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。3.1、测试过程-流程图输入输出开发人员开始测试人员编写测试需求测试过程集成测试《测试计划》项目经理是否通过接受测试申请《项目计划》《需求规格说明书》设计测试用例审核计划《测试用例》《测试申请单》、测试版本结束《测试用例》《测试报告》搭建测试环境系统测试《测试用例》z《测试需求》编写测试计划审核测试需求是否通过QA单元测试3.2、测试流程描述软件测试开发、管理流程贯穿了项目的整个开发和测试生命周期。测试流程如下：测试人员参与需求分析和设计评审，编写测试需求，确定需求的可测性，并贯穿开发的整个过程；测试负责人根据项目计划编写测试计划；测试人员编写测试用例；项目相关人员对测试计划和测试用例进行评审；测试人员或开发人员对单元模块进行单元测试；测试人员或开发人员搭建测试环境，按集成计划、从SVN配置库中获得相应版本的源代码进行产品部署；测试人员根据集成测试用例对通过构造的工作产品执行集成测试，验证各通过单元测试的模块组合在一起的功能及其接口、数据传输的正确性，满足系统设计所规定的特性；重复步骤5－7，直至该版本所有功能都完成开发和经过集成测试；测试人员根据测试计划中定义的系统测试策略，完成其它约定内容的测试如性能测试、易用性测试、安全性测试、安装/反安装测试等；测试负责人组织撰写测试报告；通过测试的项目，提交产品库并发布。4、入口准则《软件需求规格说明书》评审通过；《项目计划》建立。6、主要活动测试需求测试策划测试用例搭建环境接受测试申请单元测试集成测试系统测试缺陷管理测试过程中沟通交流测试总结6.1、测试需求测试人员依据所能获取到的需求文档进行测试需求的分析活动，并形成项目的《测试需求》文档，包括功能需求、性能需求、界面需求、安装卸载需求、兼容性需求等，提交给项目经理或项目需求分析人员及相关人员进行评审确认。有需求变更时，也需及时更新测试需求文档。视项目具体情况，《测试需求》可用WORD或QC工具进行管理。测试需求为可裁剪活动，以上为没有软件需求规格说明书或不完整的情况下执行，若需求完整清晰，则可裁剪。6.2、测试策划测试人员依据《软件需求规格说明书》、《测试需求》、《项目计划》进行测试工作的策划活动，编写《测试计划》（单元、集成、系统阶段的计划可包括在内，也可在各阶段进行细化）。测试计划内容包括：明确测试对象；实施测试活动的测试环境、测试工具、测试人员安排；测试策略；测试进度计划；测试工作汇报方式。《测试计划》需要由项目经理审核，并纳入配置库受控管理。当项目计划或测试需求发生变更时，测试计划应考虑是否需要变更。6.3、测试用例在软件设计阶段，测试人员根据需求编写测试用例，并保存在用例管理工具中。测试用例需要包括以下要素：测试用例标识、测试用例名称、测试步骤、预期结果、对应的测试需求等。测试用例需要经过评审，由测试人员组织，评审方式可以采用组内评审和个人复查，参见《评审过程》6.4、搭建环境项目测试环境需要独立的、稳定的且能有效的模拟用户的真实环境。若不能提供独立的测试环境，需由项目经理提出，经过项目领导审批后生效。根据测试计划要求搭建测试的软件、硬件、网络等环境。各方面信息。6.5、接受测试申请开发版本更新负责人，定期或不定期的提交待测试版本和《测试申请》给测试负责人，测试人员依据测试申请单的内容，对本次版本进行冒烟测试，通过后则进入正式的测试。测试申请提交流程：开发版本更新负责人提交测试申请单给测试负责人、项目经理；测试负责人在本次测试结束后，把测试结果填写在测试申请单的结果栏，然后回传该测试申请结果给相关人员告之本次测试的情况。6.5、接受测试申请（续）测试申请中需要描述新增功能和已有功能的变更情况说明（包括数据表示方式和操作步骤）等软件状态变化情况。待测试版本存放管理：项目组可以在项目初期定义一个固定位置统一放置待测试版本。当有多个测试人员时，需要指定一个测试负责人来接受测试申请、分配测试任务、反馈测试情况。使用单元测试用例及相应编码准则等，验证程序代码单元及其函数、接口已按照预设的方式（系统设计）调用执行，并产生合乎期待的结果。6.6、单元测试完成被测代码已完成已提交测试申请单和待测试版本；6.6.1、单元测试-开始标准所有提交代码测试完毕；成功地执行了测试计划中规定的所有单元测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一。6.6.2、单元测试-结束标准测试人员使用指定测试及管理工具，依据编码规范和单元测试用例，从配置库中提取标识代码模块实施测试活动；静态测试：根据开发计划和测试计划安排，由项目经理指定人员依编码规范对单元模块代码进行同行评审，及时发现、记录并修订代码中存在的语法规范或逻辑错误；动态测试：根据开发计划和测试计划安排，测试人员执行单元测试用例，记录、跟踪发现的缺陷。6.6.3、单元测试-测试过程执行批准的集成测试用例，验证各通过单元测试的功能模块的独立功能及其接口、数据传输的正确性，满足系统设计所规定的特性。6.7、集成测试执行第1个模块开发完成；已提交测试申请单和待测试版本；该版本通过冒烟测试。6.7.1、集成测试-开始标准所有模块集成完毕，并都得到测试；成功地执行了测试计划中规定的所有集成测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一。6.7.2、集成测试-结束标准测试人员根据测试内容在测试用例库中选定集成测试的测试用例，执行集成测试。在集成测试阶段，首先要对单个的模块进行功能测试，然后再把模块组装起来，进行模块与模块之间的集成测试，最后再对整个系统进行完整的功能测试。在集成测试阶段，都有需要修复和验证的bug。当有bug修改好后，需要进行回归测试。开发人员把修订好的程序给版本更新负责人统一更新，并在缺陷管理工具中修改bug的状态和其他字段，测试人员在每次版本更新后，都需要到缺陷管理工具中浏览bug，对bug状态为“已解决”，并且是分配给自己的bug进行回归验证。6.7.3、集成测试-测试过程6.8、系统测试执行系统测试用例，验证已通过各阶段测试的功能模块已具有满足需求规格说明所规定的功能、性能要求等，确保系统在要求的硬件和软件平台上工作正常。6.8.1、系统测试-开始标准系统各功能模块均已实现集成测试通过开发人员提交测试申请单和待测试版本，并且该版本通过冒烟测试。6.8.2、系统测试-结束标准成功地执行了测试计划中规定的所有系统测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一；功能性测试用例通过率达到100％，非功能性测试用例通过率达到95%；测试结果通过了专门小组的评审。6.8.3、系统测试-测试过程测试人员根据测试内容在测试用例库中选定系统测试的测试用例执行系统测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行系统的各种组装测试和确认测试，主要考虑的是各种环境以及非功能问题，如安全性、可靠性、性能等，相比集成测试是在更大的范围内进行的，着重与系统特性的测试。在系统测试阶段出现bug时，处理方式与同集成测试阶段回归测试相同，但系统测试阶段测试更新不能太频繁，保证测试的功能覆盖尽量全面，且发现的问题尽量集中更新。以免程序更新的时间加长测试时间，降低效率。如果是产品发布，最终发布的产品安装包必须通过一轮完整的回归测试才能发布。如果是客户化项目，则对本项目的业务主线进行回归测试。6.8.3、系统测试-测试过程（续）在系统测试阶段结束或系统测试达到系统测试结束准则后，由测试人员编写系统测试的《测试报告》。《测试报告》需要由项目经理等人审核，纳入配置库受控管理。测试发现的问题记录在缺陷管理工具（或者bug跟踪表）中。6.9、缺陷管理对所发现的缺陷的记录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理。6.9.1、缺陷管理-流程图输入输出开发人员开始测试人员提交bug缺陷管理验证bug结束关闭bug缺陷管理中的缺陷记录判断bug是否被解决项目经理判断是否是bug判断是否是bug是否否是否建议拒绝bug是判断是否延期修改bug否延期bug是6.9.2.1、缺陷管理-主要活动-缺陷提交对测试人员发现bug后，在缺陷管理工具中提交bug（对于在客户现场的项目，如果不方便用缺陷管理工具，可以使用bug跟踪表做记录），指派给项目内指定人员。缺陷的状态为“新建”,由指定人员进行评审、分配。提交的缺陷必须填写缺陷标题、描述、严重等级、优先级、缺陷的状态、缺陷类型、分配给、检测者、检测日期等信息。6.9.2.2、缺陷管理-主要活动-缺陷处理Bug责任人对缺陷进行分析，确定缺陷的存在性，并对缺陷进行分配，分配缺陷后的状态可能为：打开&已修正&延期&建议拒绝&拒绝&重新打开。打开状态是指被分配的开发人员开始处理Bug时，将Bug状态设置为“Open”，表示开发人员正在处理这个“Bug”；已修正状态表示开发人员对Bug进行处理并解决后，将这个Bug的状态设置为“已修正”，并根据修正缺陷过程的分析修正缺陷的类型，缺陷的引入阶段这两项内容；6.9.2.2、缺陷管理-主要活动-缺陷处理（续）延期状态表示缺陷已经确定，但是不在当前版本解决，暂时延后，此类bug需要项目经理最后确认。在后续版本开发时，这些被延期缺陷需要被列出来，确定哪些会被解决；建议拒绝状态表示开发人员认为该缺陷不是缺陷，无须修改。需要加入注释后，让项目经理，做最后确认；6.9.2.2、缺陷管理-主要活动-缺陷处理（续）拒绝状态表示该缺陷经过项目经理确认不是缺陷，被拒绝修改,只有项目经理有权限修改为此状态；缺陷提交人进行确认后在注释栏填写确认信息。如果不接受拒绝，可以和项目经理继续讨论，或者上报项目负责领导裁定。上报方式可采用邮件形式发送问题清单。重新打开状态表示该缺陷经过再次测试发现bug仍然存在，测试人员将bug再次提交开发组，将bug的状态设置为“重新打开”。6.9.2.3、缺陷管理-主要活动-缺陷解决缺陷由指定的开发人员解决后，经过自己测试,填写缺陷修改完成时间和缺陷处理结果描述.。解决后的缺陷的状态为“已解决”。缺陷解决人必须修改缺陷的“状态”。严重的问题需要写明产生原因和涉及到的代码等信息。这些信息由解决缺陷的人员负责填写。6.9.2.4、缺陷管理-主要活动-缺陷验证与关闭测试人员筛选状态为已解决的缺陷，进行验证测试。验证通过后状态为“关闭”，否则为“重新打开”。缺陷的验证必须修改缺陷的“状态”和“关闭时间”。这些信息由测试人员负