怎样保证用例覆盖全面 如何保证用例覆盖到罕见缺陷

如何提高测试用例的覆盖率问题？

1、功能的连通性，即冒烟测试，正常的流程是否走的通。

怎样保证用例覆盖全面 如何保证用例覆盖到罕见缺陷

2、页面元素的检验，即检查页面字段内容、格式、边界值、数据类型、特殊字符、样式、布局等。

3、接口测试，通过工具传参看接口能否正常响应，包括输入一些异常的数据，看接口是否有校验。

4、业务逻辑检查，这个需要充分解读需求文档上的每一句话，逻辑判断控制，以及有耦合关系的模块，前置、后置等相关联的业务模块是否都正常，而不只是检查当前的功能模块没问题就可以了。

5、数据库表检查，即前台提交的表单是否在对应的每一个表字段都正确的写入。例如前台支付成功以后，数据库可能会更新很多张表，商品表、订单表、统计表、日志表等等，不是支付成功就表示这个功能就没问题了。

6、异常类测试，例如系统在弱网或者断网情况下页面是都有提示或者相关的判断，或者是一些交易类的功能可能会回调超时，超时代码是否有重发机制等等，具体要看你测的是什么领域的业务，都有一些特殊的场景或者异常操作，往往这些就是测试的盲点

测试用例怎样编写才能尽量做到完全覆盖

家都知道，测试用例的一个核心作用就覆盖测试需求，尽可能的减少漏测，同时提高测试效率。再细想想，这种核心作用的本质也就是一种“提醒”作用。

你可能会说“对呀，本来就是这样的呀，没啥问题呀”。我也觉得这个本身没错，那关键的问题是什么呢？ 问题在于时间和可执行性。

话说，写用例、设计用例是需要时间的，而在追求速度的时代，似乎连这点时间都给不起。这不是我吹的，特别是互联网，大部分公司都采用敏捷开发模式，讲究快速，所以，时间往往是有限的，再加上很多公司对敏捷仅停留在概念阶段，以为“敏捷=快速”，把时间花在用例设计上简直就是一种浪费….这样一来，用来设计用例的时间有时候，真是少之又少。如果按传统方式，把用例写得很详细，各种前提条件，步骤，说明，预期结果，编写人，日期啥的，这个时间成本是很高的。

再说可执行性。经常看到一些人写用例写得很认真，很详细、具体，把每一步的操作都写了，还有一些人一个用例下来，十几个步骤，包含了n个验证点。这种用例的可执行性咋样呢？按我的经历来看，这种类型用例，在测试的时候，用例编写人自己都懒得看用例，完全是按自己的当前时间的想法来测试，而非用例编写人呢？同样的，他也不会完全按照上面的步骤来执行，人嘛，都喜欢按自己的方式来做事，谁会看一下用例步骤，然后操作一下呢？所以，后的结果是，用例文档就是摆设，放在那里，没人看。

怎么破？

我的观点是：测试用例必须写，而且还要“精炼”：能不写的尽量不写，能“简写”的尽量简写----“精简”的思维->简而言之，当前面的部分，已经起到了足够的提醒作用时，后面部分就可以不写。这样做的好处是，不仅可以节省时间，而且还给执行用例的人留下一定的思考空间，有利于TA的成长。

思维导图编写用例为例：

1. 一看用例名，就知道步骤及预期结果的，仅写用例名

这里的用例名，也就是我们的测试点、需求验证点。

这里对编写测试用例的人有个要求：语言组织能力+思维能力，尽量做到划分合理，且见名知意。

2. 仅看用例名，不能预知操作步骤的，还须把操作步骤写出来

3. 仅看用例名，不能预知预期结果的，还须把预期结果写出来

4. 预期结果、操作步骤有时候都可简写：直接以备注、说明、提醒点替代

对比上面的，这样写可能会给人有点“乱”的感觉，但是换个思路想，

这里实际是把预期结果、操作步骤当作是子验证点(即子用例)，采用第一条规则，这里的子用例仅写了用例名,即提醒点，验证点。也就是说，这条用例是由一组子用例构成的。

注：用例粒度可粗可细，结合时间成本考虑，做到合理的划分即可。

5. 针对一些步骤比较复杂的用例，步骤和预期结果都要写出来。

复杂情况下，一个用例包含多个操作步骤，这些操作步骤中，每个步骤可能都对应一个子测试点(预期结果)。如上，可以新增一个结点，填写预期结果，也可以和操作步骤写在同一个结点，以括号等不同方式进行区分，具体根据个人喜好或者大家达成共识的统一风格。

6. 技巧

根据具体情况，可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等)，让人看得更明白

为了避免模块层级过多，可以不进行模块划分就不划分，当然也可以采用其它技巧，比如模块名称写成“大模块-子模块”的形式 例子

面试问题：如何确保测试用例覆盖所有需求点？

一般我会觉得这个问题问得不够好，在实际测试中，我们都知道测试用例是不可能完全覆盖所有需求。只能说如何能更好的提高测试用例的覆盖率。首先是对需求点的分析，显性的需求点是很好设计测试用例的，但是对于隐形的需求，就需要进行分析。再则，需求覆盖率针对的是单个具体功能点，对于多个功能点的组合，要求覆盖所有，太难。

恩赞同

futogether

“只能说如何能更好的提高测试用例的覆盖率”的说法。也谢谢大家了

！

软件测试中，测试用例要怎么分析才能全部覆盖而不遗漏

测试遵循一个

good

enough

原则，百分百的覆盖是不可能的，因此在核心需求的覆盖上满足全部覆盖就好，另外测试覆盖度越大，投入的就会越高。

如何知道自己所写的测试用例是否覆盖完全

简单的办法就是：系统测试完毕后，如果一个bug都没有，则代表覆盖率。

测试用例覆盖率很难达到，越复杂的功能越难保证，只能说尽量提高测试覆盖率。

通过以下手段可以提高覆盖率：

1、编写测试用例前，检查相关需求需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。

2、然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例），同时还需要对既有功能进行一个梳理，检查是否会与其他功能有交互，整理出影响点。

3、把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。

4、后才行进测试用例编写，注意编写规范。

5、编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。

6、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优

7、测试完毕后对漏测的bug进行测试用例补充。