测试用例编写规范说明及模板.docx

1、部门管理文档系列* 公司测试用例编写标准及原则日期日期日期拟制审核批准> 上传内容受损的文件，检查系统怎样处理> 上传不同路径的文件，检查系统怎样处理2.8. 软件环境兼容性测试2.8.1.与操作系统的兼容性操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。而需要 测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操 作系统兼容的检查。手机操作系统包括WAP版及CS版WAP 版：> Android> iPhone OS> Linux> Linux Smartphone OS> Mymobile

2、> Palm OS> RIM OS> Symbian OS> wcbOS> Windows Mobile OSCS版：> iPhone OS> Linux> Linux Smartphone OS> RIM OS> Symbian OS> Windows Mobile OSB / S系统兼容的浏览器为ie6、IE7、IE8、火狐2、火狐3C/S 或 B/S 系统 兼容操作系统 windows XP、windows2000> windows2003、windows7 等等3. 用例设计步骤> 测试需求分析：从软件需求分

3、析文档中，找出待测软件/模块的需求，通过自己的分析、 理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点> 业务流程分析：对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要进 行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备 选流程、数据流向、关键判断条件以及完成该操作的非必要条件> 测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能 测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况> 测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员及其他相关的测试人员> 测

4、试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后， 测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测 试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用 例存在漏洞造成，也需要对测试用例进行完善3.1. 用例评审3.1.1. 评审原因测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影 响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有 必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的 合理化安排等。3.1.2. 评审

5、内容> 用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖> 用例的优先级别是否安排合理> 是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或 场景等> 用例是否有很好的可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否 清晰、正确> 是否己经删除了冗余的测试用例> 是否包含充分的负面测试用例> 是否简洁、复用性强> 是否易于管理3.1.3. 评审过程> 基于项目需求的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查> 在测试用例的设计完成之后进行复审，主要是对测试用例的结构和

6、覆盖率进行评审> 所有测试用例结束后，主要是对测试用例的具体描述是否有很好的可执行性，是否有冗余 用例的存在进行评审3.1.4. 评审人员> 部门评审：测试部全体成员参与的评审> 项目评审：项目组全体测试人员与部分开发人员、需求人员等组成的小组> 公司评审：包括项目经理、需求分析人员、开发人员、测试人员> 客户评审：包括客户方的开发人员和测试人员> 内部评审：全部参与测试的人员3.1.5. 评审方式> 会议评审（包括内部评审及客户评审）。由设计该用例的人员进行讲解，参与会议评审的相 关人员给出意见或建议，并记录评审的意见和建议> 其他类形式。非正

7、式的评审，话聊、主动请教周边同事等3.1.6. 结束标准经评审的用例由用例设计者根据评审的建议或意见进行修改，更新用例，再次发起评审、修改、 更新用例，反复评审后，直至用例达到要求。（反复评审时存在时间问题）4. 用例规范4.1.编写用例规范> 系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它 们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系>连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系 统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程 要说明同级模块以及上下级

8、模块是如何构成一个子系统，其内部功能接口是否连贯> 全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备> 正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据 发生的业务吻合> 符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务 的变化以及当前该业务行业的法律、法规> 可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果4.2.编写用例标准>测试案例编写应该制订统一的模板进行，并约定模板的使用方法；>测试案例编写应当根据项目实际

9、情况编写测试案例编写手册，包括案例编号规则、案例编写 方法、案例编写内容、案例维护等内容；>案例编写应根据手册中约定的编写方法、内容等进行编写；>案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；>案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能 点；>注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。4.3.用例实例说明4.3.1.字段说明序号功能点用例总 数结果Y结果N结果H执行率Y%N%H%编写人执行人备注1登录2首页3账户管理4转帐汇款5网上支付6网上催款总计> 功能点：按照系统一级

