标准测试中一天能写多少测试用例？执行多少用例？这个有标准不？

Posted 2023-05-16

普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。不标准，在工作过程中难免会有一些因素影响进度的。

测试用例的标准：

A.覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑），即正常流和异常流。

B.覆盖到所有的典型用户场景。

C.覆盖到所有的需求点。

D.测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短。

E.没有冗余的用例。

F.测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚。

/iknow-pic.cdn.bcebos.com/9345d688d43f8794bc38d448dd1b0ef41ad53a94"target="_blank"title="点击查看大图"class="ikqb_img_alink">/iknow-pic.cdn.bcebos.com/9345d688d43f8794bc38d448dd1b0ef41ad53a94?x-bce-process=image%2Fresize%2Cm_lfit%2Cw_600%2Ch_800%2Climit_1%2Fquality%2Cq_85%2Fformat%2Cf_auto"/>

扩展资料：

写测试用例的技巧：

（1）基于需求的用例设计过程：

A、用例编写过程：首先参照需求文档以及项目原形交互图，划分模块，以及具体的测试点，然后整理出详细的测试点文档，然后根据文档一条条编写测试用例；充分利用相关的用例编写技术。包括：

边界值分析法、等价类分析法、错误类推测法、路径覆盖法、因果分析法、正交分析法等；分析用例是否能够通过自动化或者其他测试手段来覆盖到。

B、用例评审过程：首先对照需求表来进行检查，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题。

其次评审该部分用例是否跟前面的逻辑用例和场景用例冗余；最后分析用例是否能够通过自动化或者其他测试手段来覆盖到。

（2）基于逻辑的用例编写过程：

A.用例编写过程：首先进行全面的需求分析，分析系统包含哪些功能模块，各功能模块下富含哪些子模块，每个模块之间的逻辑关系，分析一下这个需求是否存在不合理的地方。

其次完成业务逻辑图或者流程图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，正常的逻辑过程以及异常的逻辑过程，并且自己能够理解为什么这样处理。

再根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，整合成具体的文档，小组讨论并提交缺陷预防bug。

另外根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖；最后有一个原则要注意，用例要按照10分钟原则，即保证10分钟内能够执行完成，此原则针对较复杂的逻辑操作，对于大部分的测试用例都可以保证。

B.用例评审过程：前期要求参与审核的人员自己先进行需求分析，然后把自己不理解或觉得有问题的地方记录下来；然后项目主负责人先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做。

并且分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式），大家在一起讨论各种可能存在的情况，然后进行评判和筛选，找出更多的测试点。

分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式）；是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例。

分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑；分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点）。

分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率。

（3）基于场景的用例设计过程：

A、用例编写过程：整理清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么；查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面。

在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）；客户会怎样去配置该模块以满足什么样的需求（头脑风暴）；过程中客户会有哪些操作（头脑风暴）。

B、用例评审过程：安排相关项目经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户。

安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例。

C、友情提醒：模块用户场景尽量是有真实的客户，而不是自己臆想出来的；模块用户场景最好是完整的客户使用过程，而不是某一个测试点；并不是所有的模块都有场景用例。

参考技术A

普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。不标准，在工作过程中难免会有一些因素影响进度的。

测试用例的标准：

A.覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑），即正常流和异常流。

B.覆盖到所有的典型用户场景。

C.覆盖到所有的需求点。

D.测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短。

E.没有冗余的用例。

F.测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚。

扩展资料：

写测试用例的技巧：

（1）基于需求的用例设计过程：

A、用例编写过程：首先参照需求文档以及项目原形交互图，划分模块，以及具体的测试点，然后整理出详细的测试点文档，然后根据文档一条条编写测试用例；充分利用相关的用例编写技术。包括：

边界值分析法、等价类分析法、错误类推测法、路径覆盖法、因果分析法、正交分析法等；分析用例是否能够通过自动化或者其他测试手段来覆盖到。

B、用例评审过程：首先对照需求表来进行检查，是否全部覆盖到，不仅仅是测试用例，还包括测试步骤和期望结果，避免因为依赖研发的逻辑来设计用例导致问题。

其次评审该部分用例是否跟前面的逻辑用例和场景用例冗余；最后分析用例是否能够通过自动化或者其他测试手段来覆盖到。

（2）基于逻辑的用例编写过程：

A.用例编写过程：首先进行全面的需求分析，分析系统包含哪些功能模块，各功能模块下富含哪些子模块，每个模块之间的逻辑关系，分析一下这个需求是否存在不合理的地方。

其次完成业务逻辑图或者流程图，需要在测试的角度上面去画逻辑图，包括数据流完整的输入和输出过程，正常的逻辑过程以及异常的逻辑过程，并且自己能够理解为什么这样处理。

