最近在一本书上看见“测试用例是设计出来的，不是写出来的”。
我的理解是，测试用例不是翻译需求文档，不是简单的把需求文档中的内容分成许多模块。
而是根据需求文档，设计出有效的测试用例，即覆盖需求文档中的所有要求，也要包含隐含的功能（比如：可用性、性能、安全、可恢复等等），及一些破坏性的操作，程序对异常操作的处理；另一方面，要考虑测试的方法和测试用例模块的分配，尽可能将相似的测试放在一起，这样可以提高测试执行效率及测试用例的后期维护。
大家还有哪些见解，或者我有错误的理解，欢迎留言，大家一起学习
李育春 2010-06-10
版主是对的，不过现实不需要如此吧？
陆丹平 2010-06-11
赵永智 2010-06-11
测试案例要有连贯性
文珠 2010-06-11
好的测试用例应该能够覆盖测试的所有功能，还应该考虑测试人员的执行顺序。
雷雨 2010-06-11
还要考虑执行用例的时间成本~
谢明志 2010-06-11
关键是这句话是谁说的，如果是tester说的，我很晕，如果是CTO说的 ，我没问题。
李蕾 2010-06-11
谢明志: 关键是这句话是谁说的，如果是tester说的，我很晕，如果是CTO说的 ，我没问题。
是在一本测试技术的书上看见的
李蕾 2010-06-11
李育春: 版主是对的，不过现实不需要如此吧？
可能吧，现实中要根据实际工作，至少我们现在的工作也不完全是这样的
谢明志 2010-06-11
是的，不是第一次听说。
代勋 2010-06-12
理论正确，实施难
熊志男 2010-06-12
代勋: 理论正确，实施难
同意
黄海舟 2010-06-12
实际情况要复杂N倍！
赵艺骅 2010-06-12
李星星 2010-06-12
黄海舟: 实际情况要复杂N倍！
嗯，严重同意，用例要考虑隐含的需求，确实复杂N倍
汪坤 2010-06-12
一般是把规格肢解成case，其中再加入边界值，等价类等分析法；当然还有容错性测试；呵呵，好的测试用例确实难写；
写点简单的，最好只画一个矩阵表，简单实用
段辰 2010-06-12
测试用例要最大程序还原场景，来显现BUG。需求→测试需求分析→评审→基线→用例，看似简单的过程其实隐含着很复杂的因素，做好做全不容易
请 登录 后发表评论
