因果图方法设计象棋马走日的测试用例

lee_huo

此例子是讲解利用因果图设计测试用例的一个小例子。以中国象棋中走马的测试用例设计为例学习因果图的使用方法。
一、 分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）
1、如果落点在棋盘外，则不移动棋子；2、如果落点与起点不构成日字型，则不移动棋子；3、如果落点处有自己方棋子，则不移动棋子；4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；5、如果不属于1-4条，且落点处无棋子，则移动棋子；6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；7如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。
二、 根据分析明确原因和结果
原因：
1、 落点在棋盘上；
2、 落点与起点构成日字；
3、 落点处为自己方棋子；
4、 落点方向的邻近交叉点无棋子；
5、 落点处无棋子；
6、 落点处为对方棋子（非老将）；
7、 落点处为对方老将。
结果：
21、不移动棋子；
22、移动棋子；
23、移动棋子，并除去对方棋子；
24、移动棋子，并提示战胜对方，结束游戏。
添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表




考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所以对其施加异约束E.
根据因果图建立判定表：(分为两表)


注：1、以上判定表中由于表格大小限制没有列出最后所选的测试用例；2、第2表中部分列被合并表示不可能发生的现象；3、通过中间节点将用例的判定表简化为两个小表。减少工作量。
四、根据判定表写测试用例表（略）

文章出处：http://www.spasvo.com/html/ceshi/20080626-187.html


上一篇：软件测试分类：单元测试、集成测试、系统测试
下一篇：持续集成与build的周期

iamredeye

我一直不了解这些测试用例的设计方法真正的实施状况。等价类稍微容易采用些， 但比如因果图，对脑子要求满高的，对时间成本要求也高，在实际项目中大家有用过这个方法吗？项目分配给测试的时间允许这么做吗？

lee_huo

如果测试时间允许当然是先设计用例---评审----改进完善----执行用例----发现缺陷----验证修改-----更新用例----回归测试。这是比较理想的。但是实际测试过程中通常都简化用例设计或不写用例执行测试。我个人感觉因果图方法就是把简单问题复杂化，如果思路清晰，可以利用等价划分或场景法等方法所取代。因果图作为教学还是不错，可以帮助初学者更完整的设计用例，以免有遗漏。

iamredeye

那答案就是no了？:)

实际上我问的是test design methodology的问题，而不是整个项目的的testing process。就我所知到的情况而言，今天很多公司都是有自己的testing process的，比如你说的这个“设计用例---评审----改进完善----执行用例----发现缺陷----验证修改-----更新用例----回归测试”。在比较大的项目中，这个相对而言比较规范。

[ 本帖最后由 iamredeye 于 2008-7-2 17:25 编辑 ]

20065503

那答案就是no了？

实际上我问的是test design methodology的问题，而不是整个项目的的testing process ...
iamredeye 发表于 2008-7-2 17:22

    恩  比较赞同，我们公司基本就采用了这种测试流程，但无论怎么评审，总要有好的用例设计方法才行，不然流程再好也无法保证软件的质量，国内目前对测试这块还欠佳重视

风清云闲

LZ辛苦，小红花一朵给你戴上~

咕罒噜噜@▂.

没人回帖。。。我来个吧！

彩虹天堂丶

路过 帮顶 嘿嘿

那段我们

很有借鉴意义，先收藏了，谢谢楼主。

淡淡旳微笑╮

很有借鉴意义，先收藏了，谢谢楼主。

梦涂黑

很有见地的探讨，先收藏着~

wwwxcomcn

顶不错 支持下