当然该文档不是非要不可，我只是提倡一种原则，如果有类似的替代文档或有自动工具可实现此功能，则会倍加受推崇!软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大质量优异的测试用例(可参见我在“天若有情”转载的这篇文章- 如何设计编写软件测试用例)，这里只想从管理角度和大家谈谈如何有效控制测试用例的流程。应该遵守的原则是：

　　首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。按照我上述所言的测试工程师从前期阶段顺次下来，编写测试用例时，基本就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是将从步骤上描述到达校验点的方式，二是从内容上以何种数据校验功能点。

　　其次，从数量来讲，我觉得很多公司的测试用例太少，甚至远远不能覆盖系统需求，这也是很多测试人员测试开展前期按照用例执行，渐渐凭“意念”去测试的原因。应该说测试用例的数量很难用数学模型来模拟，更没办法衡量，但凭借个人经验来说，一个多于半年开发周期(指从编码开始直到提交客户的时间段)的软件系统，它的用例数量不要低于4000个，甚至更多!也许有人惊讶这一数字，不过了解IBM Microsoft 的人士会认为4000还是很少的。试想，对于一个中型软件系统，如果设计出5000个用例，那它的测试覆盖率还怕不高么!

　　再次，如此众多的测试用例的管理。是的，需要管理工具软件!本人从来都反对以word或excel来编写测试用例，那样不仅在格式上难于编写——尤其对于一些共性内容：测试目标、测试环境、参考说明等，每次都要拷贝;而且难于管理——几千个文档文件放在一个共享文件夹，你的眼睛要必将经过缭乱的洗礼!更是难于执行——莫非真要针对几千个用例都是打开一个word、执行测试、输入测试结果、关闭word?而且，根本没办法追踪测试结果——输入完本轮回归测试的结果，下一论输入哪里?输入了这些测试结果什么用?用它追踪什么?追踪得到吗?

　　使用word等软件编写测试用例的种种不便不多说，但换个思路思考一下使用集成工具的种种优势就一见分晓。测试同业者们都了解的测试用例管理工具便是rational testmanager(点击http://www-900.ibm.com/cn/software/rational/products/testmanager/index.shtml了解其基本功能)，其实还有很多国内外中小型工具，如微创的testcasemanage，他们是专业的测试用例管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案，他们是专业的测试用例管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。

　　最后，说一下测试用例格式上一般说明外的几个要点：

　　一是在测试管理工具中制定适合本公司的测试用例模版

　　二是模版有关键字索引，以方便按关键字分类查找，如测试方法(分手工/自动两种)

　　三是测试用例要有状态跟踪，如执行失败要链接到缺陷报告

　　四是测试用例的修改及运行都有日志记录

　　软件测试阶段，测试负责人划分不同的测试阶段(如集成测试 系统测试 回归测试 性能测试等)，再划分不同的子测试周期(如前两个星期做冒烟测试，可手工，也可自动;接着做第一模块功能测试，顺次…)，再为项目测试人员分配测试用例，测试人员则按照详细的用例文档去执行测试，这里要遵循的几个原则是：

　　A，有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例设计和编写就是项目全体测试人员智慧的结晶!我们一直追问众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段，如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

　　B，如有对用例认识模糊或遗漏的地方，必须经测试负责人或项目其他管理人员同意方可更新用例库。

　　C，测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级和项目高层或其他人员交流，商议解决途径，并确定或调整未来时间的测试任务。

　　D，测试执行者负责执行自己区域的测试用例，也要负责跟踪该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。

　　E，应该提及的是，大多数软件公司都采用集成的缺陷管理工具来管理软件缺陷，如rational clearquest、mantis、bugzilla、TestTrack Pro等，这是好事情，因为这些集成工具都提供了清晰的报告模版及优秀的追踪功能，测试团队的每一成员按照自己的角色和权限要不断追踪缺陷的状态。

　　F，对于自动测试(包括性能/压力测试)，有一些特殊要点。本人的原则是自动化测试无须编写测试用例，故而到此阶段才提及自动化测试;只要在编写时将用例库里适合或需要自动测试的用例的测试方法(不同工具可能名称不同)设为自动即可。自动化测试的实施方案有所不同，每款测试工具的使用和流程也不同，但都是从在这一阶段编写测试脚本，并运行自动测试。针对自动化测试原则，可参阅我的 自动化测试要点，这里要提的几个基本原则是：

　　一是选择恰当的测试工具品牌，并要求提供培训

　　二是项目测试成员有专人负责此事的进行，他们可不参与日常测试

　　三是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态

　　四是选择最简单 最重用的测试用例使用自动测试方法

　　五是使用工具厂商提供的测试框架编写脚本，千万别单纯的录制/加校验点/回放，以开发出健壮的且重用性强的测试脚本

　　六是有专人更新脚本，也有专人跟踪自动测试结果

　　七是一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理，由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试，甚至代码级单元测试等，这些需要酌情考虑测试用例的编写，以及测试的执行。

　　软件验收阶段，除了提交软件测试评估报告(各种类型测试结果的评估都有报告)这些传统工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试，即便是项目软件——提交客户后没有新版本，那也需要后期维护，维护阶段需要重新测试某功能点，然而用例不准确，碰巧又是个新员工，那就死翘翘了!

　　退一步说，如果您公司的测试部门经历一次这样重大的洗礼，有一个项目真正按照此原则实施一次，也必将对未来取得事半功倍的效果。

　　总结：综上所述，我们得出结论:

　　测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利;

　　测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全不规范;

　　测试行业仍处在群雄逐鹿、百家争鸣的时期，芸芸纷说，不如从自身出发，确立最适合自我的解决方案，整顿自身的工作流程，那才是金玉良言的上上策!