如何设计和执行测试用例
作者:网络转载 发布时间:[ 2011/6/29 9:52:50 ] 推荐标签:
测试需求收集完毕后,开始测试设计。
测试用例是什么?测试用例是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题:
测试用例的基本格式:
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。
用例编号: 测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。
测试标题: 对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如 " 测试用户登录时输入错误密码时,软件的响应情况 " .
重要级别: 定义测试用例的优先级别,可以笼统的分为 " 高 " 和 " 低 " 两个级别。一般来说,如果软件需求的优先级为 " 高 " ,那么针对该需求的测试用例优先级也为 " 高 " ;反之亦然,
测试输入: 提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。
操作步骤: 提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。
预期结果: 提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。
软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。
一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改可以应用到当前被测试的软件。 " 拿来主义 " 可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。
加强测试用例的评审:
测试用例设计完毕后,好能够增加评审过程。
同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等;如果同行评审不充分,那么,在测试执行的过程中,上述本应在评审阶段发现的测试用例相关问题,会给测试执行带来大麻烦,甚至导致测试执行挂起。
定义测试用例的执行顺序 :
在测试用例执行过程中,你会发现每个测试用例都对测试环境有特殊的要求,或者对测试环境有特殊的影响。因此,定义测试用例的执行顺序,对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动,服务器的每次重新启动都会消耗大量的时间,导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候,应该考虑把这部分测试用例放在后执行,如果在测试进度很紧张的情况下,如果优先执行这部分消耗时间的异常测试用例,那么在测试执行时间过了大半的时候,测试用例执行的进度依然是缓慢的,这会影响到测试人员的心情,进而导致匆忙地测试后面的测试用例,这样测试用例的漏测、误测不可避免,严重影响了软件测试效果和进度。因而,合理地定义测试用例的执行顺序是很有必要的。
测试用例执行
测试用例设计完毕后,接下来的工作是测试执行,测试执行中应该注意以下几个问题:
搭建软件测试环境,执行测试用例
测试用例执行过程中,搭建测试环境是第一步。一般来说,软件产品提交测试后,开发人员应该提交一份产品安装指导书,在指导书中详细指明软件产品运行的软硬件环境,比如要求操作系统系统是 Windows 2000 pack4 版本,数据库是 Sql Server 2000 等等,此外,应该给出被测试软件产品的详细安装指导书,包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品,尤其是软件项目,如果没有安装指导书作为参考,在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书,搭建测试中遇到问题的时候,测试人员可以要求开发人员协助,这时候,一定要把开发人员解决问题的方法记录下来,避免同样的问题再次请教开发人员,这样会招致开发人员的反感,也降低了开发人员对测试人员的认可程度。
测试执行过程应注意的问题 :
测试环境搭建之后,根据定义的测试用例执行顺序,逐个执行测试用例。在测试执行中需要注意以下几个问题:
全方位的观察测试用例执行结果: 测试执行过程中,当测试的实际输出结果与测试用例中的预期输出结果一致的时候,是否可以认为测试用例执行成功了?答案是否定的,即便实际测试结果与测试的预期结果一致,也要查看软件产品的操作日志、系统运行日志和系统资源使用情况,来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前,我在测试嵌入式系统软件的时候,执行某测试用例后,测试用例的实际输出与预期输出完全一致,不过在查询 CPU 占用率地时候,发现 CPU 占用率高达 90 %,后来经过分析,软件运行的时候启动了若干个 1ms 的定时器,大量的消耗的 CPU 资源,后来通过把定时器调整到 10ms , CPU 的占用率降为 7 %.如果观察点单一,这个严重消耗资源的问题无从发现了。
测试用例是什么?测试用例是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题:
测试用例的基本格式:
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。
用例编号: 测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。
测试标题: 对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如 " 测试用户登录时输入错误密码时,软件的响应情况 " .
重要级别: 定义测试用例的优先级别,可以笼统的分为 " 高 " 和 " 低 " 两个级别。一般来说,如果软件需求的优先级为 " 高 " ,那么针对该需求的测试用例优先级也为 " 高 " ;反之亦然,
测试输入: 提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。
操作步骤: 提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。
预期结果: 提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。
软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。
一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改可以应用到当前被测试的软件。 " 拿来主义 " 可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。
加强测试用例的评审:
测试用例设计完毕后,好能够增加评审过程。
同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等;如果同行评审不充分,那么,在测试执行的过程中,上述本应在评审阶段发现的测试用例相关问题,会给测试执行带来大麻烦,甚至导致测试执行挂起。
定义测试用例的执行顺序 :
在测试用例执行过程中,你会发现每个测试用例都对测试环境有特殊的要求,或者对测试环境有特殊的影响。因此,定义测试用例的执行顺序,对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动,服务器的每次重新启动都会消耗大量的时间,导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候,应该考虑把这部分测试用例放在后执行,如果在测试进度很紧张的情况下,如果优先执行这部分消耗时间的异常测试用例,那么在测试执行时间过了大半的时候,测试用例执行的进度依然是缓慢的,这会影响到测试人员的心情,进而导致匆忙地测试后面的测试用例,这样测试用例的漏测、误测不可避免,严重影响了软件测试效果和进度。因而,合理地定义测试用例的执行顺序是很有必要的。
测试用例执行
测试用例设计完毕后,接下来的工作是测试执行,测试执行中应该注意以下几个问题:
搭建软件测试环境,执行测试用例
测试用例执行过程中,搭建测试环境是第一步。一般来说,软件产品提交测试后,开发人员应该提交一份产品安装指导书,在指导书中详细指明软件产品运行的软硬件环境,比如要求操作系统系统是 Windows 2000 pack4 版本,数据库是 Sql Server 2000 等等,此外,应该给出被测试软件产品的详细安装指导书,包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品,尤其是软件项目,如果没有安装指导书作为参考,在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书,搭建测试中遇到问题的时候,测试人员可以要求开发人员协助,这时候,一定要把开发人员解决问题的方法记录下来,避免同样的问题再次请教开发人员,这样会招致开发人员的反感,也降低了开发人员对测试人员的认可程度。
测试执行过程应注意的问题 :
测试环境搭建之后,根据定义的测试用例执行顺序,逐个执行测试用例。在测试执行中需要注意以下几个问题:
全方位的观察测试用例执行结果: 测试执行过程中,当测试的实际输出结果与测试用例中的预期输出结果一致的时候,是否可以认为测试用例执行成功了?答案是否定的,即便实际测试结果与测试的预期结果一致,也要查看软件产品的操作日志、系统运行日志和系统资源使用情况,来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前,我在测试嵌入式系统软件的时候,执行某测试用例后,测试用例的实际输出与预期输出完全一致,不过在查询 CPU 占用率地时候,发现 CPU 占用率高达 90 %,后来经过分析,软件运行的时候启动了若干个 1ms 的定时器,大量的消耗的 CPU 资源,后来通过把定时器调整到 10ms , CPU 的占用率降为 7 %.如果观察点单一,这个严重消耗资源的问题无从发现了。
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南