交互测试范文

交互测试范文（精选4篇）

交互测试 第1篇

在软件开发和维护过程中,随着软件模块化水平的提高,软件的回归测试显得越加重要。然而,大规模、高频率的修改软件也使得回归测试的成本不断增加。因此,解决这一矛盾的重要方案就在于优化测试用例[1]。优化测试用例是指在保持一个较高的、稳定的故障检测率的基础上减少一组测试用例中案例的数量。回归测试中传统优化用例的方法将源码分成两个部分,一部分用于实际测试,而另外一部分则用于软件模块之间的交互。但传统的优化测试用例的方法正面临着新的挑战。例如,现有商业组件COTS的源码通常很难获取得到。另外,对大型软件的源码覆盖率进行分析不仅难度大,而且成本太高。这些问题都限制了现有优化用例方法的使用。因此有必要提出一个无需访问源码的测试用例优化方法。

本文提出了一种基于回归测试的测试用例优化方法。该方法包含一组接口函数,在软件执行过程中,通过使用该方法,可以分析出模块之间的交互过程。该方法不需要对函数源代码访问,也不需要监控模块交互过程,更加不需要对其他模块进行源代码分析,从而显著地增加了该方法的适用范围。

2、优化算法的描述

为了解决现有测试优化方法的不足之处,本文提出了一个新的测试用例优化算法。该算法是一种基于两个软件模块间交互过程的回归测试方法。该方法是对一个测试用例间模块交互“行为”的模拟,不需要访问或监控源代码。

2.1 两个模块之间的互动模式

为了模拟模块间的交互行为,新的优化算法定义了一组模块的接口函数,使其在软件测试阶段被调用执行,且新算法在使用接口函数的时候将考虑函数的传递和参数的传递。

假设有两个模块,模块A和模块B,两个模块之间的交互,通过模块B的接口完成。因此,定义:

(1)接口函数:构成一部分模块接口的函数。

(2)测试用例t的交互记录:模块B的一组接口函数,在测试案例t的执行过程中由模块A调用。假设,这些函数的名字和在调用过程中传递给它们的参数值,或者依照调用次序发生的值,体现了函数的功能。

(3)长度为k的接口函数序列:一个长度为k的连续序列表示一条交互记录。

(4)接口函数的序列集合,相当于案例t中模块A和模块B之间的交互集合一组包含所有可能性的长度为K的序列集合,代表了案例t中A和B之间所有的交互记录。本文使用“滑动窗口”技术[5](窗口的大小等于K)构建这组长度为K的序列的集合。

在这些定义的基础上,本文定义了案例t中A模块和B模块之间的交互模型,该模型表示上文所说的序列集合。

2.2 交互模型的等价关系

对于上面定义的模块之间的交互模型,本文可以定义一个等价关系。文献[6]给出了定义两个交互行为模型之间的关系为等价关系的公式:

这里M1,M2表示被比较的模型;S1,S2表示长度为K的序列;FK1,FK2表示带有参数m的函数,其中前n个参数是文本,其它参数是数值;name(FK)表示函数FK的名称;δ(name(Fi),name(Fj))表示函数fi和fj之间的等价关系;xi,yi,i=1n表示函数Fk1和Fk2的文本参数的值;δ(x,y)表示文本参数x和y的等价关系;xi,yi,i=N+1m表示函数Fk1和Fk2数值参数的值;interval(x)表示数值参数x所属区间的序号;δ(interval(x),interval(y))表示数值参数x和y之间的等价关系。

文献[6]中给出了这个等价关系的详细解释。在这里,可以总结为:两个给定模型的序列集相等时,即认为它们是相等的,否则不等。当两个函数接口序列调用的元素相匹配时,两个序列被认为是相等的。因此,以下3个条件都成立时,即认为函数f1和f2是相等的:(1)函数具有相同的名称,(2)文本参数的值是相同,和(3)数值参数的值属于相同的区间。

