所有者:张梅娜
2012年10月
Email:coci_zmn521@https://www.doczj.com/doc/b15966362.html,
MSN: zmn_coci@https://www.doczj.com/doc/b15966362.html,
QQ: 1099289293
测试用例编写
及设计原则培训
课程大纲
一．测试用例介绍
二．测试用例设计方法论及设计原则介绍
三．行业性测试用例如何编写四．测试用例设计重点注意事项五．问题答疑
一、测试用例介绍
1.什么是测试用例
2.测试用例的重要性
3.测试用例编写的目的和作用
4.测试用例编写的依据
5.测试用例分类
6.测试用例和测试点的区别和联系
7.测试用例和测试用例执行报告的区
别和联系
一、测试用例介绍-什么是测试用例 什么是测试用例：
测试用例又称为测试用例（英文：Test Case）
目前测试行业中对于测试用例基本没有一个经
典的定义。
通常的说法是：测试用例是为某个特殊目标
而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某
个特定需求。
测试用例包括测试目标、测试内容、测试环境、测试数据、测试步骤、预期结果等，并根据内
容形成一份完整的文档。
一、测试用例介绍-测试用例的重要性 测试用例的重要性：
1.测试用例是软件测试的核心
2.测试用例是设计和制定测试过程的基础
3.测试用例是正常、有序、高效开展测试的核
心基准
4.测试用例是将测试具体量化的方法之一
5.测试的“覆盖度”及“深度”与测试用例的
数量成比
6.测试用例是最终交付质量的核心保证之一
7.测试用例是对程序代码实现的质检手段之一
一、测试用例介绍-测试用例的目的和作用 测试用例编写的目的和作用：
?对于测试人员：
指导测试的实施:
对软件测试行为加以量化，避免盲目测试
提高测试效率
规划测试数据的准备
?对于测试管理者：
评估测试结果及交付质量的度量基准
评估测试过程规范性的依据之一
测试人员绩效考核的依据之一
分析缺陷的标准
一、测试用例介绍-测试用例编写的依据 测试用例编写的依据：
测试用例编写的依据首先是需求文档，所有的测试用例都需要根据用户需求文档进行编写，但是根据软件生命周期每个阶段的不同，因此也会依据所在阶段的相关产出文档进行测试用例的设计。
一、测试用例介绍-测试用例分类
按照测试用例的性质分为：
?功能测试用例
包含单元功能测试用例、模块集成功能测试用例、
系统功能测试用例等
?接口测试用例
包括内部接口测试用例、外部接口测试用例等
?业务测试用例
包括包括业务测试用例以及场景测试用例
?性能测试用例
包括性能测试用例、大容量测试用例、负载测试用例、压力测试用例等
?安全测试用例
包括安全漏洞测试用例、SQL注入测试用例、网络渗
一、测试用例介绍-测试用例分类
按照测试阶段分为：
?单元测试用例
?集成测试用例
?系统测试用例
?UAT测试用例
按照测试用例的测试对象分为：
?软件测试用例
按照软件结构分为包含B/S测试用例、C/S测试用例,嵌入式软件测试用例
?硬件测试用例
包含交换机测试用例、通信直放站测试用例、电脑硬件测试用例等
一、测试用例介绍-测试用例分类
按照测试用例的软件行业类别分为：
?电子商务软件测试用例
包括B2B、C2C、B2C等电子商务类软件
?通用系统软件测试用例
包括windows、linux等系统软件以及office、OA、MIS等办公软件?餐饮软件测试用例
?即时通信软件测试用例
?医疗软件测试用例
?安全软件测试用例
包括防毒杀毒软件和防火墙软件
?电信软件测试用例
?影音软件测试用例
?游戏软件测试用例
?金融软件测试用例
包括银行、保险、证券、财务（含ERP、CRM等)的行业软件?其他行业…
一、测试用例介绍-测试用例和测试点的区别
和联系
测试点和测试用例的区别：
?测试点是进行测试的要点内容，类似于开发的概要设计文档。
?测试用例是测试的具体内容，需要用到相关的测试方法，类似于开发的详细设计文档。
测试点≠测试用例
测试点和测试用例的联系：
?测试点是设计测试用例的基础
?测试用例是测试点具体细化的内容
只有将测试点完整的提取出来后才能设计出完整的、高覆盖率的测试用例。
一、测试用例介绍-测试用例和测试用例执行
报告的区别和联系
测试用例和测试用例执行报告的区别：
?测试用例是进行测试执行的依据，类似于开发
的详细设计。
?测试用例执行报告是测试用例的验证性文档，
以说明依照测试用例进行执行的结果，类似于开发的编码。
测试用例≠测试用例执行报告
测试用例和测试用例执行报告的联系：
?测试用例是测试执行的核心，可以视测试用例
是测试执行的指导手册和依据。
?测试用例执行报告不仅仅对测试用例进行验证，而且对测试设计的正确性进行反向验证，可以视测试用例执行报告是测试用例的实践验证。
二、测试用例设计方法论及设计技巧介绍
1.测试用例设计常用方法论
?白盒测试用例设计方法论
?黑盒测试用例设计方法论
?功能测试用例设计
?业务场景测试用例设计法
?逐级细分测试用例设计法
?兼容性测试用例设计
?易用性测试用例设计
?迁移测试用例设计
?性能测试用例设计方法论
2.测试用例设计技巧及设计思想
白盒测试用例设计方法
逻辑覆盖根据覆盖目标的不同分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。
?语句覆盖：选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。
?判定覆盖：通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值，即使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。
?条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。
?判定-条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，且每个判定本身的判定结果（真/假）也至少出现一次。顾名思义，判定-条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。
?组合覆盖：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。即满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定-条件覆盖。
?路径覆盖：设计足够多的测试用例，要求覆盖程序中所有可能的路径。
?六种逻辑覆盖之间的关系
?路径设计法
?基本路径:本质上是从程序入口到出口的一些通路。之所以称其为基本路径，原因在于可以通过对基本路径进行连接或者重复操作得到程序中的其它路径
DD路径：又称决策到决策路径，指语句的一种序列，按照Miller的话说，从决策语句的“出路”开始，到下一个决策语句的“入路”结束，在这种序列中没有内部分支，因此对应的节点像排列起来的一行多米诺骨牌，当第一张牌推倒后，序列中的其他牌也会倒下
二、测试用例设计方法-黑盒测试用例 黑盒测试用例
黑盒测试用例一般根据测试对象的不懂包括功能测试用例、业务测试用例、易用性测试用例以及兼容性测试用例等。
以上测试用例主要根据测试需求和所处的阶段的不同而采用不同的黑盒测试用例方法。
二、测试用例设计方法-黑盒测试用例 黑盒测试用例常用方法如下：
决策表，也叫判定表。在所有的功能性测试方法中，基于决策表的测试方法被认为是最严格的，因为决策表具有逻辑严格性。 在一些数据处理问题当中，某些操作的实施以来与多个逻辑条件的组合，既针对不同逻辑条件的组合之，分别执行不同的操作；决策表就是分析和表达多逻辑条件下执行不同操作情况的工具。 1 决策表通常由以下4部分组成： 条件桩(condition stub)：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。 动作桩(action stub)：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。 条件项(condition entry)：列出针对它所列条件的取值，在所有可能情况下的真假值。作项(action entry)：列出在条件项的各种取值情况下应该采取的动作。 2 决策表的生成： （1）确定规则的个数 ?有n个条件的决策表有2n个规则（每个条件取真、假值）。（2）列出所有的条件桩和动作桩 （3）填入条件项 （4）填入动作项，得到初始决策表 （5）简化决策表，合并相似规则
?若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。 ?合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为“无关条件”。 举个例子↓↓
3 决策表的优缺点： 决策表最突出的优点是，能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。 ? 利用决策表能够设计出完整的测试用例集合。 ? 运用决策表设计测试用例可以将条件理解为输入，将动作理解为输出 4 何种情况下使用？ ? 规格说明以决策表形式给出，或较容易转换为决策表；
系统测试用例设计方法 --------------王永安
目录 一、测试用例格式以及写作要点 (3) 二、系统测试用例设计方法 (4) 1、等价类划分法 (5) 2、边界值分析法 (6) 3、判定表法 (7) 4、因果图法 (9) 5、状态迁移图法 (15) 6、流程分析法 (20) 7、正交试验法 (35) 8、错误推测法 (42)
一、测试用例格式以及写作要点 测试用例编号 测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性。比如可以采用统一的约定，产品编号—ST—系统测试项名—系统测试子项名—编号。这样看到编号就可以知道是做的什么测试，测试的对象是什么。也方便维护。 测试项目 你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。例如：计算器加法功能。 测试标题 测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点是不一样的。例如：手机在没有SIM 卡的情况下，拨打119。 重要级别 重要级别分为高中底三等： 高：保证系统基本功能、重要特性、实际使用频率比较高的用例； 中：重要程度介于高和底之间的测试用例； 底：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。 注：一般情况下，重要级别为高的测试用例，一个测试子项里有且尽有一个，大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试，如果重要级别为高的太多，则就失去了预测试的实际意义。 预置条件 就是执行当前测试用例的前提条件，如果不满足这些条件，则无法进行测试。 输入 测试用例执行时，需要输入的外部信息。例如某一个文件，数据记录等。
1、兼容性测试在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件驱动程客户机工作站可能会安装不同的软件例如，应用程序、规格会有所不同。序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。测试目的 操作系统系统软件外设应用软件结果配置说明 Window2000(S) 服务器 WindowXp Window2000(P) Window2003 TestCase_LinkWorks_WorkEvaluate 用例编号LinkWorks项目名称WorkEvaluate模块模块名称研发中心-质量管理部项目承担部门 用例作者2005-5-27 完成日期质量管理部本文档使用部门评审负责人审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。 历史版本： 备注起止日期参与者作者状态/版本 V1.1 1.1. 疲劳强度测试用例
强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 用户并发设置添加10连续运行8前提条件小时,输出/响应输入测试需求/动作是否正常运行1 2小时功能4小时6小时8 小时 2小时功能1 4小时6小时 小时8 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI（图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。
讨论用TestDirector管理测试用例 编制时间:2007-03-16 编制部门:测试组 编制人:郭宏元 “测试用例”虽有国标作蓝本，但实际中，一直以来“测试用例”是所有测试人员有争议的地方，此所谓“仁者见仁，智者见智”。而“法无定法，则无定则”，所有的规范与标准都是围绕更适应人们的工作环境而创建。在此，我就我的一些体会在此与大家分享。 一般来说，“测试用例”的编写主要分三大类，贯彻的原则与基本架构如下： 分类： 1、对验证过程的一个记录； 2、展现一个功能； 3、描述一个场景步骤； 原则： 1、有“对象”属性的描述； 2、阐述了某个“对象”的方法或事件。 3、对属性、方法或事件有详细的定义。 基本架构： 1、目的； 2、前提条件； 3、输入步骤（输入动作或数据，预期结果） 以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写，并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能，而在于验证软件应该达到的功能，这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么？以及采用的方法做了一点描述。 1、目的： 围绕测试名称或满足实现测试功能而进行。 2、范围：
适用于所要测试的质检项目。 3、功能测试用例编写原则 3.1单元测试功能用例的编写目的 单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能，由于是单个模块所以无法检验关联性，可能会牵扯到数据库的操作，例如：删除时，需要查看数据库是否完全删除了数据。 3.2集成测试功能用例的编写目的 集成测试功能用例的目的在于验证软件连接时，模块的连接是否正确（及数据的传递是否正确）。.我们的软件中体现出来的是，是否正确调用界面，界面之间显示的数据是否正确，特别是财务、费用、数据方面的。 集成测试用例的编写过程中，经常将功能用例与业务流程混合编写，因为在集成测试时需验证业务流程中的数据正确性，以及界面之间的数据传递的准确无误。 3.3系统测试业务流程用例的编写目的 系统测试业务流程用例的目的在于验证软件最终数据的准确性，我们的软件体现为，手工数据与报表数据的一直性。用例与用例之间有着一定的关系，目的性十分明确。 4、测试用例设计的原则 4.1全面性 指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。 4.1.1数据库程序基本的增、删、改功能 增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合，此时可以采用等价类划分和边界值法，下面有较详细的说明。 删除的测试用例比较简单，只有操作没有数据的输入，但是应该在“备注”中注明，删除的限制条件，以及数据库中应该删除的表的情况，有条件限制时，测试用例应该包含各种删除条件，必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。 4.1.2对于无输入的操作，应该详细描述其具体的操作步骤和结果
功能测试用例的设计 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】
一、实验目的 1.用因果图法分析原因结果，并决策表设计测试用例。 2.使用场景法设计测试用例。 二、实验内容 1. 将三角形问题的可能结果扩展为：一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形，考虑用因果图法设计测试用例，给出完整步骤。 2. 有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号密码登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。使用场景法设计上述问题的测试用例。 三、实验环境 Windows XP系统 四、实验步骤和结果 1. 将三角形问题的可能结果扩展为：一般三角形、等腰三角形、等边三角形、直角三角形、等腰直角三角形和非三角形，用因果图法设计测试用例，给出完整步骤。具体如下： 1）输入的三边分别为a，b，c(斜边) 且a
2. 行在线购买，这时需要使用帐号密码登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。使用场景法设计上述问题的测试用例。
（注：在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流,“n/a”（不适用）表 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测
五、实验结果和讨论 成功使用因果图法、场景法设计了测试用例。 六、总结 1．因果图法的定义是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。 2．在事件触发机制中场景法用得最多。在测试一个软件的时候，先确定基本流也就是测试流程中软件功能按照正确的事件流实现的一条正确流程,接着去确定备选流也就是那些出现故障或缺陷的过程，用备选流加以标注。然后可以采用矩阵或决策表来确定和管理测试用例。
一、等价类划分法 例子1： 现在有一个档案管理系统，容许用户通过输入年月对档案文件进行检索，系统对查询条件年月的输入限定为1990年1月-2049年12月，并规定，日期由6位数字组成，前4位表示年，后2位表示月。 1，根据需求进行分析，找出有哪些输入条件 年份：【1990，2049】 月份：【01，12】 字符长度：6位 字符类型：数字 2，画出等价类 输入条件有效等价类边界值分析无效等价类 年份【1990，2049】（1）上点：1990，2049（12） 离点：1989，2050 内点：2016 <1990 （2）>2049 （3） 月份【01，12】（4）上点：01，12（13） 离点：00，13 内点：11 <01 （5）>12 （6） 字符长度6位（7）上点：6 离点：5，7 内点：6 <6 （8）>6 （9） 字符类型数字（10）非数字（11）3，为每个等价类规定一个唯一编号（如上图） 4，转换成测试用例 转换测试用例的原则： A，设计一个测试用例尽可能多的覆盖多个有效等价类； B，设计一个测试用例必须对应覆盖一个无效等价类。 有效等价类用例： 用例1：201611 （1）（4）（7）（10） 无效等价类用例： 用例2：198911 （2） 用例3：205011 （3） 用例4：201600 （5） 用例5：201613 （6） 用例6：20161 （8） 用例7：2016113 （9） 用例8：20161a/abcedf （11） 根据边界值分析法分析后补充测试用例 用例9：199001 （12） 用例10：204912 （13） 5，转成正式格式用例（用例写作的8大要素） 用例编号D1223232_ST_Search_Date_001 项目搜索功能 标题输入正确的日期格式成功搜索
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。 目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。 易用性细则： 1) 完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。 2) 完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。 3) 按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。 4) 界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。 5) 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 6) 同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。 7)分页界面要支持在页面间的快捷切换，常用组合快捷键Ct r l+Tab 8) 默认按钮要支持Ent er及选操作，即按Ent er后自动执行默认按钮对应操作。 9) 可写控件检测到非法输入后应给出说明并能自动获得焦点。 10) Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。 11) 复选框和选项框按选择几率的高底而先后排列。 12) 复选框和选项框要有默认选项，并支持Tab选择。 13) 选项数相同时多用选项框而不用下拉列表框。 14) 界面空间较小时使用下拉框而不用选项框。 15) 选项数叫少时使用选项框，相反使用下拉列表框。
·软件测试用例设计－－场景分析方法 方法简介 现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。 基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。 二.实战演习 1. 例子描述 下图所示是ATM例子的流程示意图。
表3-8 场景设计 注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。 3.用例设计 对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各 列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例
ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。 表3-9 测试用例表 4.数据设计 一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。
测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。 表3-10 测试用例表
举例1、保险费率计算（按照输入域划分等价类的例子）： ?某保险公司承担人寿保险，该公司保费计算方式为：保费=投保额*保险率，保险率依点数不同而有别，10点以上（含10点）费率为0.6%，10点以下费率为0.1%?点数的计算是年龄、性别、婚姻、抚养人数所得的点数的总和 ?输入：年龄、性别、婚姻、抚养人数 ?输出：保险率 输入数据说明： 解答： 第一步：输入和输出变量确认 ?输入：年龄、性别、婚姻、抚养人数 ?输出：保险率 ?等价类划分原则：按照输入变量来确认等价类（有效等价类和无效等价类） 第二步：等价类划分
a t i m e a 第三步：设计测试用例 1、设计测试用例，尽可能的覆盖尚未覆盖的有效等价类。 （1）（8）（10）（12） （2）（9）（11）（13） （3）（8）（10）（14） 2、设计测试用例，使得每一个新设计的测试用例只包含一个无效等价类，其他的选择有效等价类。 （4）（8）（10）（12） （5）（9）（11）（13） （6）（8）（10）（14） （7）（8）（10）（14） （1）（8）（10）（15） （2）（9）（11）（16） （3）（8）（10）（16） 说明：在设计无效部分的测试用例的时候，有效等价类部分，可以任意选择。 思考：若使用边界值法可以增加哪些用例？是否可以用判定表方法设计测试用例？ 举例2（因果图法设计测试用例）：某电力公司有A 、B 、C 、D 四类收费标准，其规定如下图所示，使用因果图法设计测试用例： 用电类别用电额度用电期间收费类型<100度/月—— A 类居民用电 >=100度/月B 类<10000度/月非高峰期B 类>=10000度/月非高峰期C 类<10000度/月高峰期C 类动力用电 >=10000度/月 高峰期D 类
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面： 1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。 2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。 3、完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。 4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。 5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。 6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。 7、压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。 8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。 9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。 10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。 11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。 12、可移植性：在不同操作系统及硬件配置情况下的运行性。 13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员已经解决，进行下一轮的测试。 14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。 说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。 1、其中第1、 2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
如何设计和执行测试用例测试需求收集完毕后，开始测试设计。 测试用例是什么?测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题： 测试用例的基本格式： 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时，软件的响应情况”。 重要级别：定义测试用例的优先级别，可以笼统的分为“高”和“低”两个级别。一般来说，如果软件需求的优先级为“高”，那么针对该需求的测试用例优先级也为“高” ;反之亦然， 测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用
例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。 加强测试用例的评审： 测试用例设计完毕后，最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错
测试规程/用例设计 测试规程（test procedure）是一个提供详细的测试用例执行指令的文档。测试规程应该更注重测试的流程、方法等比较泛的内容，以方便我们对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。 测试用例（test case）对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。 测试用例的设计： 测试用例可以分为基本事件、备选事件和异常事件。 设计基本事件的用例：参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。 设计备选事件和异常事件的用例：采用的基本方法仍然是等价类划分、边界值、因果图等，根据软件的不同性质和测试的不同目标灵活运用，至于最终设计的测试用例是否能暴露更多的隐藏缺陷，全凭用例设计人员的丰富经验和精心设计了。例如，测试一个手机终端的电话本模块。测试人员需要考虑，将相同的号码A存储到不同联系人名B和C 中，号码A呼入和呼出时，显示的联系人名应该是B还是C呢。类似这样的备选事件，往往在需求阶段描述的并不详尽，需要测试人员及早提出并与项目组达成一致。 测试用例在软件测试中的作用： 指导测试的实施 规划测试数据的准备 编写测试脚本的"设计规格说明书" 评估测试结果的度量基准 分析缺陷的标准 此阶段的难点和重点： 测试用例设计的几大基本点 使用合理的语言 测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出 一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构，动词总是测试 人员要做得事情，名词总是测试人员操作的对象、事物 将同一个事物命名为同一个名称，不管这个事物是否通过不同的方式出现测试用例的易测性 简洁性：简洁性的衡量方法就是执行测试花费时间的长短以及在测试过程中是否能保持
报表测试用例设计方法总结 报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能) 数据统计方面 1、报表统计数据的正确性； 2、报表统计数据的完整性； 3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等； 报表格式 1、表头字段表示的正确性； 2、表头字段表示的完整性； 3、表头字段表示的字体，字号，美观程度； 4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小； 5、页眉和页角的表示； 报表的预览和印刷 1、预览中的显示完整性； 2、多页情况下，第2页的表头显示； 3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板） 4、预览后印刷； 5、不预览，直接印刷 6、需求规定各类打印机的测试； 数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为**业务的而提供帮助的。 比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。
另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。 从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。 首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活， ①系统中报表重叠的进行比对 ②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对 ③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？ ④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错 ● 原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。 ● 数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。 ● 数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。 ● 数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。 ● 由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了if else,这样就是把表中缺失该项内容的算成了
常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 1. 等价类划分 常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2. 边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3. 错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例. 4. 因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 5. 正交表分析法 有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。 6. 场景分析方法
软件测试用例设计规范Software Test Case Design Specification
版本历史 版权信息 本文件内容由XX集团信息技术部负责解释 本文件的版权属于XX集团 任何形式的散发都必须先得到XX集团信息技术部的许可 https://www.doczj.com/doc/b15966362.html,/
【目录】 1目的 (4) 2范围 (4) 3名词定义 (4) 4工件 (4) 4.1 输入 (4) 4.2 输出 (5) 5规范内容 (5) 5.1 设计原则 (5) 5.1.1可执行性 (5) 5.1.2可维护性 (5) 5.1.3可代表性 (5) 5.1.4可判定性 (6) 5.2 必要元素 (6) 5.2.1用例包和用例对象名命 (6) 5.2.2测试目的 (6) 5.2.3测试优先级 (6) 5.2.4测试环境 (7) 5.2.5前提条件 (7) 5.2.6后置关联 (7) 5.2.7用例状态 (7) 5.3 综合策略 (7) 5.3.1必要的边界值分析 (7) 5.3.2必要的等价类划分 (8) 5.3.3必要的因果图方法 (8) 5.3.4必要的性能测试方法 (8) 5.3.5面向对象设计方法 (8) 5.4 设计活动 (8) 5.4.1分析和建立测试用例包 (8) 5.4.2分解并建立测试用例对象 (10) 5.4.3建立测试用例对象间关系 (11) 5.4.4设计测试用例 (12) 5.4.5测试实施 (14) 5.5 检查点 (17)
1目的 本规范的目的是为了明确软件测试用例的设计原则，活动和方法，提高软件测试用例的可读性、可执行、可维护性、覆盖程度、以及测试的灵活性，使软件测试用例真正能够指导测试的实施和执行，并成为评估测试结果的度量基准。 2范围 本规范适用于春秋信息技术部所有软件开发项目和产品集成测试和系统测试用例的设计。 3名词定义 4工件 4.1 输入
软件测试用例实例(非常详细)汇总
1、兼容性测试 在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。 测试 目的 配置说明操作系 统 系统 软件 外设应用软件结果 服务器Windo w2000( S) Windo wXp Windo w2000( P) Windo w2003 用例编号TestCase_LinkWorks_W orkEvaluate 项目名称LinkWorks
1.1.
1.2. 疲劳强度测试用例 强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目的 测试说明 前提条件连续运行8小时,设置添加 10用户并发 测试需求输入/ 动作 输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时功能1 2小时 4小时 6小时
8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI （图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.doczj.com/doc/b15966362.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计
测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设：某个等价类的代表值，与该等价类的其他值，对于测试来说是等价的。 因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类： 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）划分等价类的方法: 下面给出六条确定等价类的原则： ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效
1、兼容性测试 在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。 测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。历史版本： 版本/状态作者参与者起止日期备注 V1.1
1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的 测试说明 前提条件连续运行8小时,设置添加10用户并发 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI（图形用户界面）与应用程序交互，对
1、登陆 ①用户名和密码都符合要求（格式上的要求） ②用户名和密码都不符合要求（格式上的要求） ③用户名符合要求，密码不符合要求（格式上的要求） ④密码符合要求，用户名不符合要求（格式上的要求） ⑤用户名或密码为空 ⑥数据库中不存在的用户名，不存在的密码 ⑦数据库中存在的用户名，错误的密码 ⑧数据库中不存在的用户名，存在的密码 ⑨输入的数据前存在空格 ⑩输入正确的用户名密码以后按[enter]是否能登陆 11、是否支持table键？ 12、密码是否加密显示？ 2、添加 ①要添加的数据项均合理，检查数据库中是否添加了相应的数据 ②留出一个必填数据为空，应该每一个必填项都尝试一次； ③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 ④不符合要求的地方要有错误提示 ⑤是否支持table键 ⑥按enter是否能保存 ⑦若提示不能保存，也要察看数据库里是否多了一条数据 8、检查取消保存时，也要察看数据库里是否多了一条数据 3、删除 ①删除一个数据库中存在的数据，然后查看数据库中是否删除 ②支持多个同时删除的，要检查删除数据后，数据库中是否被删除； ③什么数据都不选择，直接点删除按钮，检查是否有错误提示； 4、查询 精确查询： ①输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据 ②输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据 ③输入格式或范围不符合要求的数据，看是否有错误提示 ④输入数据库中不存在的数据 ⑤不输入任何数据 ⑥是否支持table键 ⑦是否支持enter键 模糊查询： 在精确查询的基础上加上以下一点
①输入一些字符，看是否能查出数据库中所有的相关信息 设计功能和界面测试用例 1.1 文本框、按钮等控件测试 1.1.1 文本框的测试 如何对文本框进行测试 a，输入正常的字母或数字。 b，输入已存在的文件的名称； c，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理； d，输入默认值，空白，空格； e，若只允许输入字母，尝试输入数字；反之；尝试输入字母； f，利用复制，粘贴等操作强制输入程序不允许的输入数据； g，输入特殊字符集，例如，NUL及\n等； h，输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示； i，输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示 在测试过程中所用到的测试方法： 1，输入非法数据； 2，输入默认值； 3，输入特殊字符集； 4，输入使缓冲区溢出的数据； 5，输入相同的文件名； 命令按钮控件的测试 测试方法： a，点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口； b，对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示：天数不能大于31； c，对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会； 单选按钮控件的测试 测试方法： a，一组单选按钮不能同时选中，只能选中一个。 b，逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”； c，一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空； 控件文本框的测试 测试方法： a，直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10； b，利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；