其次，从数量来讲，我觉得很多公司的测试用例太少，甚至远远不能覆盖系统需求，这也是很多测试人员测试开展前期按照用例执行，渐渐凭“意念”去测试的原因。应该说测试用例的数量很难用数学模型来模拟，更没办法衡量，但凭借个人经验来说，一个多于半年开发周期(指从编码开始直到提交客户的时间段)的软件系统，它的用例数量不要低于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，他们是专业的测试用例管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案，他们是专业的测试用例管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。
最后，说一下测试用例格式上一般说明外的几个要点：
一是在测试管理工具中制定适合本公司的测试用例模版
二是模版有关键字索引，以方便按关键字分类查找，如测试方法(分手工/自动两种)
三是测试用例要有状态跟踪，如执行失败要链接到缺陷报告
四是测试用例的修改及运行都有日志记录
软件测试阶段，测试负责人划分不同的测试阶段(如集成测试 系统测试 回归测试 性能测试等)，再划分不同的子测试周期(如前两个星期做冒烟测试，可手工，也可自动;接着做第一模块功能测试，顺次…)，再为项目测试人员分配测试用例，测试人员则按照详细的用例文档去执行测试，这里要遵循的几个原则是：
文章来源于领测软件测试网 https://www.ltesting.net/