2.3 算法描述

该优化测试用例的算法由以下几点组成。首先,该测试启动相同的接口函数序列,在测试模块交互时也使用这组序列;其次,该测试不启动任何模块间的交互;再次,该方法是基于假设和过滤掉的个体测试,它既不产生新的接口函数序列,也不调用接口函数。因此,按照假设,可以使用传统思路去测试交互性。

通过在上一节建立的模块交互模型,提出了以下算法:

S-原始测试用例;

S’-优化后的测试用例,S'⊆S;

S-原测试用例中的下一个测试案例;

Ms-测试用例s的交互状况模型;

MS’-优化后测试用例S’的交互状况模型集合。

(1)首先,从原测试用例中读取下一个测试案例并执行;

(2)在程序执行的过程中,建立了测试用例s的模块交互模型Ms,如果Ms为空,程序返回到第一步;

(3)然后,判断Ms是否属于交互模型集合MS’;

(4)如果Ms不属于MS’,那么Ms加入到MS’,案例s加入到优化用例S’;

(5)当测试用例S耗尽时,程序停止,S'表示该算法工作的结果,即优化后的测试用例。

判断模型Ms是否属于交互模型集合MS’,我们将使用等价关系。这点非常重要,尽管本文讨论的是带参函数的情况,但是这个等价关系当适用于所有能定义等价关系的函数(带参或者不带参)。

2.4 收集交互记录

为了实现该方法,需要一种技术来收集软件组件之间的交互作用记录。许多平台和编程环境提供这样一个机制,可用于收集函数调用记录,而无需访问源代码。这些机制只需要有关的函数特征的信息。例如:在Linux操作系统下,一个由连接器ld提供的拦截函数调用的机制[6];在Windows操作系统下的Detour tool[7];.NET和Java平台自身都内置了这样一种机制,可以允许拦截函数调用,而无需对二进制程序或对象代码实行监控。

在本文的实验中,实验测试了用C语言编写的主应用程序并且在Linux操作系统下运行,测试是通过连接器ld提供的一种机制完成的。这种机制仅需要接口函数的特征信息、一个主程序目标代码入口、主调函数、模块(上例中的模块B)以及那些不需要消耗资源的模块或者模块源码的说明。

3、实验以及结论

本文中的优化测试用例方法主要有两个特点:

(1)测试用例优化的百分比。这一特点体现了一个优化法优化测试用例的能力。

(2)故障检测率。这一特点显示了一个测试用例的故障检测能力。优化后测试用例的故障检测率和原测试用例保持一致或者几乎一致是非常重要的。

以前的实验的实验结果表明:本文的方法可以在不降低故障检测率的基础上提高测试用例的优化率。但这些结果仍然不能说明在集成回归测试中使用优化后的测试集比使用原测试集更能节省资源。在这个实验中,除了提高测试用例优化率和故障检测率,还测量了运行回归测试所需的时间资源。为了做到这一点,本文提出了一个附加的特征,表示了回归测试中优化后测试用例和原测试用例的增益。

3.1 实验环境设置

在这个实验中,本文选用了一系列的测试用例,这些用例是在Linux Standard Base(LSB)规范下,由linux候选作业系统LSB Application Battery v.3.1[8]产生的。本次实验的实验环境采用的是Su SE Linux v10.2。调用接口函数的次数为6次,Xlib库[9]V.11版本和标准C库用作模块整合。

LSB Application Battery v.3.1测试用例本质其实是符合LSB规范的应用程序的集合,这些应用程序由LSB工程提供并用于测试候选作业系统是否满足LSB规范要求。LSB Application Battery的具体任务之一就是测试LSB所有的库函数。基于这个原因,LSB Application Battery所选择的所有的函数库都受到LSB标准的严格约束。Xlib库是c语言函数库的一个子函数库,实现了一个与X Window系统协议相连的接低级别的C语言接口。Xlib库是LSB规范v.3.1必备的函数库之一,并作为网络传输系统x windows系统的一部分。

