接口测试用例设计思路

接口测试用例设计思路（8篇）

1.接口测试用例设计思路 篇一

软件测试中报表测试用例设计方法总结

报表的测试主要分为以下几个方面:界面,安全性,准确性,展示速度(性能)

数据统计方面

1、报表统计数据的正确性；

2、报表统计数据的完整性；

3、报表统计数据的合法性；比如，统计金额字段需求要求有“$”等；

报表格式

1、表头字段表示的正确性；

2、表头字段表示的完整性；

3、表头字段表示的字体，字号，美观程度；

4、各统计字段的显示是否满足需求；比如：数据过长时要求折行还是缩小；

5、页眉和页角的表示；

报表的预览和印刷

1、预览中的显示完整性；

2、多页情况下，第2页的表头显示；

3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）

4、预览后印刷；

5、不预览，直接印刷

6、需求规定各类打印机的测试；

数据准确性测试，带有报表测试的系统分为两类，一类是业务系统中，带有统计分析功能模块，该模块中包含分析报表，这个系统的主体是业务系统，报表是为办理业务的而提供帮助的。

比如说，应年检统计报表，某月应交罚款车辆统计报表，这样的报表数据准确与否，可通过增加、删减、修改相关业务或相关业务的参数，查看统计报表数据变化，检查数据准确性。

另一类是系统只有统计功能，就是我说的数据仓库展现这类，它与业务系统分离，并且经过多层处理，比如数据仓库的数据，经过抽取，清洗，展现前会经过数据挖掘，数据再处理，有些字段在原始数据表中根本就没有。这样的数据准确性测试比较复杂，当然检查出数据错误，修改定位也是很不容易的。

从整个项目节约成本看，逐层测试效果是最好的。完全修改率也是最高的。

首先建立测试数据模型，模拟所有应用表，建立简单易跟踪的数据用例，底层的数据表测试，方法很原始，嘿嘿，通过SQL语句和手工计算，对数据进行比对。对系统中的报表数据准确性测试方法较为灵活，①系统中报表重叠的进行比对

②对子报表汇总与父报表比对，就是对月报表汇总与年报表比对，日报表汇总与月报表比对，这只是一个方面，可以从维度关系考虑，地域，行政级别、时间，个人等方面下手，进行汇总比对

③这个方法如果延伸点呢，可以将报表间的业务逻辑关系作为比对依据。呵呵，这要看测试人员的需求了解深度个人能力了。插几句不想干的话，做测试工作总让我保持快乐状态，前两天我的一个同事说，公司里一直没有人喜欢做测试工作，这个工作太枯燥。嘿嘿，我当时就说我做了这么多年的测试工作从来没有感觉到枯燥。重复性工作不代表枯燥，编程其实不也是重复嘛，人每天谁不重复昨天的事啊，吃饭，吃这个动作重复一生，有谁觉得麻烦枯燥啦？

④使用SQL和手工计算进行比对。以上是差错方式，接下来讲一下查什么错？哪些地方容易出错

●原始表使用错误：因为表比较多，又加上没有统一的数据关系对应表，很容易表使用错误，当然这应该是单元测试检查出来的错误。

●数据处理逻辑错误：这一点容易因为测试人员和开发人员对需求理解有偏差造成争执，所以在需求评审时，对数据处理规则用表达式或伪代码表示清楚。还有就是程序员失误，逻辑编写有偏差，边界值、特殊情况处理不当。

●数据权限：不同用户对数据有着不同的查看权限。这关系到数据的安全性。

●数据误差：数据的保留位数，数据是否是处理计算是否是最后一次计算使用了位数保留和四舍五入。

●由于字典表，数据错误，而造成的数据错误，如，根据性别统计，购买量，表中的男女颠倒，或者没有考虑性别缺失项，用了ifelse,这样就是把表中缺失该项内容的算成了else条件里。或者逻辑中应该考虑用户状态，数据状态类似的字段，容易被忽略，测试应该考虑到。

●最后一项，当数据量相当大的时候，统计应该考虑，切割速度，也就是数据的完整性，由于数据切割的滞后，带来的数据不完整，而造成统计结果不完整。如统计昨天的销售情况，而昨天的数据并没有完全从业务系统数据到数据池，再者月底数据，由于最后一天的数据切割不完整而造成的正月统计数量不准确。

报表的界面和输入输出测试

界面分为输入界面和输出界面；统一的界面要求：美观、统一、易操作。

输入界面要求是：

①输入项字段长度不允许超过字段长度；

②输入不符合字段要求的，不允许查询。如money类型，在输入汉字，字母、特殊字符等不允许查询，并有友好的操作提示。

③用户权限范围外的输入，不允许查询。如用户输入不是其权限范围内的客户号，不允许查询，并有友好的操作提示。

对于选项，应不出现可选择的用户权限以外的选项。

