《软件测试实施细则》.doc

PAGE PAGE １ 《软件测试实施细则》（草案） 前言 编写本方案的目的在于进一步明确软件测试所承担的工作，要达到的效果及软件测试工作中涉及到的若干细节。本方案以公司软件开发标准及软件测试标准为基础，以全面执行两个标准为原则，适用于软件测试工作全过程。 测试常用分析方法 等价类划分 等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。例如，在不了解等价分配技术的前提下，测试了1+1、1+2、1+3和1+4之后，还有必要测试1+5和1+6吗?能否放心地认为它们正确吗?那么1+999…（可以输入的最大数值）呢？这个测试用例是否与其他用例不同？是否属于另外一种类别？另外一个等价区间？这是软件测试员必须考虑到的问题。等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。 1+999…和1+13有什么区别呢？至于1+13，就像一个普通的加法，与1+5或者1+392没有什么两样，而1+999…则属于邻界的极端情况。假如输入最大允许数值，然后加1，就可能会出现问题——也许就是软件的缺陷。这个极端案例属于一个单独的区间，与常规数字的普通区间不同。 边界值分析 边界值设计测试遵循的五条原则： 如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值； 若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例； 针对每个输出条件使用上述1、2条原则； 如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例； 分析规格说明，找出其他的可能边界条件。 因果图 因果图能有效地检测输入条件的各种组合可能会引起的错误。通过画因果图，在图上标明约束和限制，转换成判定表。这适合于检查程序输入条件的各种组合情况。 基于PB的MIS系统常见BUG 数据库操作（增加、删除、修改） 操作完成后没有及时刷新数据； 数据库默认值检索不正确； 按条件检索时条件不正确； 从数据库中取出的值不正确； 操作时没有进行数据的有效性判断； 数据窗口 进行删除操作时没有进行空值判断； 带参数检索时没有传入正确的参数； 检索默认值时没有进行有效性判断； 操作完成后没有及时刷新数据窗口内容； BUG标准 符合以下描述者，均视为BUG 功能类 重复的功能 多余的功能 功能实现与设计要求不相符 功能实现不符合需求报告 功能使用方便性、易用性不够 界面类 界面不美观 界面风格不统一； 控件排列、格式不统一 焦点控制不合理或不全面 提示信息不准确； 提示信息类 提示信息重复或出现时机不合理 提示信息格式不符合要求 提示框返回后焦点停留位置不合适 流程类 流程控制不符合要求 流程实现不完整 数据处理类 数据有效性检测不合理 数据来源不正确 数据处理过程不正确 数据处理结果不正确 测试用例编写说明 测试用例是整个测试工作开展的核心，所有测试均由测试用例驱动，测试用例按以下类型划分：功能、界面、数据处理、流程处理、极限、并发、安装 每个测试对象的测试用例均包括以上类型，在测试初期，可以只有功能、界面测试用例，在不断进行的测试工作中，对测试用例进行补充，最后实现每一模块均有完整的测试用例，利于后期的测试及复测。 例：在集成测试的初期，ATS纳税人登记模块可能只关联到税源登记模块，此时，应该编写纳税人登记与税源登记的集成测试用例，随着开发的进展，加入纳税人完税模块的集成，此时，应该及时编写与完税模块的测试用例。 1、测试用例标准格式 测试对象 输入或功能描述 预期结果 是否符合要求 备注 2、测试用例编写规范 功能测试用例： 严格按需求分析、详细设计报告、用户手册、软件功能说明书编写，此用例对应到每一个具体的操作或每一项具体的功能。功能性测试用例在软件详细设计阶段完成后进行编写！如果是在软件发布后新增功能，应按新增功能详细说明及详细设计报告进行编写。功能测试用例除对模块本身的功能进行测试外，还应对通用控件的功能进行检查，本用例适用于单元测试。 主要内容： 测试对象的设计功能； 实现功能与设计功能的对照； 测试对象中每一个控件的具体功能； 设计中有关规定或约束； 常用控件的一般功能或常见功能实现； 有效性控制； 应该进行的检测或控制； 画出测试对象的功能结构图或示意图； 实例（ATS系统纳税人登记） 测试对象 输入或功能描述 预期结果 是否符合要求 备注 纳税人编码 新增纳税人 自动生成编码 纳税人名称