文档介绍：讨论用TestDirector管理测试用例
编制时间:2007-03-16
编制部门:测试组
编制人:郭宏元
“测试用例”虽有国标作蓝本,但实际中,一直以来“测试用例”是所有测试人员有争议的地方,此所谓“仁者见仁,智者见智”。而“法无定法,则无定则”,所有的规范与标准都是围绕更适应人们的工作环境而创建。在此,我就我的一些体会在此与大家分享。
一般来说,“测试用例”的编写主要分三大类,贯彻的原则与基本架构如下:
分类:
对验证过程的一个记录;
展现一个功能;
描述一个场景步骤;
原则:
有“对象”属性的描述;
阐述了某个“对象”的方法或事件。
对属性、方法或事件有详细的定义。
基本架构:
目的;
前提条件;
输入步骤(输入动作或数据,预期结果)
以下总结了一些针对测试用例的“编写要点”作出一些较简单的规范。以方便统一测试用例的编写,并保证使用最用效的测试用例来保证测试质量。我们都知道根据详细设计文档编写测试用例的目的不在于验证软件达到的功能,而在于验证软件应该达到的功能,这样可以去除软件开发过程中的随意性。所以下面就明确测试用例的“目的”、“范围”、“原则”是什么?以及采用的方法做了一点描述。
目的:
围绕测试名称或满足实现测试功能而进行。
范围:
适用于所要测试的质检项目。
功能测试用例编写原则

单元测试用例的目的在于验证单个模块是否达到了详细设计说明书中规定的功能,由于是单个模块所以无法检验关联性,可能会牵扯到数据库的操作,例如:删除时,需要查看数据库是否完全删除了数据。

集成测试功能用例的目的在于验证软件连接时,模块的连接是否正确(及数据的传递是否正确)。.我们的软件中体现出来的是,是否正确调用界面,界面之间显示的数据是否正确,特别是财务、费用、数据方面的。
集成测试用例的编写过程中,经常将功能用例与业务流程混合编写,因为在集成测试时需验证业务流程中的数据正确性,以及界面之间的数据传递的准确无误。

系统测试业务流程用例的目的在于验证软件最终数据的准确性,我们的软件体现为,手工数据与报表数据的一直性。用例与用例之间有着一定的关系,目的性十分明确。
测试用例设计的原则

指编写的测试用例应该覆盖所有的“概要设计文档”或“需求文档”以及“测试申请文档”中描述的功能。
、删、改功能
增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验。输入的数据可能有无限种组合,此时可以采用等价类划分和边界值法,下面有较详细的说明。
删除的测试用例比较简单,只有操作没有数据的输入,但是应该在“备注”中注明,删除的限制条件,以及数据库中应该删除的表的情况,有条件限制时,测试用例应该包含各种删除条件,必要时在添加或修改的测试用例后面或中间紧跟删除的测试用例。
,应该详细描述其具体的操作步骤和结果
例如:选择“用户帐号”,可以通过多种途径进行,此时应具体描述程序从何处进入,通过何种操作,达到查看“用户帐号”界面。对于报表的测试用例,最好紧跟在输入数据的后面,并且应该给出报表输出的数据的界面图(含数据)。
对于不便书写测试用例的情况,应该在备注中说明,并写出可能的操作步骤。例如:对于文件夹的拖动,说明左右拖还是上下拖,结果如何就可以了。
,多种可能的情况考虑。但是对于其余各阶段的测试用例,必须考虑多条数据时的情况,此时主用是针对新增多条数据后,进行删、改、拖等情况的考虑。
,数据的应考虑存在跨年、跨月的数据。

包括数据的正确性和操作的正确性。
首先保证测试用例的数据正确。其次预期的输出结果应该与测试数据发生的业务吻合。
操作的预期结果应该与业务流程在程序执行的结果吻合。

测试数据应符合用户实际工作业务流程,实际就是测试用例的先后顺序,先新增,后修改或删除,不能将删除放在第一位。

人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例;

测试用例中应写清测试的操作步骤,不同的操作步骤相对应的操作结果不同,达到的目的是,任何人,均可以根据测试用例,单独进行测试。
测试用例设计的方法
测试用例的核心是输入数据。预期输出是依据输入数据和程序功能来确定的,也就是说,对于某一程序,输入数据确定了,预期输出也就可以确定了,至于生成/销毁被测试对象和测试的方法等,是所有测试用例都大同小异的,一般只有操作而没有输入。因此,我们讨论测试用例设计