测试设计编写规范.docx

1、测试设计编写规范成都布络软件有限公司测试设计编写规范李厚宏2013/4/18软件测试用例编写规范以及测试设计格式规范修订记录 *A 增加 M 修改 D 删除版本号Version日期Date作者AuthorAMD变更主要原因描述Brief Description1.02013-4-18李厚宏A创建文档目录1 概述 51.1 目的 51.2 使用范围 51.3 参考资料 52 测试设计格式 52.1 文档说明 52.2 概要 52.3 测试用例 63 测试用例设计原则 73.1 连贯性 73.2 全面性 73.3 正确性 73.4 容错性（健壮性） 73.5 符合正常业务惯例 73.6 仿真性 7

2、3.7 直观性 83.8 一致性 83.9 灵活性 83.10 舒适性 84 测试用例设计方法 94.1 用例设计基本方法 94.2 功能测试用例设计方法： 94.3 性能测试用例设计方法 94.4 兼容性测试用例设计方法 105 测试用例编写规范 105.1 功能编号 105.2 测试用例编号 105.3 前置条件： 115.4 测试步骤与期望结果： 115.5 标志位： 115.6 通过情况： 115.7 BUG编号: 115.8 备注: 116 编写用例注意事项 116.1 功能检查 116.2 面向用户的考虑 126.3 数据处理 126.3.1 输入数据 126.3.2 数据处理 1

3、36.3.3 输出结果 136.4 软件流程测试 131 概述1.1 目的统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。1.2 使用范围适用于对产品以及产品业务流程功能测试用例的设计。1.3 参考资料测试设计模板配置管理实施规范2 测试设计格式测试设计分为概要和测试用例两个分页2.1 文档说明 文档命名规范： 命名格式：产品名_完整版本号_文档类型_日期例：1) B+即时通讯平台_1.0.0.1234_测试设计2) B+即时通讯平台_1.0.0.1234_测试报告

4、_20130418 命名说明产品完整版本号格式请参阅配置管理实施规范文档类型包括测试设计与测试报告两种，测试报告文档需要在文档名末尾添加测试日期 测试设计修订测试设计将按照相应版本的项目周期进行修订版本维护，每次版本确立（每次项目正式集成测试前）需要测试小组成员（至少测试主管）参与进行测试设计评审，每次评审针对项目需求对修订测试用例的完整性进行评审。测试人员可以根据测试用例编写规范在文档中随时进行内容修订，评审通过则确立修订版本并上传禅道相应文档库中以及产品代码文档目录中。2.2 概要概要分页中包括概述、测试基本信息、测试结果统计、测试总结、测试设计修订记录5部分。 概述说明该测试设计试用的测

5、试产品以及测试范围 测试基本信息 测试人员：执行测试的测试人员姓名 测试日期：执行测试的日期，仅包括年月日信息 测试版本：测试产品的完整版本号，说明详见配置管理实施规范 测试结果统计 测试用例总数：统计该设计中总的测试用例数量（自动统计） 通过：该轮测试通过的测试用例总数（自动统计） 未通过：该轮测试未通过的测试用例总数（自动统计） 待议：功能开发未完成的测试用例、规格不确定时设计的测试用例（自动统计） 通过率：测试通过用例总数占 测试用例总数和待议用例差值 的百分比（自动统计） 通过率_last：前一版本测试通过率（手动输入） 测试总结结合上一轮测试情况与本轮测试情况进行测试概要总结，总结内

6、容主要为BUG修复情况、新增功能测试基本情况，前后两轮测试结果的对比综述以及该版本产品评价 测试设计修订记录记录每个项目迭代测试用例修改内容，概要说明对应的功能模块名称以及变更测试用例数量。2.3 测试用例测试用例标签页主要包括表头产品名称、测试类型、功能模块信息、测试用例信息3大部分。功能模块信息包括功能编号、功能名称，测试用例信息包括用例编号、测试步骤、期望结果、标志位、测试结果、备注 产品名称：完整的产品名，包括产品名、大版本号、小版本号 测试类型：主要分成 功能测试、性能测试、兼容性测试，可根据产品需求进行选择，文档中至少包含功能测试用例内容。 功能模块信息：包括功能编号以及功能名称功

7、能编号：按照功能顺序以1.0、2.0、3.0进行排序 测试用例信息：测试用例信息包括测试用例编号、前置条件、测试步骤、期望结果、标志位、通过情况、BUG编号、备注3 测试用例设计原则3.1 连贯性 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面或者功能界面链接，链接是否正确； 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；3.2 全面性 应尽可能覆盖程序的各种路径 应尽可能覆盖系统的各个业务 应考虑存在跨年、跨月的数据 大量数据并发测试的准备 系统中各功能、业务的异常情况3.3 正确

8、性 输入用户实际数据以验证系统是否满足需求规格说明书的需求。 测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。3.4 容错性（健壮性）程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。3.5 符合正常业务惯例 测试数据应符合用户实际工作业务流程 兼顾各种业务变化的可能 要符合当前业务行业法律，法规。3.6 仿真性人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。3.7 直观性 用户界面是否洁净，不唐突，不拥挤。 界面不应该为用户制造障碍，所需功能或者期待的响应应该明显，并在预期出现的地

