测试用例撰写及评审规范

测试用例撰写及评审规范
测试用例撰写及评审规范

1.测试用例评审

1.1测试用例

测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。

测试用例编写方法:

常用的五种方法,包括:等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法。测试用例的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、前置条件、测试输入、操作步骤、预期结果、实际结果、附件等,下面逐一介绍。

前置条件

前置条件是执行此条测试用例需要准备的环境,数据,配置等;前置条件不为真会导致测试用例的阻塞

测试用例标题

对测试用例的简短描述,清楚表达测试用例的用途以及功能路径。比如“ 【门急诊工作站】测试用户登录时输入错误密码时,软件的响应情况” 。

重要级别

定义测试用例的优先级别.结合我司目前项目实际情况, 现将所有用例统分为四个level:

L1 --基本:~ 10%

a.系统基本功能,1级用例的数量应受到控制

b.划分依据:该用例执行的失败会导致多处重要功能无法运行的,如:表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的而经常这样使用的一些功能用例。

c.该级别的测试用例在每一轮版本测试中都必须执行。

L2 --重要:~ 30%

a.2级测试用例是实际系统的重要功能。2级用例数量较多。

b.划分依据:主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例。

c.在非回归的系统测试版本中基本上都需要进行验证,以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是够进行测试。

L3 --一般:~ 50%

a.3级测试用例涉及系统的一般功能,3级用例数量较多。

b.划分依据:使用频率较低于2级用例。例如:数值或数组的便捷情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。

c.在非回归的系统测试版本中不一定都进行验证,而且在系统测试的中后期并不一定需要每个版本都进行测试。

L4-- 生僻:~ 10%

a.该级别用例一般比较少。主要是异常功能等。

b.划分依据:该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误,但是那些用例的处罚条件非常特殊,仍然应该被植入4级用例中。

c.在版本测试中有某些正常原因(包括:环境、人力、时间等)经过测试经理同意可以不进行测试。

测试输入

提供测试执行中的各种输入条件。根据需求文档,设计文档等定义的输入条件,确定测试用例的输入范围。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有明确的定义需求的输入,那么测试用例设计中会遇到很大的障碍。

操作步骤

根据需求文档,设计文档,等相关文档对系统功能的描述,测试执行人员需要操作的步骤包括正向和逆向步骤,覆盖文档中描述的功能。

预期结果

提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实

际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。

实际结果

根据既定测试步骤执行后,软件程序前后端实际产出的输出结果,包括但不限于前端UI缺陷、程序逻辑缺陷、接口数据缺陷、数据库存储缺陷、服务端响应缺陷等

附件

为能更详尽的表述操作步骤的设计思路以及预期结果的阵列check,需要时会上传prd截图、缺陷截图、设计稿件、excel矩阵等附件

注:可参考《测试用例模板》附件

1.2 测试用例评审

测试部门内部的评审,着重于:

1. 测试用例本身的描述是否清晰,是否存在二义性

2.是否考虑到测试用例的执行效率.

3.是否针对需求跟踪矩阵,覆盖了所有的软件需求,

4.是否完全遵守了软件需求的规定。

评审的内容以及原则有以下几个方面:

1) 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。

2) 优先极安排是否合理。

3) 是否覆盖测试需求上的所有功能点。

4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结

果是否清晰、正确;期待结果是否有明显的验证方法。

5) 是否已经删除了冗余的用例。

6) 是否包含充分的负面测试用例。

7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。

8) 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复

用标准步骤。

注:另附《评审记录表模版》供参考

1.2.1评审的方式

1) 沟通之前把用例设计的相关文档或者链接地址(包括登录账号、权限赋予)发送给评审部门&人员进行前期的学习和了解,以节省沟通成本

2)召开评审会议。与会者讲解之后给出意见和建议,同时进行详细的评审记录。

3) 通用邮件或者IM工具进行同步与沟通所审核用例的后续增删改信息, 并第一时间完成用例库update。

测试用例编写规范

测试用例编写规范 变更历史

引言 1.背景 为保证测试用例对需求的覆盖率,即对一个系统从整体功能到单个功能,都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作,系统是否都做了处理; 测试用例设计首先要明确该系统存在多少功能点,要通过各种常用的测试方法来保证用例的完整性,然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行,这样才能够更有效的保证系统所有功能点的覆盖率。 2.目的 为测试用例的质量负责,使测试工作能有序、合理化的进行,从而提高实施测试时对所测产品、系统或者模块的测试质量,也是作为各测试人员在设计用例时的一种规范,使之设 计的用例能有效的被管理。 3.概念 是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合,也 指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相 组合的一个特定集合,以便测试某个程序路径或者来核实是否满足某个特定的需求。 4.适用范围 本文档适用于测试人员 本文档适用于系统进行测试时的测试案例设计 本文档适用于案例补充时的测试案例 用例规范 用途 特导江试工绘有壬亠实富対试为数畀勾抿可依确喂环实現曲項能与客户烈範的需丈观舛合 完善软件不同版本之间的重复性测试跟踪测试进度,确定测试重点评估测试结果的度量标 准增强软件的可信任度分析缺陷的标准。 设计依据 需疽说阴书忑E淀试爵求功能恵所属行业的业务知识掌握程度测试工程师本人的理解程度 (个人经验) 用例内容