对于汉字模糊查询，考虑不常见字，如“?”即汉字因译码问题，造成的汉字存储出现乱码问题。

输出界面要求：

①因为是报表所以应该有打印、打印预览、报表导出等功能。不能因为报表导出丢失数据，不能因为打印缺少了报表表格框

②报表排列方式可调，用户可按任意列升序或降序排列，或者，按某一关键列的一定规则排序

③报表标题明确，不能含糊误导用户

④报表内可关联查询的项，应能特殊显示，如鼠标有箭头变为手掌，子报表格式与父报表格式统一，数据统一。

报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表.所以,做报表测试时要注意以下方面:

1.数据的正确

用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌;加工过的数据查看加工的结构是否和手工加工的结果一致.简言之,需要测试以下内容.数据的来源：来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确.数据的范围：是否只显示了报表设置的对应范围；特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为200627~200727,那么是否应该包含9-27这天.数据的对应关系：数据库中的字段是否与报表中的信息对应

数据的格式：小数位,千位符,四舍五入等是否与报表设置一致；单位或税率转换是否正确；组合显示的数据是否合理

数据的排序：排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序)

流水号：如报表有使用流水号,流水号的生成和格式是否正确.取消操作是否会生成流水号.明细与合计的一致性：各部分明细或小节是否与最后总和一致

其他

测试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据.2.格式的正确

数据验证正确后,就需要看看报表的输出格式是否符合要求.可以从以下几方面来检查.报表的整体风格：报表是否符合规定的或用户设置的格式

报表标题：报表的标题是否是正确的报表名称；如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司200627~200727的网站访问量,这个时间段也是用户选择的.公司的一些标志：如logo,名称,地址之类的是否正确

报表的页首与页尾：是否采用了一致的规则.分页：当输出的内容多时,分页是否正确.翻页功能是否正确

友好性：数据或图表是否清晰,一目了然,数据的展示符合用户的习惯；需要特别提醒的数据(如合计,异常数据)是否突出显示；复杂算法处,用户不明白或容易混淆处是否有注释；一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等

3.权限的控制

对于有权限控制的系统，报表当然也应该和用户所具有的权限相一致。需要从两方面校验权限的控制。

报表的条件定义:在条件选择区域，有些下拉框中应该不能显示用户权限范围外的数据。如普通文员在使用报表时，报表名称下拉框中是不可以显示管理者才能查看的报表的。有些以输入的文本框有级别的划分时，都应该要测试输入超越权限的数据的相应。

注意这里一定要测试每个条目。

报表内容：报表中的内容不能显示用户本没有权限查看的数据。

4.报表的输出

报表在电脑上生成后，并不是报表的结束。报表一般都需要打印出来他用，如开会或者提交审批之类。所以报表的打印功能也是非常重要的。测试主要分成三部分：

●打印设置

●打印预览

●实际打印效果

除了打印之外，用户有可能需要导出报表做进一步的分析或用于和其他报表的比较。所以也应该提供导出报表的功能。一般可以导出为CSV,Excel,pdf,html,xml格式。

2.接口测试用例设计思路 篇二

随着计算机与人们日常生活关系日益紧密,各种类型的软件被广泛应用于各行各业之中。人们对软件的依赖性越大,就会对软件的品质要求越来越高。在这样的背景下,近年来,在国内,软件测试越来越受到软件领域的关注。

软件测试是软件生命周期中的一个重要阶段,它是软件品质得以保证的重要过程,是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例,并利用这些测试用例运行软件,以发现软件错误的过程。它是帮助识别开发完成的计算机软件的正确度、完全度和质量的软件过程;是软件质量保证(SQA)的重要子域。

软件测试用例就是在软件测试过程中为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

2 软件测试用例的重要性

如何保障软件测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量,这样就可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

因此在测试工作中,测试用例的设计是非常重要的,是测试执行的正确性、有效性的基础。如何有效地设计测试用例,一直是测试人员所关注的问题;设计好测试用例,也是保证测试工作的关键因素之一。

3 测试用例设计

3.1 文档

在编写测试用例文档时应当有文档模板,且文档模板须符合内部的规范要求,测试用例文档将受制于测试用例管理软件的约束。软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制测试目的、测试范围、定义术语、参考文档、概述等;测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素:测试索引、测试环境、测试输入、测试操作、预期结果、评价标准。

3.2 设置

早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。

按功能测试是最简捷的,按用例规约遍历测试每一功能。对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。但路径分析法也有局限性,在一个非常简单字典维护模块中就存在10余条路径,一个复杂的模块中会有几十到上百条路径是不足为奇的。

3.3 设计

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例,应该参照用例规约(或设计规格说明书),根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。

3.4 一般原则

通常,在设计测试用例时应遵循以下原则:

