《软件测试流程规范.pdf》由会员分享，可在线阅读，更多相关《软件测试流程规范.pdf（10页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、 软件测试流程规范 文件编码（GHTU-UITID-GGBKT-POIU-WUUI-8968）软件测试流程规范 一、通读项目需求设计文档 1.测试的准备阶段；2.仔细阅读软件需求规格说明书；3.根据测试手册，做前期的测试准备；二、明确测试任务的范围 功能测试；界面测试；接口测试；容错测试；负载测试；安全测试；性能测试；稳定性测试；配置测试；安装测试；恢复测试；文档测试；可用性测试；三、学习理解被测试软件 由开发人员组织讲解所要执行测试的软件或者产品，测试人员必须认真理解拿到手中待测试的软件或者产品。四、制定测试计划“工欲善其事，必先利其器”。软件测试必须以一个好的测试计划作为基础。作为测试的起
2、始步骤和重要环节。测试计划应包括：产品基本情况调研、测试策略、测试大纲（功能模块的测试、详细测试、高级测试）、测试内容（界面测试、测试需求说明）、测试人力资源配置、测试计划的变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪报告、测试通过准则、测试计划的评审意见等。另外还包括测试计划的目的、测试对象信息、测试计划使用的范围及测试参考文档。1.项目简介；对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。2.测试背景；产品在那种情况下开始研发，执行测试，交待为何而测试产品的背景。3.测试手段环境；（手工和自动化工具）测试环境 测试辅助工具 4.测试类型（方法）；（黑盒
3、测试）功能测试；界面测试；接口测试；容错测试；负载测试；安全测试；性能测试；稳定性测试；配置测试；安装测试；恢复测试；文档测试；可用性测试；5.测试资源；人力资源系统资源 人员 角色 职责、任务 时间 6.测试策略测试需求测试任务测试点；针对测试需求定义测试类型、测试方法以及需求的测试工具等。对于每种测试，都应提供测试说明，并解释其实施的原因。制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不
4、实施该测试。该测试本项目不适用”。7.测试工作计划表；No 工作内容 开始时间 结 束 时间 责任人 提交的结果 备注 五、设计测试用例 测试用例的主要来源为：1）需求说明书及相关文档 2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的 UI（可以有针对性地补充一些用例）从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。测试用例模板（Excel）：项目名称 程序版本 功能模块名 用例编号 编制人 编制时间 论坛 功能特性 测试目的 参考信息 集成测试：也叫或联合测试。在单元测试的基础上，将所有模
5、块按照设计要求（如根据结构图组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。集成测试应该考虑以下问题：1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2、各个子功能组合起来，能否达到预期要求的父功能；3、一个模块的功能是否会对另一个模块的功能产生不利的影响；4、全局数据结构是否有问题；5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系
6、统或系统。对子系统，集成测试也叫部件测试。任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。九、提交缺陷报告 BUG 单模板简版主表 BUG 编号：被测系统名称：被测系统版本号：被测模块：测试阶段：BUG 类型：测试人员：BUG 严重性：测试日期：BUG 优先级：BUG 概要：BUG 详情 测试路径导航：操作描述：1.2.结果描述：修改建议：附件：（可选）备注：(以上内容由具体测试人员填写)BUG 状态:BUG 结论:BU
7、G 原因:处理人员:处理方法:处理日期:BUG 处理意见:(以上由 BUG 的修复人员填写，通常是具体的研发人员)Bug 单附表环境 CPU：内存：硬盘：数据库：IE/版本：服务器：平台：操 作 系 统/版本：Bug 状态说明：新建：测试人员报告 bug 的状态 已指派：测试人员分配 bug 的状态 已解决：修改人员修改 bug 的状态，在解决 bug 界面准确标注 bug 的完成度 已确认：修改人员对暂时不能、以后修改的 bug 进行确认的状态 反馈：测试人员对开发人员认为不修改、但测试人员需要修改的 bug的反馈给经理的状态 公认：经理查看反馈的 bug 后认为需要修改，则标示 bug 的
8、状态为公认，认为不做修改，直接关闭此 bug，注明原因 已关闭：测试人员对修正后的 bug 进行回归测试后，确认 bug 已修正即可关闭 bug 状态 注：BUG 级别说明 A（严重级）：操作系统或者网络瘫痪；B（中等级）：应用程序崩溃、非法退出或功能模块无法实现。C（一般级）：篡改设计；功能实现错误或功能不完善，容错失败、数据逻辑关系错。D（允许级）：界面布局；操作不方便；建议性修改。职责：测试人员：准确定位 bug，新建 bug，指派 bug 与开发人员 1.对修正后的 bug 进行验证，确认修正后将其关闭 2.通过验证，bug 仍然存在，重新指派给开发人员 3.对修改人员认为不需要修改，
9、而测试人员认为要修改的 bug，反馈与经理 4.对已关闭的 bug 以后又浮现，将其重新打开，指派与原开发人员 研发人员：查看指派给自己的 bug，准确选择 bug 的完成度，添加bug 注释，将其状态置为已解决 1.查看 bug，确认是 bug，进行修正，并注明原因 2.对不属于自己模块的 bug 指派其他人修改 3.对延迟解决的 bug 标注确认 4.需要讨论的 bug，将其状态置为公认 经理：查看测试人员提交的 bug，确定要修改的，添加注释，指派与修改人员 1.需要讨论的 bug，将其状态置为公认 2.对不做修改的 bug，将其关闭 管理员：对项目、人员进行管理维护，定期备份数据库 1
10、.对于重复报告的 bug，查看报告时间，将报告晚的删除 2.对由于配置、数据库未更新将其删除 十、测试退出准则 1.系统满足需求规格说明书的要求 2.按照测试计划完成了系统测试 3.测试用例执行覆盖率达到 100%4.测试需求覆盖率达到 100%5.Block，Crash，Major 级缺陷修复率达到 100%6.Minor，Trivial 级缺陷修复率达到 80%7.Text，Suggestion，Feature 级缺陷修复率达到 75%8.程序能够处理要求的负载 9.系统在要求的硬件和软件平台上工作正常。十一、编制测试报告 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析
11、，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告基于测试中的数据采集以及对最终的测试结果分析。包括：测试执行情况（测试组织、测试时间、测试版本）、覆盖分析（需求覆盖、测试覆盖）、缺陷的统计图表（测试管理工具自动生成各种图表）与分析（缺陷汇总、缺陷分析、残留缺陷与未解决问题）、测试结论及建议、测试环境与配置、测试工具、测试报告的评审意见等。另外还包括测试报告的目的、测试对象信息、测试报告使用的范围及测试参考文档。十二、测试评审 项目经理审批意见：签字 日期 出示一份测试评审报告 十三、编写用户手册 用户手册的编写，是直接指导用户进行使用软件产品的向导，因此用户手册的编写必须规范，简洁，易懂。使用户在很短的时间内理解和使用我们的产品。