软件测试规范

软件测试规范篇一：软件测试规范整理软件测试规范 目 录1 2 3 测试目的 .3 适用范围 .3 软件测试流程 . 3 软件测试流程图 .3 软件测试流程细则 .3 单元测试 .4 集成测试 .4 系统测试 .4 图形界面测试 .5 业务功能测试 .6 兼容性测试 .6 数据存储测试 .6 系统安全测试 .6 系统性能测试 .7 磁盘空间测试 .14 系统日志测试 .14 其他测试 . 14 4 缺陷类型定义 . 16 1 测试目的 ? 测试是为了发现程序中的错误而执行程序的过程。 ? 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。 ? 成功的测试是发现了至今为止尚未发现的错误的测试。 2 适用范围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试软件测试流程 3 软件测试流程 软件测试流程图 软件测试流程细则 需求阶段： 测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。 测试人员了解项目需求变更。 设计编码阶段： 测试人员制定测试用例 。 项目开发组对完成的功能模块进行单元测试 所有单元测试及相应的修改完成后，项目开发组组织进行集成测试 测试阶段：测试人员按测试计划、测试用例的要求对被测系统进行系统测试。 填写错误报告 对修改后的情况进行回归测试。单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 ? 单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错 误处理测试等； ? 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块 进行测试； ? 单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的 bug 已经得到修改。 集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。 系统测试由测试负责人组织策划（编写测试计划、测试用例）并实施。 系统测试一般进行如下几种情况的测试：图形界面、业务功能、数据存储、系统安全、系统性能、磁盘空间、软件兼容性、系统日志等。 图形界面测试1) 光标字体布局测试： ? 光标的初始位置是否正确 ? 字体是否统一 ? 字号是否符合规定 ? 标题颜色是否清晰美观 ? 按钮的名称是否规范 ? 界面布局是否合理，整体效果如何 2) 输入值测试：? 数据类型 ? 数据长度 ? 约束条件是否满足，是否完整 ? Enter键是否起作用 ? 键盘操作能否全部代替鼠标操作 ? 输入（光标）是否按照顺序前进 3) 按钮测试： ? 按钮开放和封闭是否严格、准确，不能使用的按钮必须封闭 ? 检查“退出” 、 “取消”等具有共性按钮的功能 ? 用户友好性测试 4) 异常情况测试： 在完成正常功能测试后，按正常处理的相同操作顺序，执行与正常处理不同的动作，例如 ? 正常处理中要求输入日期的字段，这时输入字符或数字 ? 正常处理中输入字段有范围要求，这时输入超过范围的值 ? 正常处理中用两个值限定范围，这时用一个值或不限定 ? 正常处理中要求用“Tab”键，这时安“Enter”键或其他键 ? 正常处理中单选框、多选框、下拉框等，使用非指定键操作是否不同 于指定的按钮操作 篇二：软件测试标准一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 22 黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 23 测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 24 预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 25 测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 软件测试模型 公司目前采用 V模型，实现测试与软件开发的同步进行。 等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 三、开发测试流程 说明：1、新版本提供时间，由程序员与测试员按实际情况协调； 2、BUG 审核的范围包括对 BUG的抽查；对标注为不修改或待讨论 BUG的管理； 3、软件涉及到功能性修改时，应该先提供修改设计说明，讨论通过后方可 进行修改。 四、测试角色与职责 五、BUG 主要参数1、当前状态 记录 BUG的状态，包括已修改、未修改、已验证。 2、严重程度 BUG 严重程度分为四个级别 级别一：死机，数据丢失，主要功能完全丧失，系统悬挂 级别二：主要功能丧失，导致严重的问题，或致命的错误声明 级别三：次要功能丧失， 不太严重，如提示信息不太准确 级别四：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如 有错别字 3、修改次数 指同样 BUG重复修改的次数，是衡量开发人员工作效率的重要依据； 4、优先级别： 分为四个级别 级别一：必须立即修改； 级别二：一天内修改； 级别三：三天内修改 级别四：短期内无须解决或在下一版本中解决 说明：严重程度越高，优先级越高，原有错误优先级高于新版本错误。 六、测试文档 1、测试报告 详细记录 BUG出现过程，可能原因，解决方法或解决意见。测试报告要求书写工整、简明扼要，必须要详细注明 BUG发现日期、BUG 所属模块等相关信息（对于较难发现的 BUG，必须提供操作流程及应用数据） 。测试报告是测试员与开发人员交流的重要文档，也是测试评价的重要依据。注意： A、如果测试与测试任务单对应，则测试报告中必须要记录任务单编号，以利于测试验收及考核。 B、测试报告中必须注明测试用例编号，如果发现的 BUG不在测试用例范围内，则填写为“其它” ，为测试用例评估提供依据。 C、程序员在修改 BUG时，如果严重级别为一、二级，必须说明修改方法或问题原因，以利于分析。 2、测试用例 测试用例是为高效地发现程序中的 BUG而精心准备的一组测试数据或操作过程。测试用例不可能穷举软件中的所有情况，所以测试用例的设 计必须具有代表性，通过测试用例的使用可以提高工作效率、减少重复劳动、在软件进行改动或升级时，只需对测试用例进行少量的修改即可开展工作。 3、测试计划主要内容：计划时间、人员、测试工作安排 4、测试任务书 主要内容：时间要求、参与人员、验收标准或结束标志 5、测试总结报告 主要内容：计划完成情况、BUG 修改情况、经验总结、测试对象评分（10 分为上限） 6、软件修改记录 主要内容：修改对象、修改内容、修改原因、问题提出人、关联对象、测试注意事项 7、讨论记录 详细记录所有与测试相关的讨论，参与讨论者须在此记录上手工签名 8、软件升级记录 详细记录软件升级情况 9、用户问题记录 主要内容：用户情况、用户问题、解决方法、解决状态 七、测试阶段划分 1、单元测试 对某个相对独立构件的测试，结束标志为：能满足独立运行要求 2、集成测试 将已通过单元测试的模块依次进行组合并测试，结束标志为：组合后的模块能满足要求； 3、验收测试 所有模块均通过集成测试后，软件可以交付使用前的测试，结束标志为：软件可以交付使用 4、维护测试 对软件发布后发现的问题进行的修改与测试，结束标志为：问题解决、软件运行正常 八、测试类型 篇三：计算机软件测试规范计算机软件测试规范 1 目的 对软件产品（项目）的特性进行测试，以确保产品（项目）的符合性。 2 范围 适用于产品（项目）开发阶段及实施阶段的测试。 3 职责 项目经理负责测试活动的申请、明确测试内容并将测试产品（项目）提交。 测试组成员负责测试用例的设计、编写和测试实施。测试经理负责组织测试过程，执行完成后的统计分析与总结。 4 工作程序 测试启动 在产品（项目）开发完成阶段，由项目经理提交测试申请，测试经理组织编写测试大纲和测试进度计划。 测试经理参照测试大纲，结合项目的具体情况建立测试小组。 测试 除单元测试以外，在进行各种测试前应做好下述准备：a、 配备测试用的硬件环境； b、 建立相应的运行环境和网络环境； c、 准备测试数据； d、 组织和培训测试人员； e、 制定测试计划。 测试依据 测试大纲、测试计划、测试用例、需求分析文档、设计说明书、上阶段测试记录、上版软件产品用户反馈意见记录和顾客提供的相关项目资料等。 测试计划的制定 各阶段的测试计划内容应包括测试时间、人员安排、设备环境的建立、测试记录、统计方法、问题反馈处理办法、测试用例和测试数据等。 测试人员或组长制定单元测试计划、系统测试计划、验收测试计划，提交测试经理批准后执行。 测试用例的设计单元测试用例的设计 测试组成员根据单元测试计划并参阅详细设计说明书，针对详细设计说明书的每一个模块，设计出合理适用的单元测试用例，并指出用黑盒或（和）白盒方法进行测试。测试经理确认测试用例是否充分覆盖，并组织项目室、技术室、测试室有关人员对测试用例进行评审并将白盒及黑盒测试用例分开，具体操作可参见软件评审作业指导书 。 系统测试用例的设计 测试组成员根据系统测试计划，参阅概要设计说明书、需求分析文档和用户提出的系统性能方面的要求，针对需求分析报告及功能规格说明书中描述的功能需求和概要设计说明书中描述的模块集成情况分别设计出适用的黑盒测试用例或（和）集成模块的白盒测试用例分析文档，测试用例应覆盖所有的功能点， （若因条件所限，不能进行测试的，应在测试报告中说明。 ）主要应从如下几个方面考虑：数据和数据库完整性测试、性能评测、负载测试、强度测试、容量测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试。系统测试用例应经过测试组的自检、互检，经测试经理审批后，方可用于测试。在进行系统测试用例的设计过程中应定期将文档提交到项目配置库中。 测试实施 根据测试目的的不同，分几个阶段进行测试。 单元测试 测试人员从配置管理员处用例库中提取测试用例，按照测试大纲和测试计划执行单元测试，确保通过单元测试通过准则，保证模块运行正确、界面与设计说明书相一致。系统测试 测试组成员从配置管理员处配置管理用例库中提取系统测试用例，按照测试计划执行系统测试 ，测试的内容按照测试用例进行。系统测试应力图测试完整，需求制作安装盘的，应以安装的版本进行测试。安装盘由项目组制作。保证软件产品数据流计算的正确性、软件产品整体运行的稳定性、与其他软件产品数据接口间的正确性，以及与需求说明书的一致性。 (转 载 于 : 小 龙文 档 网:软件测试规范) 验收测试测试人员应严格按照测试大纲和测试计划所确定的测试用例进行测试，测试人员应如实、完整地记录测试结果，对问题级别的判断应客观、准确。 （在测试中如发现测试用例以外的软件问题，也应作好记录。 ）保证软件产品运行的稳定性和与需求说明书的一致性，同时进行软件产品加密、安装正确性的测试，以保证发版软件产品的正确性。 在验收测试完成,评审会通过、项目经理批准的情况由综合室将测试产品提交给用 户（或相当于用户的角色）进行 测试,并由综合室负责指派人员对用户 测试的跟踪工作,及时收集顾客反馈的问题，并根据顾客的反馈情况进行相应的处理。测试记录的控制 在测试过程中，测试人员应按单元测试错误等级的划分标准和系统测试错误等级的划分标准的规定进行判定并做好测试记录，随时准确详细地记录软件的错误和不妥之处。每个错误（建议）所属的模块、出错描述、错误等级、问题状态、测试日期、测试人、测试版本、图片（需要时）都应该在相应的栏目中填写清楚；所作的问题描述要求开发人员根据记录的步骤进行操作，可重现错误重现，不可重现错误能理解操作步骤，寻找错误根源。对于测试的问题可采用 OA测试用例库工具进行记录，也可用问题记录模板记录，具体方式由测试经理确定。 各阶段测试完成后，测试组应提交软件测试报告，报测试经理审批后归档。 对测试问题的判别有如下几类： P1 致命错误：将使整个系统无法满足关键性、技术性指标要求，将导致工程失败； P2 严重问题：导致系统无法正确运行； P3 不同问题：会降低系统可靠性、安全性问题，降低系统的可操作性问题； P4 轻微问题：对整个系统的影响较小，可能降低系统的效率或产生其他后果。 测试反馈和处理 对测试问题的处理 对测试中发现的问题，项目经理应及时组织修改，并定期将修改的版本提交给测试组进行下一轮的测试。 测试记录传递 a、 单元测试、系统测试和验收测试完成后，由测试人员将测试计划、数据统计分析交 测试经理审核编号后传递给项目经理，再由项目经理传递给相关相目人员，再完成此次测试修改后，由项目经理将测试的文档交与配置管理人员进行存档。 b、 用户测试后的结果，由用户反馈到营销中心，营销中心根据具体情况进行传递。 不合格项控制 对测试记录的不合格项，由测试人员及时反馈到软件开发