软件测试-测试用例的经典例子
软件测试案例分析
软件测试案例分析测试目标：1.验证电子商务网站的基本功能是否正常运行，如用户注册、登录、商品、添加购物车、下单支付等。
2.检查电子商务网站的性能是否满足用户需求，如网站访问速度、页面加载速度、系统响应时间等。
3.确保电子商务网站的安全性，如防止恶意攻击、保护用户隐私信息等。
测试用例：1.注册测试用例：d.验证注册成功后，用户的信息是否正确保存在数据库中。
2.登录测试用例：a.输入正确的用户名和密码，验证用户是否能够成功登录。
b.输入错误的用户名和密码，验证系统是否能够给出相应的错误提示。
c.验证登录成功后，用户是否能够正确跳转到首页。
3.商品测试用例：a.输入关键词，验证系统是否能够正确返回相关的商品信息。
b.输入不存在的关键词，验证系统是否能够给出相应的提示。
c.验证结果是否准确，并且能够正确展示商品信息。
4.添加购物车测试用例：a.验证用户是否能够成功将商品添加到购物车中。
b.验证购物车中是否正确显示商品的名称、价格和数量。
c.验证购物车中商品数量的增减功能是否正常。
5.下单支付测试用例：a.验证用户是否能够成功选择商品下单。
b.验证订单页面中商品信息是否准确。
c.模拟用户完成支付流程，验证是否能够成功支付并生成订单。
6.性能测试用例：a.记录网站的平均响应时间，并进行压力测试，确保网站能够稳定地处理大量用户请求。
b.验证页面加载速度是否满足用户的要求，尽量减少页面加载时间。
c.验证系统的并发性能，确保系统能够同时处理多个用户的请求而不影响性能。
7.安全性测试用例：a.检查系统是否存在安全漏洞，如SQL注入、XSS攻击等。
b.验证用户隐私信息是否得到保护，如用户密码是否被正确加密存储。
c.模拟恶意攻击，如暴力破解密码、尝试非法登录等，验证系统的安全机制是否能够有效防止攻击。
测试分析和评估：在完成所有测试用例后，可以根据测试结果进行分析和评估。
根据测试结果，可以判断电子商务网站的功能是否正常运行，性能是否满足用户需求，以及安全性是否能够保障用户信息的安全。
软件测试经典案例
软件测试一测试用例的经典例子、等价类划分问：某程序规定："输入三个整数a、b、c分别作为三边的边长构成三角形。
通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算…"。
用等价类划分方法为该程序进行测试用例设计。
(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。
)解：分析题目中给出和隐含的对输入条件的要求：(1)整数(2)三个数(3)非零数(4)正数(5)两边之和大于第三边(6)等腰(7)等边如果a、b、c满足条件(1 )〜(4 ),则输出下列四种情况之一：1) 如果不满足条件(5)，则程序输出为”非三角形”。
2) 如果三条边相等即满足条件(7)，则程序输出为"等边三角形"c3) 如果只有两条边相等、即满足条件(6)，则程序输出为"等腰三角形II114）如果三条边都不相等，则程序输出为II般三角形II列出等价类表并编号4PJ 入 条 件 输A个整数三个数菲零数正数构成一報 三角形a+t ）》Gb+c^a o+c>b构成等腿 三角形b=c l 且两边 f 之和 a=c 」大千第三边91Q初成等嵯 三角形r 逍为非曲-边为非建熱！乃为非籃数I c 为非整数 「小为非整数 两边为非-整蝌IV 肯非整数 L 密为非整数三边• &丄均抑非整数「只给连只给一边-只给b「只给貼 只给两边彳貝给毗 给出三个以上 一边为零二边为零二边 ahjC0-0 対为为 匕O 为为一边<n J bdD 匚c<D{a<X ）且 b<C id ］且 c^O b<£）且 三边均<S ：肚fl 且bdJ 且r a+Vi 1 L a+t^O <b+r<* b+r=« r a+c<b 1 a+c^b1213M 15 K 17 1020 2? 22 23 24 25 26 27 28 2P 30 3£ 32 33 34 35 36 37 3S 3940 ZT 42 43 44 45覆盖有效等价类的测试用例:a b c 覆盖等价类号码3 4 5 （1）- -（7）4 45 （1）- -（7），（8）4 5 5 （1）- -（7），（9）5 4 5 （1）- -（7），（10）4 4 4 （1）- -（7），（11）覆盖无效等价类的测试用例:二、边界值分析法NextDate函数的边界值分析测试用例在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1 ^mouth <12和1 Way <31，并设定变量year的取值范围为1912 <^ear <2050。
单元测试测试用例例子
单元测试测试用例例子在软件开发中，单元测试是一种非常重要的测试方法，用于确保代码的正确性和功能的稳定性。
而单元测试用例则是指用来验证单个代码单元（如函数、方法、类等）是否按照预期工作的测试案例。
本文将介绍一个关于登录功能的单元测试用例例子。
1. 功能描述在这个例子中，我们将以登录功能为例进行单元测试。
该功能提供用户登录的能力，当用户输入正确的用户名和密码时，登录成功，否则登录失败。
2. 测试用例2.1 正常登录情况测试目的：验证当用户输入正确的用户名和密码时，登录是否成功。
输入：正确的用户名和密码预期输出：登录成功2.2 用户名为空测试目的：验证当用户未输入用户名时，登录是否正常处理。
输入：空用户名，正确的密码预期输出：登录失败，提示用户名不能为空2.3 密码为空测试目的：验证当用户未输入密码时，登录是否正常处理。
输入：正确的用户名，空密码预期输出：登录失败，提示密码不能为空2.4 用户名错误测试目的：验证当用户输入错误的用户名时，登录是否正常处理。
输入：错误的用户名，正确的密码预期输出：登录失败，提示用户名错误2.5 密码错误测试目的：验证当用户输入错误的密码时，登录是否正常处理。
输入：正确的用户名，错误的密码预期输出：登录失败，提示密码错误3. 测试案例执行结果执行上述测试用例后，得到以下结果：2.1 正常登录情况输入：用户名 - user1，密码 - 123456预期输出：登录成功实际输出：登录成功2.2 用户名为空输入：用户名 - 空，密码 - 123456预期输出：登录失败，提示用户名不能为空实际输出：登录失败，提示用户名不能为空2.3 密码为空输入：用户名 - user1，密码 - 空预期输出：登录失败，提示密码不能为空实际输出：登录失败，提示密码不能为空2.4 用户名错误输入：用户名 - error，密码 - 123456预期输出：登录失败，提示用户名错误实际输出：登录失败，提示用户名错误2.5 密码错误输入：用户名 - user1，密码 - 123预期输出：登录失败，提示密码错误实际输出：登录失败，提示密码错误4. 测试结果分析从上述测试结果可以看出，该登录功能的单元测试用例覆盖了多种情况，并成功地检测到了异常情况。
测试用例(软件测试详细案例)
测试用例测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例（Test Case）目前没有经典的定义。
比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
不同类别的软件，测试用例是不同的。
不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。
笔者主要从事企业管理软件的测试。
因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。
测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。
对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。
从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。
测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。
测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。
测试用例反映了要核实的需求。
然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。
例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。
选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
软件测试测试用例范文
软件测试测试用例范文测试用例是用来验证软件功能是否符合需求规格说明书中所描述的功能。
下面是一个关于登陆功能的测试用例范文，共700字。
用例名称：登陆功能测试用例测试目的：验证登陆功能是否符合需求规格说明书测试环境：Windows操作系统，最新版本的Google Chrome浏览器测试数据：用户名、密码前置条件：系统已注册用户测试步骤：1. 打开浏览器，输入系统地址，并进入登陆页面。
2. 输入正确的用户名和密码，点击登陆按钮。
3. 验证登陆成功后页面是否显示用户信息。
4. 输入正确的用户名和错误的密码，点击登陆按钮。
5. 验证是否提示密码错误的提示信息。
6. 输入正确的密码和错误的用户名，点击登陆按钮。
7. 验证是否提示用户名错误的提示信息。
8. 输入不存在的用户名和密码，点击登陆按钮。
9. 验证是否提示用户名不存在的提示信息。
10. 不输入用户名和密码，点击登陆按钮。
11. 验证是否提示用户名和密码不能为空的提示信息。
12. 输入正确的用户名和密码，点击记住密码按钮，再点击登陆按钮。
13. 验证登陆成功后页面是否显示用户信息，并且下次自动填充用户名和密码。
14. 关闭浏览器，重新打开浏览器，输入系统地址。
15. 验证是否已自动填充用户名和密码。
预期结果：1. 登陆成功后，页面显示用户信息。
2. 提示密码错误的提示信息。
3. 提示用户名错误的提示信息。
4. 提示用户名不存在的提示信息。
5. 提示用户名和密码不能为空的提示信息。
6. 登陆成功后，页面显示用户信息，并且下次自动填充用户名和密码。
7. 浏览器重新打开后，已自动填充用户名和密码。
备注：该测试用例仅验证了登陆功能的几种常见情况。
根据实际情况，还可以进行更细致的测试，例如验证输入的用户名和密码超出最大长度时的处理、验证特殊字符等。
软件测试案例
案例释疑案例1-1：终点线前的遗憾说明：课堂上讲述该案例，目的是让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺陷都可能带来严重后果。
教师不必全部讲述，需摘略其中重点内容。
内容：作为长期火星探测战略的一个步骤，美国航宇局于1998年12月11日和1999年1月3日先后将两颗探测器送往火星。
其中先行一步的火星气候轨道器（MCO）经过6.65亿公里的飞行，终于在9月份飞到了火星，但在准备进入绕火星运行的轨道时，却不慎失手，让关注它的人们大失所望。
令人吃惊的是，此次事故的原因竟是一个非常低级的失误。
根据对进行入轨机动点火前采集到的跟踪数据的分析，项目官员认为火星气候轨道器失踪的原因是导航出了重大错误，致使探测器飞到了比预定高度低很多的高度。
实际上，在因飞入火星背面而与地面“正常”地失去联络之前，探测器就已经走上了一条将把它带到距火星表面最近仅57公里的错误路线。
这一高度大大低于技术人员提出的约85～100公里的最小安全距离，与预定的140～150公里高度更是相差甚远。
高度太低，探测器有可能在火星的大气中因气动热而被“火葬”，甚至还有可能坠毁在火星表面上。
事故发生后，主管该项目的美国航宇局喷气推进实验室等部门迅速开始了调查工作。
初步分析时认定，问题可能出在卫星软件上，还可能是地面系统的问题，人员操作失误的可能性也不能排除。
但最后查出的结果却让人难以置信：造成飞行高度太低的原因竟然是公制和英制的转换问题。
调查人员在9月30日公布的一份报告中称，探测器制造商洛马公司对探测器的一项关键性操作提供的是英制单位的数据，而美国航宇局喷推实验室的导航人员想当然地以为是公制，未加换算便直接将英制数据输入了采用公制数据的计算机系统内，从而造成了严重的导航错误。
问题出在一个导航软件表上。
这个出错的推力器校定表用在确定探测器位置的地面导航软件中。
它的作用是把遥测到的推力器点火工作次数转换成提供给探测器的冲量，以消除因推力器点火工作造成的弹道计算中的剩余误差。
测试用例案例
测试用例案例测试用例是软件测试中的一种技术手段，它是一种详细说明如何验证软件功能的文档或脚本。
下面是一个关于登录功能的测试用例案例。
测试用例名称：登录功能测试用例目的：验证系统的登录功能是否正常、稳定，并保证用户可以成功登录系统。
前置条件：1. 用户需要拥有一个有效的账号和密码。
2. 系统正常运行。
测试步骤：1. 打开系统登录页面。
2. 输入正确的账号和密码。
3. 单击“登录”按钮。
4. 检查系统是否成功登录，用户是否跳转到系统的主页面。
5. 系统是否显示用户的账号信息。
6. 确认用户是否可以正常操作系统的其他功能，例如查看个人信息、修改密码等。
7. 退出系统，确认系统是否正常退出。
预期结果：1. 浏览器打开系统登录页面。
2. 输入正确的账号和密码后，系统显示登录成功的提示。
3. 用户自动跳转到系统的主页面，页面显示正确。
4. 系统主页面显示用户的账号信息。
5. 用户可以正常操作系统的其他功能，例如查看个人信息、修改密码等。
6. 用户点击退出系统按钮，系统可以正常退出。
异常情况处理：1. 输入错误的账号和密码，系统应该显示登录失败的提示，并提示用户重新输入正确的账号和密码。
2. 当系统无法连接到数据库时，应该显示连接错误的提示。
3. 当用户输入非法字符时，系统应该对输入进行合理的校验，并给出相应的提示。
注意事项：1. 在测试用例中尽可能涵盖不同的用户场景，例如：正常用户、异常用户（输入错误的账号和密码）、数据库连接出错等。
2. 在测试用例中尽可能考虑不同的输入组合情况，例如：正确的账号和密码，正确的账号和错误的密码，错误的账号和密码等。
3. 在测试用例中尽可能考虑系统的边界条件，例如：输入超过系统限制长度的账号和密码等。
软件测试经典三角形案例
软件测试－黑盒测试例子一、等价类划分问：某程序规定："输入三个整数 a、 b、 c分别作为三边的边长构成三角形。
通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算… "。
用等价类划分方法为该程序进行测试用例设计。
（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。
）解：分析题目中给出和隐含的对输入条件的要求：（1）整数（2）三个数（3）非零数（4）正数（5）两边之和大于第三边（6）等腰（7）等边如果 a、 b 、 c满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：1)如果不满足条件（5），则程序输出为 " 非三角形 " 。
2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。
3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。
4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。
列出等价类表并编号覆盖有效等价类的测试用例：a b c覆盖等价类号码3 4 5（1）--（7）4 4 5（1）--（7），（8）4 5 5（1）--（7），（9）5 4 5（1）--（7），（10） 4 4 4（1）--（7），（11）覆盖无效等价类的测试用例：二、边界值分析法NextDate函数的边界值分析测试用例在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050 。
三、错误推测法测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：I.输入的线性表为空表；II.表中只含有一个元素；III.输入表中所有元素已排好序；IV.输入表已按逆序排好；V.输入表中部分或全部元素相同。
软件测试案例库范文
软件测试案例库范文1. Web应用登录功能测试案例描述：测试登录功能是否正常，包括用户名和密码验证、忘记密码功能等。
步骤：1)输入正确的用户名和密码，验证是否成功登录。
2)输入错误的用户名和密码，验证是否提示错误信息。
3)点击忘记密码，验证是否能够重置密码。
4)在登录页面中，验证是否能够实现记住密码功能。
5)在登录页面中，验证是否能够实现自动填充密码功能。
2.移动应用购物功能测试案例描述：测试购物功能是否正常，包括商品浏览、加入购物车、结算等。
步骤：1)浏览商品列表，验证是否能够正常显示商品信息。
2)点击商品，验证是否能够正常跳转到商品详情页面。
3)在商品列表或商品详情页面中，点击加入购物车，验证是否能够成功添加商品到购物车。
4)在购物车页面中，验证是否能够显示已添加的商品。
5)在购物车页面中，点击结算，验证是否能够正常跳转到支付页面。
3.桌面应用数据导入功能测试案例描述：测试数据导入功能是否正常，包括选择文件、验证文件格式、验证文件内容等。
步骤：1)点击导入数据按钮，选择需要导入的文件。
2) 验证文件格式是否符合要求，例如Excel文件是否是.xlsx格式。
3) 验证文件内容是否符合要求，例如Excel文件是否包含正确的表头和数据。
4)验证导入数据的结果是否正确，例如导入的数据是否显示在系统中。
5)验证导入数据的性能，例如导入大批量数据时，系统是否能够正常处理。
4.电子邮件应用发送邮件功能测试案例描述：测试发送邮件功能是否正常，包括收件人输入、主题输入、内容输入、附件添加等。
步骤：3)输入主题和内容，验证是否能够正常发送邮件。
4)添加附件，验证是否能够成功发送带附件的邮件。
5)验证发送邮件的性能，例如发送大附件时，系统是否能够正常处理。
5.数据库应用查询功能测试案例描述：测试查询功能是否正常，包括输入查询条件、点击查询按钮、验证查询结果等。
步骤：1)输入正确的查询条件，验证是否能够正确返回查询结果。
软件测试例子
软件故障例子 1. Google的Gmail故障 2009年2月份Google的Gmail故障，应该算是最近因软件故障而受到广泛关注的事件。据Google后称，那次故障是因数据中心之间的负载均衡软件的Bug引发的。 Gmail故障还仅是导致用户几个小时内无法访问邮箱，并没有造成伤亡。当然了，对某些用户来讲，是非常不便。
2.美国男子治疗肺炎收4400万账单 回应称软件故障 美国纽约布朗克斯区一名男子收到一张4400万美元医疗账单，吓得够呛。男子名为亚历克西斯·罗德里格斯，28岁，失业，上周在当地布朗克斯-莱巴嫩医院治疗肺炎后收到这张“天文数额”账单。 美国广播公司16日援引罗德里格斯的话报道：“我差点犯哮喘。”他说，自己所欠门诊医疗费用不超过300美元。 账单由PHY服务公司开具。出现天价账单可能缘于软件故障，把单据号误填入应缴金额一栏。 罗德里格斯不是收到类似账单的唯一病人。PHY服务公司因此接到不少投诉电话，已向患者致歉。 “如果你想咨询与布朗克斯-莱巴嫩医院账单相关的事宜，请无视现有账单，”这家企业的咨询电话自动回复说，“不久后你将收到新账单。”
3. 0.00美元账单
4. “漏网”的臭氧层空洞 南极洲上方的臭氧层空洞一直存在但长期未被发现，这是为什么？ 1978年，NASA启动臭氧层测绘的计划。在设计之时，用于该计划的数据分析软件忽略了和预测值有很大差距的数据。直到1985年，才发现南极洲上方的臭氧层空洞，但不是NASA发现的（是英国科学家先发现的）。直到NASA重新检测它们的数据，才发现这一错误。在修正错误后，NASA证实南极臭氧层的确有个很大的空洞。 5.致命的辐射治疗 1985到1987年，Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故，其罪魁祸首是医疗设备电力软件的Bug。据统计，大量患者接受高达100倍的预定剂量（治疗），其中至少3人直接死于辐射剂量超标。 另一宗辐射剂量超标的事故发生在2000年的巴拿马城（巴拿马首都）。从美国Multidata公司引入的治疗规划软件，其（辐射剂量的）预设值有误。有些患者接受了超标剂量的治疗，至少有5人死亡。后续几年中，又有21人死亡，但很难确定这21人中到底有多少人是死于本身的癌症，还是辐射治疗剂量超标引发的不良后果。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件测试－测试用例的经典例子
一、等价类划分
问：某程序规定："输入三个整数 a、 b、 c分别作为三边的边长构成
三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角
形、等腰三角形及等边三角形时，分别作计算 „ "。用等价类划分方
法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输
出之间的关系比较复杂。）
解：
分析题目中给出和隐含的对输入条件的要求：
（1）整数
（2）三个数
（3）非零数
（4）正数
（5）两边之和大于第三边
（6）等腰
（7）等边
如果 a、 b 、 c满足条件（ 1 ） ~ （ 4 ），则输出下列四种情
况之一：
1)如果不满足条件（5），则程序输出为 " 非三角形 " 。
2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形
" 。
3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰
三角形 " 。
4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。
列出等价类表并编号
覆盖有效等价类的测试用例：
a b c 覆盖等价类号码
3 4 5 （1）--（7）
4 4 5 （1）--（7），（8）
4 5 5 （1）--（7），（9）
5 4 5 （1）--（7），（10）
4 4 4 （1）--（7），（11）
覆盖无效等价类的测试用例：
二、边界值分析法
NextDate函数的边界值分析测试用例
在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为
1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为
1912≤year≤2050 。
测试用例 mouth day year 预期输出
Test1 Test2 Test3 Test4 Test5 Test6 Test7 6 6 6 6 6 6 6 15 15 15 15 15 15 15 1911 1912 1913 1975 2049 2050 2051 1911.6.16
1912.6.16
1913.6.16
1975.6.16
2049.6.16
2050.6.16
2051.6.16
Test8 Test9 Test10 Test11 Test12 Test13 6 6 6 6 6 6 -1 1 2 30 31 32 2001 2001 2001 2001 2001 2001 day超出
[1„31]
2001.6.2
2001.6.3
2001.7.1
输入日期超界
day超出
[1„31]
Test14 Test15 -1 1 15 15 2001 2001 Mouth超出
[1„12]
Test16 Test17 Test18 Test19 2 11 12 13 15 15 15 15 2001 2001 2001 2001 2001.1.16
2001.2.16
2001.11.16
2001.12.16
Mouth超出
[1„12]
三、错误推测法
测试一个对线性表（比如数组）进行排序的程序，可推测列出
以下几项需要特别测试的情况：
I. 输入的线性表为空表；
II. 表中只含有一个元素；
III. 输入表中所有元素已排好序；
IV. 输入表已按逆序排好；
V. 输入表中部分或全部元素相同。
四、因果图法
有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规
格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗
的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零
钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来
而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，
在送出饮料的同时退还5角硬币。
1) 分析这一段说明，列出原因和结果
原因：
1.售货机有零钱找
2.投入1元硬币
3.投入5角硬币
4.押下橙汁按钮
5.押下啤酒按钮
结果：
21.售货机〖零钱找完〗灯亮
22.退还1元硬币
23.退还5角硬币
24.送出橙汁饮料
25.送出啤酒饮料
2)画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右
边。建立中间结点，表示处理的中间状态。中间结点：
11. 投入1元硬币且押下饮料按钮
12. 押下〖橙汁〗或〖啤酒〗的按钮
13. 应当找5角零钱并且售货机有零钱找
14. 钱已付清
3)转换成判定表：
五、判定表驱动分析方法
问题要求：”„„对功率大于50马力的机器、维修记录不全或已运行10
年以上的机器，应给予优先的维修处理„„” 。这里假定，“维修记
录不全”和“优先维修处理”均已在别处有更严格的定义。请建立判定
表。
解答：
①确定规则的个数：这里有3个条件，每个条件有两个取值，故应
有2*2*2=8种规则。
②列出所有的条件茬和动作桩：
③填入条件项。可从最后1行条件项开始，逐行向上填满。如第三
行是：Y N Y N Y N Y N，第二行是：Y Y N N Y Y N N等等。
④填入动作桩和动作顶。这样便得到形如图的初始判定表。
1 2 3 4 5 6 7 8
条
件
功率大于50马力吗？ Y Y Y Y N N N N
维修记录不全吗？ Y Y N N Y Y N N
运行超过10年吗？ Y N Y N Y N Y N
动
作
进行优先处理 x x X X X
作其他处理 X x x
初始判定表
⑤化简。合并相似规则后得到图。
1 2 3 4 5
条
件
功率大于50马力吗？ Y Y Y N N