QA-完整的测试用例设计规范

文档审批信息序号序号角色审批人签字审批日期备注2郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范3郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范文档记录变化状态C版本编号V1.0撰写/变更人变化状态C版本编号V1.0撰写/变更人XXX批准人批准日期创建测试部相关流程文档4郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范 42适用范围 43术语解释 44测试用例设计 44.1测试用例作用 44.2设计思路 44.2.1完整项目型用例设计 5422集成产品型用例设计 54.3编写规范 54.3.1测试用例设计范围和原则 54.3.2测试用例设计方法 64.3.3功能和业务用例设计规范 74.3.4角色模块功能点用例设计规范 74.3.5业务用例设计规范 85结合工具使用 85.1测试用例管理（直接建立测试需求和测试项）5.2测试执行管理 5.3缺陷管理 5郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。本规范适用于［XXX］系统测试用例的管理和缺陷的管理。系统测试：系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正测试用例(TestCase):是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。需求用例驱动测试用例设计：通过需求文档来推动整个测试用例的设计进行，但需求测试驱动测试用例的设计并不只是单纯的用例设计工作，而是把需求分析，测试用例的设计的量化的过程。4测试用例设计便于测试经理检查测试人员对系统的理解程度。便于测试人员和开发人员就测试内容和范围达成一致，利于交流。指导测试人员的执行过程，使测试过程有序不重复。方便测试经理把握测试的实际进度，做到心中有数。便于测试结果分析。系统测试的目的在于与系统的需求定义做比较，发现软件与系统需求定义不符合或相矛盾的地方。所以编写系统测试用例前，测试人员要根据需求规格说明书和测试需求整理文档，详细理解用户的真正需求，并对软件所实现的业务目标准确理解。研发中心软件产品根据开发形式大致有完整项目型和集成产品型之分，所以我们针对不同性质的产品要采用不同的用例设计思路。软件产品的定义由研发中心高层经理决定。6郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范本文中涉及的设计思路包含两种，以软件功能模块划分进行设计和需求用例驱动设计方法。 有不同的测试用例设计方法】这种类型的产品是一个完整的项目产品，可直接适应于用户，所以产品经理(后续角色)或测试人员在这类产品的需求编写阶段就要介入，对系统需求进行全面的了解和相关知识的学习。这种类型的产品采用以需求用例驱动的设计思路。(1)以产品需求为依据，产品经理或测试人员用面向对象的思想对产品需求进行二次加工，提炼加工出测试需求文档。(2)针对提炼出的测试需求文档，产品经理或测试人员要和开发人员进行讨论确认。确认之后进行步骤3,否则重新执行步骤1。(3)根据提炼出的测试需求文档进行系统测试用例设计，按业务流程和角色模块功能设计测试用(4)测试用例设计完成后，要进行用例评审。评审不通过时，重新执行步骤3.4。这种类型的产品不是直接面向用户的，是一个框架体系结构。这种产品采用业务流程和功能模块划分的方法进行设计。提取出业务用例。(2)在业务用例的基础之上提取界面元素和各功能业务规则中的功能点。(3)根据1和2中提取的功能点和基本业务流程设计系统测试用例。(4)测试用例设计完成后，要进行用例评审。评审不通过时，重新执行步骤1.2.3.4o本部分内容作为具体编写系统测试用例的依据。测试用例按安装配置测试、业务流程测试、角色模块功能点测试(或模块功能点测试)、产品接口测试、数据权限测试、故障转移与恢复、用户界面测试、性能测试进行测试范围划分和管理，测试用例按基本流和异常流进行设计，基本流和异常流中每一个测试点标题明确测试目的，每个测试集(业务目标或功能点)开始明确测试范围和前置条件(可选)，每个测试点前置条件，紧跟测试标题，测试7郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范目录和测试集按测试优先级进行编号排序，基本流和异常流中的测试点也按测试优先级进行编号排序，测试用例管理如下图所示。-41xn茶筑测试用例亠-T01安裝配置测试匸.二罚曲鞄程测试:円□珀畸崑块功能测试叮□测产用接口测试七二T05塾据覩跟船UE十T06議障转移与恢复绿色字体显示)。依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清业务目标。(3)角色模块功能点测试(或模块功能点)依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清角色模块功能点。产品或者各模块之间的接口测试，供第三方调用的接口测试等。角色权限、不同管辖范围数据权限，交叉管理数据权限测试等。⑺性能测试大数据量查询测试，并发测试，压力测试，稳定性测试等。(8)故障转移与恢复正常执行操作过程中服务器、客户端异常断电，异常关闭测试等。等价类划分。把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。边界值分析。通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边错误推测设计方法。该方法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用8郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范因果图方法。该方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果 正交试验设计法。该方法是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。功能图法。该方法是由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个表示的逻辑功能。本部分内容主要是用来避免功能测试用例中过多包含业务用例的现象。这种现象会造成用例设计者工作量得增大，执行者重复执行用例的后果。我们以研发中心测试管理工具TestDirestor进行系统测试用例的管理，所以下面的规范结合TestDirestor中项目进行说明。1、依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清角色模块功能点，每个功能点设计基本流和异常流测试用例，基本流和异常流测试用例包含测试点，测试点标题明确测试目的，测试点按测试优先级编号排序试点目的明确，可以不设计操作步骤）（高优先级在前），每个测试点按角色操作设计测试步骤,突出操作（用绿色字体显示），下图为某服务平台角色模块功±1二I也用F＞晉瞠系*!E"DI应审背样理i+3加应用體店±Jw泵蜒営理&一^点滸加应用类卸;駅肖旺上传齟片尢b规定苗匿内二借iSA蜿須反面不林改社5.察加与茹数祐村间恨存4.筍入项允许氏度之外械」苴弓正确数搭富存9」111111IIII」111111IIII”TQ-ilaP审却业菸丽^怦T（1個匸登冕蔓不盏WFM魏爾甩只证M皆瞬交轴發：；｛TK衮址信宜苣理:It二蚀：靈谕校跟萱理V障服比独車宜.帝曲尊3J105数培奴压齟t=mo惑障转程2、考虑全面。针对测试的功能点，除了编写正常流验证功能点的正常功能外，还有考虑功能点的容错能力，依赖性等，即异常流。依赖性测试点前置条件准备数据或验证结果超过两个模块应归入业务目标测试用例中，功能点部分正常流测试用例业务流程用例已验证过可标注说明，每个测试点测试目的明确，避免测试点之间的套用的情况发生。1、依据产品需求规格说明书、产品测试需求整理文档、沟通测试需求理清业务目标，每个业务目标设计基本流和异常流测试用例，基本流和异常流测试用例包含测试点，测试点标题明确测试目的，测试点按测试优先级编号排序（高优先级在前），每个测试点按角色操作设计测试步骤，突出操作（用绿色字体显示），下图为某系统业务流程测试用例。愷日2项4czj^dep20A^AIHUIJ.1t#LL_Lite2.歸咀阳幕要苗诙旺项朮研胡£eJI^COl«Aidillifl_■!D女加::1t#h_£eQMJ工于机鬥雾个于祈号人舄伍息娟轲】.御$罰处丁写F中谏工齢人员信息「潟有管谱厠稱曽理员心信月編宦页面嗝—》人員信息歸5成功—湛皱甘强貝人员信息宦範面彌—〉人员信县帝歲功黑占谜管珪员希辑县、市级_v员&.笔刼岂理员歸磊若圾丸县2、考虑全面。每个业务目标清晰,做到有经验的测试人员看到业务目标就能想到一部分相应的测试点，测试点目的明确，步骤清晰，步骤如出现分枝，要拆分为两个测试点。5结合工具使用研发中心使用测试管理工具TestDirestor8.0对测试项目的测试需求整理、测试用例设计、执行和缺陷提交等一系列活动进行管理，那么下面简单给出在TD中建立测试项目的流程实例供大家参考。进行下面操作的前提是管理员admin已建好测试项目并设置了项目所需用户和权限。5.1测试用例管理（直接建立测试需求和测试项）1、测试人员登陆TD后进入“TESTPLAN”模块，如图所示郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范MQUlilllirrS；■*^T1ST|3IBWECTS 计划视阴分析+*Una宅七辽tied.FQTDl安薪配置测试±1□丁02业务痂程测试&SrTO3樫快珈san试［xn+ZT01系筑登录DOJ*■-T02董毓信息管理-匸T03棊本信息管理!*2)T0&日志査诲管理!*2)T0&日志査诲管理T07家统扩展功能T09个人基本噪作壬JT04产品接口测试土□丁尿故障转移与恢复S二IT0B性能测试【说明】：该视图是以“显示为测试计划树”进行查看的。2、点击左上角的“计划”，如图1:|跟踪更改r后续标志IftEUUIl项口.ftEUUIlr野分析r墨示为蔥?£计划树3口讪妄装配置测试+二)T02业务師程测试±1_T茁模摸功能测试3-n*T04产品接口测试+JT此数坊柳艮验证-故瞠转移与恢复自二丁“用户界面选择“新建文件夹”或者图2所示工具栏中简易图标创建测试需求。选择“新建测试”或者图所示工具栏中简易图标可以为已建好的测试需求建立测试项。过粗会导致测试用例步骤增多，部分预期结果繁多，影响测试执行人员的积极性。测试需求以业务流郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范程和角色模块进行划分，测试项以业务目标和功能点进行划分。测试需求编号命名规范。为了使测试需求显示有条理性，测试人员需要为每个需求编号，具体的测试目录以‘大写T+具体编号’命名；测试业务目标或功能点（非目录）以‘大写F+具体编号'编号命名，按优先级进行编号，优先级最高的为01,然后按优先级依次编号。若不明白，参考下显乔为測词计划科R丑?Vnattachedffl-DHH安獗配置测试T诧业券就握測试J-MTDO®#流程|iFD5皐位竟更基本凉:血FOfi煤塢挪艮雷正L卿管理员交更首理匚-T03複块功能测说D［円也Jj701系经登录旳］田J703基丰信息管理王□m毛営容i二105藝端稅覘莒理©-□TOG日蛊晝询管理+二TOT系筑扩展功能审口TOB个人药本撫作图3测试需求和测试项编号展示5、需求确认。测试人员创建测试需求和测试项之后，测试经理或项目经理需要确认已建测试需求和测试项的完整性和正确性。如果测试人员是根据测试计划创建的测试需求项或测试项，并且测试计划已经过评审，测试经理或项目经理可以不进行确认，只需测试项和测试计划中所列需求项的一致性即可。QA检查这些测试需求项、6、测试人员对业务目标或功能点设计测试点，具体设计格式参考下图：测试范围、前置条件、说明、正常流、异常流不必都使用。郑州市便宜商电子科技有限公司测垃范圉[XXX系统测试用例设计规范1ATF卡〔优先逻高）忧先细耐2审批方式2.1不瞎級审批初憫捌2緡审级别担优先级高〉2•疇级审批初始緬I」2强审级别担忧先级低〉3.警员一沖手机和多亍手机号煖卡审批前置爲件1.具有经过初始化的管理让时2.具有经过初始化的用戶TF卡或凶纾1>逹省级管理员掘程（市级、县级管理员的建立相似）一耀纽管理员聲录进行垂埼配置—>4鞫管理员新建耒歸角色（管理角色和普通警员角色）—》单住信息管理页南耘丽眷级单位f第一次逹的单住是省级单拉「也可以謐加已存在单位的下级单位）一从员信息页面添加省级普员-炮始人员审核贡面审核邇过—粽轨账号管理页面箫如省级誇理员账号卿定警员一瘠诵角色贞面新建角色并分配终请权限（公芒甬色和昔通轴色•只有起级营理员可以建公共常色』令芒弟色下级管程员新連角色时貝能分配上级昔理员比许讎承的权跟）在终端杈限初始化页面左省级管理员卿定的警员籾躺化琏瑞腰限z肓遇警员忝咖审批、发轧认证、注梢新程（备顋音邇警员相似）一》具育管辖权眼的营理员登录-》人昂信息管理页面麝加警员—》具看管错权跟的苜理员初始人员审檢页面审孩谨妊一淇诵权關初始化页面対辔员初始化第蒔祝限一沖请发卡贡面申谖類卡-洛于级剧蛋卡审批页面郡审把通过一运卡管理页面写卡WTs严三H=linF-1Ui~^T-kr沁KQ^I=jViEHr十TOSrnrh-^、7、测试点按执行优先级进行编号，步骤名称命名规范TD中默认的步骤名称为‘stepx'但这不利于测试点的展现，所以我们采用自命名形式。步骤命名以‘序号+、+描述’命名。序号，就是1、2、3……阿拉伯数字。执行步骤2;【说明】：如果测试步骤或其中的数据不易表达，试数据截图来帮助表达。可以借助测试步骤中的附件功能，上传步骤或测郑州市便宜商电子科技有限公司[XXX系统测试用例设计规范11、iffi冃:邸程-胡能甘砂血酌1卜炭租1百恻诅J话歩卜炭费暑杆2：壮直换启•jfl.£LMJ菠轴”U图4带附件的测试用例预期结果描述规范&部分项目开发和测试周期比较紧，不适合采用7中的步骤规范。针对这类项目，可以简化步骤规范。简化后的规范如下：步骤名称以’详细信息’中的每条测试点命名。【说明】：为保证测试进度，这部分内容暂时不写但是测试后期有时间了要进行补充。畐frl厂|和r冈工用窗般JjrasS通哥户■h□TORf限猛■启审口*TistJkn—斂正确|as