本文采用一个标准库函数的子集来实现Xlib的库和标准C库之间的相互作用进行测试。该子集定义在stdio.h头文件中,主要负责输入/输出功能。本文还采用X Window X11R6.9.0版的Xlib库、标准c语言库的glibc库作为具体实现。

3.2 实验指标与实验步骤

在实验前,本文收寻了17个分布在Xlib库源代码的不同地方的人为集成错误,由于Xlib库源码主要负责通过输入/输出程序与标准C语言库进行交互,人为错误与文献中提到的变异集成分析相似,创建了错误的样例,这些样例又将错误引入函数的输入/输出参数,并得到错误的函数返回值。并且这些参数被错误的加入到参数列表中,继而影响模块之间的交互。本文使用以下指标:(1)优化后测试用例的大小;(2)优化测试用例的百分比;(3)检测到的故障数量;(4)故障检测率(%);(5)回归测试的时间;(6)回归测试优化后时间减少的百分比。

实验的第一步:收集模块交互的记录和建立模块交互的模型。要做到这一点,需要重新编译Xlib库函数对glibc库的接口函数调用的拦截;第二步:实验执行对LSB Application Battery v.3.1测试用例的测试,并建立交互模型;第三步:实验使用本文的测试用例优化算法,建立优化后的测试用例,并且开始分析和对比两种测试用例的指标。包括:优化后测试用例与原测试用例的大小、优化后测试用例与原测试用例测试的百分比、优化后测试用例与原测试用例测试的故障检测率以及优化后测试用例与原测试用例发现的错误数量。

3.3 实验结果

实验结果列于表1:

结果表明,新的算法减少了原测试用例的88.9%(即9分之一),从而导致测试时间减少了88%,而测试用例的故障检测能力保持在原测试用例相同的水平,优化后的测试用例检测到的错误数量与原测试用例相同。

4、结语

在本文中,给出了一个新的基于回归集成测试的测试用例优化的算法。除了测试用例优化这个主要特性之外(例如测试用例优化百分比和故障检测率),新的算法在计算机资源的消耗上也获得了改进。结果表明,基于回归集成测试的优化测试用例方法具有良好的可行性。

参考文献

[1]林木,戴月明.回归测试中测试用例集优化方法的研究.计算机工程与应用,2011,47(11):54-56,163.

[2]高静,兰雨晴,金茂忠.一种基于运行时交互约束的COTS构件集成测试用例生成方法.计算机科学,2009,36(3):261-265.

[3]杨建军,陈卫东,叶澄清等.面向组件的接口变异测试方法.浙江大学学报(工学版),2003,37(2):129-133.

[4]Rountev A,Kagan S,Sawin J.Coverage Criteria for Test-ing of Object Interactions in Sequence Diagrams.Lecture Notesin Computer Science,2005,3442:289-304.

[5]Steven A Hofmeyr,Stephanie Forrest,Anil Somayaji.In-trusion Detection using Sequences of System Calls.Journal ofComputer Security,1998,6:151-180.

[6]Dmitry Kichigin.Test Suite Reduction for Regression Test-ing of Simple Interactions between Two Software Modules.Pro-ceedings of Spring Young Researchers Colloquium on SoftwareEngineering,2007,vol.2:31-37.

[7]Hunt G,Brubacher D.Detours:binary interception of Win32functions.Proceedings of the 3rd USENIX Windows NT Symposium,1999,7:135-143.

[8]Linux Standard Base Application Battery pages.http://www.linuxfoundation.org/appbat/.

交互测试 第2篇

