软件测试研究

软件测试研究（共12篇）

软件测试研究 篇1

0 引言

在计算机行业,为了保证软件产品的质量,就需要对软件的运行过程进行控制,同时在软件开发过程之中以及在被投入使用之前,都需要对软件进行多次的检测,保证在软件开发过程中就发现问题,解决问题,防止软件安全漏洞,将最好的成果展现给客户。目前,形式性的方法和软件正确性的证明都还不是使用较多的实用性方法,因此,在相当长的一段时期之内,软件测试仍然是保证软件质量的有效方法。软件测试的工作量很大,根据有关统计,一些要求较高的正规软件,用于软件测试的时间甚至占据了软件开发时间的一半以上。并且软件测试的许多操作都是重复性的、非智力创造的。因此,在针对这些操作进行检测时,就可以运用计算机的自动化技术,这样既可以提高软件开发团队的开发效率,也可以促进自动化技术的发展。

1 关于软件测试管理

在软件测试的过程之中,为了保证软件测试的各项工作能够安全有序地进行,就要对整个测试过程进行有效的干预或管理。在这个过程中,就形成了规范化的软件测试管理方案及技术。测试管理工作在各个阶段都有所体现,包括了各阶段的测试计划、具体测试案例、管理测试流程,并且对结果进行跟踪记录,最后将软件测试的结果反馈给软件开发公司或管理者。其间,测试管理人员如发现软件的任何错误或漏洞,首先必须记录在案,然后对软件漏洞进行跟踪,寻找漏洞生成的原因,并提出解决方案,在一系列的事情完成之后,统一整理成报告,上交给软件开发的管理者审阅。其目的是最大限度地将软件错误减少到最小,保证软件的可靠性。当然,在软件测试管理过程中,如果没有相应的辅助工具,仅仅依靠人工进行处理,可以说是不现实的。下文会继续简述软件开发行业常用的测试管理技术。

2 我国软件测试管理工具研究现状

目前在我国使用较为普遍的是i-Test管理系统,属于中科软科技股份有限公司研发;还有Test Center管理系统,属于上海泽众软件科技有限公司研发。以下就比较完善的i-Test管理系统为例,简述软件测试管理系统的功能特点。

大部分的软件测试管理系统都可以有效地提高软件测试的工作效率,从而极大地降低工作人员的工作负担,并且有利于加强管理层的监督,协调软件测试过程的能力。其最终目的是保证软件的质量,减少成本,i-Test管理系统的功能特点有以下几点。

2.1 运用B/S结构

B/S结构的主要特点在于其可以有效地安装在网络服务器上,这样做的作用是保证相关软件测试的人员可以无论何时何地,通过互联网登录正规工作软件,输入软件测试相关工作人员独特的账号和密码进行查询,为工作人员的工作带来了很大的便利,也大大地较少了人员集中造成的错误和麻烦。

2.2 资源共享

在软件测试管理过程中,软件开发负责企业会提供以往测试用例数据库资料和软件缺陷的数据库,并且负责软件开发的相关技术人员可以申请访问权限,从而共享和使用这些资料。通过对以往软件管理成功经验的吸取以及对失败经验的反思,才能进一步开发出优质的软件,提高软件测试技术,并且提高软件测试管理水平。

2.3 提供相应的自动化功能

软件测试的过程是一个涉及面广且比较复杂的过程,其中难免会有一些重复、无须智力创造的测试步骤。在实际软件测试的过程中,如果这些步骤全部依赖于相关项目人员,则会大大增加工作人员的负担,导致出错。而自动化功能则能代替人工去处理简单的重复、无须智力创造的步骤,可以实现高效率的编写,运行,查询测试用例;在编写软件测试缺陷报告时,能够快速地填写并且修改、查询相关资料,协助分析缺陷原因;另外还能够自动化计算软件研发的进度,输入相关数据自动生成所需的统计图表,还能进一步测试文档的模板,传送到工作电脑中进行排版并打印出来。总之,自动化功能极大地减轻了工作人员的负担,提高了工作效率。

2.4 改善测试过程中存在的缺陷

针对软件测试过程中存在的缺陷,并将其分为6个周期进行详细记录,跟踪、管理每个软件缺陷的研发过程,直到提出解决缺陷的建设性意见,并且按照严重的程度,逐一进行解决。

2.5 加强工作人员的沟通

所有的相关人员随时可以查看相关测试文档、成功用例、缺陷的信息以及测试图表,并且随时可以参与软件的讨论,提出自己的意见。这样也增强了工作人员的团队协作精神,创造了良好的工作氛围。

2.6 加强了软件测试管理的透明度,提高了管理层的监控

软件开发的管理者能对软件测试的过程进行动态的检测,如果发现问题,其有权利协调软件调试的过程。

3 相关的软件测试技术与测试工具

软件测试的核心是测试用例,测试用例的重要性在于其质量与测试的效率息息相关,并且具有良好的发现问题的能力,因此,在软件测试管理的过程中,对测试用例的管理是最核心的功能,而软件测试管理工具则需要协助测试用例的编写。常用的测试软件的方法有黑盒实验、白盒实验、灰盒实验。

3.1 黑盒实验

一般来说,软件的黑盒实验是在软件的接口处进行,即在外部进行,不考虑内部的特征和逻辑结构。这种方法就相当于将测试的对象看成是一个黑盒子,相关工作人员只需按照说明,检查软件的功能是否符合软件的说明介绍。黑盒实验的主要目的包括以下几个方面:

(1)是否存在错误或者遗漏的功能。

(2)在测试对象的接口处,输入的信息是否能被接受,接手之后能否输出正确的信息。

(3)是否存在数据结构方面的错误,或者访问权限错误。

(4)检查软件性能上能否满足客户要求。

在使用黑盒实验时,需要注意要通过制定测试用例起到对软件测试的指导作用,保证软件测试能够有计划、有目的、有条不紊地进行。还有一点就是,在黑盒实验过程中,必须加以量化,只有这样,才能真正提高软件的质量以及客户满意度。在计算机行业,具体的黑盒实验具体量化的方法包括:等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交实验设计法、功能图法、特点图法等。

3.2 白盒实验

与黑盒实验不同,软件的白盒实验主要是对软件的细节作细致的检查。这种方法就相当于把盒子打开,让盒子里的东西展现在人们眼前,由此让工作人员了解到软件的内部逻辑结构以及相关的信息,并且可以利用这些信息,设计或选择测试用例,同时对程序中所有的逻辑路径进行测试。最后通过在不同的检查点检查程序状态,确定实际的状态是否与预期中的状态一致。

白盒实验的主要功能有:

(1)在所有的软件程序中,对于独立的软件路径,每条路径至少测试一遍。

(2)对于所有的关于逻辑的判定,取“真”和取“假”的情况至少都要测试一遍。

(3)对于循环的边界或者是运行的界限内,则选择执行循环。

(4)测试软件内部结构的数据有效性。

白盒实验的具体测验方法有静态结构分析法、代码检查法、静态质量度量法、逻辑覆盖法、基本路径测试法、符号测试、域测试、程序变异等方法。

3.3 灰盒实验

所谓灰盒实验,即是介于白盒实验与黑盒实验之间的,同时具备两者的功能。也就是说,灰盒实验既关注接口处输入以及输出信息的正确性,同时也关注内部结构的逻辑性和联系性。灰盒实验不像白盒实验般详细和完整。只是通过一些特征性的现象来判断内部的运行情况。但有时候灰盒实验又是必需的,特别是在黑盒实验检验表示不存在问题,但是软件又不能正常运行时,这时候如果进行白盒实验,则工作量比较大,但是如果先进行灰盒实验,可能会发现问题,提高检测效率,也就是分担白盒实验的工作效率。

4 软件测试管理工具设计

软件测试管理系统采用的是浏览器/服务器,B/S三层软件体系结构,其中B/S结构是随着互联网技术的发展兴起的,在B/S体系结构下,客户界面可以通过WWW浏览器实现。其有一部分的逻辑结构是在前段体现的,但是主要部分的逻辑结构是在服务器端实现的。

浏览器/服务器,B/S三层结构主要是利用浏览器技术,同时结合浏览器的多种语言,在这个过程中,仅仅使用浏览器就完成了以往多种复杂操作才能实现的功能,从而大大地减少了软件开发成本。

5 结语

近年来,伴随着计算机技术的快速发展,人们对软件的要求也越来越高。本文探讨了一些软件测试的常用实验方法,能够有效地测试软件的可靠性,保证软件的实用性和精确性。同时对软件测试管理方法也有了大概的认识,可以说,在一款软件的开发过程中,对软件的测试是非常重要的,它直接涉及软件的质量,而设计软件的初衷就是为了打开市场,获取利润。同时软件的质量与市场使用量息息相关。因此,在这个过程中,只有充分关注软件测试技术,做好测试管理工作,才能开发出用户满意的优质产品。

摘要：近年来,经济的发展与社会的进步,极大地促进了计算机技术的发展。由于当今社会互联网的普遍使用,人们生活的方方面面越来越依赖于互联网,因此也对计算机软件提出了更高的要求。在这种情况下,就要求计算机行业必须具备先进的软件测试技术以及相应的测试管理研究,前者属于技术层面,是在互联网普遍发展潮流中的必然选择,也是为了满足客户的多种要求,从而取得竞争优势;而后者则属于管理层面,软件测试管理发挥着一种整体的技术,体现在软件测试过程的每个步骤之中。文章认为,两者协同作用,可以有效提高软件测试的管理水平以及软件测试水平。

关键词：软件测试,技术研究,测试管理

参考文献

[1]张德平,聂长海,徐宝文.基于Markov决策过程用交叉熵方法优化软件测试[J].软件学报,2008(10):2770-2779.

[2]蒋芃,李健.计算机软件测试管理应用研究[J].湖南理工学院学报:自然科学版,2007(1):42-44.

[3]闫茂德,许化龙,訾向勇.软件测试技术及其支持工具介绍[J].集美大学学报:自然科学版,2003(2):154-159.

[4]柳永坡,邹磊,金茂忠,等.软件测试领域的知识管理及模型研究[J].计算机应用研究,2009(1):143-145.

[5]王君,管国红,刘玲燕.基于知识网络系统的企业知识管理过程支持模型[J].计算机集成制造系统,2009(1):37-46.

[6]杨朝红,宫云战,肖庆,等.基于缺陷模式的软件测试中的区间运算应用[J].计算机辅助设计与图形学学报,2008(12):1630-1635.

软件测试研究 篇2

【摘要】随着高新技术产业的发展，信息技术在国民经济中的地位日益增加，软件工程作为信息技术产业的重要组成部分，在信息技术领域中发挥着十分重要的作用。随着因特网技术的发展，软件产品也逐渐兴起开来，但是，市场经济体制下的软件产品的质量良莠不齐，严重制约了软件行业的进一步发展，因此，这就需要我们对软件产品进行有效的监督和管理，提高软件测试的效率，使用工程化方式管理软件测试，有效保证软件产品的实用性。

【关键词】软件测试;工程化;研究和实践

前言

软件测试是对保障软件产品质量的有效方法之一，不仅能够保证软件的有效性，而且能够促进软件产品的更新换代。软件测试能够很好的避免软件运行错误对实际生产生活的影响，使得软件产品能够充分发挥其应有的作用。就目前情况分析来看，很多大型优秀的软件公司已经形成了对软件产品系统的测试方法和测试模式，实现了软件工程的规范化管理，在进行生产开发的过程中相对于其他中小型企业来说具有明显的优势。本文根据软件测试过程中主要出现的问题和特点，提出了软件测试的工程化解决方案，希望能够促进软件产业的健康稳定发展。

1.软件测试模式

当前来说，世界各大公司的主要软件测试模型包括X模型、H模型以及V模型这三种软件测试模型，V模型是目前来说最为广泛采用的软件测试模型。V模型的理念在于提高了软件工程测试工作的独立性，认为软件的测试工作的重要性与软件的开发过程等同。相关测试人员的工作需要在软件项目各个阶段同时进行，在软件开发与应用的过程中要充分了解其作用和功能，并根据项目的性能特点和功能要求进行科学合理的软件测试。及时监控并发现软件运行中出现的问题并反馈给相关技术人员，以提高软件的安全性和稳定性。[1]