(1)应该避免依赖先前测试用例的输出,因为测试用例的执行序列早期发现的错误可能导致其他的错误,从而减少测试执行时实际测试的代码量。

(2)测试用例设计过程中,包括作为试验执行这些测试用例时,常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。

(3)在整个单元测试设计中,主要的输入应该是被测单元的设计文档。在某些情况下,需要将试验实际代码作为测试设计过程的输入,测试设计者必须意识到不是在测试代码本身。从代码构建出来的测试说明只能证明代码执行完成的工作,而不是代码应该完成的工作。

4 测试用例设计方法

设计测试用例,也分为黑盒设计方法和白盒设计方法。黑盒设计方法分为等价类划分法、边界值划分法、错误推测法、因果图法等,而白盒设计方法又分为逻辑覆盖法和基本路径覆盖法,或者分为语句覆盖、判定覆盖、条件覆盖方法。在实际测试用例设计过程中,不仅根据需要、场合单独使用这些方法,常常综合运用多个方法,使测试用例的设计更为有效。测试用例设计最重要的因素是经验和常识。测试设计者不应该让某种测试技术阻碍经验和常识的运用。

4.1 黑盒测试方法及测试用例设计

黑盒测试用例设计:使用详细设计导出测试用例。

采用黑盒测试的目的主要是:检查功能是否实现或遗漏;检查人机界面是否错误;数据结构或外部数据库访问错误;性能等其它特性要求是否满足;初始化和终止错误。

黑盒测试用例设计时应该注意以下问题:

(1)测试用例要根据测试大纲来编写。

(2)测试用例也要分测试项进行归类,这样比较好分析和阅读。如:业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

(3)编写测试用例时要考虑各种情况,精力应主要集中在软件的主要业务流程和风险高的地方。

(4)熟悉系统,对编写测试用例很有帮助。

黑盒测试法侧重于对被测软件功能的检测,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生适当的输出信息,并且保持外部信息的完整性。黑盒测试法主要着眼于程序外部结构,不考虑程序内部逻辑结构,主要针对软件界面、软件功能、外部数据库访问及软件初始化等方面进行测试。具体地说黑盒测试方法主要包括边界值分析法、等价类划分法、比较测试法、因果图法、错误推错法、判定表驱动法等。

下面将对边界值分析法和等价类划分方法做一些探讨。

4.1.1 边界值分析法

边界值分析法是一种经常使用的软件测试技术,它具有很强的发现程序错误的能力。为检测边界附近的处理专门设计测试用例,通常都会取得很好的测试效果。

在用这种方法进行测试时要注意以下一些原则:

(1)如果输入条件对取值范围进行了界定,则应该以边界内部以及恰巧超出范围边界外的值作为测试用例。

(2))如果随取值的个数进行了界定,则应当分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。

(3)对于输出值同样可以按照上面两条原则来设计测试用例。

(4)若在程序规格说明书中提到的输入输出域是一个有序的集合,就应该选取该有序集合中的第一个和最后一个元素作为测试用例。

测试用例的设计只要按照以上原则设计就可以取得较好的效果。

4.1.2 等价类划分方法

等价类划分方法是一种典型的黑盒测试方法,它完全不考虑程序的内部结构,而只是根据对程序的说明和要求来进行测试用例的设计。测试人员先要对需求规格说明书的各项需求,尤其是功能需求进行细致分析,同时,还要求对输入要求和输出要求区别对待和处理。

等价类划分方法把程序的输入域划分成若干部分,然后从每个部分中选取出少数代表性数据当作测试用例。这主要是因为完成穷举测试实际上是不可能完成的工作,因此,测试人员要从大量的可能数据中选取其中一部分数据,用来作为测试用例。经过划分后,每一类的代表性数据在测试中的作用都等价于这一类中的其他值。也就是说,如果某一类中的一个测试用例发现了错误,那么这一等价类中的其他用例也能发现同样的错误;与之相反的是,如果某一类中的测试用例没有发现错误,则这一类中的其他测试用例也不会查出错误。在采用等价类划分方法来进行测试用例设计时,必须首先在分析需求规格说明的基础上划分等价类,列出等价类表,从而确定测试用例。

4.2 白盒测试方法及测试用例设计

白盒测试用例设计:使用程序设计的控制结构导出测试用例。

采用白盒测试的目的主要是保证一个模块中的所有独立路径至少被执行一次;对所有的逻辑值均需要测试真、假两个分支;在上下边界及可操作范围内运行所有循环;检查内部数据结构以确保其有效性。白盒测试用例设计的主要方法有基本路径测试、程序结构分析、逻辑覆盖等,它根据程序的控制结构设计测试用例,主要用于软件验证。

应用白盒测试方法需要遵循如下的几条原则:

(1)一个模块中的所有独立路径至少被测试一次。

(2)所有逻辑值均需测试true和false两种情况。