再根据自己的理解分析每个逻辑的处理是否完善，是否有没有覆盖到的地方，整合成具体的文档，小组讨论并提交缺陷预防bug。

另外根据逻辑编写测试用例，保证每个逻辑都能够有对应的用例覆盖；最后有一个原则要注意，用例要按照10分钟原则，即保证10分钟内能够执行完成，此原则针对较复杂的逻辑操作，对于大部分的测试用例都可以保证。

B.用例评审过程：前期要求参与审核的人员自己先进行需求分析，然后把自己不理解或觉得有问题的地方记录下来；然后项目主负责人先讲解整个业务逻辑图，需要保证评审人员对于整个业务逻辑图都非常清楚，并且能够理解为什么这样做。

并且分析整个业务逻辑图是否有没有覆盖到的场景或者分支情况（采用头脑风暴的方式），大家在一起讨论各种可能存在的情况，然后进行评判和筛选，找出更多的测试点。

分析业务逻辑的异常处理情况（是否每个业务逻辑都有对异常情况进行处理，也采用头脑风暴的方式）；是否将逻辑的用例分类比较合理，让大家通过逻辑很容易就找到对应的用例。

分析是否所有的逻辑都能够找到对应的用例（通过逻辑找到对应的用例）,包括前面没有考虑到的逻辑；分析用例是否有冗余，是否多个用例都是覆盖的同一个逻辑（包括测试步骤和检查点）。

分析用例的测试方法是否有改进，是否能够直接通过代码静态走读、接口测试、自动化测试（包括编写脚本）、引入工具等等来进一步提高我们的测试效率。

（3）基于场景的用例设计过程：

A、用例编写过程：整理清楚客户的原始需求，为什么需要这个功能，能够给客户带来的价值是什么；查看需求说明书里面的客户使用的典型用户场景，并且整合到场景用例里面。

在需求说明书的基础上进一步分析客户还可能有哪些实际的使用场景（主要是整个客户的拓扑结构）；客户会怎样去配置该模块以满足什么样的需求（头脑风暴）；过程中客户会有哪些操作（头脑风暴）。

B、用例评审过程：安排相关项目经理和主管来进行评审，主要是分析还可能有哪些场景没有考虑到，最好是能够有具体的客户。

安排讲解该模块的场景，保证用例责任人对模块场景是非常熟悉的，并且过程中分析是否可能会有其他情况，来进一步完善场景用例。

C、友情提醒：模块用户场景尽量是有真实的客户，而不是自己臆想出来的；模块用户场景最好是完整的客户使用过程，而不是某一个测试点；并不是所有的模块都有场景用例。

参考技术B

普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。不标准，在工作过程中难免会有一些因素影响进度的。

测试用例的标准：

A.覆盖到所有的业务逻辑（包括正常逻辑和异常逻辑），即正常流和异常流。

B.覆盖到所有的典型用户场景。

C.覆盖到所有的需求点。

D.测试目标明确，并且测试步骤能够最快的达到测试目的或者测试时间很短。

E.没有冗余的用例。

F.测试用例能够直接附带测试策略，该模块的策略指定人和用例执行人能够非常清楚。

扩展资料

确定测试用例之所以很重要，原因有以下几方面。

(1)测试用例构成了设计和制定测试过程的基础。

(2)测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，测试人员对产品质量和测试流程也就越有信心。

(3)判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。

(4)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

(5)测试设计和开发的类型以及所需的资源主要都受控于测试用例。

(6)测试用例通常根据它们所关联的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。

参考资料来源：百度百科-测试用例

参考技术C 这个要根据测试用例的难度，不能一概而论。
不过，普通的测试用例（执行步骤不超过10步）的话，高质量的测试用例一天编写一般在30个左右，执行在50个左右。在工作过程中难免会有一些因素影响进度的。本回答被提问者采纳

测试用例你了解多少

什么是测试用例？

一组由前提条件、输入、执行条件、预期结果、等组成，已完成对某个特定需求或者目标测试的数据，体现测试方案，方法，技术和策略的文档。

为什么要写测试用例？

科学有效的对测试步骤进行组织规划，方便管理，记录。

测试用例主要包含哪些内容？

编号、日期、设计和测试人员、优先级、标题、目标、环境、输入数据/动作、预期结果

编写测试用例需要什么？

软件需求设计说明书、软件模板

设计测试用例的注意事项

从高到低、独立性、与功能一一对立，根据需求设计，由有经验的人员设计

设计测试用例的注意事项

有模板，正确性，代表性，可判断性，重现性，详细准确清晰的步骤，符号规范

用例的管理工具

市场上的用例缺陷管理工具有很多：这里列举几个：mantis、redmine、jira、bugzilla、禅道等

用例的管理过程

编写>评审（修改>再次评审）>使用>保存管理>维护/升级