测试用例内部评审的标准？？
求助:测试用例写完以后，先要进行内部评审，
其它的人要看这个内部评审的结果，
我们内部评审通过的证据有哪些方法可以显示出来给他们看呢??
内部评审通过的标准大家都有哪些？？？ 我现在想到一些：
比如对需求了解的程度，测试用例的覆盖率，单个测试用例是否单一，描述是否清晰准确，
测试计划全面与否，测试用例多少好坏，工作耗时；耗时与产出的比例；
总觉得很多标准有重复，不知道怎么去明确区分，很多东西都不知道怎么去量化，是很主观的东西。
大家觉得还有哪些标准？？提点意见吧。。。 wonder兄你好，我们公司也想进行测试用例评审，
但也是没有一个标准，没有开始
这测试用例是由不同的测试员完成的，每个人的工作方式不一样，不知道这样做是否太牵强了？？？？
1测试用例的评审，有哪些人参加，多长时间完成，是否会有效果？
2用例的书写标准化
3不同人员对测试注意点都不一样，往往领导是希望一次写完，一次就找出所有bug
领导层的软件质量思想有多少，很多？？？？
4软件出现bug数的多少，是测试人员用心测试发现的，还是开发人员水平次产生的，对测试人员以bug多少及等级评比，对测试人员是否公平，测试人员的权力多大，应该考虑的是软件最终的质量
难呀！！！！！！ 系统分析员、程序员跟其他测试人员一起参加这个评审活动，主要要看测试用例对需求的覆盖率，测试用例的正确性、全面性、用例是否具有代表性（最少用例能测试最多的缺陷），测试用例是否描述清楚（期望结果是否说明） 系统分析员、程序员跟其他测试人员一起参加这个评审活动，主要要看测试用例对需求的覆盖率，测试用例的正确性、全面性、用例是否具有代表性（最少用例能测试最多的缺陷），测试用例是否描述清楚（期望结果是否说明） 个人认为所有的流程和规范都是为了目标的实现
测试的目标是确保质量，提高客户满意度
寻找BUG永远都是手段而非目标，
流程应该越简单越好
简单的本身就可以提高效率
检验工作的完成程度就是你希望他做到的程度
如果别人不明白你的期望或要求
就不可能满足你的期望和要求，
所以建立规范之前，首先要想清楚公司的整体目标而后是该如何达到目标
另外最关键的是要把团队的目标和每个团队成员个人的目标结合起来
只有这样才会产生效果...:) wangnan说的那些观点都挺正确.
但具体到评审测试用例的好坏,我认为可以通过下面几点考虑:
1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维. 各位DX提到的很关键。
我们在评审的过程中也有几个方面考虑：
1.找出哪些需求不可测：无法准备环境、可测试性达不到等等原因；
2.对具体需求的实现结果，设计人员、开发人员、测试人员的认识是否一致，如果不一致，谁说了算；
3.对于被测对象的性能是否有要求，怎么测？（很多模块不能用loadrunner这样的工具）
4.是不是所有的测试用例都很有价值，有些测试用例是不是可以省略来降低成本？
5.是不是把最多的测试用例精力放在模块的最主要功能上了呢？
有点疑问
那如果是由不同的人员各自负责一部分的功能点,这样写出来的用例会存在上面提到的那种情况吗(把最多的测试用例精力放在模块的最主要功能上.)? 感觉是内部标准不太统一，应该首先保证覆盖需求，然后考虑性能和压力。 同意asong401的观点1.测试用例是否覆盖了所有需求.
2.测试用例内容是否正确,是否与需求目标一致.
3.测试用例内容是否完整,是否清楚包含输入和预期输出结果.
4.测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维.
初期设计测试点时，应该进行测试组内部评审，当然首先是要保证需求全被覆盖，如果能在评审时，让需求分析人员参与进来，效果会更好。
补充
主要的一点还应邀请产品工程师来参加这个内部评审。目的是对测试用例中所覆盖的系统业务是否正确。 首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。如果是测试组内部的评审，应该着重于：
1. 测试用例本身的描述是否清晰，是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如：
收集客户需求的人员注重你的业务逻辑是否正确；
分析软件需求规格的人注重你的用例是否跟规格要求一致；
开发负责人会注重你的用例中对程序的要求是否合理。
要清楚地一点是：为了保证测试用例设计的质量，以及评审的收益，在提交项目组评审之前，必须通过测试部门或测试组内部的评审。 谢谢楼上各位前辈朋友的交流讨论，让我受益非常，刚好新公司要欲成立测试部，有幸作为其中的一份子，我深感内部优化的重要性。而作为其中起着关键作用的评审，今儿终于让我找到了完善的方向，再次感谢～～ 开发部的人员参加，主要是看测试用例的覆盖面是否到位
测试部内部的人员参加是看些的规范性，是否冗余，是否合理等
反正与开发部门是由一点区别的 开发部的人员参加，主要是看测试用例的覆盖面是否到位，可以指出重要测试点。 评审不光是审文档，还有个目的是看测试用例是否完善，方向是否有偏差。上一级主管及相关领域的测试负责人、开发人员都可参加 大家的提议都很好，其实最主要的是自己公司所执行的流程，然后在选择合适的评审方法，其实我更支持yayachen1109所说的内容，讲的很全面，也考虑的很周到了！根据自己公司的特点适当的剪裁才是最重要的！ 我感觉对测试用例做内部评审是很重要的。
我个人认为：
（1）评审人员应该包括：开发人员、系统分析人员、项目经理、相关测试人员。
（2）主要评审的内容应该包括：
<1>测试用例是否覆盖了所有需求.
<2>测试用例内容是否正确,是否与需求目标一致.
<3>测试用例内容是否完整,是否清楚包含输入和预期输出结果.
这是个人的意见。 顶！我不知道说什么，学习！
