软件测试过程专业培训

1、软件测试过程专业培训目的角色与职责过程总体描述入口准那么主要活动出口准那么目 录通过标准公司测试流程，确保测试工作的标准性和有效性，以验证产品的质量满足用户的需求。1、目的2、角色与职责角色职责项目经理提供项目测试资源；与测试负责人一起批准测试计划与测试用例；进行缺陷的分配工作，督促开发人员对缺陷的修改；监督测试计划的执行测试负责人全面负责组织测试的计划、设计、实施、执行、评估过程；检查项目测试工作完成和遗漏情况；对提交的缺陷进行有效性验证；及时汇报测试进展情况和存在的问题；负责组织对测试计划、测试用例、测试报告进行编写、修订等工作，并参与以上工作内容的评审；单元测试中测试负责人可以是项目经理

2、或项目经理指定的负责人；项目中测试负责人对项目经理负责测试人员执行测试、缺陷提交、跟踪验证、回归关闭；完成测试负责人分配的相关工作。单元测试的测试人员可以由开发人员担任测试过程质量保证，参与测试相关工作产品的审查，统计缺陷，并参与计划、设计及执行结果评审配置管理员参与测试过程中工作产品的配置工作，对测试文档及代码等相关配置项进行配置管理，按组织的配置管理过程执行3、过程总体描述测试过程的目的是标准测试工作，为软件测试工作提供指引。以发现错误、度量软件质量为目的，提高组织内部软件测试的管理水平，确保组织中开发产品的质量。软件测试确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交

3、给用户之前发现并改正。3.1、测试过程-流程图3.2、测试流程描述软件测试开发、管理流程贯穿了工程的整个开发和测试生命周期。测试流程如下：测试人员参与需求分析和设计评审，编写测试需求，确定需求的可测性，并贯穿开发的整个过程；测试负责人根据工程方案编写测试方案；测试人员编写测试用例；工程相关人员对测试方案和测试用例进行评审；测试人员或开发人员对单元模块进行单元测试；测试人员或开发人员搭建测试环境，按集成方案、从配置库中获得相应版本的源代码进行产品部署；测试人员根据集成测试用例对通过构造的工作产品执行集成测试，验证各通过单元测试的模块组合在一起的功能及其接口、数据传输的正确性，满足系统设计所规定的

4、特性；重复步骤57，直至该版本所有功能都完成开发和经过集成测试；测试人员根据测试方案中定义的系统测试策略，完成其它约定内容的测试如性能测试、易用性测试、平安性测试、安装/反安装测试等；测试负责人组织撰写测试报告；通过测试的工程，提交产品库并发布。4、入口准那么?软件需求规格说明书?评审通过；?工程方案?建立。6、主要活动测试需求测试筹划测试用例搭建环境接受测试申请单元测试集成测试系统测试缺陷管理测试过程中沟通交流测试总结6.1、测试需求测试人员依据所能获取到的需求文档进行测试需求的分析活动，并形成工程的?测试需求?文档，包括功能需求、性能需求、界面需求、安装卸载需求、兼容性需求等，提交给工程经

5、理或工程需求分析人员及相关人员进行评审确认。有需求变更时，也需及时更新测试需求文档。视工程具体情况，?测试需求?可用或工具进行管理。测试需求为可裁剪活动，以上为没有软件需求规格说明书或不完整的情况下执行，假设需求完整清晰，那么可裁剪。6.2、测试筹划测试人员依据?软件需求规格说明书?、?测试需求?、?工程方案?进行测试工作的筹划活动，编写?测试方案?单元、集成、系统阶段的方案可包括在内，也可在各阶段进行细化。测试方案内容包括：明确测试对象；实施测试活动的测试环境、测试工具、测试人员安排；测试策略；测试进度方案；测试工作汇报方式。?测试方案?需要由工程经理审核，并纳入配置库受控管理。当工程方案或

6、测试需求发生变更时，测试方案应考虑是否需要变更。6.3、测试用例在软件设计阶段，测试人员根据需求编写测试用例，并保存在用例管理工具中。测试用例需要包括以下要素：测试用例标识、测试用例名称、测试步骤、预期结果、对应的测试需求等。测试用例需要经过评审，由测试人员组织，评审方式可以采用组内评审和个人复查，参见?评审过程?6.4、搭建环境工程测试环境需要独立的、稳定的且能有效的模拟用户的真实环境。假设不能提供独立的测试环境，需由工程经理提出，经过工程领导审批后生效。根据测试方案要求搭建测试的软件、硬件、网络等环境。各方面信息。6.5、接受测试申请开发版本更新负责人，定期或不定期的提交待测试版本和?测试