Nielson主要针对信息架构中的信息分类测试方法卡片分类法，提出实际测试中可能经常出现的问题，并给出了较好的建议。所关注的问题在于：如何提高卡片分类测试的测试效果?卡片分类是信息分类可用性测试中较为理想的方法：让用户主导分类，具体做法是：用户按照自己的思路或直观感觉，把卡片归入已知的或由用户自己新建的类别里，以发现用户对于此类信息的心智模型，并检验事先假设是否直观合理，从而优化信息架构，提高信息浏览或检索的可用性。

Nielson写这篇文章的目的在于说明：卡片分类只是一种科学合理可用性测试方法，但要达到最佳的效果，操作时还需注意几点原则：

不要告诉用户完成任务所需要的具体操作名称; 例如：测试del.icio.us的导入书签功能。如果告诉用户：“你的常用浏览器中收藏了很多书签(bookmarks)，你希望能在 del.icio.us中使用它们，现在把它们导入(import)进来。” 更有甚者：“使用导入书签(import bookmarks)命令导入你的浏览器本地收藏夹”。由于事先被告知了“import”和“bookmarks”这两个词，用户可能会直接在页面中扫 描，或者打开几个菜单，试图找到“import”和“bookmarks”字眼，然而这样就无法测试出“import”和“bookmarks”两个单词 的措辞是否合理，是否符合用户心智模型。可能对于一部分用户来说，更习惯用“favor sites”而不是“bookmarks”来表述收藏夹中的网站。所以最好使用类似下面的措辞：

“你的常用浏览器中一定有不少收藏，现在完成一些操作，让你在del.icio.us中也可以使用它们。”

这 样，喜欢“favor site”而对“bookmarks”不熟悉的用户可能就会想：“favor site” 在哪?没有，那页面中出现的这个“bookmarks”是否就是我的“favor site”?此时，如果用户不喜欢尝试，或者不能迅速地把两个单词联系到一起，就有可能完不成任务，“bookmarks”可能就要换成其他什么 词，“import”也一样。正如Nielson所说：

“如果你告诉用户该用哪个，他们就永远不能以自然的方式使用软件，

只会按照你告诉他们的去做; 而不是他们通常会怎么做。”

因此，测试的时候，不要告诉用户完成任务所需要的具体操作名称。给出这条原则是为了说明卡片分类测试常会遇到的一个问题：关键词匹配。Nielson通过一个case说明：如果对卡片上的关键词设定了某些过度明显的取向，可以大大增加用户分类成功的概率，但这样往往起不到较好的效果。例 如“番茄酱”、“番茄派”、“番茄汉堡”能够很容易地被分到“番茄”类中;而“番茄派”、“草莓派”、“香芋派”则轻易地被分到“派”里。到此有些设计者 就会说：“看，我成功了，因为用户们都分对了类!而且他们分得很快!” 而事实上，这样的分类没有任何挑战性，如果用户想都不想一打眼就能正确分类，那这种测试就没有意义了。“卡片分类不是设计用户界面，是一场关于知识的启发 式演习，用于发现的用户心智模型。” 一般情况下，当设计师对关键词难以取舍、模棱两可，或对专家词汇抱有疑虑的时候才找来用户进行卡片分类测试的。因此，为了优化关键词，我们希望用户能够 “略微驻足思考一下下，而不是简单地尽快完成任务”。当然思考也不能过长，以至无法完成任务。那怎样选择合适的关键词来提高卡片分类的测试效 果?Nielson给出了两点建议：

使用同义词。使用多组同义词替换测试，或交叉组合测试。如，测试一组同义的动词1，2，3，或同义的名词a，b，c，或在需要组合的时候测试“1+b”,“2+a”等等。多组同义词测试有利于发现用户心中最合适的分类名称。

避免非并行结构。使用一组非并行结构的词会人为增加干扰，例如“我要购买”、“卖出商品”、“账单查询”，由于结构不并列，会带来不少干扰因素。而“购买商品”、“卖出商品”、“查询账单”则拥有并列结构，使得用户能够把更多注意力集中到信息的具体意义上。

总结：

