不错!
真需要了解这方面的知识呢 ! 谢谢!!! 利用自动化测试软件就如虎添翼了,希望和大家多多交流 不错,受到点启发。 哈哈,我在设计测试用例用的就是这种方法,本人认为这种方式在测试用户需求实现的覆盖率上是不错的选择,但是在发现 ad hoc类的bug 上不是很好使。拙见! 其实这种思考方式与场景法设计测试用例有什么不一样吗? skinapi朋友,麻烦你再抽点时间再结合一个实际的例子,再给我们大家讲讲吧,谢谢了! thank you !回复 #65 starseeker 的帖子
学习先好思路
lz的思路很好,我们公司主要做流程类的项目,这种方法很适用,但就像前面的朋友们说的,如果流程剧复杂的话,这样设计用例还是比较费时间的 不错不错,学了不少,谢谢~~~~~~ 设计测试用例的方法不少,但始终离不开逻辑这个概念。不管你是哪个方法,其他都可以看做是不同抽象层次的事务逻辑和不同角度看待的事务逻辑。最后还是要通过覆盖全部或者部分的逻辑来达到目标的。
黑合路径、用例事件流、领域模型、业务逻辑、类关联。这些都可以看成是不同抽象层次的事务/事物逻辑关系的表示而已。至于测试能覆盖多深,一个取决于获取的项目信息的充分程度,一个取决于你对特定层次的相关知识掌握的广度和深度。所以这也涉及到论坛里老问的测试人员需要多少开发的技能这个问题,这其实是取决于你的组织需要你测试的完全程度的,需要测试的越完全,那么就需要测试更多的细节和逻辑组合,你需要用到的知识就越多,仅此而已。
个人感觉如此,或许有错,交流一下而已。 经理以后要我转集成测试,单元测试,我的好好看看这个 运用这样的方法编写测试用例方法不错噢,这样的编写是建立在对系统有很彻底的了解的基础之上的。如果你的系统真的是使用了UML的标准用例图的话,也许会很有效果。如果不是,还是得靠自己思考有哪些情况导致这样的分支会出现。 3Q 醍醐灌顶啊~
最近觉得自己设计测试用例遇到了瓶颈,在单个功能点或者测试数据选择方面都比较得心应手,但是对整个软件的业务流程把握不是很好,测完后对软件大的方面心里都还是没底。
尝试一下用这里介绍的路径分析去看看我的测试到底覆盖了多少路径 谢了!学习中。 这个方法呢在测试中我是常用的,但对于不同的系统怎样凭测试经验去做呢? 不错,学习