7、申请?给测试负责人，测试人员依据测试申请单的内容，对本次版本进行冒烟测试，通过后那么进入正式的测试。测试申请提交流程：开发版本更新负责人提交测试申请单给测试负责人、工程经理；测试负责人在本次测试结束后，把测试结果填写在测试申请单的结果栏，然后回传该测试申请结果给相关人员告之本次测试的情况。6.5、接受测试申请续测试申请中需要描述新增功能和已有功能的变更情况说明包括数据表示方式和操作步骤等软件状态变化情况。待测试版本存放管理：工程组可以在工程初期定义一个固定位置统一放置待测试版本。当有多个测试人员时，需要指定一个测试负责人来接受测试申请、分配测试任务、反响测试情况。 使用单元测试用例及相应编码准

8、那么等，验证程序代码单元及其函数、接口已按照预设的方式系统设计调用执行，并产生符合期待的结果。6.6、单元测试完成被测代码已完成已提交测试申请单和待测试版本；6.6.1、单元测试-开始标准所有提交代码测试完毕；成功地执行了测试方案中规定的所有单元测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一。6.6.2、单元测试-结束标准测试人员使用指定测试及管理工具，依据编码标准和单元测试用例，从配置库中提取标识代码模块实施测试活动；静态测试：根据开发方案和测试方案安排，由工程经理指定人员依编码标准对单元模块代码进行同行评审，及时发现、记录并修订代码中存在的语法标准或逻辑错误；动

9、态测试：根据开发方案和测试方案安排，测试人员执行单元测试用例，记录、跟踪发现的缺陷。6.6.3、单元测试-测试过程执行批准的集成测试用例，验证各通过单元测试的功能模块的独立功能及其接口、数据传输的正确性，满足系统设计所规定的特性。6.7、集成测试执行第1个模块开发完成；已提交测试申请单和待测试版本；该版本通过冒烟测试。6.7.1、集成测试-开始标准所有模块集成完毕，并都得到测试；成功地执行了测试方案中规定的所有集成测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一。6.7.2、集成测试-结束标准测试人员根据测试内容在测试用例库中选定集成测试的测试用例，执行集成测试。在集

10、成测试阶段，首先要对单个的模块进行功能测试，然后再把模块组装起来，进行模块与模块之间的集成测试，最后再对整个系统进行完整的功能测试。在集成测试阶段，都有需要修复和验证的。当有修改好后，需要进行回归测试。开发人员把修订好的程序给版本更新负责人统一更新，并在缺陷管理工具中修改的状态和其他字段，测试人员在每次版本更新后，都需要到缺陷管理工具中浏览，对状态为“已解决，并且是分配给自己的进行回归验证。6.7.3、集成测试-测试过程6.8、系统测试执行系统测试用例，验证已通过各阶段测试的功能模块已具有满足需求规格说明所规定的功能、性能要求等，确保系统在要求的硬件和软件平台上工作正常。6.8.1、系统测试-

11、开始标准系统各功能模块均已实现集成测试通过开发人员提交测试申请单和待测试版本，并且该版本通过冒烟测试。6.8.2、系统测试-结束标准成功地执行了测试方案中规定的所有系统测试；处理了已发现的所有缺陷，缺陷状态只能为已关闭、延期、拒绝3种状态之一；功能性测试用例通过率到达100，非功能性测试用例通过率到达95%；测试结果通过了专门小组的评审。6.8.3、系统测试-测试过程测试人员根据测试内容在测试用例库中选定系统测试的测试用例执行系统测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行系统的各种组装测试和确认测试，主要考虑的是各种环境以及非功能问题，如平安性、可靠性、