10、菜单名称列出整个系统的大功能点，功能点顺序与系统菜单顺序相 符> 结果为Y：表示用例执行通过，软件实现的功能与用例描述相符> 结果为N：用例执行不通过，软件功能与用例描述不相符，软件功能错误> 结果为H：用例暂不执行，现有软件暂不能达到该条用例的执行条件> 编写人：编写该功能点测试用例的人员姓名> 执行人：执行该功能点测试用例的人员姓名> 备注：当此模块无法完成测试，或该模块被删除时，在备注中填写无法完成此功能测试的 原因或不能进行测试的原因4.3.2. 用例说明> Sheet表：每个一级菜单为一个单独的sheet表，每个sheet表中包含此一级菜单下

11、所有二 级菜单及功能点> 二级菜单命名规则：菜单序号+二级菜单名称> 序号编写规则：以手机版本.需求一级菜单号.二级菜单号.用例排序为编号规则>用例步骤1）编写完整的测试用例步骤2）列出必要的前提条件3）列出明确的输入数据4）语言表达清晰明确> 预期输出1）测试结果的可判定性，即测试执行结果的正确性是可判定的，每一个测试用例都应有相应 的期望结果2）测试结果的可再现性，即对同样的测试用例，系统的执行结果应当是相同的> 编写测试用例顺序1）验证整体页面的元素2）验证各个功能点，包括文本框、链接、按钮等（注：按照页面从上而下，从左至右的顺序 验证）3）验证业务流程&g

12、t; 测试用例填写规范1）当验证结果为Y时，需要填写需求编号、测试人和测试日期项2）当验证结果为N时，需要填写问题描述（描述由此用例测试出的BUG）、BUG编号（提交 到缺陷管理工具的BUG编号）、需求编号、测试人和测试日期项3）当验证结果为H时，需要填写测试人、测试日期、需求编号和备注（备注信息填写Hold原因或由于某个BUG影响而无法进行测试）4.4.用例级别划分目的： 保证所设计的用例在实施测试时真正起到指导作用 突出测试的重点，可以有针对性的实施测试对测试用例进行优先级的划分，一般需要从三个方面考虑：P1：确保系统基本功能及主要功能的测试用例P2：确保系统功能的完善方面的测试用例P3：

13、关于用户体验，输入输出的验证以及其他较少使用或辅助功能的测试用例对应的，我们可以对测试用例分为三个级别：高、中、低高（优先执行）：即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据 有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳 定；中（次级执行）：即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及 异常数据的输入作为中等级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件可以 进行发布了；低（最后执行）：即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别 的用例在整个项目的生命周期内不是常常

14、被运行，包括：GUL界面显示、错误信息提示不统一、可 用性、压力和性能测试等。备注：对己有的用例级别说明，包括A正常流程测试、B-异常流程洲试、C-页面元素正常输入 测试、D-页面元素异常输入测试、E-页面元素显示测试，可具体归类如下（仅供参考）：高：A-正常流程测试、C-页面元素正常输入测试中：B-异常流程测试、D-页面元素异常输入测试低：E-页面元素显示测试5. 用例的维护> 删除过时的测试用例 因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例 就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测试用 例删除，应该将要删除的测试用例

15、整行置灰，并将该行的用例计数器清为空；当整个功能 模块需要删除时，则将整个SHEET状态置灰，并将用例计数器清空>修改的测试用例随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就 会根据需求的变化相应的对测试用例进行维护，修改己经不符合目前需求的内容，并在备 注栏中加以说明> 删除冗余的测试用例如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除， 只需留下其中的一个> 增添新的测试用例对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与 之对应的测试用例，需要按照测试用例的设计标准进行增添，增加