做可用性测试只有保持中立的态度，使用中立的语言，才有可能发现更多潜在的问题;

卡片分类的主要任务是发现用户心智模型，在多组备选条目中找到最佳的表述，并找到正确的分类方式;不是单纯验证设计师分类的正确性，满足成就感。

交互测试 第3篇

关键词：网络交互式,测试题,Javascript

随着互联网技术的不断发展, 互联网在教育中的应用也越来越多, 其中测试题是检验学生学习效果的重要手段。但是, 普通文本式测试题缺少互动, 使用不方便。如果希望创建互动式测试题, 学生通过选框或输入框提交答案, 计算机自动判断答案, 并针对不同的测试题给出相应的注解, 则能大大提高使用者的效率及使用积极性, 提高学习效果。但是这种形式的网络测试题需要创建者有一定的编程基础, 多数教师没有技术来创建这样的互动式测试题。为此, 我们设计了一种操作简单、功能完备的基于JavaScript的网络交互式测试题创建系统。

要以比较简单的途径实现交互式测试题, 必须建立在多数教师已经具备的计算机技术之上, 我们设计了一种将常见的文本格式自动转换成交互式表单的转换系统。创建者按照一定的格式规则设置标题、选择项、填空、注解及答案的文本格式, 系统根据格式转换规则将文本转换成包含相应Html及JavaScript代码的交互式测试题网页供学生练习。为了尽量简化创建过程, 格式转换规则设定为“编号”格式对应单选题选项, “项目符号”对应多选题选项, 选择题标准答案对应“下划线”格式, “删除线”对应填空题。“引用”对应习题注解。这样创建者不需要编程知识, 只需按要求设置好格式, 系统将自动转换成互动测试题。一个功能完整的测试题系统, 还要包括自动判断正误、自动打分、习题注解、成绩记录等功能, 因此, 系统还需要根据格式规则提取标准答案, 读取用户提交的答案, 并进行比对判断, 逐一予以相应正误标示, 统计做题所用时间, 给出正确率, 并将这些信息保存于服务器, 便于教师与学生掌握学习效果。

1选择题的实现

按照格式规则, 对于单项选择题, 识别的是设置为“编号”格式的文本, “编号”格式对应 <ol><li>…</li></ol> 的Html标签, 单选题的答案是设置为“下划线” (对应 <u></u> 标签) 的 <li></li> 项目。因此, 需要将 <ol><li></li></ol> 转换为代表单选控件的 <inputtype=”radio” /> 标签, 并提取含有“下划线”格式的<li>的序号作为答案。

多选题与单选题类似, 正确答案标识同样为“下划线”, 不同的是将选项区块设置为“项目符号”<ul></ul> 格式, 一个 <ul> 区块内可以设置多个“下划线”选项。而在转换时, 将<ul><li></li></ul> 转换为代表多选框控件的<input type=”checkbox” />标签。

为了便于DOM操作, 本系统使用了Jquery库, 以下代码以单选题为例, 展示其实现过程:

2填空题的实现

填空题的实现与选择题原理类似, 都是用表单控件替换特定格式的文本。填空题对应的格式是“删除线”<s></s>, 系统会先提取 <s></s> 内的文本作为填空题的答案, 然后用文本输入控件<input type=”text” /> 替换 <s></s> 标签。

3注解的实现

注解对应的是<blockquote></blockquote>标签, 通过设置CSS格式, 在学生未提交答案之前设置为不显示, 即display:none属性。一旦提交结果, 系统将测试题区域内所有 <blockquote> 标签显示, 即display:block属性, 以实现测试时不显示, 提交答案后显示, 达到对于容易出现疑惑的地方给予注解的功能。

4判断对错及打分功能的实现