2.软件测试的人员要求

软件产业相对来说是一个劳动密集型产业，对于工作人员的技术素质要求也比较高。软件测试人员需要有充足的工作经验，并有较高的专业素养，才能胜任软件测试的工作。测试人员首先在测试开始之前需要对软件进行充分的了解，包括软件的运行模式、功能功效、甚至针对的用户群体等。其次测试人员要能够根据软件的实际情况设计合理的测试计划和方案。对于很多大型软件来说，往往需要多人组成的测试组来进行测试工作，这就需要测试组的各个人员之间能够进行有效的分工合作，共同设计、组织和实施软件的测试工作，保证软件测试工作的效率性和准确性。[2]

3.软件测试的生命周期

在计算机领域软件测试具有一定的生命周期是众所周知的事情，一般来说对软件的测试包括单元测试、集成测试、系统测试及验收测试，这些测试都具有相应的生命周期。软件测试人员在测试计划阶段时要充分掌握组织测试计划有关的内容，并分部分进行软件的测试，在测试之前制定软件测试计划;对于测试设计和定制个性方案的过程中，相关技术人员要充分了解该款软件的用户信息和要求，制定《测试设计方案》，确定测试的过程和方式。在测试的执行阶段测试人员可以根据《测试计划》和《测试设计方案》进行具体的测试工作，之后在测试的评估阶段根据测试过程中所发现的问题编写《测试总结分析报告》。规范测试文档是软件测试生命周期管理的另一项有效工具，在实际操作中我们需要根据测试文档产生的时间、格式以及内容等要求进行规范。比如对于单元测试来说，《测试计划》、《测试设计方案》、《测试问题报告》以及《测试总结分析报告》是必不可少的。IEEEStandardforSoftwareTestDocumentation定义了测试软件的内容和文档的类型，不同的软件企业在规范的基础上，根据自身企业的特点和软件的实际情况，可以对文档进行适当的裁剪及修改，制定出符合企业自身的软件测试文档规范。[3]

4.软件BUG的综合管理

