背景
今天在这里给大家分享做黑盒测试的一个痛苦经历，测到啥时候是个头啊？
介绍
记得第一次给自己设定目标——黑盒测试的用例覆盖度达到100%。大熊嘿嘿的笑了：“我看好你呦！加油。但是有一个问题，到时候我们怎么衡量呢？”
额~~~，这回问住我了。不出线上事故就是100%么？简单功能还好，复杂功能几亿的用户不出事故只能算运气。
或者如果写完测试用例后又给我补充了一个有效的测试用例那就不是100%。
做过黑盒测试人都知道100%的覆盖是不可能的，影响黑盒测试覆盖度的因素有：用户量、功能复杂度、功能类型等因素相关。
那么问题来了，还是如何衡量评估呢？以往的项目经验为例，都是有经验的黑盒测试人员进行主观的评估，还是没有直观、通用、可衡量的标准进行评估。
根据这个问题，开发了一款针对黑盒测试的代码覆盖率工具。黑盒测试执行完全部的测试用例之后给出一个相对的覆盖度。
以输入法现有的标准给大家一个参考：
功能类型复杂度用户量参考函数覆盖度
逻辑高***>90%
逻辑低***>95%
UI高***>70%
UI低***>85%
工具介绍
代码覆盖率工具设计如下：
客户端：
1. 需要新添加自动更新功能。
2. 筛选，添加版本选取、模块选取、路径选取、svn版本选取。方便用户使用，通用性变的更强。
3. 添加解释未覆盖的原因供使用者选取。
后台服务器：
1. 分为全新打包和自动两个流程，精简并优化现有的打包流程，避免再出现手动干涉。
2. 增量打包，缩短打包时间，优化打包的速度。
3. 重构svn的更新功能，更精准的定位变化的功能和函数。
数据库设计：
1. 重新设计了数据库的表结构，避免在开发的过程中重新设计表，功能大改。
2. 方便统计变化的功能模块和函数。
Web端显示：
今天先给大家介绍到这里，后续会针对代码覆盖率工具给大家进行详细的介绍。