(3)检查程序的内部数据结构,保证其结构的有效性。

(4)在取值上下边界及可操作范围内运行所有循环。

任何有关路径分析的测试都可以称为路径测试。可以给出对路径测试的简单的描述,路径测试就是指从一个程序的入口开始,执行所经历的各个语句的完整过程。路径测试是白盒测试中最为典型的问题,完成路径测试的理想情况是做到路径覆盖。对于比较简单的小程序实现路径覆盖是可能做到的,但是程序中如果出现多个判定、多个循环,路径数目将会急剧地增长,不可能实现路径覆盖。

基本路径测试是一种白盒测试技术。其基本思想是测试用例设计者导出一个过程设计的逻辑复杂性测度,并使用该测度作为指南来定义执行路径的基本集,从该基本集导出的测试用例保证对程序中的每一条执行语句至少执行一次。

基本路径测试的方法步骤如下:

(1)画出控制流图

图1中的每一个圆称为流图的节点,代表一条或多条语句。流图中的箭头称为边或连接,代表控制流。任何过程设计都要被翻译成控制流图。如下面的C函数:

值得注意的是,如果在程序中遇到复合条件,例如条件语句中的多个布尔运算符(逻辑OR、AND)时,为每一个条件创建一个独立的节点,包含条件的节点称为判定节点,从每一个判定节点发出两条或多条边。例如:

对应的逻辑如图2所示。

(2)计算圈复杂度

圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量,将该度量用于计算程序的基本的独立路径数目,为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。

有以下3种方法计算圈复杂度:

1)流图中区域的数量对应于环型的复杂性。

2)给定流图G的圈复杂度-V(G),定义为V(G)=E-N+2,E是流图中边的数量,N是流图中节点的数量。

3)给定流图G的圈复杂度-V(G),定义为V(G)=P+1,P是流图G中判定节点的数量。

对应上述图1中代码的圈复杂度,计算如下:

V(G)=10条边-8节点+2=4;

V(G)=3个判定节点+1=4。

可以看出,控制流图中有四个区域;

(3)导出独立路径

根据上面的计算方法,可得出四个独立的路径:

路径1:3-13

路径2:3-5-6-12-3-13

路径3:3-5-7-8-12-3-13

路径4:3-5-7-10-12-3-13

(4)设计测试用例

根据上面的独立路径,设计输入数据,使程序分别执行到上面四条路径。如:

Sort(0,1)测试路径1

Sort(1,0)测试路径2

Sort(1,1)测试路径3

Sort(1,2)测试路径4

5 结语

针对软件测试过程中的黑盒测试和白盒测试的测试用例设计作了一些探讨,但影响软件测试的因素很多,例如软件本身的复杂程度、开发人员的素质、测试方法和技术的运用等。因为有些因素是客观存在的,有些因素则是波动的、不稳定的,工作状态也会受到情绪等因素的影响等,有了测试用例,就能在很大程度上保障测试的质量,提高软件的品质。

参考文献

[1]郑人杰.实用软件工程[M].北京:清华大学出版社,2002.

[2]王春森.高级设计师教程[M].北京:清华大学出版社,2001.

[3]沃特金斯,贺红卫.实用软件测试过程[M].北京:机械工业出版社,2004.

[4]柳纯露,黄子河.软件评测师教程[M].北京:清华大学出版社,2005.

[5]韩万江,姜立新.软件开发项目管理[M].北京:机械工业出版社,2004.

3.小议软件测试用例的设计论文 篇三

白盒测试方法的主要作用有：

（1）至少测试一次程序子模块的所有独立执行路径；

（2）针对所有可能的逻辑判定，至少一次取“真”或“假”两种情况；（3）在运行界限内和循环边界处执行循环体；

（4）测试程序内部的数据结构的有效性。在实际的数据测试中，如果程序具有多种循环嵌套的情况，不同的执行路径数目可能是天文数字，例如一个有5条路径的嵌套20次循环的小程序，包含不同执行路径条数为520次方，如果每一条路径测试1ms，全年无休时要测试完所有路径需要约3170年的时间。因此，我们必须采用一些替代办法，典型的方法是有选择的执行程序中某些最有代表性的通路。白盒测试的主要技术有：

1根据程序内部的逻辑结构设计测试用例的技术—逻辑覆盖

（1）语句覆盖，选择足够多的测试数据以使被测程序中每条语句都至少执行一次。语句覆盖不考虑对程序的逻辑覆盖，它主要关心表达式的结果，却对每个条件取不同值的情况不做测试。因此，语句覆盖是比较弱的逻辑覆盖标准。在图论中和语句覆盖对应的是点覆盖。