9、方。 界面组织和布局是否合理；是否允许用户轻松地从一个功能转到另一个功能，下一步做什么是否有明显提示。 是否在任何时刻都可以决定放弃或者退回、退出。 所有输入都是否得到承认，菜单或者窗口是否深藏不露等等。 测试还将检查是否有多余功能；软件整体或局部是否做得太多；是否有太多特性把工作复杂化了；是否感到信息太庞杂。 帮助系统是否准确，能够正确指导用户完成工作。3.8 一致性 快速键和菜单选项是否合乎标准，例如信息发送快捷键Ctrl+Enter组合键与Enter 键是否能够设置后及时成功切换。 整个软件是否使用了相同的术语和命令，特性命名是否一致；例如， 新增是否一直叫新增,而不是有时叫增加。 软件

10、是否一直面向同一级别用户。 按钮位置和等价的按键。具有相似功能的按钮在不同的窗口中位置是否相同，快捷键是否一致，命名是否一样。3.9 灵活性 各种数据状态终止和跳过，都具有容错处理能力。 允许多种数据输入和输出方式；用户希望有多种方法输入数据和查看结果。例如，在写字板插入文字可用键盘输入、粘贴、从其他文件格式读入、作为对象插入、或者用鼠标从其他程序拖动输入。 用户界面或者功能界面内容是否便于用户查看和显示是否完整。例如界面缩放时内容无法完整显示时，是否提供滚动条便于用户拖动查看。3.10 舒适性 恰当的软件外观和感觉应该与所做的工作和使用者相符。 错误处理分级处理，并且以恰当的方式呈现给用户。

11、 程序当中，图形按钮要有气泡式提示框。程序应该在用户执行严重错误的操作之前提出警告，并允许用户恢复由于错误操作导致丢失的数据。4 测试用例设计方法4.1 用例设计基本方法利用有效的和无效的数据来执行各个测试用例或功能，以核实以下内容： 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用。 测试业务流程的正确性。 模块间集成测试：主要测试有联系的各个模块之间的逻辑关系4.2 功能测试用例设计方法： 最低用例设计标准覆盖测试：遵循语句、判定、条件、组合、路径覆盖基于需求：等价划分、边界值、错误猜测、指定行为测试 测试方法简要概括为：(1)

12、 对业务功能进行正常的流程测试。主要测试功能界面是否能正确跳转，数据是否正确传递；(2) 对业务功能进行非正常的流程测试；(3) 对所有界面进行FE满空测试；(4) 对文本框进行特殊字符测试；(5) 根据每个界面的界面规范进行测试；(6) 进行小范围的集成测试；(7) 网络相关测试。主要测试评标过程中不同的网络状况下业务处理能力，如即时聊天系统在、离线状态下聊天。4.3 性能测试用例设计方法 负载测试将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评

13、估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 强度测试实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 数据库容量测试数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果

14、测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，统计计算相关页面的调用时间。 基准测试基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。通过已知友方类似软件系统的性能数据，与己方软件系统性能测试数据比较，得出双方性能差异，便于改进己方软件系统。 竞争测试软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装己方软件系统，又安友方类似软件系统。当CPU占有率下降后，看看是否

15、能够强过用友方软件产品，而且自己的系统能够正常运行。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 测试步骤与期望结果： 基本的功能测试测试步骤与期望结果为一对一方式，每个详细的操作步骤对应一个期望结果，如每一次点击操作，对应一个点击后将会表现的期望结果。组合测试用例设计

16、时，组合步骤需要分点描述，每个步骤组合对应一个 期望结果。 测试用例根绝有序的测试操作步骤定义，尽可能避免不同功能模块之间的来回切换操作，功能模块间的集成组合测试除外。 测试用例中包含其他测试用例的完整步骤，该步骤可用测试用例编号代替并且添加该步骤的超链接，便于测试用例间的切换。 期望结果与界面表现有关则尽可能以简单的描述界面信息，如有提示语，需要在期望结果中写明完整的提示信息。5.5 标志位：标志位主要包括：完整性、正确性、连贯性、UI测试、直观性、一致性、灵活性、容错性、舒适性5.6 通过情况：通过情况分为（通过）、（不通过）、-（待议）3种，在测试设计中以下框形式提供选择。5.7 BUG

17、编号:对于未测试通过的测试用例需要写明该用例发现的BUG对应禅道上的BUG编号。5.8 备注:主要用于描述测试结果与期望结果的差异，可用于标注BUG跟踪情况、测试疑问、用例状态备注等信息。6 编写用例注意事项6.1 功能检查1 、功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使用是否方便2 、功能是否多余3 、功能是否可以合并4 、功能是否可以再细分5 、软件流程与实际业务流程是否一致6 、软件流程能否顺利完成7 、各个操作之间的逻辑关系是否清晰8 、各个流程数据传递是否正确9 、模块功能是否与需求分析及概要设计相符10、批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数

18、据量较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据字段的有序切换6.2 面向用户的考虑1 、操作方便性，如：按键次数是否最少，并不以开发实现技术限制为限制，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理建议2 、易用性，面对用户的操作是否简单易学3 、智能化考虑4 、提示信息是否模糊不清或有误导作用。错误信息是否有用户语言风格的出错后续处理建议提示5 、要求用户进行的操作是否多余，能否由系统替代。系统升级后，用户能否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓存等动作6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置7 、是否不经确认

19、就对系统或数据进行重大修改8 、能否及时反映或显示用户操作结果9 、操作是否符合用户习惯，比如：热键10 、各种选项的可用及禁用是否及时合理11 、某些相似的操作能否做成通用模块6.3 数据处理6.3.1 输入数据1. 边界值2. 大于边界值3. 小于边界值4. 最大个数5. 最大个数加 16. 最小个数7. 最小个数减 18. 空值、空表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. 违反流程的打乱流程的不按操作手册的乱操作