怎么保证测试用例的覆盖率?

-------------------------------------------------------文章参考 乐搏软件测试

《怎样保证测试用例的覆盖率？【切面设计】》

《怎样保证测试用例的覆盖率？【详细用例设计】》
《怎样保证测试用例的覆盖率？【测试数据设计】》

---

个人觉得在编写测试用例的前提，是需要了解产品的业务流程，以及数据的来源和走向。

需要关注内部处理、专转换、业务逻辑、相互影响等关系。

测试用例的切面设计：

一般我们在分析需求的是，是从上到下，逐渐细分，大模块包括小模块，依次拆分到最小功能。

此时我们要注意的是：

1.功能点切面：

        我们可以从最小功能点，比如一个输入框，使用我们所学的等价类边界值等方法进行分析。

需要注意：组合查询，新增数据->修改->删除->再次新增->查询数据是否正确；按钮多次点击是否出现异常；存在严格前后顺序的，颠倒顺序操作，系统是否会出现问题。

• GUI界面测试：一定要从使用者的操作习惯出发，从用户操作方便性考虑。
• 数据初始化情况测试：

       不该为空的数据是否有校验；

        该有默认值的数据默认值是否正确；

        引用其它功能生成的数据，是否会实时刷新；

        页面关闭或系统重启后，数据的初始化设置等都是这类用例。

• 业务需求实现是否正确：

　　数据的长度、类型控制是否合理

　　业务逻辑控制是否合理

　　提供的实现方式是否合理

　　所做的数据控制是否合理

　　所做的数据控制是否完整

　　还有其它一些操作细节上的满足

---

2.特定切面：

        提取界面通用操作单独写成一页，比如说，前端有七八个功能界面，都是由同一个后台进行处理，那么我们就可以将这个后台操作的点，单独写一模块。

       

3.隐含切面：

        后台隐含处理（比如有效时长，轮询开启等）；多个功能之间的关联处理（这个也是比较容易出问题的）；某种特定情形下的处理；

        测试用例还是需要从点（功能点）、线（完整的一个功能项）、面（多个相关功能结合成完整业务流）三个方面进行区分编写

        特定情况下处理（这个是比较容易被遗漏且比较容易出纰漏的地方）：日期处理：月尾一天、月头一天、年尾一天、年头一天；比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如；再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等

         编写测试用例时们需要考虑数据完整性：数据源删除或者关键字修改后引用的数据是否会出错。两个途径进入的数据是否会冲突或重复。还有因为相关的几个功能由不同人员编码，从而导致彼此的控制不一致，如A功能进入的数据在可允许的极端情况下，到B功能中引用会否异常。

        后台特殊处理：订单保存时，后台是否会有重复数据的判断、非法数据的处理、业务逻辑上的冲突情况处理。比如备份功能，在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等

        功能业务之间的关联与转换：相关联的几个功能之间数据的传递，是否产生影响；

新增录入的某种特殊字符，要查询时会引起查询SQL语句异常；下载文件名中存在中文等字符，下载时由于编码问题导致乱码的出现；

        并发操作时的测试：两个/多个用户同时操作同一功能引起数据的混乱。【同开页面，或者多端操作】

        无界面的后台功能：通过参数设置、代码调用等方式实现测试，测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突？

        比如后台有个文件搬运的服务，那有没有可能在前台文件生成过程中，后台执行文件搬运了？若有可能就要注意会否出现问题了。----------------这个确实没有考虑到过。

        业务流的相关测试：建议画流程图，然后依次组合测试

        

---

4.第三方系统模块、组件、函数，确认是否需要测试

5.除功能测试外的其他类型测试

        可靠性（准备大量数据不停地执行）、安全性（考虑数据的加密、数据的传输、数据的破坏）、恢复性（一般从网络、电源方面着手）、配置安装测试（根据系统可支持的配置，搭建相应环境进行功能验证）

测试数据注意点：

1. 设计的数据必须时唯一性，结果不能存在二义性
2. 对于不便具体列示的数据，要详细描述清楚你要测试的数据特性：比如数据库字段限长20，要测试超长数据时，可以描述为：尝试输入长度为21位的半角英文字符；尝试输入长度为19位的半角英文字符，然后切换到中文全角再输入一位全角字符等。
3. 测试数据的设计必须有明确目的性