（2）判定覆盖，又叫分支覆盖，它首先满足语句覆盖的条件，同时对每个判定的每种可能的结果都至少执行一次，即对每个分支都至少执行一次每个判定，判定覆盖对程序的逻辑覆盖程度也不高。在图论中和判定覆盖相对应的是边覆盖。

（3）条件覆盖，指的是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果，条件覆盖中可能不包含判定覆盖。

（4）判定/条件覆盖，指选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，每个判定表达式也取到各种可能的结果。

（5）条件组合覆盖，要求选择足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。条件组合覆盖是逻辑覆盖标准中最强的。

（6）路径覆盖，指的是选取足够多的测试数据，使程序的每条可能路径都至少执行一次。测试用例设计举例1：如下图1所示程序段流程，实现语句覆盖需要设计的测试数据有：X=0，Y=3和X=-1，Y=2；实现条件覆盖至少采用的测试数据有：X=0，Y=3和X=3，Y=1；实现判定覆盖至少应用的测试数据有X=0，Y=3，X=1，Y=2和X=-1，Y=2。

2测试程序的控制结构，主要包括条件测试，循环测试和基本路径测试。

其中基本路径测试是由TomMcCabe提出的一种白盒测试技术，这种技术在设计测试用例时需要首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合。在实际测试中，仅靠基本路径测试还不能满足要求，还需要结合条件测试技术来检查程序模块中包含的逻辑条件，还有循环测试来专门测试循环结构的有效性。

黑盒测试技术中的测试用例设计方法研究

黑盒测试主要用来测试软件的功能特点，通过黑盒测试可以发现：（1）是否有遗漏了的功能或者不正确的功能；（2）能否有正确的接收输入和正确的输出结果，这主要针对接口而言；（3）是否有外部信息访问错误或数据结构错误，同时，软件运行时能否满足性能上的要求；（4）软件在初始化或者退出时有无错误等；使用黑盒测试同样不可能将所有可能的输入条件和输出条件用于测试，因为测试用例的组合是天文数字。例如一个程序有两个输入量和一个输出量，在32位计算机上运行，若X，Y取整数，按穷举测试时需要232×232=264组，如果一组数据需要1ms，全年无休，需要5亿年的时间。显然，我们必须设计合理的方案来减少测试用例的数量。目前黑盒测试的主要测试用例设计技术有：

1等价类划分

等价类划分是把程序的输入域划分成若干个数据类，据此导出测试用例，因为对于同一类中的数据而言其作用是相同的[3]。等价类划分可以分为有效等价类和无效等价类。有效等价类是指符合程序功能要求的数据类，该类中包含的都是有意义的数据；而无效等价类指不能满足程序正确运行或者预期结果的数据类的集合。我们在设计测试用例时，要同时考虑有效等价类和无效等价类的设计方案。等价类的划分有自己的原则。在具体使用等价类划分设计测试用例时有两个步骤：（1）设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；（2）设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。

2边界值分析

使用边界值分析方法来设计测试用例时需要开发者具有一定的经验和创造性，通常根据划分的输入等价类和输出等价类的边界来确定边界值的结果，即选取刚刚等于、刚刚小于和刚刚大于边界值的测试数据，而不是选择等价类内部的数据作为测试用例。

3错误推测法

错误推测法主要依靠直觉和经验，需要有一定开发大型软件工程的经验，其基本思想是通过列举出程序中可能有的错误和容易发生错误的特殊情况，并根据这些情况来选择测试方案。

小结

4.测试用例 篇四