16、测试用例时，需要在相 应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明6. 风险分析没有正式需求的测试用例。 用例编写进度跟不上项目进度 用例的评审只是走形式需求变更后未及时通知测试人员测试人员后期加入项目，对需求了解不透彻7. 测试用例模板测试用例根据以下模板进行填写用例ID考勤用例名称门禁权限变更管理流程1测试目的验证门禁权限变更管理流程正常实现预置条件申请人审批人流程环节预设：SQ1-） SPI> SP2 （门禁管理员）步骤操作描述（输入数据说明）期望结果步骤1申请人SQ1登录系统，考勤管理-门禁 管理。门禁权限变更管理，在申请列表 页面点击新增功能进入门禁权限变更申请表

17、的填写页面步骤2申请人SQ1新建一条门禁权限变更申请 信息并提交。1、门禁权限变更申请记录成功提交，系统自 动返回门禁权限变更申请列表页面。2、SQ1申请记录状态为“初始二3、申请人SQ1自助平台的己办事务中产生 SQ1申请记录。4、审批人SP1自助平台的待办事务中产生 SQI申请记录。步骤3申请人SQ1在门禁权限变更申请列表页 面选择该记录，对该申请记录进行撤回操 作。1、系统自动返回门禁权限变更申请列表页 面。2、SQ1申请记录状态为“撤回3、审批人SP1自助平台的待办事务SQ1申请 记录被撤销。步骤4申请人SQ1对撤同的记录在门禁权限变 更申请表页面进行编辑并保存。1、系统自动返回门禁权

18、限变更申请列表。2、SQI申请记录状态为“撤回"。步骤5申请人SQ1对撤回的记录在门禁权限变 更申请表页面进行重新提交。同步骤2结果步骤6审批人SP1登录系统，自助平台-待办 事务，选择待审批的门禁权限变更申请， 点击审批按钮，进入门禁权限变更申请审 批页面，对该申请做批准操作1、SQ1申请记录状态为“传送”。2、SQ1申请记录从审批人SP1自助平台的待 办事务转入己办事务。3、审批人SP2自助平台的待办事务中产生 SQI申请记录。步骤7审批人SP2登录系统，自助平台-待办 事务，选择待审批的门禁权限变更申请，1、SQI申请记录状态为“批准二2、SQ1申请记录从审批人SP2自助平台的

19、待点击审批按钮，进入门禁权限变更申请审批页面，对该申请做批准操作办事务转入己办事务。步骤8申请人SQ1登录系统，自助平台-己办事务，查看SQ1申请记录1、SQ1申请记录状态为“批准”。测试说明测试结果口通过口未通过口免测试测试人测试日期修订历史记录版本日期AMD修订者说明1.0A初稿1.1M（A添加,M.修改,D-删除）1. 引言51.1 背景51.2 目的51.3 适用范围51.4 缩写和术语52. 测试用例52.1. 概念52.2. 用途62.3. 设计依据62.4. 编号规则62.5. 用例内容62.6. 用例设计方法72.6.1. 等价类划分法72.6.2. 边界值分析法82.6.3.

20、 错误推测法82.7. 功能性测试方法82.7.1. 输入非法数据82.7.2. 输入默认值92.7.3. 输入使缓冲区溢出的数据92.7.4. 输出不符合业务规则的无效输出92.7.5. 数据结构溢出92.7.6. 文件内容受损92.8. 软件环境兼容性测试102.8.1. 与操作系统的兼容性103. 用例设计步骤113.1. 用例评审II3.1.1. 评审原因II3.1.2. 评审内容113.1.3. 评审过程123.1.4. 评审人员123.1.5. 评审方式123.1.6. 结束标准124. 用例规范124.1. 编写用例规范124.2. 编写用例标准134.3. 用例实例说明134.

21、3.1. 字段说明134.3.2. 用例说明144.4. 用例级别划分155. 用例的维护156. 风险分析167. 测试用例模板161.引言1.1背景为保证测试用例对需求的覆盖率，即对一个系统从整体功能到单个功能，都尽可能的高的覆盖。 而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作，系统是否都做了处理；测 试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性， 然后再对各功能点的边界范围进行考虑。所以要保证测试用例的设计按照一种合理的结构组织进行, 这样才能够更有效的保证系统所有功能点的覆盖率。1.2目的为测试用例的质量负责，使测试工作能有序、

