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

领测软件测试网

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

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

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

推荐企业采用类似于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吗？

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

    使用word等软件编写测试用例的种种不便大致如上，但换个思路思考一下使用集成工具的种种优势便更加一见分晓。测试同业者们都了解的测试用例管理工具便是IBM Rational TestManager（查看官方说明：http://www-900.ibm.com/cn/software/rational/products/testmanager/index.shtml），它是专业的测试用例管理和测试管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。以其为测试管理平台，测试人团队成员可以计划、管理、组织、执行、评诂以及报告等纵向测试活动，如果与IBM Rational Clearquest（查看官方说明：http://www-900.ibm.com/cn/software/rational/products/clearquest/index.shtml）集成使用，还可即时跟踪软件的需求变更，从而增强整个软件团队的横向沟通与合作。

    而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。

 

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

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

    二、是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工/自动两种）

    三、是测试用例要有状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）

    四、是执行失败的用例要链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小

    五、是测试用例的修改，以及每个测试周期的运行都有日志记录，以便后期追踪和新员工参考

    4） 软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做冒烟测试，测试方式是手工/自动，测试版本是**，测试环境是**，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

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

    B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

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

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

    E）应该提及的是，大多数软件公司都采用集成的缺陷管理工具来管理软件缺陷，如IBM Rational ClearQuest（变更管理与缺陷管理工具）等，这是值得称颂的好迹象；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

    F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。本人的原则是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。例如IBM Rational Robot（参考官方说明http://www-900.ibm.com/cn/software/rational/products/robot/index.shtml）或XDE Tester（http://www-900.ibm.com/cn/software/rational/products/xde_tester/index.shtml，现更名为Rational Functional Tester）。针对自动化测试原则，可参阅笔者的"自动化测试要点"译文，这里要提的其他几个基本原则是：

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

    二、是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；

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

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

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

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

    七、是一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

    八、是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本，IBM Rational ClearCase（参考官方说明：http://www-900.ibm.com/cn/software/rational/products/clearcase/index.shtml）是当前业界功能最强大的配置管理工具，可以将开发代码和测试代码都集中管理，进行高效的版本控制和工作空间管理，保证多人开发大量代码的稳定性。对于局域网范围内的开发工作，使用ClearCase LT版足够。

    由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。

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

    退一步说，如果您公司的测试部门经历一次这样重大的洗礼，有一个项目真正按照此原则实施一次，也必将对未来测试工作的开展发挥推波助澜的作用、起到事半功倍的效果。

    6） 其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

    另外，笔者不赞成对人员的强制性管理，例如大张旗鼓整顿公司测试部门的管理，采取缺陷报告数和人员绩效挂钩、不按测试规范执行就适当惩罚等手段；个人认为切不可急功近利，当以人为本，鼓励+促进甚善然、甚妙哉！

    综上所述，我们得出结论-- 测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范；至于如何解决，笔者提出了微薄建议，供业界朋友参考与交流。

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

 

    【作者简介】

    网名：Sincky，本名张振兴，是北京的一名测试工程师，擅长软件功能测试和和自动化功能测试，也从事过白盒测试、性能测试与测试管理工作，尤其对IBM Rational工具套件和RUP理论具有深入的了解和研究，多年也积累了一定测试经验和测试思想，在此分享给业界同行