学生做完测试题并提交答案后, 系统将提取用户提交的表单数据, 与之前提取的标准答案数据进行比对, 对于选择题, 如果与标准答案一致, 则为答案添加绿色边框, 表示正确;否则用红色边框标出标准答案, 表示做错。对于填空题, 如果正确则为文本输入控件添加绿色边框, 如果错误则添加红色边框, 同时为该文本输入框添加Title与PlaceHolder属性, 其值均为标准答案, 这样鼠标悬停在该文本框上时, 会显示标准答案, 在手机等无鼠标的设备上, 只需清空输入内容, 标准答案就会自动显示。最后统计测试题总数与做正确习题数, 将习题总数、正确数、正确率、所用时间等信息展示出来, 并提交到服务器保存, 以便教师和学生随时掌握学习效果。

交互测试 第4篇

问题在于，对于用户来说，在陌生的地方运用任务式的测试方式会让他们小心翼翼、如履薄冰，无法保持自然状态。也许用户不会将紧张、不安的情绪表露出来，但是如果在测试中任务无法完成，用户会更可能将问题归咎于自己，而不是产品的缺点。为了让用户尽可能快的进入测试状态，主动发现和报告问题，给出更有价值的反馈意见，我们在沟通过程中可以使用一些小技巧，快速解除用户的心理防备。

首先要做一些环境准备，将体验室布置得温馨一些，桌上准备一些茶水小零食之类，让刚刚到来的用户喝水休息一下，找到亲切感。

正如运动前也需要进行热身活动调节身体的能量一样，可用性测试开始之前也需要热身，试着熟悉了解用户，尽力调动用户积极性。比如热身交谈过程中可以从用户基本情况开始，引入到使用习惯，多让用户回忆起自己平时的使用场景。这个过程中尽量使用口语化的对话，比如“您平时有什么兴趣爱好?”“平时使用过哪些类似的软件?”“在使用的时候，有没有出现过一些问题?”等等，在加深对用户了解的同时缓解消除陌生感，“话匣子”一打开，用户就容易将想法表达出来，吐露自己真实感受。

在测试开始后，除了主导测试的进行，还要随时注意用户的表情、肢体动作和言论，比如用户不停的皱眉、咬唇表示他们对操作没有信心;当用户瞪大眼睛查看时，表示他们对界面存在困惑;每完成一个动作就立刻把鼠标松开等待下一步指令;操作过程中不时看工作人员的标签，或不时询问自己操作是否正确;反复说自己对操作不熟悉，怕完不成任务等等，这些都是用户紧张、不自然的表现，

这个时候我们要做的就是尽量向用户提示这不是考试，交谈用语尽量避免“请您来进行测试”类似的字眼，改为“请您来体验下我们的产品”会使用户更放松。提示的次数因用户心理素质不同而异，对于不紧张的用户，在测试开始时请用户尽可能按照自然状态使用就可以了，而对于较拘谨的用户，除了测试开始时的提示之外还要随时注意用户情绪，帮助他们舒缓心理压力，当用户在测试过程中出现问题时，提示用户放松，向他们说明这是我们产品的问题，而不是用户问题，请用户不要把责任归咎于自己。

如果用户在测试过程中给予好的意见和建议，应该及时鼓励夸奖，让用户觉得自己的价值得到了认同。如果用户在给出意见的时候吞吞吐吐，欲言又止，应当鼓励用户大胆得讲出来，即使给出的意见并没有什么新意，我们也应该对用户表示感谢，强调这些意见给了我们改进的机会。

用户心理防备逐渐解除以后，可以在适当的时候故意引起用户好奇心，使用户对产品操作产生兴趣，从而在测试时更专注。

需要注意的一点，用户对产品的专业术语知道的有限，通常会用自己常用的词语代替，为了避免凭空猜测用户表达的意思，工作人员可以按照自己的理解复述用户的话，如果用户表示赞同，就代表理解正确;如果用户不赞同，通常都会再重复一遍，并且叙述地更清楚明了。复述时注意使用用户熟悉的词语，避免专业名词，更不要试图纠正用户语句，避免因此使用户产生紧张情绪。