《制定测试需求和设计测试用例》由会员分享，可在线阅读，更多相关《制定测试需求和设计测试用例（17页珍藏版）》请在金锄头文库上搜索。
1、制定测试需求和设计测试用例,彭卫萍（Kelly) Email: 2005-07-07 智能互联研究所 Intelligent Grouping Research and Development Institute Amoi Electronics Co., Ltd,课程目标,理解测试需求，学会怎样制定测试需求 理解测试用例，学会怎样设计测试用例 熟悉各种测试方法，以及怎样运用到设计测试用例中去 更好地执行测试用例,测试需求,定义：描述在你的应用程序中哪些需要被测试，简单来讲就是一个测试的范围。根据这个范围再来拟制测试计划 依据：软件规格说明书、市场需求，产品本身的属性 内容：内容就是需要被测
2、试的“哪些”，这个“哪些”包括功能、性能与效率、易用性、配置、兼容性,测试用例,1 定义: 所谓测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。 2 目标: 尽可能早的发现软件缺陷，发现更多的软件缺陷。一个好的测试用例是发现至今未发现的问题 3 衡量标准: “需求覆盖率”，这样测试用例的全面性很大程度上决定于需求的全面性测试代码的覆盖率逐渐成为软件测试的统一标准，但这个标准基于白盒子测试，而对于黑盒子测试用例，代码覆盖率很难度量。,需求-测试用例,一般我们把软件规格书作为测试的标准，使用说明书也是标准之一,测试按要素分
3、类的两种方法,数据测试 状态测试,测试基本方法,通过测试确认软件至少能做什么，功能测试基本是通过测试。 失败测试纯粹为了破坏软件而设计和执行的测试案例，这一类测试通常被称为压迫测试,例子：1，MP3软件中的一些删除文件失败的例子,我们采用的测试方法,我们测试过程是进行通过测试，确认软件能完成软件规格定义的功能，再对其进行一些失败测试。两个阶段的完成都采取数据和状态测试的方法，也可以说数据测试和状态测试都分为两个阶段。整个过程如下图所示：,时间轴,一个需求的主题的实现在程序上来说不仅是数据的处理也有一个状态的变化，所以数据测试和状态测试在用例里面有时是不怎么能区分的，然而在某些测试用例里这两种测
4、试的概念会比较清楚：比如边界测试和路径测试,设计测试用例,设计测试用例实际是一个选择的过程。 选择的方法：,测试软件操作界限所在的边缘情况,状态测试,状态描述要素1，界面（我们的嵌入式系统界面是体现状态的一个主要途径，比如A-B重复）有些不同的界面但是状态并不是独立的 2，潜在的状态变量 3，软件处理的不同对象 状态测试的主要依据之一 状态转化图。 路径测试路径测试实质上是状态测试。我们把他当成功能测试的一种补充，为了更加全面的测试到一些不同的状态,等价分配,不完全测试所以要冒一定的风险 示例：1，MP3本机信息里显示磁盘容量的测试，容量显示范围是0-241M，只支持显示整数，通过等价分配我们
5、可以分为0-1， 1-9，10-99， 100-241，三个区间，即通常的一位数，两位数，三位数的位置区间。2，编码率歌曲的选择 （32KBPS，192KBPS，320KBPS），要讲究一个代表性。 注意：按键输入是穷举法，不进行等价分配，因为不存在等价的输入。,边界测试,边界条件类型（1，数值 2，字符 3，位置 4，数量）特征-第一个/最后一个、最大值/最小值、开始/完成、空/满、最慢/最快、最大/最小、相邻/最远、超过/在内、 次边界条件（2的乘方、ASCII表、默认、空白、空值、零值） 测试边界线（左右摇一摇）,测试执行,眼明（发现异常）手快（压迫测试） 追根究底（寻找随机问题的规律） 缩定范围，重复查找（在发现问题的地方在东敲敲，西找找）一个软件缺陷很可能是泄露附近更多软件缺陷的信号,Defect(缺陷）,1、软件未达到客户需求的功能和性能； 2、软件超出客户需求的范围； 3、软件出现客户需求不能容忍的错误； 4、软件的使用未能符合客户的习惯和工作环境。,测试原则,完全测试程序是不可能的 软件测试是有风险的行为 测试无法显示潜伏的软件缺陷 找到的软件缺陷越多，就说明软件缺陷越多,如何看待测试结果,只能证明缺陷存在，而不能证明缺陷不存在,谢谢大家！,希望在以后的工作中多多交流，累积经验。,