12、性能等，相比集成测试是在更大的范围内进行的，着重与系统特性的测试。在系统测试阶段出现时，处理方式与同集成测试阶段回归测试相同，但系统测试阶段测试更新不能太频繁，保证测试的功能覆盖尽量全面，且发现的问题尽量集中更新。以免程序更新的时间加长测试时间，降低效率。如果是产品发布，最终发布的产品安装包必须通过一轮完整的回归测试才能发布。如果是客户化工程，那么对本工程的业务主线进行回归测试。6.8.3、系统测试-测试过程续在系统测试阶段结束或系统测试到达系统测试结束准那么后，由测试人员编写系统测试的?测试报告?。?测试报告?需要由工程经理等人审核，纳入配置库受控管理。测试发现的问题记录在缺陷管理工具或者跟

13、踪表中。6.9、缺陷管理对所发现的缺陷的记录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除等一系列活动状态的管理。6.9.1、缺陷管理-流程图6.9.2.1、缺陷管理-主要活动-缺陷提交对测试人员发现后，在缺陷管理工具中提交对于在客户现场的工程，如果不方便用缺陷管理工具，可以使用跟踪表做记录，指派给工程内指定人员。缺陷的状态为“新建,由指定人员进行评审、分配。提交的缺陷必须填写缺陷标题、描述、严重等级、优先级、缺陷的状态、缺陷类型、分配给、检测者、检测日期等信息。 6.9.2.2、缺陷管理-主要活动-缺陷处理责任人对缺陷进行分析，确定缺陷的存在性，并对缺陷进行分配，分配缺陷后的

14、状态可能为：翻开 & 已修正 & 延期 & 建议拒绝& 拒绝& 重新翻开。翻开 状态是指被分配的开发人员开始处理时，将状态设置为“，表示开发人员正在处理这个“；已修正 状态表示开发人员对进行处理并解决后，将这个的状态设置为“已修正，并根据修正缺陷过程的分析修正缺陷的类型，缺陷的引入阶段这两项内容；6.9.2.2、缺陷管理-主要活动-缺陷处理续延期 状态表示缺陷已经确定，但是不在当前版本解决，暂时延后，此类需要工程经理最后确认。在后续版本开发时，这些被延期缺陷需要被列出来，确定哪些会被解决；建议拒绝 状态表示开发人员认为该缺陷不是缺陷，无须修改。需要参加注释后，让工程经理，做最后确认；6.9.2

15、.2、缺陷管理-主要活动-缺陷处理续拒绝 状态表示该缺陷经过工程经理确认不是缺陷，被拒绝修改,只有工程经理有权限修改为此状态；缺陷提交人进行确认后在注释栏填写确认信息。如果不接受拒绝，可以和工程经理继续讨论，或者上报工程负责领导裁定。上报方式可采用邮件形式发送问题清单。重新翻开 状态表示该缺陷经过再次测试发现仍然存在，测试人员将再次提交开发组，将的状态设置为“重新翻开。6.9.2.3、缺陷管理-主要活动-缺陷解决缺陷由指定的开发人员解决后，经过自己测试,填写缺陷修改完成时间和缺陷处理结果描述.。解决后的缺陷的状态为“已解决。缺陷解决人必须修改缺陷的“状态。严重的问题需要写明产生原因和涉及到的代

16、码等信息。这些信息由解决缺陷的人员负责填写。 6.9.2.4、缺陷管理-主要活动-缺陷验证与关闭测试人员筛选状态为已解决的缺陷，进行验证测试。验证通过后状态为“关闭，否那么为“重新翻开。缺陷的验证必须修改缺陷的“状态和“关闭时间。这些信息由测试人员负责填写。 6.9.3、缺陷管理-缺陷说明缺陷类型缺陷等级缺陷发现阶段缺陷引入阶段 6.10、测试过程中的沟通交流测试需求的交流：测试需求来源于软件需求对工程的要求，测试人员在编辑测试需求和理解软件需求时，对于测试关注点软件功能，实体对象数据结构不清晰的情况需要和需求分析人员进行沟通，同时在软件需求评审中提出评审意见。软件提交测试时的交流：软件提交测试时，需要开发人员提交新增功能和变更功能包括数据格式变动和操作步骤细节等的说明，说明的方式可以包括详细设计、用户手册、功能操作清单、变更清单等。测试人员发现新版本软件和正式文档描述或者前版本软件中操作或者数据不一致情况，及时与软件开发人员确认是否进行了实现细节的调整。6.10、测试过程中的沟通交流