软件测试中强化测试用例在测试活动中的作用 改进测试用例执行过程

软件测试中强化测试用例在测试活动中的作用 改进测试用例执行过程

本文的目的不是将软件测试流程优化的话题阐述的面面俱到，而是从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。
常闻软件测试者的如此抱怨：
测试用例在实际中根本没有起多大作用？
测试人员在实际测试时都没有按测试用例来执行？
测试执行后没有把需要更新的测试用例补充到用例库中？
……

当前国内软件企业测试流程不规范的原因分析：

1） 从事物的发展规律看，软件测试行业在我国还是新兴行业，目前还处于起步和探索期，虽然国外的同行业发展到了一定阶段，但事实上他们也在不断的否定自我并探索着更成熟的方法、寻求着更有效的方案；而国内的测试行业发展期不过10来年，所谓的测试管理流程不规范，也就情有可原了。

2） 从企业个体角度讲，测试部门的整顿和加强，按照企业自身发展的优先层次，还没有被纳入优先解决的程度，开拓市场、签订定单才是首要问题，也是维系企业生存发展的命脉。当然国内很多优秀的大中型软件公司的测试部门相对完善，如神州数码、用友、联想等，他们和大型跨国软件公司的合作，也从中汲取了宝贵的管理经验。

3） 还有一个普遍存在的问题。近几年国内软件企业为了加强企业的竞争优势和名气提升，通常大搞特搞ISO/CMM认证；笔者也很支持这么做，但更关注的是通过这些认证后的企业有多少真正按照那些规范、设计的标准在后续的测试或软件开发管理工作中着手开展下去呢？社会上流传着这样的话：任何认证到中国，最后都免不了砸牌儿！笔者读书时很多高校搞的MCSE认证，有培训机构明目张胆声称"百分百通过率"！当年也有专门媒体报道此事。听到这样的话，我们都会寒心，这里真心希望我们的软件企业通过ISO/CMM后真正为企业的内部软件开发流程带来一点新生的曙光。

4） 最后一个原因，我想是企业内部测试管理人员和技术人员技能的不足，还有自身工作态度的不够端正。有了再好的规范标准，没人遵守不行！没人实施不行！应该说，很多中小软件企业的高层都或多或少的逐渐意识到软件测试的重要性和必要性，以及它的标准化、流程化改革的紧迫性，但也有很多的工程师、技术人员并不理会这套，常常在实际工作中投机取巧；也有很多测试管理人员后天的经验不足、技能不够，对公司测试管理工作考虑不到位，和开发工程师交流不充分，和上层领导反映不及时等等。

总之，任何问题的出现都不是单方面的原因，从宏观的社会形势到微观的企业个人，都有无可推卸的责任；正因为如此，解决问题也要对症下药，如何完善软件测试流程，就要从小处出发；本文不可能将软件测试流程优化的话题阐述的面面俱到，因此只从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。

强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用,在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中……为何如此？我们分析认为，根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，从三个方面具体来说：

1） 测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2） 制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3） 测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将其扼杀在萌芽阶段，以防后期阶段出现问题时互相推卸责任或干脆束手无策！

1） 软件需求分析阶段，笔者从来认为测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？虽然该观点被大多数同行所认可，但我知道依然有很多公司为了节省费用，不让测试人员参与前期调研或制定需求，经常的做法是等到系统开发完毕或将近完成，跟测试经理说一声"这边有个项目，你找几个人来测试一下吧！"经验表明，这样的做法实不可取。

测试人员（指项目的测试负责人和测试工程师）在需求阶段的任务有：

参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

推荐企业采用类似于IBM Rational Requisitepro（参考其官方说明： http://www-900.ibm.com/cn/software/rational/products/requisitepro/index.shtml）的需求管理工具来制定和管理软件需求，同时需要测试人员的配合，保证对软件测试环节的充分考虑。

2） 软件分析设计阶段，测试人员除制定测试计划书等基本工作外，笔者认为还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。

之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。

如果公司采用类似于IBM Rational Rose（参考官方说明： http://www-900.ibm.com/cn/software/rational/products/rose/index.shtml）的建模分析工具和IBM Rational Rose XDE Developer（参考官方说明： http://www-900.ibm.com/cn/software/rational/products/xde_developer/index.shtml）的可视化设计开发环境，这个工作更好执行；如果没有，那么测试人员更有必要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

当然该文档不是非要不可，笔者只是提倡一种原则，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

笔者之所以推荐IBM Rational系列产品在软件项目中的应用，是因为IBM Rational倡导的RUP（Rational Unified Process）方法论采用了用例驱动的原则。所谓用例驱动，是以体系结构为中心，采用迭代、增量方式的开发过程；而其Rational工具系列正是将这一理念进行行为表述，是当前软件工程领域一套无可比拟的强大工具集，从需求到测试，它都以用例为基本模型，全面贯穿软件开发的每个环节。

3） 软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大、质量优秀的测试用例（可参考笔者主页转载的"如何设计编写软件测试用例"），这里只想从管理角度和大家谈谈如何有效控制和增强测试用例在测试活动中的应用。应该遵守的原则是：

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

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

再次，如此众多测试用例的管理问题。是的，需要管理工具软件！笔者从来都反对以word或excel来编写测试用例：

格式上难于编写--通常方式是企业自己设计表格模版，但编辑上始终存在不便，尤其对于一些共性内容，如测试目标、测试环境、参考说明等，每次都要大量的复制、粘贴。

其次难于管理--如果把几千个文档文件放在一个共享文件夹里，即便以子目录方式管理，但是每次查找一个特定用例，你的眼睛也必将饱受煎熬！

更是难于执行--莫非真要针对几千个用例都是打开一个word-执行测试-输入测试结果-关闭word吗？

最重要的是，根本没办法追踪测试结果--在本轮回归测试输入完测试结果，但是下一轮结果输入到哪里？输入了这些测试结果什么用？能方便的根据其结果统计软件质量吗？还有，可以用它追踪发现的软件缺陷吗？有办法追踪吗？