测试用例(Test Case)目前没有经典的定义，比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的`测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

编制测试用例的具体做法，

1、测试用例文档

编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

2、测试用例的设置

我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

5.测试用例书写标准 篇五

在编写测试用例过程中，需要参考和规范一些基本的测试用例编写标准，在ANSI/IEEE829-1983标准中列出了和测试设计相关的测试用例编写规范和模板。标准模板中主要元素如下。

 标识符（identification）：每个测试用例应该有一个唯一的标识符，它将成为所有和测试用例相关的文档/表格引用和参考的基本元素，这些文档/表格包括设计规格说明书、测试日志表、测试报告等。

 测试项（test item）：测试用例应该准确地描述所需要测试地项及其特征，测试项应该比测试设计说明书中所列出地特性描述更加具体，例如做windows计算器应用程序地窗口设计，测试对象是整个地应用程序用户界面，这样测试项就应该是应用程序地界面地特性要求，例如缩放测试、界面布局、菜单等。

 测试环境要求（test environment）：用来表征执行该测试用例需要地测试环境，一般来说，在整个的测试模块里面应该包含整个的测试环境的特殊要求，而单个测试用例的测试环境需要表征该测试用例所单独需要的特殊环境需求。

 输入标准（input criteria）：用来执行测试用例的输入需求。这些输入可能包括数据、文件，或者操作（例如鼠标的左键单击，鼠标的按键处理等），必要的时候，相关的数据库、文件也必须被罗列。

 输出标准（output criteria）：标识按照指定的环境和输入标准得到的期望输出结果。如果可能的话，尽量提供适当的系统规格说明书来证明期望的结果。

 测试用例之间的关联：用来标识该测试用例与其它的测试（或其它测试用例）之间的依赖关系，例如，用例A需要基于B的测试结果正确的基础上才能进行，此时需要在A的测试用例中表明对B的依赖性，从而保证测试用例的严谨性。

综上所述，如果使用一个数据库的表来表征测试用例的话，它应该有以下的格式：

例一：对Windows记事本程序进行测试，选取其中的一个测试项――文件菜单栏的测试 测试对象：记事本程序文件菜单栏（测试用例标识1000，下同），所包含的子测试用例描述如下：

|---------文件/新建（1001）

|---------文件/打开（1002）

|---------文件/保存（1003）

|---------文件/另存（1004）

|---------文件/页面设置（1005）

|---------文件/打印（1006）

|---------文件/退出（1007）

|---------菜单布局（1008）

|---------快捷键（1009）

选取其中的一个子测试用例――文件/退出（1007）作为例子，测试用例如下表所示：

通过这个例子了解了测试用例的组成方法。要组织成一个完整的良好测试用例，还需要更多的技巧，并要考虑一些常见的因素。

测试用例设计考虑因素

测试是不可能实现穷举测试的，因此试图用所有的测试用例来覆盖所有测试可能遇到的情形是不可能的，所以，在测试用例的编写、组织过程中，尽量考虑有代表性的典型的测试用例，来实现以点带面的穷举测试。这要求在测试用例设计中考虑一些基本因素：  测试用例必须具有代表性、典型性。

 测试用例设计时，要浓缩系统设计。

例二：常见的web登录页面，通过这个例子来阐述从功能规格说明书到具体测试用例编写的过程

A）用户登录的功能设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 用户登录

1．1满足基本页面布局（图示，略）

1．2当用户没有输入用户名和密码时，不立即弹出错误对话框，而是在页面上使用红色字体来提示，见2描述

1．3用户密码使用掩码号（*）来标识。

1．4*代表必选字段，将出现在输入文本框的后面。

2． 登录出现错误

当出现错误时，在页面的顶部会出现相应的错误提示。错误提示的内容见3。错误提示是高亮的红色字体实现。

3． 错误信息描述

3．1

3．2密码为空

3，3用户名/

（注：本例子中的页面图示，消息编号如WMSG001的描述均为给出。）

―――――――――――――――――――――――――――――――――――――――

B）通用安全性设计规格说明书（摘选）

―――――――――――――――――――――――――――――――――――――――

1． 安全性描述

1．1输入安全性：在用户登录或者信用卡验证过程中，如果三次输入不正确，页面将需要重新打开才能生效。

1．2密码：在所有的用户密码中，都必须使用掩码符号（*），数据在数据库中存储使用统一的加密和解密算法。

1．3Cookie：在信用卡信息验证，用户名输入时，Cookie都是被禁止的，当用户第一次输入后，浏览器将不再提供是否保存信息的提示，自动完成功能将被禁用。

1．4SSL校验：所有的站点访问时，都必须经过SSL校验。

2． 错误描述（略）

―――――――――――――――――――――――――――――――――――――――

C）测试用例

结合相关的规格说明书，理解和掌握测试用例设计的关键点，测试用例设计如下表所示。

 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分

析怎样使得这样的错误或者异常能够发生。

用户登录功能测试用例

完善的测试用例

6.Web安全测试用例设计研究 篇六

随着电子商务和互联网的广泛应用,Web应用软件被越来越广泛的使用。除了传统的应用如电子邮件、新闻网站等,目前Web应用软件也被越来越多的关键性任务使用,例如互联网证券、互联网银行、网络购物等涉及金钱交易的应用,以及政府部门的电子政务等业务通过互联网来开展等。上述关键性的应用对软件安全的要求越来越高,假如由于软件的不安全造成系统被破坏或信息被泄露,将会给国家、集体甚至个人带来巨大的损失。所以,确保Web应用软件的安全是非常重要的,设计全面、有效的安全测试用例则是重中之重。

2 常见Web安全问题

研究Web应用软件的安全性测试技术,首先应对已知的应用软件安全问题进行研究,了解各种漏洞产生的原因、触发的条件、造成的后果,抽象出各类漏洞的特征,进行科学的分类,才能有效指导安全性测试工作,保障其科学性、高效性和针对性。OWASP(The Open Web Application Security Project)是一个致力于web应用安全的国际组织,OWASP分析实际应用中经常出现的安全漏洞,并对各类漏洞进行总结描述,发布每年度的最危险的十大漏洞,能够很好地反映Web安全所面临的威胁和这些威胁的发展趋势,被众多权威性机构(如美国国防部、国际信用卡数据安全技术标准、美国联邦贸易委员会等)列为应用程序安全规范。根据OWASP提出的Web应用安全漏洞数据分布来看,Web应用程序面临的安全形势依然严峻,常见的安全问题包括:

1)注入式攻击。例如SQL、OS以及LDAP注入,发生在不受信任的数据作为一条指令或是查询要求的一部分被发往解释程序之时。攻击者所植入的恶意数据可以骗过解释程序,导致该指令或查询要求在无意中被执行。

2)跨站点脚本(简称XSS)。每当一个应用程序携带了不受信任的数据并将其发送至页面浏览器而又未经过相关验证及转换解析时,XSS类漏洞就会蠢蠢欲动。XSS允许攻击者在受害者的浏览器中执行脚本,这会导致用户的会话遭受劫持、网站受到破坏或者是将用户的访问目标重新定向至某些恶意网站。

3)无效的认证及会话管理功能。应用程序的相关认证及会话管理功能在执行过程中常常发生各种问题,导致攻击者有可能获取到密码、密钥、会话授权或是通过利用其他执行性漏洞来盗取用户身份。

4)对不安全对象的直接引用。当开发者公开引用某种对内部执行对象,例如索引系统、一个文档或是数据库关键信息时,就有可能发生这种不利情况。由于缺乏访问控制检查等安全保护措施,攻击者能够利用引用信息对未获授权的数据进行访问。

5)伪造的跨站点请求(简称CSRF)。CSRF类攻击的特点是,强迫受害者的某个已进行登录操作的浏览器向安全保护薄弱的页面应用程序发送一条伪造的HTTP请求,包括受害者会话缓存内容及其他任何自动产生的包含认证信息的内容。这就导致了攻击者可以通过强制受害者浏览器向具有漏洞的应用程序传递请求的方式,使相关的应用程序认定该请求是受害者本人所发出的合理请求。

3 Web安全测试内容

攻击者攻击网络的手段多种多样,目的在于寻找并利用网络中存在的漏洞。要想实现周密的安全防范,就需要分析攻击者入侵网络的方式。攻击者对网络攻击的方式包括本地攻击、远程攻击和伪远程攻击。他们的目的主要包括:非法访问目标系统,以获取不应有的访问权限;篡改相关数据,修改重要资料;获取所需资料;使用有关资源,发布虚假信息、占用存储空间甚至发动分布式攻击等。

攻击者进行Web应用攻击行为的过程包括:首先,发现Web系统或应用程序中已存在的漏洞;然后,根据具体漏洞的类别采取对应的、有效的攻击手段;最后,人工分析攻击结果,获取想要的信息或权限。按照目前常见的攻击手段,应该有针对性的进行测试,主要的测试内容如下:

1)漏洞扫描。安全漏洞扫描一般需要借助特定的漏洞扫描器完成,漏洞扫描器其实就是一种能自动检测本地主机或远程端安全性弱点的程序。系统管理员通过漏洞扫描器能及时发现维护的信息系统中存在的安全漏洞,这样在保卫信息系统网络安全过程中可以有的放矢,及时对漏洞进行修补。按照常规标准划分,漏洞扫描一般分为两类,分别为网络漏洞扫描器(Net Scanner)和主机漏洞扫描器(Host Scanner)。网络漏洞扫描器是指通过网络,远程检测目标主机或网络系统的安全漏洞的程序,典型的程序包括ISS Internet Scanner、Satan等。主机漏洞扫描器是指在本地主机或网络系统上运行检测安全漏洞的程序,如著名的COPS、Tiger等软件。

2)功能验证。功能验证属于软件测试当中的黑盒测试方法,对涉及软件的安全功能,如权限管理功能、用户管理功能、认证功能、加密功能等进行测试,验证上述功能是否安全有效。进行黑盒测试的目的是为了模拟一个用户可能采取的恶意行为,观察Web应用系统及其配套的安全措施能否真正地起到防护过滤恶意行为的作用。

3)网络侦听。实际上,网络侦听是指在数据交互或数据通信过程中对数据进行截取并分析的过程。目前,比较通用的网络侦听技术就是捕获网络数据包,我们通常称为Capture,黑客可以通过该项技术盗取公司或个人有价值的数据,同理,测试人员一样可以利用该项技术测试Web应用软件或系统的安全性。

4)模拟攻击测试。模拟攻击测试对于安全测试来说是一种特殊的黑盒测试案例,我们通过模拟攻击的方式来验证信息系统或软件的安全防护能力,在数据处理与数据通信环境中常见的攻击包括冒充、重演、消息篡改、服务拒绝、内部攻击、外部攻击、陷阱门、特洛伊木马等。

4 测试用例设计原则

一个完整的Web安全测试用例体系设计可以从身份验证、加密、输入验证、敏感数据、配置管理、授权、异常管理、会话管理、参数操作、审核和日志记录、部署与基础结构等几个方面入手。下面将详细描述测试用例设计时需要注意的要点。

1)数据加密设计原则。执行数据传输操作需要对某些数据进行信息加密和过滤,比如用户登录密码信息、用户信用卡信息等。此时,其他操作也需要相应进行,如解密发送到客户浏览器或用户电子邮箱、将信息存储到数据库等。目前的加密算法种类越来越多,设计越来越复杂,但数据加密的过程一般是可逆的,意思就是能对数据进行加密,也能对数据进行解密。一般可在后台数据库查看登录的账户和密码是否进行了加密。

2)目录设计原则。Web的目录安全是一个不容忽视的因素,如果Web服务器或Web应用程序的设计不合理,攻击者就可以通过简单的URL推测和替换,完全获取整个Web目录的权限,这样就对Web站点造成很大的安全性隐患。我们可以采取一定的预防措施,如在访问每个目录时设置index.htm,或者访问Web服务器的目录时对权限进行严格的设定,从而使发生安全问题的可能性尽可能地降低到最小程度。

3)登录设计原则。一般的Web应用站点都会采用登录或注册后使用的方式,所以必须对用户名和密码进行匹配校验,以防止用户非法登录。进行登录测试时,需要考虑的方面包括输入的密码是否区分大小写、是否有长度条件限制,最多可以尝试登录多少次,哪些文件或者页面需要登录后才能访问或下载等。

4)服务器脚本语言设计原则。脚本语言存在一定的安全隐患,每种脚本语言的细节略有不同,有些脚本语言允许访问根目录,其他脚本语言只允许访问邮件服务器,但是有经验的黑客可以通过脚本漏洞获取服务器的用户名和口令。设计测试用例时需确认站点使用了哪种脚本语言,并研究该语言的漏洞,还需要考虑是否存在没有经过授权就在服务器端编辑或放置脚本的情况。

5)SSL设计原则。现在越来越多的Web站点使用SSL安全协议进行数据传送。SSL是Secure Sockets Layer(安全套接字协议层)的缩写,是Netscape首先发布的网络数据安全传输协议。SSL的原理是通过私有密钥/公开密钥的加密技术(RSA),在TCP层和HTTP层之间对用户与服务器之间的通信进行加密,确保信息传递的安全性。SSL是在私人密钥和公共密钥的基础上进行工作,任何用户都可以获取公共密钥来加密数据,但解密数据需要使用相应的私人密钥。打开一个SSL站点后,有时候能看到浏览器弹出警告信息,地址栏的http变成https,对SSL进行测试的时候需要确认上述特征,以及站点是否具备时间链接限制等相关的安全保护措施。

5 结束语

Web应用是一种典型的应用程序,Web应用本身越来越复杂,同时它所使用的开发语言和开发模型在不断发展,所有这些因素给测试带来了很大的难度。目前的安全测试主要依赖测试工程师的直觉和经验,Web安全测试被认为是一个耗时、代价昂贵的过程,因此,迫切需要设计一套系统的Web安全测试用例对Web应用进行全面的测试。本文正是基于以上目的,对Web安全漏洞进行分类,研究了Web安全测试内容,阐述了安全测试用例设计原则。

参考文献

[1]方建超,徐全军.网络安全漏洞检测技术分析[J].计算机安全,2005(10):32-33.

[2]施寅生,邓世伟,谷天阳.服务安全性测试技术研究[J].计算机工程与科学,2007,29(10):11-13.

[3]刘焕洲,缪淮扣.Web应用程序建模和测试用例生成方法[J].计算机工程,2008,34(6):60-62.

[4]The Open Web Application Security Project[EB/OL].http://www.owasp.org/index.php/Main_Page.

7.编写测试用例方法心得体会 篇七

编写测试用例方法心得体会

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^ 在我测试工作中，碰上的测试类型我自己划分成这么４种： ^

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^ 你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ 我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

北京测试空间科技发展有限公司是注册于北京市海淀区高新技术园的软件企业，目前主要业务范围包括软件测试管理 工具研发、软件测试项目外包和软件测试专业技术人才培养及派遣。在软件测试管理工具研发领域已成功开发具有

8.接口测试用例设计思路 篇八

关键词软件测试，测试用例，复用，分词

0 引言

软件测试是在规定的条件下对程序进行操作，以发现程序错误，由此来衡量软件质量，并对其是否能满足设计要求进行评估的过程。作为软件生命周期中的重要环节，其成败直接决定着软件的最终质量。软件测试工作不仅保证了软件质量，而且降低了日后维护成本。随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试也逐渐受到软件企业的关注，正逐步成为一个新兴的产业。测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于测试某个程序路径或核实是否满足某个特定需求。