在软件测试过程中，往往会显露出软件运行过程中的各种问题，对软件的问题进行有效的管理是进行软件测试工程量化管理的重要保证。一般来说，软件问题包含优先级、运行环境、严重级、问题来源、问题种类、负责人、状态、问题关联、附件、缺陷细节以及附图等内容。这些软件问题记录对于软件产品的测试工作和改进工作提供了科学的参考，因此，对软件问题进行综合的`管理是当前我们所要关注的首要问题，目前来说主要的两种软件问题管理方式分别是手工或半自动化软件问题管理和软件问题自动化管理这两种管理模式。

4.1手工或半自动化软件问题管理

在手工或者半自动化软件问题管理中，要把握住管理的核心即“问题报告单”。问题报告单能够直观准确的反映出软件的问题，是有软件问题的基本信息构成的，一般来说一个软件问题会产生一个问题报告单，问题报告单可以是Word版本或者Excel版本。在问题管理的过程中我们需要保证的是问题信息的完整性，在实际操作中需要按照问题类型制定统一的报告单模板。

4.2软件问题的自动化管理

在软件问题的综合管理模式中，软件问题的自动化管理方式目前来说得到了软件行业的广泛重视，其管理模式相对于手工或半自动化软件问题管理模式来说管理更加先进，而且管理过程中自动化程度很高解放了人力，且更加高效。我们使用HP公司的测试管理工具QualityCenter管理软件问题的生命周期，通过该测试管理工具得到软件的问题状况，利用QualityCenter跟踪软件问题的特点使得相关工作人员能够及时的掌握软件的运行情况，从而及时对软件问题进行修复，提高软件的质量。软件问题的自动化管理技术使得软件运行过程中的问题能够及时有效的反馈到技术人员手中，弥补了手工或半自动化软件问题管理的缺陷，有效提高了软件测试工作效率，从而促进软件产业的发展。

4.3QualityCenter的具体应用

我公司都使用QualityCenter管理测试出的软件问题，一般软件问题的处理流程为：测试人员将测试出的软件问题记录到QualityCenter中，由项目主管判断软件问题是否存在，如果存在则分配给相关的开发人员进行修改处理，处理后再由测试人员验证该软件问题是否正确解决，如果正确解决则关闭该软件问题，否则还需开发人员再次修改。QualityCenter可以在整个流程中管理软件问题的各个状态，并记录重要的信息。

5.软件测试的辅助工具

测试实施的辅助工具主要分为白盒测试工具和黑盒测试工具。其中白盒测试工具主要测试的内容是软件的代码问题，从而问题信息的指向是软件代码，对问题的定位十分准确。黑盒测试工具主要包括两方面的内容，一方面是功能测试工具，另一方面是性能测试工具。黑盒测试工具利用的是脚本的录制和回放功能，从而进行用户操作的模拟，将测试工具中的输出记录下来与标准的结果做出对比，发现软件测试中的问题。

6.结束语

随着我国IT行业的飞速发展，软件测试技术也随之兴起。将软件测试行业更加的规范化和工程化可以有效提高软件的检测效率，而且能够对整个测试过程进行控制，及时发现软件中出现的问题并有效处理。对于不同的软件而言，我们需要根据软件的具体情况进行合理的测试方式选择，从而提高软件测试的合理性和准确性，促进对于软件检测的整体管理。目前已经有很多高效的检测软件用于软件测试，也有很多软件问题管理系统用于管理软件问题，这些都提高了我国的软件行业整体质量，使得软件行业能够更高效更安全的发展。

参考文献

[1]张光泽,于鑫.“软件测试”工程化教学模式初探[J].大学教育,2015,(3).

[2]李亚.“软件测试”教学探索与实践[J].计算机教育,2016,(6):31-32.

软件测试方法的分析与研究 篇3

【关键词】软件测试；测试方法；黑盒测试

【中图分类号】TP306 【文献标识码】A 【文章编号】1672-5158（2013）03-0026-01

随着软件产业的迅速发展，软件产品的质量已成为软件企业生存与发展的关键。软件缺陷自软件诞生的那一日起就跟随着出现，软件测试就应运而生。随着软件内容和结构的不断丰富，软件缺陷也日趋多样化，引起更为严重的质量问题。软件测试方法的研究正是本着提高软件质量，降低软件缺陷的影响。随着人们对软件质量的重视，软件测试也不断得到加强和持续发展。

1、软件测试的定义

软件测试应该是以查找软件缺陷为目标的一种过程，测试用例设计和缺陷管理是软件测试中提高缺陷查找效率和缺陷处理效率的两个有效手段。软件测试依靠的是强大的逻辑和条理性来完成工作，也同时存在着一定的风险。软件的应用形式多样，输出和实现功能的方式也不止一种，而产品设计中缺乏客观的标准，就使得软件缺陷的标准也变的多样，没有任何一种方式能够对软件进行完全测试。这样，就无法通过软件测试显示隐藏的软件缺陷，只能尽量查找软件缺陷，找到的软件缺陷越多，说明软件本身的缺陷就越多，同时尚有在测试过程中被发现和断定的缺陷，这也是软件测试的局限性。

2、软件测试的基本方法

软件测试过程包含几个阶段：测试需求的分析和确定；测试计划；测试执行；测试记录和跟踪；回归测试；测试总结和报告。狭义的测试是指在代码编写完成后对代码进行测试，而广义的测试开始于需求阶段，伴随着设计、实现阶段。如测试需求规格说明书，测试设计框架等。可以从不同角度来划分软件测试方法。

2.1静态测试和动态测试

软件测试从是否需要执行被测软件的角度，可以将软件测试分为静态测试和动态测试。静态测试是指依据需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行，对软件进行分析、检查和测试，不实际运行被测试的软件，约可找出30%到70%的逻辑设计错误。这种方式不通过程序运行就能够寻找代码中的缺陷或对程序中的代码进行评估，可以由人来操作，发挥了人的逻辑思维的优势或测试经验，能够批量性地发现问题，并直接定位到缺陷或错误的具体位置。静态测试可以分为静态分析和代码走查。静态分析是一种计算机辅助静态分析方法。主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。静态分析的对象是计算机程序，程序设计语言不同，相应的静态分析工具也不尽相同。代码走查是一种人工测试方法，它一般依靠有经验的程序员根据需求分析、设计规格等来执行。动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试有两个基本要素：被测试程序和测试数据。

必须生成测试数据来运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析测试质量依赖于测试数据。

2.2黑盒测试、白盒测试、灰盒测试

从测试是否针对系统的内部结构和具体实现算法来看，可以将软件测试分为黑盒测试、白盒测试、灰盒测试。

黑盒测试又称功能测试，数据驱动的测试或者基于规格说明书的测试。黑盒测试可以从软件的功能为起始，根据功能的需求说明测试所用的方式，并依据该方式的需求来运行被测试的程序。从名字上来解释，就是将软件看成是不透明的黑盒子，对于盒子内部的结构不理会，只关注软件的实用功能，并对这些功能进行测试。

白盒测试又称结构测试，玻璃盒测试或基于覆盖的测试。相比较于黑盒测试，它更关注于软件内部逻辑结构，其测试的重点是测试用例的覆盖程序结构的程度。白盒测试，是将软件比作透明可见的盒子，测试人员可以根据程序内部的逻辑结构来设计测试用例，来测试程序的逻辑路径。

灰盒测试，也称跟踪法测试，是指介于白盒测试和黑盒测试之间的一种测试方法，它关注输出对于输入的正确性，同时也关注内部结构形式的程度，它跟踪程序的运行过程，特别是输入数据在程序中的“流程”。比如，测试人员输入数据后，软件会将其转换为代码并通信至服务器，服务器经过一系列的处理，将数据传送给客户端，并最终显示给测试者。灰盒测试能够对整体的过程进行追踪，对每一步的数据进行测试。。但较白盒测试而言，灰盒测试没有深入解析程序的结构，但也不像黑盒测试那样只关注输入和输出，它也关心程序中间的某些流程是否正确。

3、软件测试用例设计

传统软件测试用例设计是从软件的各个模块的算法细节得出的，而面向对象的软件测试用例则着眼于适当的操作序列，以实现对类的说明，主要有基于故障的测试、基于脚本的测试和类层次的分割测试等形式。

3.1基于故障的测试

软件系统最终是以实现用户的需求为目的的。基于故障的测试是从模型分析开始，逐步来测试软件可能发生的故障，为了确定故障的类型和存在方式，一般设计用例去执行代码。基于故障的测试核心问题是测试者怎么来判定错误的性质。“可能的错误”可以是意料之外的结果，不正当的操作，错误的引用等。如果是操作不当引起的错误或故障还需要对操作进行检查，排除操作因素引起的故障。这种方法除用于操作测试外，还可用于属性测试，确定其对于不同类型对象行为是否赋予了正确的属性值。

3.2基于脚本的测试

基于脚本的测试主要关注用户的需求，并从用户任务中找出用户要做什么及去执行。这种基于脚本的测试有助于在一个单元测试情况下检查多重系统，所以基于脚本用例测试比基于故障测试更实际也更复杂。

3.3类层次的分割测试

类层次的分割测试可以减少用完全相同的方式检查类测试用例的数目，这与传统测试中的等价类划分测试很相似。类层次的分割测试主要分为：基于状态的分割，按类操作是否改变类的状态来分割；基于属性的分割，按类操作所用到的属性来分割；基于类型的分割，按完成的功能分割。

4、结语

软件设计中出现的缺陷是无法完全消除的，却可以通过软件测试来降低缺陷的发生，随着市场对软件质量要求的提高，软件测试在软件开发中的地位越来越重要。软件测试的最终目的不是为了找出软件设计中的错误和故障，而是通过测试来发现缺陷，找出缺陷的分布特征和出现的规律，以期在新的开发项目中寻找更优的方式来避免缺陷的出现，改进设计结构，同时也能够通过设计有针对性的检测方法，改善软件测试的有效性。

参考文献

[1]侯衍龙.基于UML的面向对象建模技术与应用[D].南京，南京航空航天大学，2002

软件测试性定义研究 篇4

随着软件规模和复杂度的增大, 软件测试面临的问题也日益突出, 如要求测试的类型和数量越来越多、执行测试的难度越来越大、对测试充分性的要求越来越高等。这些问题不但会增加测试费用、影响测试效果, 还会影响用户对测试结果的信任程度。

软件测试性研究能在一定程度上解决上述问题。测试性设计能在不增加或少增加软件复杂性的基础上将易于测试的原则融合到软件设计或编码中去, 从而提高软件测试性。软件测试性越高, 软件越易进行测试, 软件中的缺陷越易暴露, 只需进行较少的测试就能发现更多的问题。测试性分析能在软件测试之前得到软件测试性的大小, 测试人员可据此分配测试资源以进行更充分的软件测试, 由此提高测试结果的可信性[1]。

良好的软件测试性定义是测试性研究的基础, 是顺利进行软件测试性分析和设计的保证, 因此有必要对软件测试性定义进行深入研究。

1 软件测试性定义现状

IEEE在1990年出版的软件工程技术术语中提出软件测试性是:1) 为一个系统或构件建立测试标准并通过执行测试来确定该标准被满足的难易程度;2) 对每一个声明的需求建立一个测试标准并通过执行测试来确定该标准被满足的难易程度[2]。该定义比较抽象和难以理解, 文献[3]在对通信软件的测试性定义时进行了简化, 认为软件测试性是软件为易于应用测试方法、发现存在的软件错误和更快地纠正错误而提供便利的一种属性。文献[3]将错误纠正也纳入了软件测试性范畴, 软件测试性是与软件测试相关的软件特性, 而错误纠正并不属于软件测试活动, 在软件测试性中进行讨论不太合适。

文献[4]认为软件测试性是使用传统的程序测试方法论证程序正确性的难易程度;文献[5]对软件测试性的定义是测试软件设计的难易程度;文献[6]将面向对象系统的软件测试性定义为暴露软件缺陷的相对难度和费用;文献[7]将软件测试性定义为测试软件所需的费用。上述定义都是将测试性与测试难易程度结合起来进行考虑。软件测试性与测试难易程度的确存在密切关系:测试性能够预计测试的难易程度, 测试难易程度同样能反映测试性好坏。但两者还是存在区别:软件测试性是软件本身的属性, 理论上只要软件不发生变化, 软件测试性也不会发生变化;而测试难易程度不仅与软件相关还与测试的过程、方法、工具等外部条件相关, 使用不同的测试方法、运用不同的测试工具都会影响测试难易程度。因此使用测试难易程度定义软件测试性并不恰当。

文献[8]认为软件测试性是在某一特定的输入分布下, 软件中包含的一个缺陷在下一次测试执行过程中失效的概率;文献[9]认为软件测试性不但与软件的输入分布和缺陷有关还与测试预言存在很大的关系, 因此将软件测试性定义为在程序有错并且给定了明确预言的条件下, 从一个特定的输入分布中抽取一个输入进行测试时被拒绝的概率。如果说以往的研究者是从测试过程的角度研究软件测试性对测试费用、测试进度的影响, 文献[8, 9]定义的软件测试性就是从测试结果的角度讨论软件暴露自身缺陷的能力。然而这些定义都是基于软件的故障/失效模型, 它们只反映了软件实现 (代码) 的测试性而不能表示软件整体的测试性, 因为它们未能考虑软件的其他方面如需求、设计等。

还有部分研究者通过将软件测试性分解为其他软件特性的方式定义软件测试性, 其中比较典型的文献[10]就将构件测试性定义为可理解性、可观测性、可控性、可跟踪性和测试支持能力的综合, 这种定义虽然有助于人们全面地了解软件测试性, 但也只是列出了软件测试性内容而没有揭示软件测试性本质。

总结上述软件测试性定义发现:当前软件测试性定义众多但还存在不足, 没有形成统一的认识;各定义在表达形式、表述内容、适用范围上还存在差异, 不利于后续的软件测试性分析设计。因此目前还需要对软件测试性定义进行更深入地研究以帮助人们更好地理解软件测试性。

2 软件测试性定义

上述软件测试性定义都是从软件测试角度提出, 考虑了软件测试的不同方面。文献[2, 4]把软件测试性与测试过程联系起来, 将软件测试性定义为与测试过程相关的软件属性, 无论定义为便利的程度还是测试的难度与费用都是为了描述软件测试性对测试过程的影响。软件在开发过程中不可避免地要引入缺陷, 软件测试的目标就是要将这些内在缺陷暴露为软件失效。从软件缺陷到软件失效需要经历一系列过程, 这个过程不仅与软件的自身结构相关还与软件的一些外在条件如施加的输入、确定的预言有关, 文献[8, 9]将软件的内外条件结合起来定义软件测试性、揭示了软件测试性对测试结果的影响。

考虑软件测试性对软件测试的不同影响, 综合上述各软件测试性定义, 本文认为软件测试性是软件易于测试和暴露缺陷的能力, 该定义可从以下几个方面进行理解:

1) 软件综合后的软件测试性定义不是针对构件或软件设计提出, 而是针对宏观意义上的软件提出。此处的软件可以是软件的需求、设计, 也可以是软件的实现;可以是软件的程序, 也可以是软件的文档;语句、函数、模块、构件, 软件各个设计层次的产品都在此范围之内;系统软件、应用软件、嵌入式软件, 各种类型的软件也都包含其中。

2) 能力软件测试性是软件的一种设计特性, 软件一旦开发出来就具备一定的测试性, 理论上与软件的外部条件无关。为了体现软件测试性的这一特点, 本文使用“软件测试性是软件…的能力”的方式进行表述, 指出软件测试性是软件的一种能力、是软件的一个内部特性。

3) 易于测试参考文献[2-4, 6]的定义, 综合后的软件测试性定义提出软件测试性包含软件易于测试的能力。该能力主要由软件的需求和设计决定, 能够影响软件测试过程。软件易于测试的能力越高, 测试越易进行, 测试所需的时间或费用越低;反之, 软件易于测试的能力越低, 测试越难进行, 测试所需的时间或费用越高。

4) 易于暴露缺陷文献[8, 9]的软件测试性定义结合了软件的内外条件, 本文去除其中的外在条件、只考虑软件将内在缺陷表现为外在失效的能力, 并将之重新描述为软件易于暴露缺陷的能力。该能力主要由软件的实现决定, 受软件的编程语言、内部结构影响, 能够影响软件测试结果。

综合后的软件测试性定义考虑的软件范围更广;指出了软件测试性是软件的一个内在特性;反映了软件对测试过程和测试结果的影响;定义的形式简单、易于理解。与其他软件测试性定义相比, 该定义具有明显的优势。

3 测试性特性分析

从文献[10]的测试性定义可以看到软件测试性不是单一的软件特性, 而是众多与软件测试相关的软件特性集合, 本文将这些软件特性统称为测试性特性。由于每个测试性特性代表了软件测试性的一个方面, 了解测试性特性有助于更全面地理解软件测试性。总结当前的研究工作, 可以得到如下测试性特性:

可理解性是为更好地理解软件, 软件提供信息的表达程度。测试准备过程中需要根据软件信息生成测试用例, 包括确定测试输入和预期输出、确定软件的执行条件等。为了完成这些工作, 就要求软件文档必须详细、准确、无二义、易于理解, 软件代码的结构必须清晰、模块化程度高、可读性好。

可控性是软件易于施加外部输入和控制内部状态的能力。测试执行的一项主要工作就是向被测软件施加输入, 输入越多、输入间的关系越复杂、输入接口的通用性越差就越难施加输入, 可控性也就越差。另一方面, 为了验证软件的某些特殊功能或测试软件在某些特殊情况下的反应, 可能需要软件处于一些非正常状态, 此时就需要能够控制软件内部状态。

可观测性是软件易于观测外部输出、监控内部状态的能力。测试执行过程中的另一项主要工作就是观测和收集测试结果, 软件的输出是否明显、是否易于观察、输出数据是否易于收集都将影响软件的测试效果。对于外部输出不明显、不易于观测或输出数据过少等情况, 就要求软件能方便地监控内部状态、辅助判断测试结果。

测试支持能力是软件对测试工具的支持能力。人工测试的效率低下, 使用测试自动化工具能极大地缩短测试时间、减少测试费用;对于某些输入输出过于复杂或者时序要求比较高的软件, 可能根本就无法进行人工测试, 只能使用测试工具。因此当条件具备时, 软件能否方便地支持测试工具将极大地影响测试过程。

简单性是软件在满足需求的基础上尽量简单、无冗余的特性。从软件本身角度:软件越简单、功能越少, 软件的规模就越小、复杂度越低, 软件出错的可能性也越低。从测试的角度:软件的功能越少, 需要测试的数量就越少, 测试费用也越低;软件操作越简单, 越容易施加测试输入, 测试的难度就越低。

可分解性是软件能被分解为独立的模块进行单独测试的能力。将软件分解为几个独立部分, 测试时只需考虑与该部分有关的输入和输出, 常常可以简化测试, 因此文献[11]指出如果能单独对模块进行测试将极大地提高系统的测试性。

适用性是软件适应各种使用环境的能力。主要从两方面进行考虑:一方面是软件运行时的环境要求, 要求越低, 表明软件对外部环境的依赖越低、越易搭建测试环境;另一方面为软件是否足够灵活、能否根据环境的变化自动改变自身配置, 如根据显示器分辨率自动调节窗口大小等。

可跟踪性是软件能跟踪自身功能操作、属性和行为的能力。程序调试过程中可能需要跟踪代码的执行情况, 观察此过程中使用的不同变量的取值, 从而判断程序是否正确;测试过程也是如此, 有时也需要跟踪功能在执行过程中经历的操作、属性或行为, 根据它们的情况判断软件是否正确。

敏感性是软件易于暴露自身缺陷的能力。开发过程中的人为错误可能会在程序中留下缺陷, 这些缺陷不会主动暴露, 只有当隐含缺陷的代码被执行、造成某些状态错误、软件将这些错误的状态传递到外部后才能发现。敏感性就是对软件将缺陷转化为错误状态、再将错误状态传递到软件外部的能力的描述, 敏感性高的软件在测试过程中更易发现软件缺陷。

软件测试性与测试性特性的关系如图1所示:软件测试性可划分为软件易于测试能力和软件易于暴露缺陷能力两部分, 其中软件易于测试能力又可细分为可理解性、可控性、可观测性、测试支持能力、简单性、可分解性、适用性和可跟踪性, 软件易于暴露缺陷能力则能用敏感性表示。

简单的分析可以发现, 上述测试性特性中除了可观测性与可跟踪性, 其它测试性特性分别代表了软件测试性的一个不同方面、相互独立。可跟踪性可看作可观测性的一种扩展, 要求能根据功能的执行观察相应的操作、属性或行为的输出。如果将可观测性限定为对固定的外部输出或内部状态的观测, 可跟踪性就是对变化的输出的观察, 两者将代表软件测试性两个互不交叉的领域。

至此, 软件测试性可用测试性特性集合表示, 对软件测试性的分析也可分解为对各测试性特性的分析。软件测试性的集合表示如下:

4 测试性与其它质量因素

软件质量模型中, 软件测试性不是作为一个独立的因素就是包含在其它质量因素中, 了解软件测试性与其它质量因素的关系有助于更深入地理解软件测试性。

Perry总结了Boehm模型中各质量因素的相互关系并将它们分为三类:反相关、中立和正相关, 其中测试性与正确性、可靠性、可用性、可维护性、灵活性、可移植性和重用性正相关, 与效率反相关[12];同样是分析Boehm模型中的质量因素, Glass使用关系矩阵表示因素间的相互关系, 指出测试性与效率、人素工程、易理解性和可修改性之间存在相互关系[13];Shumskas主要考虑系统在开发过程中与性能、设计和适用性相关的质量因素如可靠性、可维护性、测试性等, 指出效率对测试性产生消极影响, 可维护性和重用性对测试性产生积极影响, 反过来测试性对效率、可靠性产生消极影响, 对可用性、正确性和可维护性产生积极影响[14]。

Perry给出的质量因素相互关系是从经验或直觉出发, 不够准确;Glass的分析过程相对客观而准确, 但只是指出因素间的关系而没有给出关系类型;Shumskas从测试性对其它质量因素的影响和其它质量因素对测试性的影响两方面分析软件测试性与其它质量因素的关系, 比其它方法更为全面和准确。无论上述哪种分析, 其分析对象都是Boehm等人在1976年确定的软件质量因素, 时至今日, 随着软件质量概念的发展软件质量因素也都发生了改变, 因此有必要对软件测试性与其它质量因素的关系进行重新分析。

当前比较通用的ISO9126质量模型[15]将软件质量属性划分为六大特性 (功能性、可靠性、易用性、效率、维护性和可移植性) , 每个特性又进一步细分为若干子特性, 测试性是维护性的一个子特性。本文选择了维护性中与测试性同级的质量因素 (易分析性、易改变性、稳定性) 以及上述六大特性, 应用Shumskas方法分析了它们与软件测试性的关系, 最后得到的结果如表1所示, 其中“+”表示积极影响、“-”表示消极影响, “A”表示要根据具体的软件分析。

5 结论

软件开发的性能测试与研究论文 篇5

度量式测试可以发现隐患问题，而检查式测试却只能找到表面问题。检查式测试本身标准明确，正确或错误明确标识，显而易见，且一般一个功能只检测一次。度量式测试客观的记录软件状况，比如：软件“死机”是个必然存在的情况，大多数情况下都会有所影响，且有一定后续不良反应。有种数据就是针对死机问题专门收集的各种类似情况，其中包括软件外部偏离受损、非自愿操作、死锁、功能受损的显现，根据死机原因提供相应参考资料，找出死机问题的原因，制定对应的解决方案，这类的可靠性运用在软件中较少，但是在其他工业运用中比较常见。另外一种度量式测试专门解决非一般性的问题，多出现在 测试阶段，找出问题的同时针对软件本身重新调整开发设计。互联网的一些软件操作习惯和方式多数都是互动操作，对之前的设计加以改进，并研究出新的软件开发性能需求。度量式测试的前期需要的数据不用太灵活的判断分析，可调整相关资源，使之得到最大化的利用，所以合适的度量式测试会使软件项目的测试效果更高、更好，使软件开发的性能能上升到一个新的高度。

4 结语

总体来讲，检查式和度量式具有本身的优点，同时也存在缺点。项目中不同的测试需求、不同的资源开发和不同的测试人员都可以选择相应的测试方法进行测试，善于合理运用检查式测试和度量式测试这两种方法，利益结合，避免隐患缺陷，将迅速提高软件测试的高效率。正确利用软件性能测试，必须知道性能测试的内涵，站在不同的角度方位去想问题，了解社会发展趋势，熟悉目前流行的软件性能测试方法，合理掌握过程，注意将检查式测量和度量式测量结合运用，收集相关数据种类和方式，以提高软件的性能测试效率成为未来研究的重点思路。

作者简介

手机软件功能的测试研究 篇6

关键词 手机终端测试平台 软件测试 数据库

中图分类号：TN92 文献标识码：A

1国内外研究现状

现在的社会是一个对于信息化依赖程度不断加深、对信息速度要求不断提高的社会，必然会对可移动信息设备提出全方位的要求——安全、稳定可靠、方便灵活。手机测试正是控制软件产品质量的重要手段。

长期以来，我国手机企业产品开发时，测试成本常常被压缩。导致我国手机产品质量低下，无法创出自己品牌，走向世界。

2主要开发任务

测试平台需要关联测试目标、测试用例库、测试辅助程序库、历史结果集等对象。系统管理员由登录发起对测试平台、测试用例库、辅助程序库、历史结果集的管理及监控等任务。在执行这些任务的过程中，测试平台需要自动地完成某些数据和文档的自动存储和关联。

在性能方面，对于测试平台要求：其具有足够的稳定性，并发性，在数据读取方面要求也比较高。其次要求有完整的冲突处理机制。在业务或者任务发生变更之后，需要能够对测试员进行有效的提醒。

3系统的功能需求

3.1测试用例管理

测试用例管理包括添加新的测试用例，删除过期的测试用例，修改测试用例，按条件查询测试用例以及执行测试用例。系统管理者可以对测试用例进行增删改查等操作，而普通的测试工程师只能够对测试用例进行执行操作。

添加新的测试用例：当一款新的手机产品需要进行测试时，手机生产厂商会提供手机的功能说明书，测试工程师会根据说明书来测试相应的功能且将这些测试用例写到系统中。

删除过期的测试用例：在手机的测试过程中，手机会根据测试报告进行一些功能上的修改，根据各方面的分析可能会删除一些功能，那么相应功能的测试用例就需要被删除。拥有删除权限的测试工程师可以删除这些测试用例。

修改测试用例：在测试的过程中，手机某方面的功能修改了，那么相应的测试用例就需要修改。拥有修改权限的测试工程师可以修改这些测试用例。

3.2用户管理

新用户注册：与其他系统不同的是，由于IT行业需要极高的保密性，测试的手机和版本未上市，这需要在测试过程中对测试的产品进行保密。创建新的用户需要系统管理员来执行，并且由系统管理来将账号和密码发送给测试工程师。

基本信息修改：用户登录后，可对自己的一些基本信息进行修改。

密码修改：用户登录成功后，进入密码修改页，可重新设置登陆密码。

3.3权限控制

只有管理员具有此权限。管理员进入权限控制页面，为不同的角色分配不同的权限，权限细分到每个功能点，设定好角色的权限后，管理员可为不同的用户分配不同的角色。

4系统与数据库数据交互使用存储过程

存储过程是为了完成特定的功能而汇集成一组的SQL语句，用户为该SQL语句命名，经编译后存儲在SQL Server的数据库中。同时，用户可以指定存储过程的名字和参数来执行它。在存储过程中可以验证数据的有效性，并且可以将执行的结果返回给用户。

5功能分析

系统的功能分为：登录模块，测试用例管理模块，测试用例执行模块，用户权限模块等。

登录模块：主要提供用户登录系统的功能。

测试用例管理模块：用户登录成功后会查看测试用例以便对测试用例进行相应的操作。

测试用例执行模块：用户在登入之后能够执行必要的操作。

用户角色管理模块：用户可以对自己的角色进行修改和管理。

用户权限模块：这个权限只用于对用户本身，只有自己才能登入。

6存在问题

当用户登录后，系统会从数据库中读取大量测试用例，因为手机软件功能测试用例一个feature就存在几百条，当多个用户同时读取多个feature时，造成数据拥塞，读取比较慢。所以在一定的程度上面还是无法大幅度的进行彻底改变，但是我们可以从微小的细节上进行修改，比如减少不必要的测试以及重复的测试用例来提高对速度上的改变。或者是一个个的读入而不是一次性把所有的用例全部读进去，再一个个的分析。

7结论

本论文主要通过对NET手机软件功能测试平台的设计与实现的相关技术的研究。在系统设计和开发过程中，首先进行系统的需求分析，确定系统的功能点，完成需求，接着进行各功能模块的设计和数据库设计，最后对系统进行相关的测试，编写测试用例。

参考文献

[1] 巫红霞.关系数据库中查询优化方法的探讨.镇江高专学报，2007.

[2] 张能立.ASP.NET在网站开发中的应用.计算机与数字工程，2005.

[3] 邵良珊.ASP.NET（C#）实践教程.清华大学出版社，2007.

[4] 陈冠军.精通ASP.NET 2.0典型模块设计与实现.人民邮电出版社，2007年.

软件测试能力培养体系研究 篇7

一、软件测试行业现状

国外软件测试的历史较长, 最早可以追溯到20世纪50年代后期的“调试”时期, 后续经历了论证时期、破坏性测试时期、生命周期评估和预防性测试时期。目前, 国外软件测试已有严格的测试工作标准和范围规定。从业人员平均技能水平较高, 可从事时间也比较长。待遇与开发相当, 人员配比充分合理。软件测试能力培养在自动化和手工测试方面均有很强的实力。

相比于国外, 我国软件行业起步较晚。整体软件产业于20世纪80年代开始起步。而软件测试在2000年才开始发展。2005年后软件测试行业和人力需求开始呈现急速上升趋势。而与产业飞速发展形成鲜明对比的是软件测试“缓慢”的人才培养, 软件测试从业者能力水平一般, 培养体系不健全。结合当前国内软件测试的现状和各企业对软件测试的需求情况, 从当前和长远情况来看, 专业性和职业化的软件测试都会有很大的发展空间。

二、企业对软件测试人员的能力要求

国内企业对软件测试从业人员能力的要求差异较大。在规模较大且流程较为规范的软件企业, 一般具有独立的测试部门和质量部门。测试部门通过合理的人员分配, 以产品或项目目标为核心, 向项目组配置相应测试人员来辅助产品或项目的正常开展。这些项目组的测试人员, 按照其职责和所负责的模块, 分别关注功能测试、性能测试、压力测试及安全测试等。此外, 在协助产品的开发过程时测试人员也会分别介入包括单元测试、集成测试等。针对这些不同的测试过程, 企业对相应从业人员有着对应的要求。在这样的环境中, 企业对软件测试人员的能力要求较为细化。这些企业中的软件测试从业人员的专项技能较为突出。比如从事功能测试的人员具有很强的业务知识和背景知识;而从事性能测试或压力测试的人员对场景分析和结果分析能力较强, 而对业务可能关注较少。

而在国内众多的中小型软件企业, 对软件测试有不同的做法。这些企业可能没有独立的软件测试部门, 也许连软件测试的工作都不是由专人担当。此外, 这些企业的软件测试人员有时不仅需要做功能测试, 对于产品出厂验收时所要求的性能测试、压力测试等也都会参与。这样的企业对软件测试从业人员的要求跟上面所说的较为规范的企业就有所不同。他们一般要求内部的测试人员, 首先要能胜任本职的功能测试工作;除此之外, 对于一些非功能性的测试也可以快速胜任;而正常的工作中测试人员一般还要负责相应的现场支持维护升级等工作。

无论企业的大小或流程的规范与否, 企业对软件测试从业人员的基本素质要求是有共通点的。企业都希望测试人员拥有良好的沟通与协调能力、责任心, 耐心、细心、自信心、发散思维。对于专业技能方面, 软件测试人员与开发类似, 也需要熟悉操作系统、数据库、编程语言和网络等方面知识。此外, 测试人员对测试理论、测试方法和测试管理的掌握也是必要的。

三、现有软件测试培训存在的不足

当前, 企业中的软件测试从业人员来源主要有以下四种:第一, 计算机软件相关专业的毕业生, 他们在校期间接触过软件测试课程或学习过软件开发相关课程, 有一定理论和专业技术基础;第二, 培训机构的专项培训生, 培训期间对口培训过软件测试相关内容;第三, 其他专业毕业生, 对软件测试存在一定兴趣, 转投软件测试行业。软件测试人员在企业中工作的过程, 也是一个不断学习和接受培训的过程;第四, 社招人员, 具有一定测试经验甚至管理经验。

首先, 现有的培训机构还相对较少而且单一, 重视软件测试的培训结构相对更少。由于行业间的竞争少, 且国内对软件测试的重视程度也较为一般, 对软件测试的要求不高, 很多企业对软件测试的要求仅限于能找Bug, 保证产品顺利上线运行。培训机构为了追求利益和自身的发展, 往往是最近热炒什么方向, 就开放什么样的课程, 并不注重过程和质量。他们切中目前企业对软件测试所存在的不足, 投机取巧, 培训出的测试人员也仅限拥有基础的测试技能, 保证可以满足初期的上岗即可, 缺乏对学生自身定位和对未来方向的引导。

其次, 培训往往都是速成的, 培训机构只关心在短时间里培训出能上岗的测试人员, 没有从根本上培养测试人员的个人素质培养。培训的内容较为简单, 趋于表面。而往往在正式的项目工作中, 产品的运行环境往往非常复杂, 测试结果的分析往往因为影响因素众多而比较复杂, 培训的理想型测试与实际测试情况差距较远。并且一些测试工具不是开源的, 需要高额的使用费用。培训机构往往会精简这些经典工具使用的介绍。

第三, 培训起步晚, 很多软件测试从业人员起初参加软件测试培训并不是因为自身兴趣, 往往是看到软件这个测试行业的要求较低, 且收入可接受;再加上培训机构对软件测试就业趋势和软件行业发展的宣传。很多培训生在培训阶段的后期都未对软件测试产生兴趣, 最后仅是在结果的导向下跨入软件测试行业。这些从业人员在测试工作过程中因为缺乏兴趣性, 导致思维不够发散, 较为狭隘。在某种程度上与测试人员基本素质思维发散想违背。

相对于培训机构的不足, 高校毕业生从事软件测试行业的不足之处则相对单一, 大部分院校无软件测试专业和课程, 基本上以计算机基础知识和软件开发为主, 因此对于软件测试的专业理论和方法理解还缺乏系统性的认识。进入公司之后, 公司出于成本和时间的考虑, 一般以老带新方式进行培训, 而老员工由于测试任务在身, 非常容易忽视新员工的能力培养需求。同时, 如果新员工缺乏学习主动性, 再遇到拥有技术私心的师傅, 新员工的成长历程可想而知。

社招测试人员招聘对于大型企业是通常性的做法, 毕竟拥有实际项目测试经验的人员可以直接上手, 缩短磨合期。但是社招测试人员并不代表其不存在不足, 一是测试转测试管理角色的经验缺乏, 二是满足现状, 遇到测试能力提升瓶颈, 容易受到年轻测试人员的竞争冲击。对于小微软件企业来说, 以自身经营实力现状是无法满足中高级测试人员的薪资要求的, 所以高校毕业生和培训机构专项学员仍是他们长期的主要需求对象, 然而毕业生和学员自身能力的缺陷和公司的运营成本限制, 又造成了人员培训的两难境地。

四、如何完善软件测试培训体系

探讨如何建立一套完善的软件测试能力培养体系, 首要需要关注的就是软件测试培训体系所涉及的三大元素:企业、高校、培训机构。完善和建立软件测试培训体系, 可以更好辅助高校人才培养, 也有利于为企业输送更合适的人才, 为社会解决毕业生就业问题。本体系初步设计了一个企业、高校、培训三者紧密联系的人才流动环形, 如图1。

一个理想的软件测试培训体系这三个元素息息相关。完善和建立软件测试培训体系本质上就是完善和建立这三者之间的关系。从图1可以看出其实培训机构起到了很重要的桥梁作用。本文以培训机构为主, 介绍培训机构在完善培养体系中所扮演的重要角色, 以及如何去发挥在体系中的核心作用。

(一) 培训机构与高校体系

1.培训机构与高校关系现状。高校出于师资资源、专业配置和就业前景等考虑, 很少开设软件测试专业。计算机类的学生并不是所有都能在软件开发当中脱颖而出, 一些基础比较薄弱或者本身对开发不感兴趣的学生, 会退而求其次选择入门门槛较低的软件测试行业, 但自身竞争力较弱。当今社会早已不是高校就业包分配的时代, 现在的大学院校基本以将毕业生推向就业市场即作为使命的结束, 毕业生在浩瀚的就业人潮中拼杀, 也不一定能落实心仪的企业。站在企业角度, 他们既希望能够挑到“物美价廉”的应届生, 又希望具有一定工作或项目经验。此时培训机构的作用就显得尤为重要。传统的模式为高校应届生学生自己报名参加社会培训机构组织的测试培训课程, 大部分是看中了培训机构所承诺的包就业和薪资预期, 学生为此要支付不菲的培训费用。实际一些机构所谓的包就业也是根据培训收取的费用层次来安排, 推荐的单位也是层次不齐, 如果不接受推荐, 机构也不一定会退还培训费用, 因为培训之前学生了签订了一些协议条款, 之中均隐含机构的责任规避, 学生作为初入社会的弱势群体, 很难做到自身维权, 只能妥协。

2.培训机构与高校的联动创新。第一, 高校软件测试专业外包。针对没有开设软件测试专业, 而又存在软件测试培训需求的院校, 高校可以依托培训机构所能提供的培训教育资源, 通过选修课外包服务的方式来完成对学生的软件测试教学工作, 同时培训成绩直接与学分挂钩, 培训机构相当于学校的一个软件测试课程, 甚至是软件测试专业。社会上有些院校虽然已经设立软件测试课程或者专业, 但是由于仅局限于书本和理论知识的传授, 缺乏实际操作性。而高校通过与培训机构合作, 可以利用培训机构理论与实操结合的软件测试培训模式来完善自身的教学结构, 直接为社会输送能力合格的应届生。

第二, 引入国际测试培训标准。以南京市质检院为例, 引入ISTQB (国际软件测试工程师) 认证培训, 通过ISTQB初级培训认证, 让学生掌握软件测试的基础理论知识, 这些均是非大学课堂和普通培训机构所能传授的专业知识, 并与国际水平接轨。因此也减轻了导师的教学压力, 学生能够在上项目之前迅速理解测试内容, 掌握基本测试方法。同时ISTQB的标准培训内容, 可以作为判断学生是否具有软件测试基本能力的重要条件之一。

第三, 一站式培训就业保障。毕业生就业率是社会外界来衡量高校教育质量的重要条件。除尚未毕业的大四应届生外, 已毕业的应届大学生可以与培训机构签约企业直通车协议, 参加企业岗前培训, 凡是经过培训机构和企业的软件测试专项培训, 取得ISTQB初级认证, 并通过能力测验 (包括理论和实际操作考试) , 顺利获得结业证书的学生, 将会直接被培训机构的合作企业录用。同时就业是企业和个人的双向选择, 如果学生认为企业与个人期望有所差距, 培训机构会继续作为实习生留用, 并可参与测试外包项目, 直到签约心仪的软件企业。这样既能保证高校毕业生就业率, 也能在学生未进入企业之前, 持续不断的积累测试经验和项目经验, 避免找工作阶段而造成的经验和能力要求脱节现象。

(二) 培训机构与企业

1.培训机构与企业关系现状。当前培训机构和企业之间只是单纯的人才推荐机制, 并且软件测试行业目前的人员流动性也比较大, 特别是具备2~3年测试经验的工程师为跳槽的主力群体, 而他们恰恰是软件测试的中坚力量。因此企业每年都会存在较大的测试人力缺口, 除了社会招聘外, 培训机构的定点输送也成为人力补充的重要渠道。正是这种功利性的人力需求, 造成了培训机构功利性的培训模式, 完全忽略了学生个性化和符合自身特点的培训需求, 导致学生仅仅是暂时起到人力补充的作用, 而非真正意义上的测试人才。学员在不同的行业、项目和任务上还需要企业再次的内部培训, 通过时间的积累来提高自己的测试能力, 这对于企业来说又是成本的无形增加。

2.培训机构与企业的联动创新。第一, 企业定向培训。大型企业的软件测试部门, 一般会将测试人员分配到不同的团队进行模块划分。这样每个团队无需改变各自测试内容, 同时可以完成不同项目的测试任务, 正所谓测试流水线化。所以学生除了软件测试的基础知识培训外, 可根据自身性格特点和兴趣爱好, 进行分组培训, 例如黑盒测试组、性能测试组、白盒测试组及自动化测试组等, 实现软件测试培训的内容细化和技术深化, 无需进行长时间的笼统知识培训, 有利于企业对人才定向要求。

第二, 企业在职人员进阶培训。企业员工的内部培训也是不可忽视的需求。企业的软件测试人员经过一段时间的工作经验积累往往会遇到测试能力提升的瓶颈阶段。即一是对测试内容产生枯燥甚至厌恶感, 二是无法从简单基本的功能测试和性能测试, 上升到拥有自动化测试等高级水平阶段。ISTQB国际软件测试认证课程正是一种自基础到高级演进的培训结构, 分为基础级:针对有一定测试专业基础知识的测试人员, 包括测试工作人员和有志于从事软件测试的学生等;高级:针对3到5年以上测试相关经验的测试人员, 包括测试员、测试分析师、测试工程师以及软件开发人员等。而参加该级别认证的人员需先通过ISTQB基础级认证;专家级:针对至少5年的实际测试工作经验以及2年的专家级领域工作的测试人员。通过ISTQB的进阶式培训, 一方面满足了企业对高级测试人才内部开发, 无需通过社招来增加额外的人力要求, 又满足了测试人员本身提高行业竞争力和争取更优厚待遇的现实需求。

第三, 测试管理人员培训。测试工程师的长期发展路线较为清晰, 在成为资深测试工程师之后均会往测试管理方向发展, 即独立带领测试团队, 甚至成为公司整个测试部门领导者。管理是门艺术, 从测试执行者到测试管理者身份的转变, 并不是水到渠成的过程, 同样需要在工作当中经过相关管理执行的历练。测试管理者需更多的去学会如何与测试执行者交流, 如何发挥团队的力量去完成各种各样的测试任务。

第四, 企业测试项目外包。企业中有时遇到一些简单项目的开发需要外包时, 一般都是与现有的一些外包服务公司合作。其实培训机构拥有很多的人力资源, 而培训学员在学习中缺少的又是实际项目操作。对于一些不是很重要且可以放出的模块, 可以与培训机构签订相应的合作协议, 在导师保障质量的前提下, 交由培训机构的学员去完成, 这对企业和培训机构来说是一种双赢。

(三) 培训机构的“互联网+”

在移动互联网蜂拥而至的形势下, 它带来的是场教育培训领域的革命, 比如说美国的MOOC系统。移动互联网平台系统内容的各种应用对培训机构所带来的冲击和变革, 毫无疑问会变得日新月异。一是培训方式的改变。原始的培训方式完全是单向传授式的。未来的培训方式更多地应该是智能化的, 老师借助于智能化的分析, 了解每个学生的缺点, 对学生进行更加有效的个性化辅导。培训模式可能会变成纯粹的线上教学, 或线上线下结合的教学培训体系。二是收费模式的变化。原来的收费模式是学生支付培训费用, 培训机构安排相应课程。未来很有可能很多课程是全部免费的, 比如国外非常火爆的MOOC在线课程。但免费并不意味着没有收费模式, 比如说如何通过腾讯这样的增值体系模式交费, QQ是免费使用的, 但是正是因为积累了大量的客户群体, 可以再通过会员、游戏、等增值服务来实现营收。在线培训既可以通过增值服务来实现收费, 也可以通过结业颁发相关认证来收费, 前提是需要培训机构的含金量和证书的行业认可度。虽然目前的在线培训和在线教育的营收模式尚不成熟, 但是基于在线培训是未来的大趋势, 所以未来在商业成果上一定会有所突破。

(四) 软件测试学校

这是本文所研究的软件测试培养体系里面最上层的理念, 但是也同样伴随着诸多现实问题, 所以这里所提出的概念只做探讨和构想。在中国, 高等院校众多, 但是每个院校都有自己的王牌专业, 这些王牌专业往往就是某个行业主要的人才输送渠道。如果想形成一个行业中的人才密集输出, 相对于社会上鱼目混杂的培训机构, 学校必定是主体。开办软件测试学校将是一项创新举措, 软件测试学校可以发挥招生优势, 依托科学合理的教育教学体系, 让学生完成从入学到毕业的全过程教育培训, 充分保持软件测试的培训粘度, 实现学员的测试水平由懂到专到精的平稳过度, 真正培养出基础扎实, 水平高于同等综合性大学的软件测试人才。随着测试学校毕业生群体在社会上不断得到认可, 甚至成为行业顶尖人才, 随之而来的将是学校影响力的不断扩散, 测试学校将逐渐发展成为软件测试行业和领域的黄埔军校, 最终实现软件测试行业的生态循环。

参考文献

[1]梅耶.软件测试的艺术[M].张晓明, 黄琳, 译.北京:机械工业出版社, 2012.

[2]G.li.软件测试工程师面试秘籍[M].北京:人民邮电出版社, 2014.

软件性能测试研究 篇8

根据测试的目的和内容的不同, 性能测试主要包括以下方面:

(1) 负载测试:确定在各种工作负载下系统的性能, 目标是测试当负载逐渐增加时, 系统各项性能指标的变化情况。

(2) 强度测试:确定在系统资源特别低的条件下软件系统运行情况。

(3) 容量测试:在用户可接受的响应范围内, 确定系统可处理同时在线的最大用户数。

(4) 压力测试:通过确定一个系统的瓶颈或者最大使用极限的测试。

(5) 疲劳强度测试:以系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数, 持续执行一段时间业务, 通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作强度性能的过程。

(6) 大数据量测试:大数据量测试侧重点在于数据的量上, 包括独立的数据量测试和综合数据量测试。独立的数据量测试针对某些系统存储、传输、统计、查询等业务进行大数据量测试, 而综合数据量测试一般和压力性能测试、负载性能测试、疲劳性能测试相结合。

2 软件性能测试流程

2.1 测试方案设计

在软件性能测试的初始阶段, 首先应对业务模型和系统架构进行调研, 收集测试需求, 然后生成性能测试计划。业务调研和系统调研, 需要性能测试团队提前了解被测试项目的业务功能和系统架构。其间, 开发部门应协助提供被测系统相关的文档和说明, 如系统总体介绍、系统规格书、用户使用手册、网络拓扑结构图和系统配置说明、关键服务器及应用部署与配置等文档。通过和业务部门协商明确本次测试针对哪些业务行为, 制定此次测试的目标, 细化测试的关注点和性能指标要求。通过以上内容制定详细的测试方案, 并制定详细测试计划和各阶段目标。

2.2 测试环境的搭建

测试环境的搭建分为软硬测试系统的环境搭建和测试相关的数据准备工作。环境搭建包括被测试系统的硬件环境建立和软件应用系统建立及基础数据环境建立。保障被测试系统的业务可用性和功能的正确性, 包括测试系统 (如被测试项目的操作系统、中间件、数据库、压力测试控制台、压力测试发起工具等) 的环境搭建、软件的安装;测试环境的网络环境建立 (如开放防火墙和网关等) ;最后进行测试环境可用性验证。测试数据准备包括测试应用系统基础数据准备, 即需要按性能测试规模要求, 准备足够的、一定规模的基础数据, 通常采用全量恢复生产数据的方式以达到和生产环境数据一致性的要求。

2.3 测试场景开发

测试场景开发指测试程序 (脚本) 的开发。测试程序 (脚本) 的开发是对被测系统的用户业务行为进行模拟、录制、编程、参数化、脚本定制和调式等一系列工作, 以使测试程序 (脚本) 可以真实模拟实际生产中的业务交易行为, 并通过对程序中参数的配置实现对并发数、思考时间等属性的准确控制。

2.4 测试执行

测试执行是在测试方案的制定、测试环境准备、测试场景开发工作正确完成的基础上进行的。

2.5 测试报告和分析

性能测试报告和结果分析是在测试执行完成以后, 对性能数据进行采集结果收集工作和针对性能测试过程中暴露的问题进行分析的阶段。性能测试报告是对性能测试过程中的监控结果以及报表进行汇总, 按照一定的模板整理出的一份结论性文档。开发团队和性能测试团队应依据对性能测试实施过程中监控和记录的数据和表格, 分析系统中存在的性能问题和程序缺陷。并有针对性的在报告中阐述问题、分析原因、提出解决或优化方案。

2.6 回归测试

回归测试是开发部门在性能测试报告的基础上针对软件的性能或者效率缺陷进行优化或者修复, 为了验证优化的效果而进行的再测试。

3 软件性能测试工具LoadRunner

作为软件质量控制中的重要一环, 性能测试已经越来越受到软件开发商和用户的重视, 成为软件测试的重中之重。性能测试通常在系统测试阶段执行, 常常与强度测试结合起来, 一般需要使用测试工具。一个优秀的软件测试工具, 不仅可以辅助测试工作, 满足科学测试的基本要求;而且可以自动化测试过程, 节约大量的时间、成本、人员和资源, 提高软件产品的质量。目前市场上主要使用的测试工具有微软公司的WAS (Web Application Stress Tool) 、Compuware公司的QALoad、RadView公司的WebRunner、HP (Mercury) 公司的LoadRunner。下面以LoadRunner为例, 介绍软件测试工具的工作流程。

LoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能检测来确认和查找问题, 能够对整个企业架构进行测试。通过使用LoadRunner, 企业能够最大限度的缩短测试时间, 优化性能和加速应用系统的发布周期。LoadRunner能支持广泛的协议和技术, 功能比较强大, 可以为特殊环境提供特殊的解决方案。LoadRunner由下面三部分组成:Virtual User Generator用来录制脚本、编辑脚本;Controller用来布置测试场景、执行测试场景;Analysis用来对测试结果进行分析。

用LoadRunner进行负载测试的流程通常由五个阶段组成:计划、脚本创建、场景定义、场景执行、监视执行和结果分析。

(1) 计划负载测试:定义性能测试要求, 例如并发用户的数量、典型业务流程和所响应时间;根据软件项目相关需求, 定义相关测试的细节, 撰写性能测试报告。

(2) 创建Vuser脚本:将最终用户活动捕获到自动脚本中;LoadRunner的脚本是C语言代码, LoadRunner有自己的一整套函数接口, 可以供外部调用。脚本可分INIT、ACTION、END三部分, 其中:INIT部分可以理解为初始部分, ACTION可以理解为事务部分, 也是测试的主体, END是退出结束。

当录制完一个基本的用户脚本后, 在正式使用前我们还需要完善测试脚本, 增强脚本的灵活性。一般情况下, 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。

(3) 定义场景:使用LoadRunner Controller设置测试环境;录制好脚本之后, 就可以把脚本加入到场景里面去了, 这里首先介绍一下LR的场景类型, LR有2种大的场景类型。

①Manual Scenario:该项要完全手动的设置场景, 这项下面还可以设置为每一个脚本分配要运行的虚拟用户的百分比, 可在Controller的Scenario菜单下设置。

②Goal—Oriented Scenario:如果你的测试计划是要达到某个性能指标, 比如:每秒多少点击, 每秒多少transactions, 能到达多少VU, 某个Transaction在某个范围VU (500-1000) 内的反应时间等等, 那么就可以使用面向目标的场景。

(4) 设置场景:

Design:设计测试场景的静态部分, 设置模拟用户生成器、模拟用户数量、 模拟用户组等。

Run:设计测试的动态部分, 主要指添加性能计数器, 在脚本运行的过程中可以通过这些计数器反馈的数据。

建立了测试场景后, 我们可以对Edit_Schedule进行设置, 设置测试开始执行的时间, 对于手动设计的测试还可以设定它的持续时间, 以及何时起用或禁止调用模拟用户。

(5) 运行场景:通过LoadRunner Controller驱动、管理和监控负载测试。

设置完毕后, 点击“开始方案”运行场景。在运行过程中, 可以监视各个服务器的运行情况 (DataBase Server、Web Server等) 。监视场景通过添加性能计数器来实现, 下列数据需要特别关注:

①Memory:Available Mbytes物理内存的可用数 (单位 Mbytes) 至少要有10% 的物理内存值。

②Processor:Processor Time CPU 使用率。这是查看处理器饱和状况的最佳计数器。显示所有 CPU 的线程处理时间。如果一个或多个处理器的该数值持续超过 90%, 则表示此测试的负载对于目前的硬件过于沉重。为多处理器服务器添加该计数器的 0 到 x 个实例。

③Processor Queue Length:是指处理列队中的线程数, 小于2。处理器瓶颈时会导致该值持续大于 2。

④Context Switches/sec:如果切换次数到5000*CPU个数和10000*CPU个数中, 说明它忙于切换线程。

⑤Network Interface:Bytes Total/sec 为发送和接收字节的速率, 包括帧字符在内。判断网络连接速度是否是瓶颈, 可以用该计数器的值和目前网络的带宽比较。

(6) 分析结果:使用LoadRunner Analysis创建图和报告并评估性能。

LR的报表分析功能也异常强大, 有各种各样的报表, 甚至可以将单个报表组合, 也可以导出到Excel文件和Html文件。

摘要：随着当今软件开发技术的发展与成熟, 越来越多复杂的软件系统应用于人们生活的各个领域, 软件系统运行时的性能表现已经成为衡量软件产品质量的一个重要标准。研究了软件系统性能测试的整体的流程, 并结合自动化测试工具LoadRunner, 对软件性能测试的相关信息进行了探讨和分析。

关键词：软件测试,性能测试,LoadRunner

参考文献

[1]朱少民.全程软件测试[M].北京:电子工业出版社, 2007.

[2]古乐, 史九林.软件测试技术概论[M].北京:清华大学出版社, 2003.

[3]LydiaAsh.The Web Testing Companion[M].北京:机械工业出版社, 2003.

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

嵌入式软件测试技术研究 篇9

随着信息技术的不断发展, 与硬件发展日益稳定相比, 软件故障却日益突出, 因此软件测试的重要性已经越来越被人们所重视。嵌入式软件有着开发工具昂贵、内存较小、实时性要求较高、CPU种类繁多、I/O通道较少等特点, 为此, 嵌入式软件的测试也与一般PC应用软件的测试有很大的差异。

1 嵌入式软件测试概述

1.1 嵌入式软件特点分析

嵌入式软件测试的主要目的在于验证软件的可靠性, 与通常的PC应用软件相比, 嵌入式软件的测试有如下几个特点: (1) 嵌入式软件是针对在特定硬件环境下开发的, 其运行和测试也需要依据特定的硬件环境; (2) 实施性要求较高, 除了要求有正确的输出结果以外, 还需要考虑是否能够在规定的时间内得到运行结果。

1.2 嵌入式软件测试环境分析

一般采用交叉开发环境来搭建嵌入式软件的测试环境。例如单元测试、集成测试等可以在PC机上完成的测试, 通常都在PC机上进行测试, 从而可以避免硬件环境的影响, 提高测试效率。在后期的集成测试中, 需要在具体的嵌入式软件硬件环境中, 搭建交叉测试环境来完成嵌入式软件的测试。交叉测试环境的搭建需要注意以下几个方面的内容:

(1) 主机与目标机之间的通信问题。可以通过以太网或者串口进行主机与目标机之间的物理连接, 主机与目标机之间的数据格式可以预先进行定义。

(2) 主机对目标机的测试控制。主要包括主机如何向目标机发送测试用例, 如何跟踪目标机的测试, 查看是否正常进行。

(3) 目标机测试结果的反馈。通常运行嵌入式系统的目标机没有视频显示等便利的测试结果输出端口, 因此目标机上的异常、错误信息和正常响应信息等测试结果都需要返回到主机上进行显示和输出。

在嵌入式软件测试环境的搭建过程中, 需要测试嵌入式系统与已建设备是否协调, 硬件设备电气特征是否正常, 以及主机与目标机之间的物理信道是否通畅等, 从而保证测试结果不受到嵌入式软件以外其它因素的影响。

1.3 嵌入式软件测试策略

嵌入式软件不同的测试阶段有不同的测试策略。

(1) 单元测试。为了提高嵌入式软件的测试效率, 一般会将较大的嵌入式软件系统划分成若干相对较小的任务单元进行测试。由于宿主机上有更加丰富的资源, 同时也为了方便对嵌入式软件的调试, 一般在宿主机上进行单元测试。单元测试一般采用白盒测试策略, 尽可能测试到单元模块中的每一个程序语句, 每一个分值, 从而提高代码测试的覆盖率。

(2) 集成测试。为了找出系统逻辑结构错误和各个功能模块之间的数据传递错误, 需要采用黑盒和白盒相结合的方式进行嵌入式软件集成测试。需要通过最大程度地模拟嵌入式软件实际运行环境。集成测试分成两个部分, 首先可以在宿主机上测试软件是否存在逻辑结构错误, 以及测试各功能模块之间是否有传递错误;然后, 通过构建真实的嵌入式软件运行环境, 来测试软件是否存在内存定位和分配上的错误。

(3) 确认测试。确认测试必须是嵌入式软件运行在真实的硬件目标环境中, 主要测试嵌入式系统是否由于测试环境的移植而受到影响。由于受到硬件目标环境资源不足、测试结果输出方式等限制, 嵌入式软件的确认测试一般采用黑盒测试方案。

2 嵌入式软件测试技术

2.1 静态测试技术

静态测试可以充分发挥人的逻辑思维能力, 包括代码检查、静态结构分析以及代码质量度量等方式。

(1) 代码检查。代码检查主要包括对嵌入式软件开发的代码审查、代码走读等工作。代码检查的内容主要包括分析代码是否遵循嵌入式软件设计、开发标准, 数据是否正确, 接口是否正确等内容。

代码检查能够快速地找到嵌入式软件的缺陷, 可以发现70%以上的编码和逻辑设计缺陷。因此, 在实际应用中, 代码检查可能比动态测试更加有效。

(2) 静态分析。静态分析是借助测试工具对软件代码进行分析的方法, 只可以分析是否存在内存泄露等特定的缺陷, 受其他模块的影响较小。静态分析主要包括对数据流的分析、对控制流的分析以及对软件度量的分析等。

嵌入式软件的静态测试, 主要是通过开发、测试人员对软件源代码进行审核分析, 不需要进行测试用例的设计, 因此嵌入式软件不需要特定的测试环境。

2.2 动态测试技术

根据是否需要了解软件内部结构的区别, 嵌入式软件的动态测试包括黑盒测试和白盒测试两种。

(1) 白盒测试技术。在对嵌入式软件进行白盒测试时, 需要对软件进行如下几个方面的检查:至少对系统中所有独立路径进行一次测试;至少在循环限内和循环边界对循环测试一次;对所有的逻辑判定都需要测试一次;对内部数据结构的有效性进行测试。

与通用的PC应用软件相比, 嵌入式软件的白盒测试需要更高的代码覆盖率。而且嵌入式软件的白盒测试不需要在目标硬件环境中运行。

(2) 黑盒测试技术。黑盒测试需要知道用户需要哪些功能, 可能会遇到什么样的问题, 在嵌入式软件自动化测试时, 采用黑盒测试技术较为方便。但是, 黑盒测试的代码覆盖率较低, 一般仅为总代码量的30%左右。

2.3 覆盖测试技术

覆盖测试技术根据嵌入式软件的内部结构来进行测试用例的设计, 是白盒测试技术的一种。覆盖测试的基本准则是:所设计的测试用例要能够尽可能覆盖嵌入式系统的内部结构, 从而发现嵌入式系统的问题和错误。覆盖测试的内容包括提高测试覆盖率、未被测试用例激活代码的测试、代码冗余检测等。因此, 覆盖测试也是一个提高软件质量的手段, 覆盖测试一般在嵌入式系统的单元测试中应用。

2.4 程序插桩技术

程序插桩技术是覆盖测试的一个重要实现手段, 其含义就是通过对程序测试状态的跟踪, 来发现嵌入式软件中的缺陷。

程序插桩的基本思想包括:

(1) 探针插入。可以在嵌入式程序中插入计数器、打印语句或者赋值语句来采集程序运行状态。

(2) 探针编译。根据设计好的测试用例, 重新编译嵌入式软件, 通过执行探针来获取嵌入式软件执行的动态信息。

(3) 特征数据处理。对特征数据进行分析和处理, 从而获得嵌入式软件的数据流或者控制流信息, 并且最终得到嵌入式软件的判定覆盖、语句覆盖等信息, 并且形成最终报表。

由于嵌入式软件运行的真实运行环境往往会受到输出方式的限制, 为此嵌入式软件的程序插桩测试通常都采用宿主机和目标机结合的方式, 其测试流程如图1所示。

在插桩完成之后, 需要对嵌入式软件进行重新编译, 并且将编译好的程序下载到目标机中, 同时通过宿主机与目标机的通信, 来对探针的运行以及探针运行结果进行分析。

3 嵌入式软件测试内容

嵌入式软件测试的内容主要为:软件代码测试、编程规范标准符合性测试、代码编码规范符合性测试、开发维护文档规范符合性测试、用户文档测试。

其中软件测试服务范围包括:系统级测试、应用测试、中间件测试、BSP及驱动程序测试、嵌入式硬件设计测试。

其中, 按照嵌入式软件有无操作系统将嵌入式系统分为两大类:无操作系统的嵌入式软件、有操作系统的嵌入式软件。

3.1 无操作系统的嵌入式软件

无操作系统的嵌入式软件主要包括C语言代码、汇编语言代码、Apa代码等。

C语言模式软件测试:硬件设备及其他宏定义 (编译阶段处理) 、API函数测试、模块初始化 (包括系统初始化) 、中间功能件测试、功能模块测试、中断处理测试、任务调度测试、区域功能测试、总体功能测试。

汇编语言模式软件测试:硬件设备及其他宏定义 (编译阶段处理) 、模块初始化 (包括系统初始化) 、中间功能件测试、功能模块测试、中断处理测试、区域功能测试、总体功能测试。

3.2 基于操作系统的嵌入式软件

基于操作系统的嵌入式软件主要包括应用软件测试、系统软件测试、整体性能测试。

应用软件测试:模块初始化 (包括系统初始化) 、中间功能件测试、功能模块测试、区域功能测试、总体功能测试。

系统软件测试:硬件设备及其他宏定义 (编译阶段处理) 、API函数测试、模块初始化 (包括系统初始化) 、中间功能件测试、功能模块测试、中断处理测试、区域功能测试、总体功能测试、标准符合性测试。

其中, 操作系统的标准符合性测试依据的标准主要包括:

整体性能测试:基于操作系统之上的嵌入式系统整体软件测试, 主要采用应用软件测试, 着重分析性能、内存分配、代码覆盖率、软件执行流程, 并采用仿真器、逻辑分析仪等硬件测试工具进行整体性能的测试。

4 嵌入式软件测试工具

用于辅助嵌入式软件测试的工具很多, 下面对几类比较有用的嵌入式软件测试工具加以介绍和分析。

4.1 内存分析工具

在嵌入式系统中, 内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后, 通常难以再现, 可能导致的失效难以追踪, 使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具———软件工具和硬件工具。基于软件的内存分析工具可能会对代码的性能造成很大影响, 从而严重影响实时操作;基于硬件的内存分析工具价格昂贵, 而且只能在工具所限定的运行环境中使用。

4.2 性能分析工具

在嵌入式系统中, 程序的性能通常是非常重要的。经常会有这样的要求, 在特定时间内处理一个中断, 或生成具有特定定时要求的一帧。开发人员面临的问题是决定应该对哪一部分代码进行优化来改进性能, 常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据, 说明执行时间是如何消耗的, 是什么时候消耗的, 以及每个例程所用的时间。根据这些数据, 确定哪些例程消耗部分执行时间, 从而可以决定如何优化软件, 获得更好的时间性能。对于大多数应用来说, 大部分执行时间用在相对少量的代码上, 费时的代码估计占所有软件总量的5%~20%。性能分析工具不仅能指出哪些例程花费时间, 而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数, 性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。

4.3 GUI测试工具

很多嵌入式应用带有某种形式的图形用户界面进行交互, 有些系统性能测试是根据用户输入响应时间进行的。GUI测试工具可以作为脚本工具在开发环境中运行测试用例, 其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程。很多嵌入式设备没有GUI, 但常常可以对嵌入式设备进行插装来运行GUI测试脚本, 虽然这种方式可能要求对被测代码进行更改, 但是节省了功能测试和回归测试的时间。

4.4 覆盖分析工具

在进行白盒测试时, 可以使用代码覆盖分析工具追踪哪些代码被执行过。分析过程可以通过插装来完成。插装可以是在测试环境中嵌入硬件, 也可以是在可执行代码中加入软件, 也可以是二者相结合。测试人员对结果数据加以总结, 确定哪些代码被执行过, 哪些代码被巡漏了。覆盖分析工具一般会提供有关功能覆盖、分支覆盖、条件覆盖的信息。对于嵌入式软件来说, 代码覆盖分析工具可能侵入代码的执行, 影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些, 但是价格一般比较昂贵, 而且限制被测代码的数量。

5 结语

嵌入式软件的测试主要是为了保证嵌入式软件系统的高可用性和高质量。嵌入式系统的特殊性, 使得嵌入式软件的测试在整个软件的开发过程中都占有非常重要的地位。为此, 对嵌入式软件测试的研究势在必行。在具体的嵌入式软件测试过程中, 应该根据嵌入式软件自身特点, 开发具有针对性的测试工具来提高嵌入式软件测试的效率和质量。

参考文献

[1]张君施.嵌入式软件测试[M].北京:电子工业出版社, 2004.

[2]王璞, 张臻鉴.面向实时嵌入式机载软件的测试技术研究[J].航空计算技术, 1997 (4) .

嵌入式软件测试的研究 篇10

1 嵌入式软件测试概述

软件测试是为了确保软件能够满足相应的需求规格, 嵌入式软件有其特定的实效判定准则, 这就需要对其进行严格的测试。由于嵌入式软件构成的系统不同于其他桌面系统, 嵌入式系统具有实时性等特点, 需要在特定的硬件环境下才能有效运行, 这就使得嵌入式软件测试既要保证嵌入式软件的实时性, 还要保证其在特定硬件环境下运行的可靠性。与一般商用软件的开发和测试相比, 嵌入式软件的开发环境与运行环境并不保持一致, 这就对嵌入式软件测试提出了更高的要求, 测试所需要的信息需要在目标机上产生, 测试工具要在宿主机上运行, 这说明嵌入式软件需要面临宿主机环境和目标环境的双重测试, 除了测试代价增加外, 嵌入式软件的测试策略问题就成为了考虑的重点[1]。

2 嵌入式软件测试分析

2.1 嵌入式软件测试环境分析

嵌入式软件测试通常会采用仿真技术, 即使用特定软件或硬件模拟设备的功能实现简化测试环境的目的。根据界面和运行环境的不同, 嵌入式软件仿真测试环境主要分为全实物仿真测试环境、半实物仿真测试环境和全数字仿真测试环境。全实物仿真是指被测软件完全处在真实的运行环境中, 嵌入式软件与相交联的设备建立了真实的链接, 这种闭环测试对环境的要求相对较低;半实物仿真主要利用仿真模型来对真实系统进行测试, 这种非侵入性闭环测试对环境的要求要高于闭环测试;全数字仿真利用数字化硬件环境模型来对软硬件系统进行测试, 这种测试对环境的要求最高。嵌入式软件交叉开发环境也提供了一个交叉测试环境, 而构建嵌入式软件交叉测试环境则需要解决三个问题:主机与目标机通信连接的问题;如何实现主机对目标机程序进行测试控制的问题;如何实现目标机反馈主机测试信息的问题。

2.2 嵌入式软件测试技术分析

鉴于嵌入式软件的特殊性, 对其进行测试必要要有专门的工具, 嵌入式软件测试面临的技术挑战有很多, 如测试工具通用性较差、缺少适合单一方面测试的工具, 受动态复位代码影响软件的执行流程无法实现可视化, 测试的有效性难以预知。从实现形态上看, 嵌入式软件测试工具主要分为软件测试工具、硬件测试工具以及软硬件相结合的测试工具, 其中, 软件测试工具主要采用的是软件仿真技术, 即在宿主机上对目标机进行模拟, 从而使大部分测试能够在仿真的宿主机上完成, 这种方式应用的比较广泛, 较为典型的是Host/Target, 该软件测试工具采用的是软件插桩技术, 即将测试用例嵌入到源程序中, 通过软件运行状况来发现存在的问题;硬件测试工具通常用于系统的硬件设计和测试工作, 主要利用逻辑分析仪对系统的工作状态进行有限的性能分析, 该种方式并不具备对内存分配和检测的能力, 因此很难得到满意的结果;软硬件结合测试工具结合了软、硬件测试工具的各自优势, 较为典型的是AMC公司设计的CodeTest高性能测试工具, 该测试工具具备了性能分析、测试覆盖分析、执行追踪分析、动态存储器分配分析等功能, 但是也存在着一定的缺陷, 如对硬件依赖性较强[2]。

3 嵌入式软件测试的相关策略

嵌入式软件测试的重点在于测试用例和例程的设计、测试工作管理、测试环境建立等, 这也是嵌入式软件测试需要解决的主要难题, 测试用例和例程的设计要想达到一定的质量要求, 一定要提高设计者的分析和设计能力, 这种技巧性活动很难得到有效的控制。目前, 测试工作管理还缺乏可供参考的资料和测试实施模式, 测试环境也很难建立。面对这些难题, 嵌入式软件测试需要一定的测试策略, 在不同环境下选择不同的测试策略, 从而实现测试开发效率最大化。嵌入式软件测试通用的策略主要有单元测试策略、需求测试策略、设计测试策略、集成测试策略以及系统测试和确认测试策略。其中, 单元测试完全可以在主机环境下进行, 能够以最小的目标单元访问所有目标指定的界面;需求测试是指对软件需求说明书的测试, 主要运用的是静态测试技术;设计测试是通过文档审查的方式来对软件设计文档进行测试;集成测试的优势主要体现在低级别的主机平台上;系统测试和确认测试完全可以在目标环境下进行, 能够对所有软件成分进行充分的测试[3]。

4 结语

总而言之, 嵌入式系统应用的日益广泛, 我们对嵌入式软件测试的研究也越来越必要, 嵌入式软件测试是保证嵌入式软件质量乃至嵌入式系统可靠运行的重要手段, 对其进行研究有着重要的现实意义。

参考文献

[1]盛云龙.基于组合覆盖的嵌入式软件测试平台研制[D].哈尔滨工业大学, 2013

[2]陈佳豫, 孔德柱, 刘金国, 周怀得, 赵莹.基于蝴蝶模型的星载嵌入式软件测试策划[J].光学精密工程, 2011, 10 (7) :17-18

软件测试研究 篇11

一、遗传算法

遗传算法（Genetic Algorithm）是最初由美国Michigan大学J.Holland教授于1975年首先提出来的，是模拟达尔文生物进化论的自然选择和遗传学机理的生物进化过程的计算模型，是一种通过模拟自然进化过程搜索最优解的方法。遗传算法包含5个要素：初始化种群，选择，交叉，变异，更新初始群体，结束条件。

模拟退火算法是根据固体退火原理，将固体加热到充分高的温度，再让其徐徐冷却，加温时，固体内部的粒子随着温度上升变为无序状，内能增大，而徐徐冷却时粒子渐趋有序，在每个温度都达到到平衡态，最后在常温时达到基态，内能减为最小【1】。

由于遗传算法具有良好的全局搜索能力，但是对于局部空间搜索却不是很有效，容易产生早熟收敛现象，陷入局部最优【2】。为了解决这个问题，可以将模拟退火算法结合到遗传算法中，模拟退火算法的局部搜索能力可以解决遗传算法局部搜索能力差以及早熟现象，同时也解决了模拟退火算法全局搜索能力差和效率不高的问题。

二、软件测试

软件测试是运行程序并发现程序错误的过程。测试是为了发现程序中的错误，而不是证明程序中没有错误。而测试用例应该包括为测试某个程序路径或者确定是否满足某个特定需求而编制的一组测试输入、执行条件和与之对应的预期结果。一个好的测试用例是能够快速有效的发现程序中的错误。一般把测试分为两类：白盒测试也称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试，是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作；黑盒测试也称为功能测试或数据驱动测试，是通过测试来确认每个功能是否得到完整实现，检测每个功能是否都能正常使用。而黑盒测试的测试用例设计通常是用等价划分法。

用等价类划分法首先要划分等价类：输入规定了的取值范围或值的个数就可以确定一个有效等价类和两个无效等价类。输入规定了的输入值的集合或者一个布尔量可以确定一个有效等价类和一个无效等价类。输入规定的输入数据的一组值（假设m个）且对每一个输入值分别处理可以确定m个有效等价类和一个无效等价类。输入的数据必须遵守一定的规则可以确定一个有效等价类和若干个无效等价类。已划分的等价类中各元素处理方式不同时应将等价类再划分为更小的等价类。其次确定测试用例：给等价类编号设计一个重复使其尽可能多地覆盖尚未被覆盖过的合理等价类直到所有合理等价类被测试用例覆盖的测试用例。设计一个使其只覆盖一个不合理等价类的测试用例。

三、用模拟退火遗传算法需求最佳测试用例

（1）编码。模拟退火遗传算法需要将软件测试中的一个问题的可行解从解空间转换到遗传算法所能解决的搜索空间。初始化种群规模为100，编码方法可以选择浮点法、grey法则和二进制法，本文每个参数的编码方式采用二进制编码。

（2）选择退火算子

在软件测试中，测试的目的是发现程序中至今没有发现的错误，一个好的测试用例就相当于遗传算法中适应度值大的个体，本文将初始群体中的100个个体进行适应度评价，个体适应度值越大，该个体被遗传到下一代的概率也越大。

①随机选择初始群体两个个体A、B，计算其个体适应度值f（A）和f（B）。

②如果f（A）

③重复①、②操作直到新的一代群体中也包含100个个体。

（3）选择。染色体的选择方法可以采用锦标赛法和轮盘赌法，本文采用轮盘赌法，通常适应度大的被选择的几率较高。

（4）交叉。在遗传算法的遗传操作中，交叉运算决定了遗传算法的全局搜索能力【3】。将父代中的任意两个个体进行交叉产生最新染色体。进行退火操作，如果最佳适应度大于最新染色体适应度，就用最新染色体适应度取代之前的最佳适应度，否则以概率P（exp（（f（A）-f（B））/T））接受最新个体。重复操作，直至以概率0.7完成所有的交叉操作。

（5）变异。在遗传算法的遗传操作中，变异操作决定了遗传算法的局部搜索能力【3】。变异方法的选择浮点法和单点法。本文采用浮点法。随机选择一个的内部选择两个节点进行变异，如果新产生的个体适应度小于原个体适应度，就用最新个体取代原个体，否则以概率P（exp（（f（A）-f（B））/T））接受最新个体。重复此操作。直至以概率0.05完成所有的交叉操作。

（6）终止条件。当进化代数超过某个值而适应度不变时或者进化代数达到最大值时。最后留下的也即最优的软件测试用例。

四、结束语

综上所述，本文重在在软件测试中使用模拟退火遗传算法需找最好的软件测试用例。以一种高效率的方式完成软件中的黑盒测试，并找出最佳测试用例。

参考文献

[1]季海婧.基于模拟退火—量子遗传算法的路径测试数据自动生成方法研究[D].浙江：杭州师范大学，2012.

[2]杨清平.基于改进遗传算法的测试用例自动生成研究[D].广东：广东工业大学，311.

[3]李欣，基于贝叶斯网络和遗传算法的测试用例生成模型[D].重庆：重庆交通大学，2012.

基于RUP的软件测试研究 篇12

RUP的软件测试过程与传统的软件测试过程不同，基于RUP的软件测试工作必须要通过计划测试、设计测试、实施测试、执行测试、评估测试几个阶段[1]来完成。本文针对一个PetStore系统，结合RUP测试过程，通过使用测试工具TestManager和Robot对该系统进行了功能和性能方面的测试。

1 测试计划

RUP是一个综合而详尽的流程框架，同样基于RUP的测试流程框架也是十分复杂的。下面列出测试计划中的一些重要部分。

1.1 部分测试输入

测试计划编制的第一步是确定测试输入。一个“测试输入”(test input)是测试的依靠或是测试需要的验证。测试输入可以帮助决定需要测试的内容。

1.2 部分测试需求

1.2.1 系统测试(功能测试)

应用程序测试应该集中在可以被直接追踪到用例(或业务功能)和业务规则的目标需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正确实施。这种类型的测试基于黑盒技术，即通过GUI与应用程序交互并分析输出(结果)来验证应用程序(及其外部进程)[2]。该系统的测试方法如图一所示:

1.2.2 性能测试

性能测试评测响应时间、事务处理速率和其它与时间相关的需求。性能测试的目的在于核实和确认性能需求是否已经得到满足[3]。执行最初的测试时应该使用“额定”负载，该负载与目标系统所使用过(或预期的)的正常负载相近。第二次性能测试则使用最大负载。该系统的性能测试方法如图二所示:

1.2.3 负载测试

负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。该系统的负载测试方法如图三所示:

2 测试设计与实施

2.1 部分功能测试设计与实施

本次功能测试实施主要是使用Rational Testmanager和Rational Robot工具，针对得到的测试用例，生成相应的GUI测试脚本。主要步骤如下:

(1)录制测试脚本

根据已获得的测试用例，使用Robot录制相应的测试脚本。以下是其中测试脚本RS_用户订购1的代码:

(2)编辑测试脚本

必要时应对已录制的测试脚本进行编辑和扩展，以及插入查证点。本次由于录制功能简单，在录制过程中就已经在测试脚本中安排插入了查证点。

(3)创建测试组(suites)

测试组(Suites)是另一个在TestManager中实施测试的方法[4]。一组suite展示了要测试的工作的一个分层描述，或要添加到系统中的工作量。它展示了诸如用户或计算机组之类的条目，每个组的资源分配，执行哪个组的测试脚本，以及每个测试脚本执行的次数。本次功能测试用例全部采用测试组方式实施，这样做有利于对实施测试用例的测试脚本进行修改和维护。其它功能测试用例的设计与实施从略。

2.2 部分性能测试设计与实施

本次负载测试实施主要是使用Rational TestManager和Rational Robot工具，针对得到的测试用例，生成相应的VU测试脚本。主要步骤如下:

(1)录制VU测试脚本

在录制用于性能测试的VU脚本时，也同样要注意测试环境的准备。在VU脚本录制过程中要根据测试的需要插入同步点(synchronization)、计时点(timer)、阻塞点(block)。同步点是为了控制让虚拟测试者同时完成一个动作;计时点是为了模拟真实的客户端与服务端的交互时间，它同时考虑了用户的思考时间以及系统的响应时间;阻塞点则与计时点基本类似，只是它不考虑用户的思考时间，也就是它只计算了事务处理的时间。

(2)设置和应用数据池

对于负载测试要求模拟不同的用户同时完成测试脚本，这就需要使用数据池(Datapool)功能。数据池在rational测试中是使用率很高，同时它也充分体现了自动化测试的优势。通过使用数据池，可以通过简单的脚本完成大量数据的测试，缩短测试时间，提高测试效率和测试质量。

(3)创建测试组

在性能测试中，一个suite不仅仅能够执行测试脚本，也可以模拟用户的活动以添加工作量到一台服务器中去。本次性能测试用例的实施同样采用测试组方式。其它性能测试用例的设计与实施从略。

3 测试执行

在TestManager中执行测试主要是通过以下几种方式:

(1)自动测试脚本;

(2)手动测试脚本;

(3)测试用例;

(4)测试组。

本文中主要讨论测试的自动执行，也就是自动测试脚本的执行。TestManager工具能够根据测试的目的，以不同的方式执行以上生成的测试脚本。可以把测试脚本与相应的测试用例联系起来，然后通过执行测试用例来执行测试脚本。也可以把测试脚本与相应的测试组联系起来，然后通过执行测试组来执行测试脚本。

4 测试评估

Test Manager中可生成的报告主要有测试用例报告(Test Case Reports)、性能测试报告(Performance Testing Reports)和列表报告(Listing Reports)三类[5]。本文主要列出性能测试报告。

性能测试报告能帮助分析在指定条件下，一个服务器的性能。性能测试报告也有几种类别，比如在测试组执行完毕时显示的性能报告(Performance Report)和命令状态报告(Command Status Report)，在此列出50个用户同时登录测试组的响应时间报告。它展示出了单个虚拟用户的单个命令的响应时间和是否通过，如图四所示。

5 结束语

通过基于RUP的软件测试，经过计划测试、设计测试、实施测试、执行测试、评估测试几个阶段工作的进行，给出了针对PetStore系统的测试报告，从而根据结果可以对软件的质量和测试工作自身的质量做出一个客观的评价。

参考文献

[1]中国软件测评中心.性能:软件测试中的重中之重[J].中国计算机用户,2004,5.

[2]B.Kelley.Testing Client/Server System[J].McGraw-Hill Inc,1997.