22、合理化的进行，从而提高实施测试时对所测产品、 系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效 的被管理。1.3适用范围> 本文档适用于测试人员> 本文档适用于x x系统进行测试时的测试案例设计> 本文档适用于X X案例补充时的测试案例1.4缩写和术语无2.测试用例2.1.概念是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了 实施测试而向被测对象提供的组输入、输出数据以及由各种执行条件和期望结果相组合的个特 定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。22用途> 指导测试工作有序进

23、行，使实施测试的数据有据可依> 确保所实现的功能与客户预期的需求相符合> 完善软件不同版本之间的重复性测试> 跟踪测试进度，确定测试重点>评估测试结果的度量标准> 增强软件的可信任度> 分析缺陷的标准2.3. 设计依据> 需求说明书> 项目测试需求功能点> 所属行业的业务知识掌握程度> 测试工程师本人的理解程度（个人经验）2.4. 编号规则> 以XX版本.需求一级菜单号.二级菜单号.用例排序为编号规则，例如：CS.1.I.1> 以各项目制定的规范为依据2.5.用例内容用 例 编 号功 能 点用 例 级 别标 题 概 述前条

24、件用 例 步 骤输 入 数 据预 期 结 果实 际 结 果问 题 描 述执 行 结 果Bug 编 号需 求 编 号用 例 编 写 者测 试 执 行 者执 行 日 期备 注> 用例编号： 唯一标识，与需求编号对应，为多对一关系> 用例编写者：设计用例的人员> 被测对象：要测试的功能点（模块、系统）> 用例标题：对测试项简短的描述> 用例级别： 确定用例执行的级别。参考5.4> 前提条件：执行用例时需要的预置条件>输入条件：执行该动作需要输入的数据> 操作步骤：执行该动作需要完成的操作> 预期结果：执行完该动作后程序的表现结果> 实际结果

25、：实际输出的结果> 问题描述：执行该用例出现后系统显示的错误>验证结果：该测试用例是否执行通过> BUG编号：填写BUGBASE中对应此用例的BUG编号> 需求编号： 唯一标识，与用例编号对应，为一对多关系> 测试执行者：按照该用例执行测试的人员> 测试日期： 执行测试的时间> 备注：对未执行或不能进行执行的用例进行说明2.6.用例设计方法2.6.1.等价类划分法1）概念是一种最典型的黑盒测试方法，它完全不考虑程序的内部结构，而是只根据对程序的要求和说 明进行测试用例的设计。测试人员要求对需求说明书中的各项功能需求进行细致分析，把程序的输 入域划分成若

26、干个部分，然后从每个部分中选取少数代表性数据作为测试用例，经过这种划分后， 每一类的代表性数据在测试中的作用都等价于这-类中的其他值。2）分类> 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的 集合>无效等价类：是指对程序的规格说明来说是不合理的、无意义的输入数据构成的 集合3）步骤> 从需求说明书中找出各个输入条件> 对找出的每个输入条件划分两个或两个以上的等价类4）方法> 在输入条件规定了取值范围或值的个数时，可以确定一个有效等价类和两个无效等价类> 在输入条件规定了输入值的集合或者规定了 “必须如何”的条件情况下，可以确定一个有效等 价类和一个无效等价类> 在输入条件是一个布尔量时，可以确定一个有效等价类和一个无效等价类> 在规定了输入数据的一组值（假定n个），并且程序要求对每一个输入值分别处理的情况下，可确定n个有效等价类和一个无效等价类2.6.2. 边界值分析法是等价类测试的特例，主要考虑等价类的边界条件，在等价类的边缘处选择元素，是指输入和 输出的等价类中那些恰好处在边界，恰好超过边界或恰好在边界以内的数据集合组成的用例。对边界值设计测试用例原则：> 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超出这 个范围边界的值作为测试输入数据>