编写用例原则 系统性:对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;对模块业务流程要说明子系统内部功能、重点功能以及它们之 间的关系 连贯性:对系统业务流程要说明各个子系统之间是如何连接在一起,若需要接口,各子系统之间是否有正确的接口,若是依靠页面链接,则页面的链接是否正确; 对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统,其内部功 能接口是否连贯 全面性:应尽可能覆盖各种路径、尽可能覆盖各个业务点,并要考虑跨年、跨月的数据以及大数据量并发测试的准备 正确性:输入界面后的数据应与测试文档所记录的数据一致,而预期结果也应与测试数据发生的业务吻合 符合正常业务规则:测试数据要符合用户实际工作中的业务流程,同时也要兼顾各种业 务的变化以及当前该业务行业的法律、法规、人名、地名、电话号码等应 具有模拟功能,符合一般的命名惯例;不允许出现与知名人士、小说中人物名等雷同情 况。 可操作性:测试用例中要写清楚测试的操作步骤,以及不同的操作步骤相对应的测试结果 编写用例标准 测试案例编写应该制订统一的模板进行,并约定模板的使用方法; 测试案例编写应当根据项目实际情况编写测试案例编写手册,包括案例编号规则、案例编写 方法、案例编写内容、案例维护等内容; 案例编写应根据手册中约定的编写方法、内容等进行编写;

考试系统测试用例

在线考试管理系统 产品简介 本产品可供各类学校、培训机构进行考试管理使用。 本产品具备在线考试管理、考卷管理、试题管理、手工及自动组卷、标准试卷打印、自动阅卷、成绩管理等多项功能。 产品结构 管理员:教师管理、班级管理、试题分级、题目种类、题型管理、难度管理 教师:学生管理、题库管理、组卷管理、考试管理、考试监控、评卷管理、成绩管理 学生:在线考试、成绩查询 产品特点 A、完善的权限管理——有完善的权限设置分配功能,使不同人员具有不同的操作查看权限,保证系统使用的安全性,更易于管理。 B、不断扩展的资源库——在线考试可增加考试类别、题目类别,扩充考题。 C、丰富考试的内容——在线理论考试支持多种多媒体题目。 D、强大的组卷功能——试题随机抽取的自动方式和人工选题的手工方式并用,实现快速组卷,轻松组卷,灵活组卷。 E、出卷方便快捷,省时省力——计算机组卷后导出为Word格式,并以A3/A4版式打印。 F、两种阅卷方式——客观题系统自动阅卷,主观题可在线阅卷,提高阅卷的准确性,同时提升工作效率。 G、监考功能——在线考试中,将设计防拷贝、防切屏、锁定IP、监控在线状态等功能,保证考试的公平和顺利进行。 H、数据保护——考试系统平台设计缓存系统,数据实时保存,保证系统永不丢失数据。 I、批量导入数据——包括试题、人员、部门、试卷等各种信息,达到快速建立考试平台的目的。

1.1测试步骤1.1.1题库 增加 删除 修改

查询 1.1.1.1试题管理 增加 删除

修改 查询 1.1.1.1.1试题属性增加 删除

修改 查询 1.1.1.1.1.1题型增加 删除

测试用例规范说明

测试用例规范约定 一、用例设计书写的标准规范 1.用例标题 描述清楚该用例所要达到的测试目的,不是单纯的描述所在模块或; 正确示例: 未登录状态下发布动态能否成功 或 登录状态下只发布文字动态内容能否成功 2.前置条件 用例必须清晰地描述此用例所需的前提条件; 正确示例: 1、用户已登录云转诊APP; 2、用户已进入动态页面; 3.用例步骤 测试用例编写要步骤明确,输入输出要素(输入数据值)清晰,并且无疑义; 输入数据值:指当前用例输入值的具体范围及明确值; 正确示例: 1、点击动态下的(发动态)按钮 2、输入文字:我很享受音乐 3、点击(发送)按钮 4.预期结果 预期结果必须具有可判定性,即测试步骤执行后,结果是可判定的,每一个测试用例的步骤都应有相应的唯一的预期结果,预期结果中不能包含步骤; 正确示例: 发布动态成功,页面跳转至动态页面 错误示例: 1.云转诊APP成功打开 2.显示我的页面 3.打开编辑页面 4.弹出性别选择窗口 5.测试用例集 一条用例内多个用例步骤对应多个预期结果时,禁止使用编号内附加子级编号形式编写测试用例,需要单独表述。测试用例可以使用单条用例或测试用例集的方式编写,单条用例需要把同一情况下的测试用例整合在一条内编写,预期结果与操作步骤相互对应。测试用例集需要操作步骤与预期结果编号相对应,完整的表达操作与结果之间的关系

