功能测试用例如何来设计？

微笑流淌

看书上写的测试用例分为：等价傎法、边界值法、因果图法等等，看上面的例子也看的懂，可是在实际运用中就有点蒙了，不知道什么时候该用什么方法了？
现在我基本是上这样做的，根据设计文档（没有需求文档的）找出测试点，然后把这个测试点相关的功能全部考虑好测试一遍，然后再测试下一个测试点，不知道这种方法会不会遗漏掉什么呢？
比如说加好友的功能测试，我会考虑：加对方为好友对方也添加自己为好友，加对方为好友好友只接受，加对方为好友好友拒绝，加对方为好友好友关闭添加好友框，对方账号为不存在等几种情况，至于添加好友时添加的备注语等细节情况，会在测试上面几种情况时顺便测出来
不知道这样的方法有没有误区，请大家多多指导！

微笑流淌

自己顶一个

Jackc

感觉LZ设计用例时，思维有些混乱，建议尝试把各个测试点分类整理，分类规则取决于“使自己能够更清晰理解各个用例设计的目的”。

大的方向可以分为正常与异常两大类测试点。
正常测试点主要覆盖需求，它一般按照需求展开；而这部分用例覆盖主要靠反复分解需求完成。
异常测试点主要覆盖结果，它一般由“实际结果”反向推导，如好友测试中，账号不存在的用例，其实是“添加好友失败”用例组中的一个子用例“账号非法”。这部分用例覆盖主要靠测试经验累积完成。
————————————————————————————————————————————————————
例子：

加好友测试，可以使用因果图为主体的设计方法（因果法在列举各个组成部分时，也是对需求点的简单分类）：

因：接受、拒绝、取消
果：添加对方为好友、添加对方为好友并向对方发送添加好友请求、没将对方添加为好友、没将对方添加为好友并向对方发送文字信息

中节点（覆盖率主要体现在这里）：对方是否已经存在于好友列表中、是否勾选添加对方为好友选项、是否编辑消息.....（任意非必选项都可做为中节点，甚至可以将异常测试的前提条件也做为中节点，如账号是否存在）

——————————————————————————————————————————————————————

简单来说，用例设计由于设计者不同，使用的方法组合各不相同。而先整理测试点，并分类设计的方法，使用频率比较高。
分类时，不要期望一次就完成所有分类，逐层分类测试元素有助于用例测试的覆盖。

真实的追求者

楼上的说的好

愿望树yhm

功能测试有时真很乱！

微笑流淌

回复 3# Jackc


先谢谢版主了

不过不太懂中节点是什么意思，在用例设计时组合方法是什么呢？是把所有中节点正交法排列那样去设计，再与因、果组合设计用例吗？

微笑流淌

回复 5# 愿望树yhm


是啊，经常晕头转向的，有时候干脆不设计用例了，按自己想的去测

Jackc

回复 6# 微笑流淌

因果图的中节点是整个因果法的第二核心，第一核心是它自带的与、非、或运算符。正是中节点的存在让因果图能设计出覆盖较高的用例组。

————————————————————————————————
因果图中节点并没有严格的限制，它可能是一个判断，如“是否有acb用户存在”；也可能是一个特殊的输入状态，如“网络连接中断”……
就概念来说，中节点是“因”的辅助“前置环境/输入步骤”，它为实现特定的“果”而存在。

通俗来讲：中节点就是对测试环境/步骤的必要补充
—————————————————————————————————

用例设计组合方法就是将各种基本用例设计方法组合到一起，最终设计出完整的用例组。
也就是你的说“所有中节点正交法排列那样去设计，再与因、果组合设计用例”

需要注意的是：组合方式由实际项目和设计者本人决定，没有任何一种组合是完美的

微笑流淌

回复 8# Jackc

对于测试用例设计方法知识还是比较欠缺，版主讲的大概是听懂了，可是如果应用的话还是会有些问题，我自己再好好消化消化……
多谢版主……

liyb2006

如果说对页面或窗口内的单一功能编写了用例,还需要按流程,或者说场景设计一些复杂的用例,对相关联的功能进入覆盖.如一个完整的事务.曾经遇到一个BUG,修改了一个数据后,添加的时候失败了,其他操作并不会出现这样的情况,至今还不明白该怎么设计用例来覆盖这样的问题.如果能明白系统内部结构,设计用例效率会很高的.

微笑流淌

回复 10# liyb2006


    学习了，谢谢！