为何强化测试用例在测试活动中的作用 软件测试
本文不可能将软件测试流程优化的话题阐述的面面俱到，因此只从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。
1. 强化测试用例在测试活动中的作用
测试用例在实际中没有起多大作用,在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中……为何如此?我们分析认为，根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，从三个方面具体来说：
1) 测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢?答案是肯定的!
2) 制定了完备有效的测试用例，为什么不按测试用例执行测试呢?首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做;其次是个别测试人员投机取巧心理作祟的表现。
3) 测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试;如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。
2. 改进测试用例执行过程
那么究竟如何做，才能尽量避免上述问题呢?我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将其扼杀在萌芽阶段，以防后期阶段出现问题时互相推卸责任或干脆束手无策!
1) 软件需求分析阶段，笔者从来认为测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢?虽然该观点被大多数同行所认可，但我知道依然有很多公司为了节省费用，不让测试人员参与前期调研或制定需求，经常的做法是等到系统开发完毕或将近完成，跟测试经理说一声"这边有个项目，你找几个人来测试一下吧!"经验表明，这样的做法实不可取。
测试人员(指项目的测试负责人和测试工程师)在需求阶段的任务有：
a. 参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等;更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。
b. 全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。 推荐企业采用类似于IBM Rational Requisitepro的需求管理工具来制定和管理软件需求，同时需要测试人员的配合，保证对软件测试环节的充分考虑。
2) 软件分析设计阶段，测试人员除制定测试计划书等基本工作外，笔者认为还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。 之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。 如果公司采用类似于IBM Rational Rose的建模分析工具和IBM Rational Rose XDE Developer的可视化设计开发环境，这个工作更好执行;如果没有，那么测试人员更有必要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据;它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。
文章来源于领测软件测试网 https://www.ltesting.net/
