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

测试用例是否覆盖完全要进行以下测试：

1、数据完整性的测试

当某数据被其它功能引用；或当前功能要引用其它来源的数据，就会涉及到数据完整性的测试。最常见的如被引用的数据删除了，或关键字被修改了，引用的数据会否出错；

2、后台的特殊处理

是指某功能除了表面所见以外的程序处理。比如订单录入，表面所见的就是订单的保存，但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理

3、功能业务之间的关联与转换

相关联的几个功能之间数据的传递，会否产生影响。比如新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；又如某下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；再有报表填写时到小数点后四位，生成报文时会不会被忽略成两位了等等。

4、从设计实现发掘测试点

这个就是我们测试中最难捉的BUG了，它往往是由编码人员自己在编码时创造出来的，连设计人员都不会知道。

此时若能确切知道采用的是哪种实现方法，就可以直接找到其漏洞所在。比如采用后一种方法，当产品类别长度变化时，明显系统会出错。那么即使确认该实现方式不改，测试人员也应将其作为限制写入测试报告。

5、并发操作时的测试

即两个或多个用户同时操作同一功能时，会否引起数据的混乱。通常在C/S结构下，如果有同时操作的可能，是需要做此测试的；而在B/S结构下由于其特殊性，此问题通常难以解决。

6、GUI界面的测试

这类测试是测试人员的强项，具体测试项目如限长、非法输入等等，就不必赘述了。要提醒的是在测试时，一定要从实际使用者的操作习惯出发。要知道界面原型所能确定的也只是页面的摆放显示，而实际操作时的控制实现仍是编码人员自行实现的。

7、数据初始化情况测试

不该为空的数据是否有校验；该有默认值的数据默认值是否正确；引用其它功能生成的数据，是否会实时刷新；页面关闭或系统重启后，数据的初始化设置等都是这类用例。

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

测试用例覆盖率很难达到100%，越复杂的功能越难保证，只能说尽量提高测试覆盖率。
通过以下手段可以提高覆盖率：
1、编写测试用例前，检查相关需求需求、设计文档是否有问题（功能描述不清，设计逻辑缺陷），如有问题找相关设计或者开发问清楚。
2、然后整理成需要覆盖的功能列表或者思维导图，功能列表包含新增和修改功能点，性能需求也要列出来（因为要整理对应的性能测试用例），同时还需要对既有功能进行一个梳理，检查是否会与其他功能有交互，整理出影响点。
3、把功能列表发给组员，并找时间进行会议评审，主要对功能等进行查漏补缺。
4、最后才行进测试用例编写，注意编写规范。
5、编写完毕后，把测试用例发给组员，开会进行评审，主要对检查点、用例规范进行查漏补缺。
6、执行测试用例过程中，发现用例不完善或者错误，需对测试用例进行及时的修改与调优
7、测试完毕后对漏测的bug进行测试用例补充。

用户名和密码,这两个选项都各有3种可能:为空,错误的,正确的
所以,10多中情况不就出来了

测试用例很难完全覆盖的，但是只要保证基本功能的测试用例写完全了就可以了
在测试时，除了需要按照测试用例执行外，还要测试者的经验等等。
有些bug是不能通过测试用例来检测出来的。