简而精的测试用例？

liangliang1

你看我这个想法对不对，就是那些明显不会有错误的功能点就不需要写在测试用例里面的，比如界面上有“确定”“返回”按键等等这样的，书写测试用例是为了寻找bug，不是为了写而写的，应该将着重点进行细化，所以测试用例应该是简而精的，我知道有通过测试和失败测试的，而且也有理论说测试人员不应该相信任何不会有错误的情况的，可真的需要这样吗？

cncnily

错 书写测试用例不一定是为了找BUG！
1.写测试用例可以反映游戏的进度，也要给上级看的
2.反映程序的实现与策划案是否相符
3.加入方法查找BUG
用测试用例找BUG不是写测试用例的目的，你可以看看你报的BUG都是怎么找的就明白了

msnshow

同意，不是为了写测试用例而写测试用例
、

msnshow

同意，不是为了写测试用例而写测试用例
、

星空物语

我觉得还是看你公司具体情况吧
如果管理比较规范，上级相对重视，那你就写上
如果不是很重视，或时间紧迫，就没必要

werm520

确定、返回你觉得没必要写？
    我测得项目中就以为一个功能点击确定没有实现，而被直接打回给开发的转测试失败，你如果写就可以记录下来，作为跟踪，而且这些不同阶段的测试用例和执行情况都是需要交付的，确定和返回这都是直接影响用户的功能，必须要在测试中给予体现的。
    测试用例不仅仅只作为测试的一部分，同时也是考察产品质量以及后期产品上线评定定责任的重要依据。
    当然对于这样公共常用的测试控件，没必要每个都详细些，你可以写些公共用例什么的，但是必须要在用例中覆盖到。

cncnily

好记忆不如烂笔头，都觉得这玩意一看就知道，但总会有遗漏的时候。

liyb2006

用例只是用来量化测试工作的，同时也可以让测试变得可控制。只能说按照一些方法，归类用例降低用例数量，如把数据和用例分开，减少用例，增大用例复用，以及降低用例维护工作量。但是一味追求用例合并，或者对部分相对简单的用例省略，会造成测试遗漏和不可控，容易带来风险，从而降低测试效果。用例也不只属于个人（编写人员）使用的，要考虑更多情况。

liuwwb

学习了！

Indisorder

测试的工作就是发现和记录

独喵喵

是啊，不能为了写测试用例而写测试用例。