测试用例设计得不可能天衣无缝，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现;那么事后该将其补充到用例库里，以方便他人和后续版本的测试;如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范或流程了。
那么究竟如何做，才能尽量避免上述问题呢?我们不妨从需求阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，以防后期出现问题是互相推卸责任或干脆束手无策!
软件需求分析阶段，我从来认为测试人员从软件生命周期的需求阶段就开始介入，因为测试人员的工作通常开展在该周期的末尾，如果前期不涉入，如何通晓整个系统的架构而对其测试呢?虽然该观点被大多数同行所认可，但我知道依然有很多公司为了节省费用，不让测试人员参与前期调研或制定需求，经常的做法是等到系统开发完毕或将近完成，跟测试经理说一声“这边有个项目，你找几个人来测一下吧!”经验表明，这样的做法实不可取。
测试人员在需求阶段的任务有：
全面了解系统需求，从客户角度考虑软件测试需要达到的验证值。
参与软件需求调研，以测试角度分析需求的可测性;对不可测问题与客户或项目经理协调解决。
如果企业采用类似与rational requistepro的需求管理工具，这个工作也需要测试人员的配合实施。
软件分析设计阶段，测试人员除制定测试计划书等本职工作外，我认为还有一个必不可少的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。
如果公司采用类似于rational rose的建模分析工具，这个工作更好执行;如果没有，那么测试人员更有必要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的分析文档加工成站在测试角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试 何种数据测试 期望测试结果等，这些信息都是描述性的，无须具体数据;它的作用是据此编写测试用例，以及测试执行时的参考依据，它直接来源于需求，覆盖最全，也最贴近客户。
当然该文档不是非要不可，我只是提倡一种原则，如果有类似的替代文档或有自动工具可实现此功能，则会倍加受推崇!软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大质量优异的测试用例(可参见我在“天若有情”转载的这篇文章- 如何设计编写软件测试用例)，这里只想从管理角度和大家谈谈如何有效控制测试用例的流程。应该遵守的原则是：
首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。按照我上述所言的测试工程师从前期阶段顺次下来，编写测试用例时，基本就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是将从步骤上描述到达校验点的方式，二是从内容上以何种数据校验功能点。
文章来源于领测软件测试网 https://www.ltesting.net/