真实示例如下图所示: 二、用例设计书写的颗粒度描述 要求:验证一个功能点一条用例,没有重复、冗余的测试用例。 功能测试用例需要从用户层面来设计用户使用场景和使用流程。 1.冒烟测试 验证系统正向功能流程通畅及验证系统正向必填项(系统要求验证项)输入值、单选项、下拉框、按钮等符合系统要求; 2.功能测试 用例中需要合理的使用测试用例编写方法设计反向用例、容错性用例、三方交互用例等场景,以确保覆盖业务操作的基本路径和异常路径,以及对其他模块/功能的影响和必填项(系统要求验证项),保证达到系统规定; 3.UI测试 对系统UI页面进行检查,确保UI布局合理、文字统一、易用性(易操作、易理解和易学习)、友好性等达到系统要求(同一页面没有操作整体时,页面检查算一个功能点); 三、用例执行规范 1.出现非Pass的用例必须标记对应的状态,Fail的用例必须提交缺陷; 2.由于某个Bug缺少测试条件导致用例不能执行,标为Block添加备注信息; 3.功能模块没有设计好,或者不适用于本轮测试的用例,标为N/A加备注信息; 四、用例测试执行突发状况处理

如何进行测试用例评审

如何进行测试用例评审 测试用例评审工作对测试人员能力的提高,测试效率的提高都有很好的作用,那么如果进行测试用例评审呢?它又哪些标准呢?通过的标准又是什么呢? 关于“测试用例内部评审的标准”的讨论的摘要: 首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。 如果是测试组内部的评审,应该着重于: 1.测试用例本身的描述是否清晰,是否存在二义性 2.是否考虑到测试用例的执行效率 . 往往测试用例中步骤不断重复执行,验证点却不同, 而且测试设计的冗余性,都造成了效率的低下 3.是否针对需求跟踪矩阵,覆盖了所有的软件需求, 4.是否完全遵守了软件需求的规定。这并不一定的,因为即使再严格的评审,也会出现错误,应具体情况具体对待。 如果是项目组内部的评审,也就需要评审委员会来做了,角度不同,评审的标准也不同。比如: 收集客户需求的人员注重你的业务逻辑是否正确; 分析软件需求规格的人注重你的用例是否跟规格要求一致;开发负 责人会注重你的用例中对程序的要求是否合理。 要清楚地一点是:为了保证测试用例设计的质量,以及评审的收益,在提交项目组评审之前,必须通过测试部门或测试组内部的评审。 1.测试用例是否覆盖了所有需求 . 2.测试用例内容是否正确 , 是否与需求目标一致 . 3.测试用例内容是否完整 , 是否清楚包含输入和预期输出结果 . 4.测试用例是否具有指导性 , 是否能灵活指导测试人员通过用例发现更多缺陷 , 而不是限 制他们的思维 . 初期设计测试点时,应该进行测试组内部评审,当然首先是要保证需求全被覆盖,如果能在评审时,让需求分析人员参与进来,效果会更好。 测试用例评审如何去做呢? 测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。 1、需要评审的原因

最新测试用例实例

测试用例实例 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的测试用例,应该包含以下信息: 1)软件或项目的名称 2)软件或项目的版本(内部版本号) 3)功能模块名 4)测试用例的简单描述,即该用例执行的目的或方法 5)测试用例的参考信息(便于跟踪和参考) 6)本测试用例与其他测试用例间的依赖关系 7)本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限 8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、实例 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。 表4-1登录界面测试用例

自动取款机取款用例规约和测试用例 取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息; 4. 系统验证客户输入的密码信息,确认正确后,进入选择系统主界面; 5. 用户选择取款选项; 6. 系统进入取款金额界面并提示用户输入金额; 7. 系统验证可以取款并输出钱款; 8. 系统提示用户取卡,操作完成。 基本流: 用户取款。 备选流: 1.用户密码错误 2.取款金额不符合要求。 前置条件: 用户必须插入正确的银行卡才能开始执行用例。

测试用例书写标准

测试用例书写标准 在编写测试用例过程中,需要参考和规范一些基本的测试用例编写标准,在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。 ●标识符(identification):每个测试用例应该有一个唯一的标识符,它将成为所有和测试 用例相关的文档/表格引用和参考的基本元素,这些文档/表格包括设计规格说明书、测试日志表、测试报告等。 ●测试项(test item):测试用例应该准确地描述所需要测试地项及其特征,测试项应该比 测试设计说明书中所列出地特性描述更加具体,例如做windows计算器应用程序地窗口设计,测试对象是整个地应用程序用户界面,这样测试项就应该是应用程序地界面地特性要求,例如缩放测试、界面布局、菜单等。 ●测试环境要求(test environment):用来表征执行该测试用例需要地测试环境,一般来 说,在整个的测试模块里面应该包含整个的测试环境的特殊要求,而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。 ●输入标准(input criteria):用来执行测试用例的输入需求。这些输入可能包括数据、文 件,或者操作(例如鼠标的左键单击,鼠标的按键处理等),必要的时候,相关的数据库、文件也必须被罗列。 ●输出标准(output criteria):标识按照指定的环境和输入标准得到的期望输出结果。如 果可能的话,尽量提供适当的系统规格说明书来证明期望的结果。 ●测试用例之间的关联:用来标识该测试用例与其它的测试(或其它测试用例)之间的依 赖关系,例如,用例A需要基于B的测试结果正确的基础上才能进行,此时需要在A 的测试用例中表明对B的依赖性,从而保证测试用例的严谨性。 综上所述,如果使用一个数据库的表来表征测试用例的话,它应该有以下的格式: 例一:对Windows记事本程序进行测试,选取其中的一个测试项――文件菜单栏的测试 测试对象:记事本程序文件菜单栏(测试用例标识1000,下同),所包含的子测试用例描述如下: |---------文件/新建(1001) |---------文件/打开(1002) |---------文件/保存(1003) |---------文件/另存(1004) |---------文件/页面设置(1005) |---------文件/打印(1006) |---------文件/退出(1007) |---------菜单布局(1008) |---------快捷键(1009)

