测试设计编写规范.docx
《测试设计编写规范.docx》由会员分享，可在线阅读，更多相关《测试设计编写规范.docx（12页珍藏版）》请在冰豆网上搜索。
测试设计编写规范
成都布络软件有限公司
测试设计编写规范
李厚宏
2013/4/18
软件测试用例编写规范以及测试设计格式规范
修订记录
*A–增加M–修改D–删除
版本号
Version
日期
Date
作者
Author
A
M
D
变更主要原因描述
BriefDescription
1.0
2013-4-18
李厚宏
A
创建文档
目录
1概述5
1.1目的5
1.2使用范围5
1.3参考资料5
2测试设计格式5
2.1文档说明5
2.2概要5
2.3测试用例6
3测试用例设计原则7
3.1连贯性7
3.2全面性7
3.3正确性7
3.4容错性（健壮性）7
3.5符合正常业务惯例7
3.6仿真性7
3.7直观性8
3.8一致性8
3.9灵活性8
3.10舒适性8
4测试用例设计方法9
4.1用例设计基本方法9
4.2功能测试用例设计方法：
9
4.3性能测试用例设计方法9
4.4兼容性测试用例设计方法10
5测试用例编写规范10
5.1功能编号10
5.2测试用例编号10
5.3前置条件：
11
5.4测试步骤与期望结果：
11
5.5标志位：
11
5.6通过情况：
11
5.7BUG编号:
11
5.8备注:
11
6编写用例注意事项11
6.1功能检查11
6.2面向用户的考虑12
6.3数据处理12
6.3.1输入数据12
6.3.2数据处理13
6.3.3输出结果13
6.4软件流程测试13
1概述
1.1目的
统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。
为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。
1.2使用范围
适用于对产品以及产品业务流程功能测试用例的设计。
1.3参考资料
《测试设计模板》
《配置管理实施规范》
2测试设计格式
测试设计分为概要和测试用例两个分页
2.1文档说明
Ø文档命名规范：
●命名格式：
产品名_完整版本号_文档类型_日期
例：
1）B++即时通讯平台_1.0.0.1234_测试设计
2）B++即时通讯平台_1.0.0.1234_测试报告_20130418
●命名说明
产品完整版本号格式请参阅《配置管理实施规范》
文档类型包括测试设计与测试报告两种，测试报告文档需要在文档名末尾添加测试日期
Ø测试设计修订
测试设计将按照相应版本的项目周期进行修订版本维护，每次版本确立（每次项目正式集成测试前）需要测试小组成员（至少测试主管）参与进行测试设计评审，每次评审针对项目需求对修订测试用例的完整性进行评审。
测试人员可以根据测试用例编写规范在文档中随时进行内容修订，评审通过则确立修订版本并上传禅道相应文档库中以及产品代码文档目录中。
2.2概要
概要分页中包括概述、测试基本信息、测试结果统计、测试总结、测试设计修订记录5部分。
Ø概述
说明该测试设计试用的测试产品以及测试范围
Ø测试基本信息
●测试人员：
执行测试的测试人员姓名
●测试日期：
执行测试的日期，仅包括年月日信息
●测试版本：
测试产品的完整版本号，说明详见《配置管理实施规范》
Ø测试结果统计
●测试用例总数：
统计该设计中总的测试用例数量（自动统计）
●通过：
该轮测试通过的测试用例总数（自动统计）
●未通过：
该轮测试未通过的测试用例总数（自动统计）
●待议：
功能开发未完成的测试用例、规格不确定时设计的测试用例（自动统计）
●通过率：
测试通过用例总数占测试用例总数和待议用例差值的百分比（自动统计）
●通过率_last：
前一版本测试通过率（手动输入）
Ø测试总结
结合上一轮测试情况与本轮测试情况进行测试概要总结，总结内容主要为BUG修复情况、新增功能测试基本情况，前后两轮测试结果的对比综述以及该版本产品评价
Ø测试设计修订记录
记录每个项目迭代测试用例修改内容，概要说明对应的功能模块名称以及变更测试用例数量。
2.3测试用例
测试用例标签页主要包括表头产品名称、测试类型、功能模块信息、测试用例信息3大部分。
功能模块信息包括功能编号、功能名称，测试用例信息包括用例编号、测试步骤、期望结果、标志位、测试结果、备注
Ø产品名称：
完整的产品名，包括产品名、大版本号、小版本号
Ø测试类型：
主要分成功能测试、性能测试、兼容性测试，可根据产品需求进行选择，文档中至少包含功能测试用例内容。
Ø功能模块信息：
包括功能编号以及功能名称
功能编号：
按照功能顺序以1.0、2.0、3.0……进行排序
Ø测试用例信息：
测试用例信息包括测试用例编号、前置条件、测试步骤、期望结果、标志位、通过情况、BUG编号、备注
3
测试用例设计原则
3.1连贯性
Ø对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面或者功能界面链接，链接是否正确；
Ø对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；
3.2全面性
Ø应尽可能覆盖程序的各种路径
Ø应尽可能覆盖系统的各个业务
Ø应考虑存在跨年、跨月的数据
Ø大量数据并发测试的准备
Ø系统中各功能、业务的异常情况
3.3正确性
Ø输入用户实际数据以验证系统是否满足需求规格说明书的需求。
Ø测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。
3.4容错性（健壮性）
程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。
3.5符合正常业务惯例
Ø测试数据应符合用户实际工作业务流程
Ø兼顾各种业务变化的可能
Ø要符合当前业务行业法律，法规。
3.6仿真性
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。
3.7直观性
Ø用户界面是否洁净，不唐突，不拥挤。
Ø界面不应该为用户制造障碍，所需功能或者期待的响应应该明显，并在预期出现的地方。
Ø界面组织和布局是否合理；是否允许用户轻松地从一个功能转到另一个功能，下一步做什么是否有明显提示。
Ø是否在任何时刻都可以决定放弃或者退回、退出。
Ø所有输入都是否得到承认，菜单或者窗口是否深藏不露等等。
Ø测试还将检查是否有多余功能；软件整体或局部是否做得太多；是否有太多特性把工作复杂化了；是否感到信息太庞杂。
Ø帮助系统是否准确，能够正确指导用户完成工作。
3.8一致性
Ø快速键和菜单选项是否合乎标准，例如信息发送快捷键Ctrl+Enter组合键与Enter键是否能够设置后及时成功切换。
Ø整个软件是否使用了相同的术语和命令，特性命名是否一致；例如，新增是否一直叫新增,而不是有时叫增加。
Ø软件是否一直面向同一级别用户。
Ø按钮位置和等价的按键。
具有相似功能的按钮在不同的窗口中位置是否相同，快捷键是否一致，命名是否一样。
3.9灵活性
Ø各种数据状态终止和跳过，都具有容错处理能力。
Ø允许多种数据输入和输出方式；用户希望有多种方法输入数据和查看结果。
例如，在写字板插入文字可用键盘输入、粘贴、从其他文件格式读入、作为对象插入、或者用鼠标从其他程序拖动输入。
Ø用户界面或者功能界面内容是否便于用户查看和显示是否完整。
例如界面缩放时内容无法完整显示时，是否提供滚动条便于用户拖动查看。
3.10舒适性
Ø恰当的软件外观和感觉应该与所做的工作和使用者相符。
Ø错误处理分级处理，并且以恰当的方式呈现给用户。
Ø程序当中，图形按钮要有气泡式提示框。
程序应该在用户执行严重错误的操作之前提出警告，并允许用户恢复由于错误操作导致丢失的数据。
4测试用例设计方法
4.1用例设计基本方法
利用有效的和无效的数据来执行各个测试用例或功能，以核实以下内容：
✧在使用有效数据时得到预期的结果。
✧在使用无效数据时显示相应的错误消息或警告消息。
✧各业务规则都得到了正确的应用。
✧测试业务流程的正确性。
✧模块间集成测试：
主要测试有联系的各个模块之间的逻辑关系
4.2功能测试用例设计方法：
Ø最低用例设计标准
覆盖测试：
遵循语句、判定、条件、组合、路径覆盖
基于需求：
等价划分、边界值、错误猜测、指定行为测试
Ø测试方法简要概括为：
（1）对业务功能进行正常的流程测试。
主要测试功能界面是否能正确跳转，数据是否正确传递；
（2）对业务功能进行非正常的流程测试；
（3）对所有界面进行FE[满空]测试；
（4）对文本框进行特殊字符测试；
（5）根据每个界面的界面规范进行测试；
（6）进行小范围的集成测试；
（7）网络相关测试。
主要测试评标过程中不同的网络状况下业务处理能力，如即时聊天系统在、离线状态下聊天。
4.3性能测试用例设计方法
Ø负载测试
将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
Ø强度测试
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
Ø数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。
做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，统计计算相关页面的调用时间。
Ø基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
通过已知友方类似软件系统的性能数据，与己方软件系统性能测试数据比较，得出双方性能差异，便于改进己方软件系统。
Ø竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
比如：
一台机器上即安装己方软件系统，又安友方类似软件系统。
当CPU占有率下降后，看看是否能够强过用友方软件产品，而且自己的系统能够正常运行。
4.4兼容性测试用例设计方法
5测试用例编写规范
5.1功能编号
功能编号直接以1.0、2.0、3.0为规则
5.2测试用例编号
以功能模块编号为母编号，子编号根据操作步骤而定，如功能编号为1.0的第一个操作步骤的用例编号为1.1，功能编号为2.0的第三个操作步骤为2.3，以此类推。
5.3前置条件：
可选填写项，系统权限配置或前、后台配置描述（所有进行操作的前提条件）
5.4测试步骤与期望结果：
Ø基本的功能测试测试步骤与期望结果为一对一方式，每个详细的操作步骤对应一个期望结果，如每一次点击操作，对应一个点击后将会表现的期望结果。
组合测试用例设计时，组合步骤需要分点描述，每个步骤组合对应一个期望结果。
Ø测试用例根绝有序的测试操作步骤定义，尽可能避免不同功能模块之间的来回切换操作，功能模块间的集成组合测试除外。
Ø测试用例中包含其他测试用例的完整步骤，该步骤可用测试用例编号代替并且添加该步骤的超链接，便于测试用例间的切换。
Ø期望结果与界面表现有关则尽可能以简单的描述界面信息，如有提示语，需要在期望结果中写明完整的提示信息。
5.5标志位：
标志位主要包括：
完整性、正确性、连贯性、UI测试、直观性、一致性、灵活性、容错性、舒适性
5.6通过情况：
通过情况分为√（通过）、×（不通过）、-（待议）3种，在测试设计中以下框形式提供选择。
5.7BUG编号:
对于未测试通过的测试用例需要写明该用例发现的BUG对应禅道上的BUG编号。
5.8备注:
主要用于描述测试结果与期望结果的差异，可用于标注BUG跟踪情况、测试疑问、用例状态备注等信息。
6编写用例注意事项
6.1功能检查
1、功能是否齐全，例如：
增加、删除、修改，查询条件是否合理，用户使用是否方便
2、功能是否多余
3、功能是否可以合并
4、功能是否可以再细分
5、软件流程与实际业务流程是否一致
6、软件流程能否顺利完成
7、各个操作之间的逻辑关系是否清晰
8、各个流程数据传递是否正确
9、模块功能是否与需求分析及概要设计相符
10、批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数据量较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据字段的有序切换
6.2面向用户的考虑
1、操作方便性，如：
按键次数是否最少，并不以开发实现技术限制为限制，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理建议
2、易用性，面对用户的操作是否简单易学
3、智能化考虑
4、提示信息是否模糊不清或有误导作用。
错误信息是否有用户语言风格的出错后续处理建议提示
5、要求用户进行的操作是否多余，能否由系统替代。
系统升级后，用户能否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓存等动作
6、能否记忆操作的初始环境，无需用户每次都进行初始化设置
7、是否不经确认就对系统或数据进行重大修改
8、能否及时反映或显示用户操作结果
9、操作是否符合用户习惯，比如：
热键
10、各种选项的可用及禁用是否及时合理
11、某些相似的操作能否做成通用模块
6.3数据处理
6.3.1输入数据
1.边界值
2.大于边界值
3.小于边界值
4.最大个数
5.最大个数加1
6.最小个数
7.最小个数减1
8.空值、空表
9.极限值
10.0值
11.负数
12.非法字符
13.日期、时间控制
14.跨年度数据
15.数据格式
16.数据之间的关联性、逻辑性，数据范围、格式限制是否合乎日常情理，如年龄不应为负数，身份证位数必须为15或18位且与性别严格相关联，与生日可以有区别（考虑到阴历阳历的问题）但不相同时给予提示，私人电话号码的长度且国内电话只能有数字及短横线标识区号等
6.3.2数据处理
1.处理速度
2.处理能力
3.数据处理正确率
4.计算方式及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题
6.3.3输出结果
1.正确率
2.输出格式
3.预期结果
4.实际结果，金额数字的可能要验证小写大写的一致性，大写可能要测试多种金额的大写，包括没有整数的情况下，没有小数的情况下，带整数和小数的情况下……
6.4软件流程测试
1.反流程操作
2.反逻辑操作
3.重复操作
4.反业务流程操作
5.违反流程的打乱流程的不按操作手册的乱操作
升级会员 