测试用例编写规范Word下载.docx
《测试用例编写规范Word下载.docx》由会员分享，可在线阅读，更多相关《测试用例编写规范Word下载.docx（11页珍藏版）》请在冰点文库上搜索。
测试用例设计首先要明确该系统存在多少功能点，要通过各种常用的测试方法来保证用例的完整性，然后再对各功能点的边界范围进行考虑。
所以要保证测试用例的设计按照一种合理的结构组织进行，这样才能够更有效的保证系统所有功能点的覆盖率。
2.目的
为测试用例的质量负责，使测试工作能有序、合理化的进行，从而提高实施测试时对所测产品、系统或者模块的测试质量，也是作为各测试人员在设计用例时的一种规范，使之设计的用例能有效的被管理。
3.概念
是指为了实施测试而编写的一组有规范性、有据可依的输入数据与输出数据的组合，也指为了实施测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合，以便测试某个程序路径或者来核实是否满足某个特定的需求。
4.适用范围
●本文档适用于测试人员
●本文档适用于系统进行测试时的测试案例设计
●本文档适用于案例补充时的测试案例
用例规范
用途
●指导测试工作有序进行，使实施测试的数据有据可依
●确保所实现的功能与客户预期的需求相符合
●完善软件不同版本之间的重复性测试
●跟踪测试进度，确定测试重点
●评估测试结果的度量标准
●增强软件的可信任度
●分析缺陷的标准。
设计依据
●需求说明书
●项目测试需求功能点
●所属行业的业务知识掌握程度
●测试工程师本人的理解程度（个人经验）
用例内容
1
用例实际内容
用例编号
唯一标识。
规则“模块名-功能点-编写人-001，单词或中文首字母。
2
模块名称
3
功能点
测试的功能点
4
用例标题
对测试项简短的描述
5
用例级别
确定用例执行的级别[P0,P1,P2,P3]
6
前提条件
执行用例时需要的预置条件
7
操作步骤
执行该动作需要完成的操作，需要明确输入数据。
8
预期结果
执行完该动作后程序的表现结果
9
执行结果
执行状态
用例的执行结果[通过，失败，延后]
10
实际结果
实际输出的结果
11
问题描述
执行该用例出现后系统显示的错误
12
BUG编号
填写bug库中对应此用例的BUG编号
13
执行人
按照该用例执行测试的人员
编写用例原则
●系统性：
对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；
对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系
●连贯性：
对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；
对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯
●全面性：
应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备
●正确性：
输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合
●符合正常业务规则：
测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规、人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；
不允许出现与知名人士、小说中人物名等雷同情况。
●可操作性：
测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果
编写用例标准
●测试案例编写应该制订统一的模板进行，并约定模板的使用方法；
●测试案例编写应当根据项目实际情况编写测试案例编写手册，包括案例编号规则、案例编写方法、案例编写内容、案例维护等内容；
●案例编写应根据手册中约定的编写方法、内容等进行编写；
●案例编写要步骤明确，输入输出要素清晰，并且与需求和缺陷相对应；
●案例编写应严格根据需求规格说明书及测试需求功能分析点进行，要求覆盖全部需求功能点；
●注重案例的可复用性，即在以后相似系统的测试过程中可以重复使用，减少测试设计工作量。
用例设计步骤
测试需求分析：
从软件需求分析文档中，找出待测软件/模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。
业务流程分析：
对所在行业的业务知识要熟悉，然后对被测软件/模块的业务流程要进行全盘的整理出来（可画简单的流程图作为参考），主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件。
测试用例设计：
测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑边界、异常等情况。
测试用例评审：
由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他相关的测试人员。
测试用例完善：
测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；
在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；
在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善；
用例级别划分
P0：
确保系统基本功能及主要功能的测试用例
P1：
确保系统功能的完善方面的测试用例
P2：
关于用户体验，输入输出的验证；
较少使用或辅助功能的测试用例。
P0（优先执行）：
即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；
若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定；
P1（次级执行）：
即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例；
若该级别的测试用例完全执行通过，则表示该软件可以进行发布了；
P2（最后执行）：
即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：
GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。
备注：
对已有的用例级别说明，包括A-正常流程测试、B-异常流程测试、C-页面元素正常输入测试、D-页面元素异常输入测试、E-页面元素显示测试，可具体归类如下（仅供参考）：
A-正常流程测试、C-页面元素正常输入测试
B-异常流程测试、D-页面元素异常输入测试
E-页面元素显示测试
用例的维护
删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能够将整行的测试用例删除，应该将要删除的测试用例整行置灰，并将该行的用例计数器清为空；
当整个功能模块需要删除时，则将整个SHEET状态置灰，并将用例计数器清空
修改的测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明
删除冗余的测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个
增添新的测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明
用例设计方法
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；
基本目标是：
设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
等价划分：
将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
边界值分析法：
确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
场景法：
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
基本流：
是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：
一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；
（各种错误情况）
因果图：
利用图解法分析输入的各种组合情况，设计测试用例，检查程序输入条件的各种组合情况。
正交表：
在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。
正确性测试：
输入用户实际数据以验证系统是满足需求规格说明书的要求；
测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
容错性（健壮性）测试：
程序能够接收正确数据输入并且产生正确（预期）的输出；
输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。
把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
完整（安全）性测试：
对XX的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
接口间测试：
测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
数据库测试：
依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
压力测试：
输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行，进行测试。
错误推测：
主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
效率：
完成预定的功能，系统的运行时间（主要是针对数据库而言）。
可理解（操作）性：
理解和使用该系统的难易程度（界面友好性）。
可移植性：
在不同操作系统及硬件配置情况下的运行性。
回归测试：
按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。
比较测试：
将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。
兼容性测试：
操作系统的兼容性测试内容不仅包括软件的安装，还需对关键流程和功能点进行检查。
而需要测试哪些操作系统的兼容性，首先取决于软件用户文档上对用户的承诺，其次就需要对一些常用操作系统兼容的检查
历史版本兼容性测试：
某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。
需要不同版本进行测试。
用例评审
评审原因
测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。
评审内容
用例设计的结构安排是否清晰合理，是否高效的需求进行覆盖用例的优先级别是否安排合理
是否覆盖了测试需求的所有功能点，包括需求中的业务规则、所有用户可能使用的流程或场景等
用例是否有很好的可执行性。
例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确
是否已经删除了冗余的测试用例
是否包含充分的负面测试用例是否简洁、复用性强、是否易于管理
评审过程
基于项目需求的测试计划完成之后，进行初审，主要是对测试范围和测试要点进行审查在测试用例的设计完成之后进行复审，主要是对测试用例的结构和覆盖率进行评审所有测试用例结束后，主要是对测试用例的具体描述是否有很好的可执行性，是否有冗余用例的存在进行评审
评审人员
部门评审：
测试部全体成员参与的评审
项目评审：
项目组全体测试人员与部分开发人员、产品人员等组成的小组
内部评审：
全部参与测试的人员
评审方式
会议评审（包括内部评审及客户评审）。
由设计该用例的人员进行讲解，参与会议评审的相关人员给出意见或建议，并记录评审的意见和建议
邮件评审邮件形式发给参与评审的相关人员，然后以邮件的形式把评审意见反馈给评审发起人。
结束标准
经评审的用例由用例设计者根据评审的建议或意见进行修改，更新用例，再次发起评审、修改、更新用例，反复评审后，直至用例达到要求。
（反复评审时存在时间问题）
用例执行
1、建立测试计划
2、建立对应的版本
3、添加测试用例到对应的测试计划中
4、分派测试用例给制定的测试人员
5、逐条执行测试用例，并及时更改用例状态，通过时，标记通过，当用例执行失败时，编写缺陷报告。
6、回归测试，阻塞和失败用例重新执行后，及时更改用例状态。
风险分析
●没有正式需求的测试用例。
●用例编写进度跟不上项目进度
●用例的评审只是走形式
●需求变更后未及时通知测试人员
●测试人员后期加入项目，对需求了解不透彻
●执行用例不彻
●
升级会员 