软件测试标准和测试用例汇总

软件测试标准 前言 前一版的《软件测试标准》,在测试工作中发挥了很好的指导作用。本次修改在原标准基础上,提出了新的测试理念、工作方法、组织方式,使之更贴近实际工作,真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为:验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试,测试目标是检查程序部逻辑结构和逻辑路径,是代码级的测试。 2.2黑盒测试 基于程序功能的测试,根据输入输出的关系推断程序功能的正确性。 2.3测试用例 测试方案,包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2.4预防性测试 其原理为:只要测试在生命周期中进行得足够早,就能够提高待测软件的质量。 2.5测试风险分析 其目的为:确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型,实现测试与软件开发的同步进行。

2.7等价类划分 将测试对象按某种约定划分为有限个组成部分,提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析 审核需求分析,编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯,并与需求分析作出对比 概要设计审核概要设计,从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告,与需求分析、概要设计进行比对 编写单元测试用例 编写用户手册总体框架 单元测试阶段提出测试计划审核测试用例执行测试 测试总结 集成测试阶段 验收测试阶段 补充测试用例 资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试测试总结 复测 测试报告复测 测试用例复测 三、开发—测试流程

软件测试用例(标准参考)

{ 项目名称} { 测试用例标题} 机构公开信息

版本历史

目录 0. 文档介绍 (5) 0.1文档目的 (5) 0.2文档范围 (5) 0.3读者对象 (5) 0.4参考文献 (5) 0.5术语与缩写解释 (5) 1. 接口-路径测试用例 (6) 1.1被测试对象(单元)的介绍 (6) 1.2测试范围与目的 (6) 1.3测试环境与测试辅助工具的描述 (6) 1.4测试驱动程序的设计 (6) 1.5接口测试用例 (6) 1.6路径测试的检查表 (7) 2. 功能测试用例 (8) 2.1被测试对象的介绍 (8) 2.2测试范围与目的 (8) 2.3测试环境与测试辅助工具的描述 (8) 2.4测试驱动程序的设计 (8) 2.5功能测试用例 (8) 3. 健壮性测试用例 (9) 3.1被测试对象的介绍 (9) 3.2测试范围与目的 (9) 3.3测试环境与测试辅助工具的描述 (9) 3.4测试驱动程序的设计 (9) 3.5容错能力/恢复能力测试用例 (9) 4. 性能测试用例 (10) 4.1被测试对象的介绍 (10) 4.2测试范围与目的 (10) 4.3测试环境与测试辅助工具的描述 (10) 4.4测试驱动程序的设计 (10) 4.5性能测试用例 (10) 5. 图形用户界面测试用例 (11) 5.1被测试对象的介绍 (11) 5.2测试范围与目的 (11)

5.3测试环境与测试辅助工具的描述 (11) 5.4测试驱动程序的设计 (11) 5.5测试人员分类 (11) 5.6用户界面测试的检查表 (11) 6. 信息安全性测试用例 (12) 6.1被测试对象的介绍 (12) 6.2测试范围与目的 (12) 6.3测试环境与测试辅助工具的描述 (12) 6.4测试驱动程序的设计 (12) 6.5信息安全性测试用例 (13) 7. 压力测试用例 (13) 7.1被测试对象的介绍 (13) 7.2测试范围与目的 (13) 7.3测试环境与测试辅助工具的描述 (13) 7.4测试驱动程序的设计 (13) 7.5压力测试用例 (14) 8. 可靠性测试用例 (14) 8.1被测试对象的介绍 (14) 8.2测试范围与目的 (14) 8.3测试环境与测试辅助工具的描述 (14) 8.4测试驱动程序的设计 (14) 8.5可靠性测试用例 (15) 9. 安装/反安装测试用例 (15) 9.1被测试对象的介绍 (15) 9.2测试范围与目的 (15) 9.3测试环境与测试辅助工具的描述 (16) 9.4测试驱动程序的设计 (16) 9.5安装/反安装测试用例 (16) 附录:评审意见 (16)

软件测试规范一(控件测试用例编写规范)

