不知道现在其他的一些公司，是否会遇到这种情况：

　　公司的一些内部项目，启动时也有一些文档，如：需求规格说明书、概要设计等

　　我们在测试的时候呢，却发现需求中提到的很多东西都没能实现。但是根据和项目经理的沟通，我们的产品已经可以达到上线推广使用了，而且时间紧，那些需求中提到的东西要在以后逐步完善（可需求中并未提到是要分批次完成）

　　这个时候我们在测试完毕后（需求中完成的部分都以符合要求），我们在测试报告中，计算需求覆盖率，要怎样去考虑和分析这个问题呢？

　　如果公司的软件生产流程还不规范，我们应该以怎样的对策去面对，那些突如其来的问题呢？

　　呵呵，像这样的情况我们公司也有，但是由于某些原因我们没有去写测试报告。个人觉得这个时候本不应该计算需求覆盖率，如果真需要计算的话只需要计算实现了的需求的测试覆盖率，同时还需要注明哪些需求没有实现。

　　说实在的，这样的测试老火啊！

　　用例执行百分比=项目完成百分比

　　时常会有人通过用例执行的百分比来宏观的去看一个项目的测试进度情况。

　　但是遇到这种情况的时候测试工程师会说，用例的执行的百分比不足以展示一个项目的测试进度。

　　为什么会有这种矛盾呢？

　　其实这个等式成立有一定的前提条件，那就是测试工程师写的测试用例的测试粒度是否合理

　　怎样的粒度才是合理？

　　1、测试粒度不宜过细，测试用例分解的测试粒度过细会给测试工程师带来成倍的额外工作量，对于项目管理来讲，这样是不合算的。

　　2、测试粒度不宜过粗，这是因为如果一个测试用例，里面包含了太多验证点。比如在写取钱的用例时，要检查余额查询，用户最大额度查询类似的本可以单独一个用例的东西都硬拼到了一起，那么用例的执行进度和项目的进度肯定不能划等号。简单说就是有的用例简单有的用例复杂，所以有的也许要验证半天，有的只需要10分钟。这样的话，文章开头的等式就当然不相等了。

　　粒度过粗还有个麻烦就是，发现很多bug都对应着一个用例。这样给缺陷管理和统计起来也带来麻烦。在项目后期的报告中不能清晰的统计缺陷。

　　如何划分测试粒度？

　　1、使用功能点划分，细化每个功能点，到这个功能点不能再拆分。

　　2、所要测试模快对该系统的整体影响.看其重要性。

　　3、最好在用例编写前，项目的测试工程师可以讨论出一个适合项目的统一测试粒度。