用例写成什么样的才是好的？
软件测试测到什么时候算结束？欢迎大家讨论，相互学习，共同进步。 领导审阅时放心；
用例执行时舒心；
质量跟踪时省心；
成本审核时开心；
这样的用例就是好用例。
至于测试结束时间，通常参考产品发布时间。
多谢！
:handshake回二楼
能否再 说的详细点，因为对于新手来说在写用例时，对编写步骤、覆盖率高的编写方法还没有一个完整的思路；
或者是写的用例步骤、内容描述的不够清晰，请问对于这种情况应该怎样去避免、完善，？
谢谢
回复 4# 的帖子
写测试用例前先了解需求，对你写用例很有帮助 能否再 说的详细点，因为对于新手来说在写用例时，对编写步骤、覆盖率高的编写方法还没有一个完整的思路；
开心果说的很对。
用例思路通常来源于文字需求和产品实际实现的功能两部分。只有熟悉测试目标后，才可能提高用例对测试点的覆盖。
而针对每个单独测试点的覆盖，则需要通过用例设计方法和对实际业务的理解来增加周边的用例，以达到更高的覆盖率。
或者是写的用例步骤、内容描述的不够清晰，请问对于这种情况应该怎样去避免、完善，？
谢谢
1、书写格式是大同小异的，大方向上追求“易审阅，易修改"。所以通常会选择为分类后的列表格式。如：
分类为：序号/名称/测试环境/测试步骤/测试数据/预期结果/实际结果/备注……
然后以从上之下的排列顺序分布各个用例。（可以参考excl的用例模板）
2、内容描述方面，讲究文字的清晰，简洁。还可以多参考公司内相似功能用例的描述语言，对相同或相似操作尽量使用相同的词语来描述。
如自己无法单独体会，建议进行用例的同行评审，在评审中熟悉并理解文字描述的尺度。
回五楼和六楼 ，谢了
你们说的很详细、很实际也很容易理解谢谢！:handshake 除了格式上的要求之外，书写测试用例还要记得从业务的角度上进行设计和衡量
对于业务上的逻辑，要进行详细覆盖
对于业务功能点，要进行覆盖
设计上，有效性验证，无效性验证都要覆盖到，对于逻辑比较复杂的，要加大覆盖的力度。
总的来说，测试用例的设计需要你用心去研究客户的需求，业务的逻辑和相互的关系。然后用尽可能少的用例，覆盖较多的功能点，而且要有针对性，可以检查出更多隐藏的问题。
在书写上，自然就是楼上几位提出的那样，清晰，易修改，可复用性强，没有歧义。。 :handshake 关于测试结束
1.质量：软件产品是否符合需求规格说明书的要求
2.市场，也就是二楼所说的发布时间
在满足需求规格说明书之后，肯定还有很多bug，如果追求完美，就没完没了了，所以必须还有个最后期限，比如软件发布时间。有时候确实找不到bug，在所有成员都同意停止测试的情况下，也可以提前终止 实践是检验真理的标准，能发现别人发现不了的bug……
页:
[1]
