下载文档原格式
测试⽤例设计--判定表1、为什么⽤判定表设计测试⽤例？等价类⽅法详细的考虑了需求输⼊域，但对于输⼊域与输⼊域存在关联时⽆法覆盖，（⽐如等价类划分设计测试⽤例时，设计⼀条新的测试⽤例，使其仅覆盖⼀个⽆效等价类，直⾄所有的⽆效等价类完全被覆盖，没有考虑⽆效等价类与⽆效等价类的组合情况）。
所以需要⼀种能考虑输⼊域间的互相关系设计⽅法来考虑业务描述性的测试需求。
2、什么是判定表？判断表是分析喝表达若⼲输⼊条件下，被测对象根据输⼊作出不同响应的⼯具，适⽤于业务逻辑关系和多种条件组合情况。
判定表的结构条件桩：被测对象的所有输⼊条件项：针对条件桩可能输⼊的真假值动作桩：针对条件桩被测对象可能采取的所有动作动作项：针对动作桩，被测对象响应可能结果取值3、怎么⽤判定表设计测试⽤例？步骤：⼀、列出所有的条件和动作⼆、根据提取出来的条件桩和动作桩，设计判定表确定规则的个数（假如有n个条件，每个条件有2个取值（0、1），就可以产⽣2的n次⽅种规则）三、填写判定表四、简化判定表（合并判定表是牺牲测试充分性，混乱业务逻辑为代价。
8条以内的规则不建议合并）五、抽取测试⽤例（简化判定表后，可抽取判定表中的每⼀条规则作为测试⽤例，判定表得到的是测试规则，不是最终的测试⽤例。
规则不能验证功能点正确性，仅验证业务规则的正确性）4、判定表设计测试⽤例的优缺点？优点：判定表充分考虑了输⼊域之间的组合情况，每条规则覆盖了多条输⼊条件，考虑输⼊的约束关系，降低了漏测的风险。
同时利⽤判定表可推断出需求规格本⾝的逻辑性，反向证明了需求的正确。
缺点：当输⼊项过多时，规则数以2的n次⽅剧增，判定表会⾮常庞⼤，采⽤判定表合并时会造成逻辑缺失，业务混乱错误的情况。
5、判断表设计测试⽤例的例⼦⽰列⼀：停机或⽋费不允许主被叫步骤⼀：列出所有的条件和动作条件：停机/⽋费动作：主被叫步骤⼆：确定规则数有3个条件，每个条件有2个取值，故有8个规则步骤三：填写判定表步骤四：只有4条规则不合并，8条以下的规则不建议合并步骤五：规则抽取：(1)⽤户不停机不⽋费，可进⾏主被叫(2)⽤户不停机⽋费，不允许主被叫(3)⽤户停机不⽋费，不允许主被叫(4)⽤户停机⽋费，不允许住被叫。
测试⽤例设计--判定表1.定义判定表通常由四部分组成，如上图：条件桩：它列出决定⼀组条件的对象；条件项：它列出各种可能的条件组合；动作桩：它列出所有的操作；动作项：它列出在对应的条件组合下的动作。
2.应⽤的范围在多个条件多个动作，并且每个条件的取值只有两种的情况下，我们就可以采⽤判定表⽅法。
3.步骤 1）识别条件和动作 2）⽣成判定表 3）简化判定表4.案例订购单的检查。
如果⾦额超过500元，⼜未过期，则发出批准单和提货单；如果⾦额超过500元，但过期了，则不发批准单；如果⾦额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。
判定表分析过程 1）识别条件和动作条件桩条件项1：⾦额＞500元订购⾦额是否⼤于500元0：⾦额＜=500元1：订单未过期订购单是否过期0：订单过期动作桩动作项发出批准单X：表⽰发出批准单发出提货单X：表⽰发出提货单发出通知单X：发出通知单 2）⽣成判定表条件桩条件项订购⾦额是否⼤于500元1100订购单是否过期1010发出批准单X X X发出提货单X X X发出通知单X 3)简化判定表在很多情况下，⼀个判定表写出来以后，是很复杂的，我们需要对其进⾏简化。
如果表中有两条或者多条规则具有相同的动作，并且其条件项之间存在极为相似的关系，我们就可以将其合并。
条件桩条件项订购⾦额是否⼤于500元--10订购单是否过期100发出批准单X X发出提货单X X发出通知单X 这⾥引⼊⼀个概念，规则，以上判定表⾥，右部的每⼀列（条件项和对应的动作项）都是⼀条规则。
以上判定表⾥每⼀条规则都可以转化为测试⽤例。
测试用例确认表
编号：序号：04
项目名称XX项目负责人XX
评审人员部门职务或职称评审人员部门职务或职称XX XX XX XX XX XX
XX XX XX XX XX XX
评审内容：“□”内打“√”
表不同意
表评审通过，“？”表有建议或疑问，“X”
1.是否能按照测试计划时间完成用例编写？是□否
2.用例是否按照公司定义的模板进行编写？是□否
3.测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？是□否
4.每个测试用例是否都阐述预期结果和评估该结果的方法？是□否
5.业务流程中最长的流程用例是否覆盖？是□否
6.测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？是□否存在问题及改进建议：
无
评审结论：
测试用例可用
领导意见：
无
确认人：XX 日期：XX 客户意见：
同意测试用例设计
确认人：XX 日期：XX
制表单位：XX有限公司。
功能测试及性能测试技术白皮书一、软件测试的概念软件测试定义：在软件投入运行前对软件前对软件需求分析、软件设计规格说明和软件编码进行的查错（包括代码执行活动和人工活动）。
也可以说，软件测试是为了发现错误而执行程序的过程。
或者说，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序的错误，这是在软件投入运行前，对软件需求分析、软件设计规格说明和软件编码的最终复审，是软件质量保证的关键步骤。
二、软件测试的前提软件的可测试性：是一个计算机程序能够被测试的容易程度软件可测试性表：可操作性――运行的越好，被测试的效率越高可观察性――所看见的，就是所测试的可控制性――对软件的控制越好，测试越能够被自动执行与优化可分解性――通过控制测试范围，能够更好的分解问题，执行更灵巧的再测试简单性――需要测试的内容越少，测试的速度越快稳定性――改变越少，对测试的破坏越小易理解性――得到的信息越多，进行的测试越灵巧三、软件测试的目的G len Myers在他的软件测试著作中就软件测试的目的提出下列观点。
（1）测试是一个为了寻找错误而运行程序的过程。
（2）一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。
（3）一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
正确认识测试的目的是十分重要的，只有这样，才能设计出最能暴露错误的测试方案。
测试的目的应从用户角度出发，通过软件测试暴露软件中潜在的错误和缺陷，而不应从软件开发者的角度出发，希望测试成为表明软件产品不存在错误，验证软件已正确实现用户的要求的过程。
否则，开发者测试时会选择不易测试出错误和缺陷的用例，这与上述测试目的相违背。
测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。
另外，应该认识到：测试只能证明程序中错误的存在，但不能证明程序中没有错误。
举例1、保险费率计算（按照输入域划分等价类的例子）：✓某保险公司承担人寿保险，该公司保费计算方式为：保费=投保额*保险率，保险率依点数不同而有别，10点以上（含10点）费率为0.6%，10点以下费率为0.1% ✓点数的计算是年龄、性别、婚姻、抚养人数所得的点数的总和✓输入：年龄、性别、婚姻、抚养人数✓输出：保险率输入数据说明：解答：第一步：输入和输出变量确认✓输入：年龄、性别、婚姻、抚养人数✓输出：保险率✓等价类划分原则：按照输入变量来确认等价类（有效等价类和无效等价类）第二步：等价类划分第三步：设计测试用例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：居民用电A：A类计费2：动力用电B：B类计费3：<100度/月C：C类计费4：<10000度/月D：D类计费5：用电高峰期第二步：画出因果图，所有原因结点在左边，所有结果结点在右边，并建立四个中间结点，表示处理的中间状态第三步：把因果图转换为判定表；第四步：为判定表每一列设计一个测试用例；一、程序如下：Int A.B;Double X;if (A > 1 && B == 0)X = X/A;if (A == 2 || X > 1)X = X + 1;cout<<A<<B<<X;要求：1、画出程序流程图；2、分别使用语句覆盖、判定覆盖、条件覆盖、条件组合覆盖方式设计测试用例；3、在TD上编写出测试用例二、有一个员工管理系统，现对其录入模块进行测试。
判定表设计用例案例
# 场景一：正常购买。
用户：普通乔。
操作：投入硬币，选择商品，按下购买按钮。
预期结果：售货机吐出商品，找零（如果有的话）。
测试用例：
1. 乔投入5块钱，买了一瓶3块钱的可乐，机器应该吐出可乐和2块钱的零钱。
2. 乔投入10块钱，买了一包5块钱的薯片，机器应该吐出薯片和5块钱的零钱。
# 场景二：找零不足。
用户：小气李。
操作：投入硬币，选择商品，按下购买按钮。
预期结果：售货机吐出商品，但由于找零不足，应该显示“找零不足”并退还硬币。
测试用例：
1. 小气李投入1块钱，想买一瓶2块钱的矿泉水，机器应该退还1块钱，并显示“找零不足”。
2. 小气李投入3块钱，想买一瓶2块钱的可乐，机器应该吐出可乐，但因为找零不足，不退还1块钱。
# 场景三：商品缺货。
用户：贪心赵。
操作：投入硬币，选择一个已经售罄的商品，按下购买按钮。
预期结果：售货机显示“商品缺货”，并退还硬币。
测试用例：
1. 贪心赵投入5块钱，选择了一个已经卖完的巧克力棒，机器应该退还5块钱，并显示“商品缺货”。
2. 贪心赵投入10块钱，选择了一个还有库存的饮料，机器应该正常吐出饮料和找零。
# 场景四：机器故障。
用户：倒霉钱。
操作：投入硬币，选择商品，按下购买按钮。
预期结果：售货机显示“机器故障”，并退还所有硬币。
测试用例：
1. 倒霉钱投入5块钱，机器突然卡住，应该退还5块钱，并显示“机器故障”。
2. 倒霉钱投入10块钱，机器正常工作，应该吐出商品和找零。
简述判定表法设计用例步骤判定表法是一种用于设计测试用例的有效方法，它可以帮助测试人员针对复杂的业务规则设计出全面的测试用例。
本文将介绍判定表法的基本步骤，以及如何应用该方法来设计测试用例。
下面是本店铺为大家精心编写的4篇《简述判定表法设计用例步骤》，供大家借鉴与参考，希望对大家有所帮助。
《简述判定表法设计用例步骤》篇1一、判定表法的基本步骤判定表法是一种用于设计测试用例的方法，它通常分为以下几个步骤：1. 识别条件和动作测试人员需要先了解业务规则，识别出所有可能的条件和动作。
条件是指影响业务规则执行的因素，动作是指在条件满足时需要执行的操作。
2. 生成判定表根据识别出的条件和动作，测试人员可以生成一个判定表。
判定表通常由四个部分组成，即条件桩、条件项、动作桩和动作项。
条件桩列出决定一组条件的对象，条件项列出各种可能的条件组合，动作桩列出所有的操作，动作项列出在对应的条件组合下的动作。
3. 简化判定表在生成判定表后，测试人员需要对其进行简化。
如果表中有两条或多条规则具有相同的动作，并且其条件项之间存在极为相似的关系，我们就可以将其合并。
4. 转化为测试用例每一条规则都可以转化为测试用例。
测试人员可以根据判定表中的规则，设计出对应的测试用例，以覆盖所有的业务规则。
二、应用判定表法设计用例的案例以一个交易所的手续费计算规则为例，根据交易金额和每股价格和股数的关系，手续费分为三种情况：1. 如果交易金额少于 1000 元，则基本手续费为交易金额的8.4%；2. 如果交易总金额在 1000 元~10000 元之间，则基本手续费为交易金额的 5%，再加 34 元；3. 如果金额超过 10000 元，则基本手续费为交易金额的 4% 加上 134 元。
当每股售价低于 14 元时，附加手续费为基本手续费的 5%，除非买进、卖出的股数不是 100 的倍数，在这种情况下附加手续费的9%。
当每股售价在 14 元到 25 元之间时，附加手续费为基本手续费的某个百分比。
1)条件桩（Condition Stub）：列出了问题得所有条件。
通常认为列出的条件的次序无关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。
这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。
在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
5.规则及规则合并
1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。
在判定表中贯穿条件项和动
作项的一列就是一条规则。
显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
2)化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。
6.规则及规则合并举例
1)如下图左端，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何
值，都执行同一操作。
即要执行的动作与条件3无关。
于是可合并。
“－”表示与取值无关。
2)与上类似，下图中，无关条件项“－”可包含其他条件项取值，具有相同动作的规则可合并。
二.实战演习
1.问题要求：”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，
应给予优先的维修处理……” 。
这里假定，“维修记录不全”和“优先维修处理”均已在别
处有更严格的定义。
请建立判定表。
解答：
①确定规则的个数：这里有3个条件，每个条件有两个取值，故应有2*2*2=8种规则。
②列出所有的条件茬和动作桩：
③填入条件项。
可从最后1行条件项开始，逐行向上填满。
如第三行是：Y N Y N Y N Y N，第二行是：Y Y N N Y Y N N等等。
④填入动作桩和动作顶。
这样便得到形如图的初始判定表。
初始判定表
⑤化简。
合并相似规则后得到图。
2.NextData函数的精简决策表
M1＝{月份，每月有30天}
M2＝{月份，每月有31天}
M3＝{月份，2月} 有29＝512条规则
D1＝{日期，1～28} 12月末31日和其它31 D2＝{日期，29} 日月份的31日处理不同D3＝{日期，30} 平年2月28日处理不同D4＝{日期，31} 于2月27日
Y1 ＝{年：年是闰年}
Y2 ＝{年：年不是闰年}
改进为
M1＝{月份：每月有30天}
M2＝{月份：每月有31天，12月除外}
M4＝{月份：12月}
M3＝{月份：2月}
D1＝{日期：1<=日期<=27}
D2＝{日期：28}
D3＝{日期：29}
D4＝{日期：30}
D5＝{日期：31}
Y1 ＝{年：年是闰年}
Y2 ＝{年：年不是闰年}
输入变量间存在大量逻辑关系的NextData决策表
3.用决策表测试法测试以下程序：该程序有三个输入变量month、day、year（month、day和year均
为整数值，并且满足：1≤month≤12和1≤day≤31），分别作为输入日期的月份、日、年份，通过程序可以输出该输入日期在日历上隔一天的日期。
例如，输入为2004年11月29日，则该程序的输出为2000年12月1日。
1)分析各种输入情况，列出为输入变量month、day、year划分的有效等价类。
2)分析程序规格说明，结合以上等价类划分的情况给出问题规定的可能采取的操作（即列出所有的动
作桩）。
3)根据（1）和（2），画出简化后的决策表。
案例分析如下：
1)month变量的有效等价类：
M1: {month=4,6,9,11} M2: {month=1,3,5,7,8,10}
M3: {month=12} M4: {month=2}
2)day变量的有效等价类：
D1:{1≤day≤26} D2: {day=27} D3: {day=28} D4: {day=29} D5: {day=30} D6: {day=31}
3)year变量的有效等价类：
Y1: {year是闰年} Y2: {year不是闰年}
4)考虑各种有效的输入情况，程序中可能采取的操作有以下六种：
a1: day+2 a2: day=2 a3: day=1
a4: month+1 a5: month=1 a6: year+1
4.判定表在功能测试中的应用
1)一些软件的功能需求可用判定表表达得非常清楚，在检验程序的功能时判定表也就成为一个不错的
工具。
如果一个软件的规格说明指出：
I.当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、3和条件4满足时，要执行
操作1。
II.在任一个条件都不满足时，要执行操作2。
III.在条件1不满足，而条件4被满足时，要执行操作3。
根据规格说明得到如下判定表：
这里，判定表只给出了16种规则中的8种。
事实上，除这8条以外的一些规则是指当不能满足指定的条件，执行3种操作时，要执行1个默许的操作。
在没必要时，判定表通常可略去这些规则。
但如果用判定表来设计测试用例，就必须列出这些默许规则（如下表）。
默许的规则
2)判定表的优点和缺点
I.优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
II.缺点：不能表达重复执行的动作，例如循环结构。
3)B. Beizer 指出了适合使用判定表设计测试用例的条件：
①规格说明以判定表形式给出,或很容易转换成判定表。
②条件的排列顺序不会也不影响执行哪些操作。
③规则的排列顺序不会也不影响执行哪些操作。
④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。
⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。
B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。
其实对
于某些不满足这几条的判定表，同样可以借以设计测试用例，只不过尚需增加其它的测试用例罢了。
