关于测试用例编写详细度覆盖度的问题（B/S网页测试）
编写的测试用例拿给项目经理看，总是嫌弃我们编写的太简单，不够详细。可是如果写得详细那就真的真的会写很多很多。。。
其实在测试时我们也会用很多测试用例用于测试，只是写测试用例时总觉得没必要都写得那么详细。
我们主要做B/S架构的网页测试，测试就我们2个人，都是新手。。。
所以平时有很多困惑和不解。
举例：
1. 选择下拉菜单中的一个条件，然后点击查询，查询出相关的信息。
下拉菜单有30项，那么写测试用例时还要写出30条来每次选择一个条件点击查询吗？
大家有没有什么好点的建议？
2. 在新增一条信息的页面中，有很多文本框和选择项，要针对每个文本框每个选择项的N多种测试方法写好多测试用例吗？
谢谢！ 很多人都会遇到这样的问题。我们一般说这是测试用例的粒度。如果粒度太大，用例就会少，执行起来容易遗漏。如果太小，用例数量会很多。而且执行起来会有难度。
在用例的编写过程中，要结合程序本身的特点，分析潜在问题。对于复杂的功能点，需要减小测试粒度，编写更为详细的测试用例。对于简单的功能就可以用大的粒度进行覆盖。另外，要把用例的数据分开，减少用例数量，增强用例可用性，减少维护工作。对于操作过程相似的功能验证，可以写成测试用例组。也就是公共用例。
用例的编写详尽程度要根据与之相关人员的水平来确定。如果只是自己用的，又是对系统比较熟悉的人来查看，可以写的简单扼要一些。
用例主要是量化测试工作，为测试结果分析提供依据。只要能达到这样的目标就可以了。 关于控件这中，如下拉框，复选框等，可能写成公用用例。
平时重点写一些业务层面的！ 组织一个会议，讨论下要弄什么什么样子。 可以是测试用例评审会议，会议邀请：测试组全体，项目经理，开发主要成员。 回复 3# liyb
嗯，谢谢！经理的意思是我们现在不怎么会写，要写得详细些，以后熟悉了就可以写得少一些。
我们现在是没有专业的，什么都要自己慢慢琢磨，很郁闷。。。 回复 5# 千里
嗯，我们公司现在没有一个比较专业的人。。。
不同人就有不同的想法，这个要这样写，那个要那样写。
还是要慢慢讨论呀！
谢谢！ 归类整理一下，同类项合并
页:
[1]