软件测试规范一(控件测试用例编写规范) 【编写说明】 以集成性功能测试为主,针对测试用例的编写规范进行说明。重点突出了各种控件、网站/软件的常用业务功能和界面及外部接口的测试。 第一章功能测试——控件测试用例编写规范 一、文本框控件 1.输入的字符类型: 根据需求/设计说明,或者当前设计程序的使用功能默认,确定输入字符要求: ①全中文; ②全英文; ③全数字; ④全其他字符`~!@#$%^&*()-=_+[]\{}|;’:”,./<>?等; ⑤中英文混合; ⑥中文和数字/其他字符混合; ⑦英文和数字/其他字符混合; ⑧包含空格。 2.输入长度测试: 根据需求/设计说明,或者当前设计程序的使用功能默认,确定输入长度要求: ①正常的长度输入; ②临界值长度输入; ③临界值范围内、紧临临界值长度输入; ④临界值范围外,紧临临界值长度输入。 3.输入格式测试: 根据需求/设计说明,或者当前设计程序的使用功能默认,确定输入内容的格式: ①正常格式、正常值范围输入; ②非正常输入格式; ③允许输入值的临界值输入(最小值,最大值); ④允许输入值的临界值范围内紧邻临界值的输入(最小值内,最大值内); ⑤允许输入值的临界值范围外紧邻临界值的输入(大于最大值、小于最小值); ⑥是否允许输入空格。 上述测试要覆盖字符类型、长度和格式的各种组合。 4.复制、粘贴: ①进行一次复制、一次粘贴操作; ②进行一次复制、多次粘贴操作。 5.普通文本框的测试用例(如:企业名称、姓名、设备名称等)

允许输入的内容一般分为以下几种:全中文(如姓名)、全英文、全数字(如数量)、全其他字符、中英文混合、中英文数字混合、英文数字混合、英文数字其他字符混合、数字其他字符混合。 全中文测试: 1)考虑一个正常长度的全中文输入; 2)考虑一个最小长度的全中文输入; 3)考虑一个比最小长度多一个的全中文输入; 4)考虑一个比最小长度少一个的全中文输入; 5)考虑一个最大长度的全中文输入; 6)考虑一个比最大长度多一个的全中文输入; 7)考虑一个比最大长度少一个的全中文输入; 全英文测试: 8)考虑一个正常长度的全英文输入; 9)考虑一个最小长度的全英文输入; 10)考虑一个比最小长度多一个的全英文输入; 11)考虑一个比最小长度少一个的全英文输入; 12)考虑一个最大长度的全英文输入; 13)考虑一个比最大长度多一个的全英文输入; 14)考虑一个比最大长度少一个的全英文输入; 全数字测试: 15)考虑一个正常长度的全数字输入; 16)考虑一个最小长度的全数字输入; 17)考虑一个比最小长度多一个的全数字输入; 18)考虑一个比最小长度少一个的全数字输入; 19)考虑一个最大长度的全数字输入; 20)考虑一个比最大长度多一个的全数字输入; 21)考虑一个比最大长度少一个的全数字输入; 全其他字符测试: 22)考虑一个正常长度的全其他字符输入;限制禁止输入其他字符。 23)考虑一个最小长度的全其他字符输入; 24)考虑一个比最小长度多一个的全其他字符输入; 25)考虑一个比最小长度少一个的全其他字符输入; 26)考虑一个最大长度的全其他字符输入; 27)考虑一个比最大长度多一个的全其他字符输入; 28)考虑一个比最大长度少一个的全其他字符输入; 29)考虑一个正常长度的中英文混合输入;限制禁止输入其他字符。 30)考虑一个最小长度的中英文混合输入; 31)考虑一个比最小长度多一个的中英文混合输入; 32)考虑一个比最小长度少一个的中英文混合输入; 33)考虑一个最大长度的中英文混合输入; 34)考虑一个比最大长度多一个的中英文混合输入; 35)考虑一个比最大长度少一个的中英文混合输入; 36)考虑一个正常长度的中文和数字混合输入; 37)考虑一个最小长度的中文和数字混合输入;

软件的测试用例实例(非常详细)

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注 V1.1

1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用 而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不 明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强 度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则 的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对 交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate_02 项目名称https://www.360docs.net/doc/f314891477.html, 开发人员模块名称WorkEvaluate 用例作者参考信息工作考核系统界面设计(2005_03_28).vsd 测试类型设计日期2006-9-27 测试人员 测试方法黑盒测试日期 用例描述 前置条件

测试用例实例

测试用例实例 Corporation standardization office #QS8QHH-HHGX8Q8-GNHHJ8

测试用例实例 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的用例,应该包含以下信息: 1)软件或项目的名称 2)软件或项目的版本(内部版本号) 3)功能模块名 4)测试用例的简单描述,即该用例执行的目的或方法 5)测试用例的参考信息(便于跟踪和参考) 6)本测试用例与测试用例间的依赖关系 7)本用例的前置条件,即执行本用例必须要满足的条件,如对的访问权限 8)用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。

取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息;

测试用例编写规范

测试用例编写规范 1、目的 统一测试用例编写的规范,为测试设计人员提供测试用例编写的指导,提高编写的测试用例的可读性,可执行性、合理性。为测试执行人员更好执行测试,提高测试效率,最终提高公司整个产品的质量。 2、范围 适用于集成测试用例和系统测试用例的编写,现在编写用例的辅助工具为TestDirector 8.0。 3、术语解释 集成测试: 集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。 系统测试 : 系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。 4、测试用例原则 4.1 系统性 1. 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系; 2. 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系; 4.2 连贯性

1. 对于系统业务流程来说,各个子系统之间是如何连接在一起,如果需要接口,各个子系统之间是否有正确的接口;如果是依靠页面链接,页面链接是否正确; 2. 对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系 统,其内部功能接口是否连贯; 4.3 全面性 1. 应尽可能覆盖程序的各种路径 2. 应尽可能覆盖系统的各个业务 3. 应考虑存在跨年、跨月的数据 4. 大量数据并发测试的准备 4.4 正确性 1. 输入界面后的数据应与测试文档所记录的数据一致 2. 预期结果应与测试数据发生的业务吻合 4.5 符合正常业务惯例 1. 测试数据应符合用户实际工作业务流程 2. 兼顾各种业务变化的可能 3. 要符合当前业务行业法律,法规。 4.6 仿真性 人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例;不允许出现 与知名人士、小说中人物名等雷同情况。 4.7 可操作性 测试用例中应写清测试的操作步骤,不同的操作步骤相对应的操作结果。 5、测试用例主要元素 标准规范中包含的主要元素如下: 测试名称(Test Name):测试用例编号和测试用例名称。

测试用例管理规范(V1.0)

测试用例管理规范(V1.0) 1 总则 1.1 说明 软件最终呈现在用户面前的质量,与测试执行的程度和力度密不可分。测试用例设计的基本目的,是确定一组最有可能发现某个错误或者某类错误的一组测试数据。测试用例不但构成了设计和制定测试过程的基础,而且测试的深度与测试用例的数量成正比。判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这个又是以确定和执行的测试用例的数量为依据的。如今,用户对手机软件质量要求日趋严苛,几乎对每一种现实中可能发生的操作都要求软件保证正确。在这种情况下,完全覆盖测试和大量用例验证不可避免,而测试工作量又与用例数量成正比,因此,该如何兼顾测试工作量和效率,如何测试,用什么方式测试,在什么环境和什么条件下测试,如何避免重复测试,已成为测试人员必须考虑的问题。本规范就是从以上列举的方面出发,通过对测试用例科学化的组织、归纳和管理,来指导测试行为,提高测试效率,保证软件质量。 1.2 测试用例意义 1.2.1 对降低项目风险的意义。 在设计测试用例的过程中,测试人员可以根据自己的理解,对需求提出不同的看法,或者发现需求中某些功能描述得不够详细或者有歧义的地方,可提早发现问题,降低项目风险。 1.2.2 对测试与开发的意义。 测试用例的质量在一定程度上决定了测试工作的有效程度。一个好的测试用例使得测试工作事半功倍,并且能尽早的发现一些隐藏的BUG,测试用例的设计是软件开发中的重中之重。 1.2.3 对测试过程的意义。 测试的目的是在有限的资源下,尽可能多的找出系统的缺陷。这就要求在测试中,尽可能完全的走完系统的所有流程,保证所有的功能点都经过测试。而测试过程是由人来执行的,不可避免的会遗漏一些应该测试的内容,这样就很容易出现测试不全面的问题。再者,对手机软件开发而言,需求变更频繁,经常需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全面,当进行第二轮测试的时候,可能也会遗漏某些功能点。为规避这种风险,通常引入测试用例来指导我们的测试行为。当需求入基线后,测试人员开始介入项目,对需求进行分析,并设计出详细的测试用例,以对测试行为进行科学化的组织和归纳。这样在测试执行时,只需按照设计好的过程去执行,就可避免由于人为原因而造成的测试不全面的问题。 2 适用范围 本规范适用于软件测试组。 手机软件黑盒测试整个过程。 手机软件自动化测试、白盒测试部分过程。 测试用例建设整个周期。 3 测试用例编写规范 3.1 测试用例编写格式及要求 3.1.1 测试用例定义

软件测试用例实例(非常详细)汇总

软件测试用例实例(非常详细)汇总

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。 测试 目的 配置说明操作系 统 系统 软件 外设应用软件结果 服务器Windo w2000( S) Windo wXp Windo w2000( P) Windo w2003 用例编号TestCase_LinkWorks_W orkEvaluate 项目名称LinkWorks

1.1.

1.2. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目的 测试说明 前提条件连续运行8小时,设置添加 10用户并发 测试需求输入/ 动作 输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时功能1 2小时 4小时 6小时

8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.360docs.net/doc/f314891477.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计

软件测试用例设计规范

软件测试用例设计规范Software Test Case Design Specification

版本历史 版权信息 本文件内容由XX集团信息技术部负责解释 本文件的版权属于XX集团 任何形式的散发都必须先得到XX集团信息技术部的许可 https://www.360docs.net/doc/f314891477.html,/

【目录】 1目的 (4) 2范围 (4) 3名词定义 (4) 4工件 (4) 4.1 输入 (4) 4.2 输出 (5) 5规范内容 (5) 5.1 设计原则 (5) 5.1.1可执行性 (5) 5.1.2可维护性 (5) 5.1.3可代表性 (5) 5.1.4可判定性 (6) 5.2 必要元素 (6) 5.2.1用例包和用例对象名命 (6) 5.2.2测试目的 (6) 5.2.3测试优先级 (6) 5.2.4测试环境 (7) 5.2.5前提条件 (7) 5.2.6后置关联 (7) 5.2.7用例状态 (7) 5.3 综合策略 (7) 5.3.1必要的边界值分析 (7) 5.3.2必要的等价类划分 (8) 5.3.3必要的因果图方法 (8) 5.3.4必要的性能测试方法 (8) 5.3.5面向对象设计方法 (8) 5.4 设计活动 (8) 5.4.1分析和建立测试用例包 (8) 5.4.2分解并建立测试用例对象 (10) 5.4.3建立测试用例对象间关系 (11) 5.4.4设计测试用例 (12) 5.4.5测试实施 (14) 5.5 检查点 (17)

1目的 本规范的目的是为了明确软件测试用例的设计原则,活动和方法,提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性,使软件测试用例真正能够指导测试的实施和执行,并成为评估测试结果的度量基准。 2范围 本规范适用于春秋信息技术部所有软件开发项目和产品集成测试和系统测试用例的设计。 3名词定义 4工件 4.1 输入

软件测试规范二(业务功能测试用例编写规范)

功能测试——业务功能测试用例编写规范 一、编辑操作: 编辑操作包括剪切,复制,粘贴操作: 1.测试剪切操作的方法 1)对文本,文本框,图文框进行剪切; 2)剪切图像; 3)文本图像混合剪切。 2.复制、粘贴操作 1)粘贴复制的文本,文本框及图文框; 2)粘贴所复制的图像; 3)复制后,在不同的程序中粘贴; 4)多次粘贴同一内容,如:复制后,在程序中连续粘贴3次; 5)利用粘贴操作强制输入程序所不允许输入的数据。 二、查找替换操作: 通常是针对文本型的编辑框,还有针对表格的全部或某一部分。 例如:word中的"替换"对话框。测试本功能有通过测试和失败测试两种情况: 1.通过测试: 1)输入内容直接查找,或查找全部; 2)在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确。如:已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以。 2.失败测试: 1)输入过长或过短的查询字符串。如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试; 2)输入特殊字符集。如:在word中,^g代表图片,^代表分栏符,可以输入这类特殊字符测试。 3.编辑操作窗口的功能测试的用例: 1)关闭查找替换窗口。不执行任何操作,直接退出; 2)附件和选项测试。假如:设定“精确搜寻”、“向后”搜索等附件选项等等来测试; 3)控件间的相互作用。如:搜寻内容为空时,按钮“搜寻全部”、“搜寻”,“全部替换”,“替换”都为灰色。 4)热键, Tab键。回车键的使用。 三、插入操作: 1.插入文件测试用例: 1)测试插入; 2)插入图像; 3)在文档中插入文档本身; 4)移除插入的源文件; 5)更换插入的源文件的内容。

测试用例编写规范

测试用例编写规范 一.测试用例整体要求 一般的测试用例包括如下几个部分:需求标识、用例编号、用例名称、用例级别、预置条件、操作步骤、预期结果、备注、用例编写者、测试执行者、测试日期。 需求标识:唯一标识,与用例编号对应,为一对多关系。 用例编号:能够准确的标识每一条用例,每一个用例编号在所有测试用例中必须唯一。 用例名称:能够清晰表达测试用例的测试目的和关键测试要素。 用例级别:区分测试用例的重要程度,确定用例执行的级别。 预置条件:需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。 需要保证在完成预置条件中所描述的状态和配置以及外部环境后,测试执行的正确性、一致性。用例描述(测试步骤):为了达到测试用例的测试目的,所需要执行的操作;每个操作步骤对应一个预期 结果。 预期结果:针对测试用例的测试目的,测试步骤中操作后对应的预期输出状态。 用例编写者:设计用例的人员。 测试执行者:按照该用例执行测试的人员。 测试日期:执行测试的时间。 二.测试用例实现规则 规则1:用例要素要求 需求标识、用例编号、用例名称、用例级别、预置条件、操作步骤、预期结果、实际结果为必选要素,不能为空,其他字段为可选要素。 规则2:用例名称描述要求 用例名称不允许出现重复、包含关系,或者仅有数字编号差异。 规则3:用例级别分为高、中、低3个级别 高(优先执行):产品基本的功能验证,不设计配置及场景测试。即关键路径的测试用例,包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例;若该级别的测试用例完全执行通过,则表示该软件功能渐趋稳定。 中(次级执行):产品功能测试,常见的配置、交互及场景的测试。即可接收级测试的用例,包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例。

如何编写有效的测试用例及进行用例评审

如何编写有效的测试用例及进行用例评审 如何编写有效的测试用例及进行用例评审软件测试 测试用例在测试工作中占有重要作用,因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢? 一、明确项目的进度及计划 只有明确了项目的进度及计划,我们才知道应当在何时进行测试用例的编写,何时完成测试用例的编写。以保证在测试执行时,至少已经有了第一版本的测试用例。同时也可以避免因时间仓促而草草编写的测试用例。另外,测试用例编写任务的下达必须要明确完成的时间及需要达到的目标,没有时间限定及目标的测试用例编写将是低效的。 二、提供产品的相关文档 正所谓“巧妇难为无米之炊”,要求测试人员编写测试用例,就必需要为提示人员提供尽可能多的产品相关信息,如软件需求说明书、市场同类产品信息、市场反馈的相似产品的主要问题、软件及硬件环境,甚至于开发人员联系方式及项目的主要负责人信息等。这些信息都将有力的推动测试用例的有效性。 三、深入理解产品的相关文档 在正式编写测试用例之前,需要深入理解产品的相关文档。虽然需求分析人员都具有一定的产品规划能力,但是也有可能会犯错。很难想像根据一份有瑕疵的、甚至是严重错误的需求文档编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前,需要深入的理解产品的相关文档。建议可以采用会议的方案来进行,各自提出自己的见解,经过讨论会将相关的疑问提前给需求分析人员重新确认。同时将这些疑问作为BUG进行提交,记住这也是工作成果的一部份。一份完美的需求应该不存在任何的歧义或含糊的地方。 四、编写测试用例概要 在充分的理解产品的相关文档之后,就可以正式编写测试用例的概要了。之所以没有要求进行详细测试用例的编写,主要是出于编写测试用例时间的压力及评审的需要。由于测试人员的工作除了编写测试用例以外,还要进行日常的测试工作及各类报告的书写,工作量大且相对繁琐,因此应当尽量的控制编写测试用例的时间,以保证测试人员有充分的休息时间。同时对于一份详尽的、完整的测试用例而言,对于进行评审是很不经济的(试想一下,让你对1000个详尽的测试用例进行评审,你会作何感想?)。 测试用例的概要应该简洁明了,只需要说明验证点即可。同时在编写测试用例的概要时,尽量反映时编写测试用例的基本思路。对于100个测试用例概要进行分别评审比对10类(每类10个)的测试概要进行评审要困难得多。 测试用例概要可以采用如下格式: 五、测试用例的评审 在测试用例概要编写完成之后,下一步的工作就是进行测试用例的评审。个人对产品的理解及经验始终是有限的。测试用例的评审的主要目的就是集众人的经验及认识于一体,对测试用例进入查漏补缺,使得测试用例的有效性进一步提升。

测试用例编写规范教程文件

测试用例编写规范

测试用例编写规范 变更历史

引言 1.背景 为保证测试用例对需求的覆盖率,即对一个系统从整体功能到单个功能,都尽可能的高的覆盖。而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作,系统是否都做了处理; 测试用例设计首先要明确该系统存在多少功能点,要通过各种常用的测试方法来保证用例的完整性,然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行,这样才能够更有效的保证系统所有功能点的覆盖率。 2.目的 为测试用例的质量负责,使测试工作能有序、合理化的进行,从而提高实施测试时对所测产品、系统或者模块的测试质量,也是作为各测试人员在设计用例时的一种规范,使之设计的用例能有效的被管理。 3.概念 是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合,也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和

期望结果相组合的一个特定集合,以便测试某个程序路径或者来核实是否满足某个特定的需求。 4.适用范围 本文档适用于测试人员 本文档适用于系统进行测试时的测试案例设计 本文档适用于案例补充时的测试案例 用例规范 用途 指导测试工作有序进行,使实施测试的数据有据可依 确保所实现的功能与客户预期的需求相符合 完善软件不同版本之间的重复性测试 跟踪测试进度,确定测试重点 评估测试结果的度量标准 增强软件的可信任度 分析缺陷的标准。 设计依据 需求说明书 项目测试需求功能点 所属行业的业务知识掌握程度 测试工程师本人的理解程度(个人经验)

用例内容 1 用 例 实 际 内 容用例编号唯一标识。规则“模块名-功能点-编 写人-001,单词或中文首字母。 2模块名称模块名称 3功能点测试的功能点 4用例标题对测试项简短的描述 5用例级别确定用例执行的级别[P0,P1,P2,P3] 6前提条件执行用例时需要的预置条件 7操作步骤执行该动作需要完成的操作,需要明 确输入数据。 8预期结果执行完该动作后程序的表现结果 9 执 行 结 果执行状态用例的执行结果[通过,失败,延后] 10实际结果实际输出的结果 11问题描述执行该用例出现后系统显示的错误 12BUG编号填写bug库中对应此用例的BUG编号13执行人按照该用例执行测试的人员 编写用例原则 系统性:对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关 系;对模块业务流程要说明子系统内部功能、重点功 能以及它们之间的关系 连贯性:对系统业务流程要说明各个子系统之间是如何连接在一起,若需要接口,各子系统之间是否 有正确的接口,若是依靠页面链接,则页面的链接是 否正确;对模块业务流程要说明同级模块以及上下级

相关文档
最新文档