当然该文档不是非要不可，笔者只是提倡一种原则，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇!
笔者之所以推荐IBM Rational系列产品在软件项目中的应用，是因为IBM Rational倡导的RUP(Rational Unified Process)方法论采用了用例驱动的原则。所谓用例驱动，是以体系结构为中心，采用迭代、增量方式的开发过程;而其Rational工具系列正是将这一理念进行行为表述，是当前软件工程领域一套无可比拟的强大工具集，从需求到测试，它都以用例为基本模型，全面贯穿软件开发的每个环节。
3) 软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大、质量优秀的测试用例(可参考笔者主页转载的"如何设计编写软件测试用例")，这里只想从管理角度和大家谈谈如何有效控制和增强测试用例在测试活动中的应用。应该遵守的原则是：
首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。按照我上述所言的方式，测试工程师从前期阶段顺次下来，编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点;如此可实现趋向最大需求覆盖率。
其次，从数量来讲，笔者觉得很多公司的测试用例太少，甚至远远不能覆盖系统需求，这也是很多测试人员在测试工作开展初期按照用例执行、而后渐渐凭"意念"去执行测试的原因。应该说测试用例的数量很难用数学模型来模拟，更没办法衡量，但凭借个人经验来说，一个多于半年开发周期(指从编码开始直到提交客户的时间段)的软件系统，它的用例数量不要低于4000个，甚至更多!也许有人惊讶这一数字，不过了解IBM等大公司测试过程的人士会认为4000还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出5000个用例，那它的测试覆盖率还怕不高么!
再次，如此众多测试用例的管理问题。是的，需要管理工具软件!笔者从来都反对以word或excel来编写测试用例：
首先，格式上难于编写--通常方式是企业自己设计表格模版，但编辑上始终存在不便，尤其对于一些共性内容，如测试目标、测试环境、参考说明等，每次都要大量的复制、粘贴。
其次难于管理--如果把几千个文档文件放在一个共享文件夹里，即便以子目录方式管理，但是每次查找一个特定用例，你的眼睛也必将饱受煎熬! 更是难于执行--莫非真要针对几千个用例都是打开一个word-执行测试-输入测试结果-关闭word吗? 最重要的是，根本没办法追踪测试结果--在本轮回归测试输入完测试结果，但是下一轮结果输入到哪里?输入了这些测试结果什么用?能方便的根据其结果统计软件质量吗?还有，可以用它追踪发现的软件缺陷吗?有办法追踪吗? 使用word等软件编写测试用例的种种不便大致如上，但换个思路思考一下使用集成工具的种种优势便更加一见分晓。测试同业者们都了解的测试用例管理工具便是IBM Rational TestManager，它是专业的测试用例管理和测试管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。以其为测试管理平台，测试人团队成员可以计划、管理、组织、执行、评诂以及报告等纵向测试活动，如果与IBM Rational Clearquest集成使用，还可即时跟踪软件的需求变更，从而增强整个软件团队的横向沟通与合作。
而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。 最后，说一下测试用例格式上一般内容以外的几个要点：
一、是在测试管理工具中制定适合本公司的测试用例模版
二、是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法(分手工/自动两种)
三、是测试用例要有状态跟踪，可根据用例执行状态索引用例(测试通过、测试失败、测试中断等)
文章来源于领测软件测试网 https://www.ltesting.net/
