从测试用例看测试的问题及变化

樱qq · 发表于 2009-3-30 12:04:58

赞，说出了俺们的困惑哦

wuyawei · 发表于 2010-10-15 15:46:27

回复 17# 冷月

冷月这个是个很不错的想法，但是无疑增加了工作量。我现在的做法是，还是以功能点的测试用例为主导，但是在功能点测试用例的排布上是一个个连贯的业务流程。另外把业务流程的测试用例（相对比较少，而且一旦确定之后比较稳定），作为测试用例的p1部分，冒烟测试时使用

450683057 · 发表于 2011-9-3 17:13:25

恩！恩！

likaihon · 发表于 2013-7-22 16:57:22

写得很好，学习了

rexlu · 发表于 2013-10-8 16:35:30

学习中，支持

test-fuji · 发表于 2013-10-14 13:47:59

非常感谢，很多问题就是发生在我身边的

liaojuan · 发表于 2013-10-17 16:03:41

回复 1# dionysus
功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。
引用lz的这句话，我觉得说的很对，我下面的疑惑是不是可以用您这句话就可以解释了啊，

书上面说在需求定下来之后就开始编写测试用例，但是在实际的工作当中，需求定下来了，但是页面上具体有什么功能不知道，这怎么去编写，靠想象吗？那这样编写的测试用例与实际功能会存在很大差异，而且很多功能测试点可能还写不全，那这样的测试用例写来有什么用、有什么意义？很疑惑。
编写测试用例是方便测试，降低漏测率；我以前编写测试用例就是照着做好的页面或是做好的功能编写测试用例，这样知道页面上有什么功能点，就知道该怎么写，就算是这样也可能会有遗漏的，因为你不知道开发是如何来实现该功能的，那这个时候就需要操作下看功能是怎样的，再照着写测试用例，那这样编写出来的测试用例有什么用，完全是对着功能写的，就算有漏测也不知道啊？

liaojuan · 发表于 2013-10-19 14:08:51

回复 1# dionysus

功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。

那是不是说在些功能测试用例的时候我们可以依据开发做好的来进行写测试用例，而业务流程测试用例，我们可以在需求定下来的时候就可以进行编写

		自动登录	找回密码
密码			(注-册)加入51Testing

[原创] 从测试用例看测试的问题及变化

站长推荐 /1