能够执行的用例就是好用例吗？
前段时间做了个小项目，把我累死了！他们说我写的case不能执行（我写了别人执行），我也承认我写的不是很好，我觉得写case的跨度要大，而他们盯着一个点在写case，把这个点从左看，从右看，从上看，从下看，凭自己想象这个点该具有什么功能写case，这个对吗？ 能否执行的测试用例不一定是好用例，但是，不能执行的用例肯定不是好用例。
测试用例不仅要求可以执行，还要求设计的全面。 同意testing
我再说说关于case跨度的问题：
1。涉及到一点的case和涉及到多点的case都是需要的，都应该在测试用例设计中考虑，所以你和他们的想法都没错。
2。如果我们把case都看成一个过程或者流程的话，case就可以分成单一过程和组合过程，你想考虑的就是组合过程。
3。单一过程一般比较容易考虑（开发人员也容易考虑清楚），因此组合过程通常更能发现问题。
4。组合过程不是各种单一过程的简单拼凑，只有对被测对象充分了解才能设计出优秀的组合过程。他们觉得你写的case不具有可测性是不是由于你设计的过程很难实现或者实际应用中根本不可能出现。
我不同意testing
不能用的用例并不一定不好用，很简单的一个与语音有关的例子，测试用英文和中文都可以测试某一功能，用例设计者考虑到与测试点与语言种类关系不大，就用了适合大部分人的英语编写测试用例，而使用用例者觉得英文听不懂，就会来一句，用例不好用（自己不好意思说自己英文不好或者更习惯中文，还少说一句，为什么不用中文的语音交互）。
所以，不好用的用例并不一定就不是好用例，测不出问题，确认不了功能点的用例才不是好用例。 testing说的是不能执行，而不是不好执行：） 凭自己想象这个点该具有什么功能写case，这个对吗？
这个不正确，在设计测试用例时，功能都已经存在了，而不是，我们去凭空想象它具有什么功能。我们只是将所有的功能需求在我们的测试用例中覆盖到就可以了。 能够吃的东西不一定适合你哦！ 能不能执行不是最重要的 ，只要能找出bug的用例，就是好用例啊 各位！
测试用例的好坏是看对提高软件的质量有没有帮助。不是看能不能发现BUG！ 建议大家不要把楼主的话题扩大化，我们主要还是要讨论“能够执行的用例就是好用例吗？ ”，而不是讨论什么样的测试用例是好的测试用例。 能够执行的用例不一定是好的用例，好的用例一定是能够执行的
不能执行的用例一定不是好的用例，不好的用例不一定不能执行:p 能执行的用例当然不一定是好用例,反之,能保证产品的质量,就是好的测试用例,也许现在不能实现,但它给我们提供了测试方向,提供了努力的方向,等到条件成熟的时候就组织资源去实现 我不明白, 不能执行那还叫用例吗? 不能编译的能叫程序吗?
楼主说的是不容易执行吧,比如实现的代价比较大?
回复 #10 jackei 的帖子
能执行的还的看看得没得到预期的测试要求和结果啊1
页:
[1]
