测试软件测试（共12篇）
测试软件测试 篇1
软件测试是控制软件质量的重要手段。来自智联招聘、南方人才网、中华英才网等相关网站的信息显示,2007年前后国内软件测试人才缺口极为严重,目前软件测试人才就业前景仍然向好[1]。高校要培养合格的、适应市场需求的软件测试人才,需要学生对软件测试有系统的认识,理解软件测试的真正意义,还要有尽可能多的实践经验[2]。这样的需求决定了《软件测试技术》课程的讲授应包括理论讲解和测试实践两部分,理论讲授过程中需要学生用尽可能短的时间掌握软件测试的基本概念、测试过程、测试方法和测试原则,能够读懂相关技术资料,拿到一个软件项目知道该从哪里入手。
查阅软件测试资料时我们会看到许多软件测试门类:白盒测试、黑盒测试、单元测试、集成测试、静态测试、动态测试、回归测试、自动化测试、性能测试、压力测试、α测试、β测试……总结起来有三、四十个,这些测试类别常常搞得学生晕头转向,能让他们在短期内记住并理解其含义已经很困难了,对软件测试的认识更是雾里看花。其实这些词汇是从不同角度对软件测试的划分,如果能够汇总这些测试种类,引领学生从不同的角度对软件测试进行分析,会使学生更好地认识软件测试。正如通过横看、侧看、远看、近看、里看、外看、俯看、仰看……终归会识得庐山的真面目。
1对软件测试的全面总结与分类
关于软件测试分类,有的书上说“软件测试分为白盒测试和黑盒测试”,有的则说“软件测试分为单元测试、集成测试,系统测试、验收测试”,其实每种说法都只关注了软件测试的一个方面。结合前人的总结和当前软件测试的发展,本文从六个角度对软件测试进行了类别划分,具体内容如图1所示。
软件测试不仅仅是在软件开发完成后测试一通儿就可以的,软件测试通常会经历单元测试、集成测试、确认测试、系统测试和验收测试几个阶段(根据具体软件的不同特性有些阶段可能会被合并);如果从测试过程中是否分析被测程序的结构,软件测试可以分为白盒测试和黑盒测试;如果从测试过程中是否需要执行被测程序,可将软件测试划分为静态测试和动态测试;如果根据测试关注点和测试目标不同,可将软件测试划分为功能测试、性能测试、压力测试、安全性测试、可用性测试等;如果从测试过程中是否使用自动化测试工具,软件测试又可划分为手工测试和自动化测试;从测试组织角度软件测试可以划分为开发商测试、用户测试和第三方测试。若以此为主线分别对软件测试进行更详细的介绍,对软件测试的认识也就清晰了。
2课堂组织
有了上面对软件测试的全面总结,还要考虑如何将这个庞大的“关系网”传授给学生,如果直接把这张图展现给学生并从上到下依次讲解,很容易让学生感觉很枯燥,因此要考虑针对不同内容采取不同方式进行知识传授,使他们在愉快、轻松的心境中全身心地投入到学习过程中,全面认识软件测试。
2.1知识的回顾与引申
学习软件测试课程的同学基本上都学习过软件工程的基础知识,所以在讨论按测试阶段划分软件测试的时候,先引领学生回顾软件工程的瀑布模型,结合瀑布模型告诉他们软件测试工作不仅仅局限在“测试阶段”去做,告诉他们在软件开发过程中单元测试、集成测试、系统测试等都做什么,何时做;告诉他们测试的准备工作早在系统分析阶段可能就已经开始了———这样学生知道了软件测试与软件开发的关系,同时也懂得了软件测试按阶段的划分。
2.2利用有趣的实例帮助分析
G.J.MYERS对软件测试的定义“软件测试就是为了发现错误而执行程序的过程”在很长一段时间里被软件测试业所认可并经常被引用,然而随着软件测试的发展,软件测试过程不光通过“执行程序”来实现。比如校园网上有包含很多判断、循环句式的“幽默”程序用于判断“女孩是否该嫁给某个男生”,这样的程序他们一看便懂,带领学生分析这样的程序使他们认识到分析程序代码也是测试的一种方式,继而引入“白盒测试”、“静态测试”的概念。
2.3用类比法加深学生对问题的理解
关于对软件测试不同角度的分类,问学生“如果对在座同学分分类可以分成几类?”,他们有的会想到两类,有的会想到四类———因为按性别划分、按行政班级划分、按所在省份划分结果都不一样,对任何事物进行分类首先要考虑分类的角度,因此把软件测试分成那么多类也就不难理解了。
2.4设置疑问引发学生思考
经过学生认真思考过的问题他们往往都会记得很清楚。讲解手工测试和自动化测试时给学生设计题目:“自动化测试是相对于手工测试而言的,它的好处有哪些?”,“自动化测试会不会取代手工测试?”,“自动化测试有什么不足之处?”,经过学生的思考和回答,再对问题进行总结,学生对自动化测试就有了一定的理论基础,再通过后面具体自动化测试工具的使用,对自动化测试的认识就全面而深刻了。
2.5变换教学媒体
在课堂教学中,单一的教学媒体容易引起学生疲劳和注意力分散,教学效果也会受到影响。因此在通过PPT演示稿讲解课程的同时,可以就一个知识点在黑板上扩展来分析,或者结合视频、编译环境中的代码等来讲解。比如在学生回答软件工程的各个阶段时,在黑板上写出学生的答案,也可以让他们思考更改,再在其中插入软件测试的内容,富于变换。
2.6紧密结合软件测试的发展
随着软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。如从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门,测试工作从简单测试演变为包括制定测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试;测试方式则由单纯手工测试发展为兼有手工测试和自动化测试;第三方专业测试公司的出现等。在分析软件测试分类的过程中适时插入这些内容,使学生了解软件测试的发展。
3课程总结与补充
通过不同方式将不同角度下的软件测试分类介绍给学生后,展现出上面的图片,以提升学生的总体认识。面对图1对问题进行总结,同时补充一些知识点,如冒烟测试、回归测试是怎么回事,白盒测试与静态测试有何异同,哪些测试阶段可以合并,单元测试与静态测试、单元测试与白盒测试是否有必然的联系等等。
对于在后面课程中有详细介绍的内容,如白盒测试、黑盒测试、自动化测试等,只需讲清概念,方法、原理、原则等姑且略过,而对于静态测试等其他概念则要讲清概念、特性及测试要点。
在学生充分理解图1的同时要求他们能够画出这张图,这样前言中所提到的那些测试种类在学生的眼中不再是杂乱无章的了,它们都有各自的含义,它们都有合适的位置,它们之间存在着某种确定的联系。这样,学生对软件测试就清晰了。
4结束语
知道软件测试共有多少类不是目的,通过分析从不同角度对软件测试的划分可以更清晰地理解软件测试,更好地掌握软件测试的相关术语。实践证明,经过对软件测试分类的全面总结,以图1所展示的内容为主线,可以更好地向学生传授软件测试的基础理论,使他们更好、更快地理解软件测试。
参考文献
[1]IT行业软件测试人才就业前景仍然良好[EB/OL].南方人才网,http://www.nfrencai.com/html/200892395010.html,2008.9.
[2]软件测试就业前景跳出“专业框架”[EB/OL].北大青鸟,http://www.nj-test.com/post/5486.htm,2009.4.
[3]贺平.软件测试教程[M].电子工业出版社,2007.6.
[4]赵斌.软件测试技术经典教程[J].科学出版社,2008.4.
[5]Andreas Spilner,等.Software Testing Foundations[M].人民邮电出版社,2008.4.
测试软件测试 篇2
对于测试新手来说，学好测试的理论知识是必须的，因为这些是你测试的基础，千万不要好高骛远，别忘了一句话“磨刀不误砍柴工”。举个例子，如果你没有学习测试理论基础，老板让你做一个测试基线，你知道怎么做吗？就算是你知道基线是什么，那么你会做好一个基线吗？
如果基础没打好，不要急着学习测试工具，因为工具其实是很好学的，无非就是点几个按钮，顶多是写几句脚本，进行一下脚本什么的优化。但是如果不会测试理论基础，你用自动化工具做出来的结果你会分析吗？自动化得出的结果不是最终的测试报告，这些需要测试人员再分析的，最终才能得出结果。再举个例子，你用loadrunner测试出来了一堆数据，你能根据那些数据得出系统瓶颈吗？不能，因为系统瓶颈的种类，分析方法，以及不同的系统要注意的瓶颈点不同，这些如果没有扎实的理论基础是很难分析出来的，因为它要综合各个情况才能得出系统瓶颈的。
还有一点，那就是一定要学习一些其他的东西，因为测试是一个多学科的科学，你必须要懂得，至少了解linux系统，网络技术、一门开发语言、CMM等内容。因为如果这些你不懂，老板让你搭建一个linux的测试环境，你会吗？让你搭建VPN，你会吗？
系统软件测试中的测试需求分析 篇3
关键词：系统软件测试；测试；需求；分析
中图分类号：TP311
1 什么是测试需求
简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。
一条有用的测试需求是唯一的、精确的、有边界的、可测试的。例如：软件产品可能有这样一个测试需求“系统主要事务的响应时间能满足系统要求”。这就是一个不符合要求的测试需求，怎样的指标是“满足”？系统的要求又是什么都不清晰，测试就无法开展。
一个完整清晰的可测试的软件测试需求是这样的：在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。符合标准的测试需求是存在一个明确的可预知的结果，可以通过某种方法对这个结果进行判断和验证
测试需求应覆盖已经定义的业务流程，功能及非功能方面的需求。
2 为什么要做测试需求分析
测试需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where）。是衡量测试覆盖率的重要指标。
确立测试需求是为了保证测试质量与进度，测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。在软件工程项目中，存在一些普遍的现象例如：需求阶段的问题，到测试的最后阶段才被发现；开发、测试、市场等不同角色的人员对软件功能细节存在理解歧义。确立测试需求可以避免这些问题的产生。
3 什么时候开始做测试需求分析
软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。
4 如何做测试需求分析
做测试需求分析有两个关键词，一个是“测试需求”，一个是“分析”，下面我从以下几个步骤来说明如何做测试需求的分析。
4.1 对软件需求说明书进行需求验证
一个良好的软件需求应当具有一下特点：（1）清晰性；（2）组织和完整性；（3）一致性；（4）可修改性；（5）可跟踪性；（6）可检验性；（7）接口：界面、接口的说明；（7）质量、性能属性；（8）可靠性；（9）软硬件；（10）特殊问题。
4.2 搜集和提取测试需求（包括隐性的需求）
测试需求并不等同于软件需求，它是从测试的角度出发并根据软件需求整理出一个测试列表，作为该软件的主要测试内容。提取测试需求要以软件需求说明书及规格说明书为依据，以业务功能为中心，深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。隐形需求包括：用户隐式的需求如业务规则；行业规范；编写人员的技术能力所限等。提取方法可通过列表的方式对软件开发需求进行梳理，先提取出所有的需求点。这些需求点可能存在重复和冗余，再根据项目的功能模块进行组织归类，删除重复的需求、细化测试粒度太大的需求、合并相关联的需求，最后根据业务规则及相关文档等，对测试需求进行检查和完善。测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。如软件需求规格、Usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（2）与客户或系统分析员的沟通。（3）业务背景资料。如待测软件业务领域的行业标准及知识等。（4）正式与非正式的培训。（5）其他途径。
4.3 根据测试阶段和重点，整理测试需求
测试处于不同的阶段，测试的重点也是不同的，例如集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。因此确立测试阶段和重点，才能在测试需求分析时，做到方向正确、目标明确。除了需要确保要求实现的功能正确，还要考虑软件的特性。银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。关注测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。系统功能测试需求分类：（1）业务功能测试需求；（2）可靠性测试需求；（3）安全性测试需求；（4）易用性测试需求；（5）可移植性测试需求；（6）可维护性测试需求。
5 测试需求评审
测试需求的评审是质量保证的必须步骤，通过评审可保证测试需求获得相关干系人的认可，做到有据可依。测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等。同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审各发的一致理解，在测试需求之间以及与开发需求没有矛盾和冲突，每一项测试需求都可以作为设计测试用例的依据。
测试需求评审的形式没有固定的要求，有条件可以采用正式的小组会议形式进行评审，在评审之前确定好参会人员的各个角色和相关的责任，确保评审之前参会人员已经拿到了评审材料并有了足够的了解，评审结束时以签名及会议纪要的方式把评审结果通知相关单位及人员。此方式的优点是有计划有组织地进行，评审更加有效和权威，缺点是需要协调相关人员时间及会议场地等，在很多实际项目中有较大难度。测试需求评审还可以采取非正式的走查和轮查形式，将需要评审的内容发给相关人员，收集他们的意见，并把统一意见修改确立后的测试需求再发给相关评审人员进行确认。这种方式的优点是方便有效，缺点是少了多方人员的讨论和沟通。对于大型的重要项目，可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。
6 测试需求维护
在实际的软件工程中，软件需求的变更是很常见的，甚至频繁变更软件需求。如果一直使用初始的测试需求来指导我们的测试工作，必然造成测试的结果存在错误和差异。因此必须及时维护测试需求，适应实际工作的需要。在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：（1）哪些需求发生了变化；（2）这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试需求？（3）明确这些变化，会对自己的工作进度产生多大的影响。（4）对于必须更改的测试需求变化，要及时更新测试方案和用例。
软件测试需求分析是做好软件测试工作的重要条件，好的需求分析可以为后面的工作指引方向，带来便利。
浅析软件测试技术与测试管理 篇4
1 下面介绍几种测试的方法
1.1 静态测试和动态测试
(1) 静态是指被测试程序不在机器上运行, 而是采用人工检测和计算机辅助静态分析的手段对程序进行检测, 主要方法包括人工测试和计算机辅助静态分析。静态分析的查错和分析功能是其他方法所不能替代的, 静态分析能发现文档中问题。目前, 静态测试已被当做一种自动化的、主要的代码校验方法。但静态测试不能检测程序的实际执行情况, 无法得到程序的执行结果。
(2) 动态测试是实际运行被测程序, 输入相应的测试用例, 判定执行结果是否符合要求, 从而检验程序的正确性、可靠性和有效性。一般意义上的测试主要是指动态测试。动态测试是一种经常运用的测试方法, 无论在单元测试、集成测试中, 还是在系统测试、验收测试中, 都是一种有效的测试方法。但动态测试不能发现文档问题, 必须等待程序代码完成后进行, 发现问题相对迟得多, 一旦发现问题, 必须重新设计、重新编码, 必然增大不良质量的成本。
1.2 黑盒测试和白盒测试
(1) 黑盒测试, 也称功能测试或数据驱动测试。黑盒测试是在已知产品所应具有的功能, 通过测试来检测每个功能是否都能正常使用。测试时, 测试者只在程序接口进行测试, 它检查程序功能是否按照需求规格说明书的规定正常使用, 程序是否能适当地接收输入数锯而产生正确的输出信息, 并且保持外部信息的完整性。“黑盒”法是穷举输入测试, 只有把所有可能的输入都作为测试情况使用, 才能以这种方法查出程序中所有的错误。实际上人们不仅要测试所有合法的输入, 而且还要对那些不合法但是可能的输入进行测试。
(2) 白盒测试, 也称结构测试或逻辑驱动测试。白盒测试是通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时, 测试者必须检查程序的内部结构。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误, 因为穷举路径测试决不能查出程序违反了设计规范, 即程序本身是个错误的程序。
1.3 自动化测试
随着软件系统规模的扩大和软件应用领域的不断扩展, 软件系统的测试也变的越来越困难, 传统的测试已经无法满足测试的需要, 自动化测试应运而生, 自动化测试是指在预设条件下运行系统或应用程序, 评估运行结果, 包括正常条件和异常条件, 自动化主要研究的是自动化框架测试、自动化测试脚本技术、自动化用例生成。通过资料了解, C-ATFM模型。该模型基于C语言, 面向对象集成环境, 采用源码嵌入有效的分析软件的代码、词法、语法、策略、指令。并且随着软件工程及软件测试的发展, 自动化的机器测试发展更有前景。
2 下面简介软件测试的过程
2.1 模块测试
模块测试主要针对软件设计中的程序模块, 通过测试技术测试程序块是否正确, 模块测试的主要目的是测试程序内部的错误, 根据程序设计的结构检查代码和程序是否合理, 是否符合设计思路和理念, 是否能够正常运行。
2.2 组装测试
在模块的基础上, 需要将所有模块的功能全部测试完成后组装成为系统, 组装测试的目的在于, 连接所有模块之后, 模块之间的接口、触发器是否能正常运行, 并且计算显示的数据是否正确, 模块之间的功能是否互相冲突, 是否达到预期的目的和结果显示, 是否构成正确的、预期的数据结构。不同模块之间的误差有多少, 有多少可以解决, 有多少不能解决。
2.3 确认测试
确认测试的目的是验证软件的功能和特性是否达到预期的愿望, 是否能按照预期的组织结构、系统结构、用例分析和时序分析运作, 并且进行验收测试和安装测试。
2.4 系统测试
系统测试是确认软件是否与硬件互相支持, 是否能满足软件使用者对软件的需求和操作简便的愿望, 比如说查询模块运行完后界面中查询条件应该为查询之间输入的查询条件。系统测试保证了系统的正常运行, 另外很重要的就是权限测试, 系统在研发之初定义的权限信息和权限功能是否实现, 是否发现软件成品与软件定义不符合或者矛盾。
3 软件测试技术的地位
程序是由人完成的, 并且软件开发是个很复杂的过程, 期间很容易产生错误, 无论是软件从业人员还是专家、学者都无法避免的产生错误, 因此, 软件中存在错误和BUG是正常的、无法改变的。所以, 软件测试的目的是通过测试技术尽可能的发现软件在研发和使用中的漏洞, 并且找到解决问题的办法, 以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。其实, 。软件编程的过程也会出现一些不可避免的错误, 例如:对于用户需求的错误分析和编程出现的一些语法错误, 如果软件与发票费用相关更是与测试密不可分。软件不断地接近成熟和完成以及投入使用阶段, 软件测试工程师必须更加谨慎的检测每一部分程序, 一段程序的完成, 测试工作量占有总工作量40%以上, 这就给我们说明:测试是软件开发成功的重要组成部分。
4 软件测试的展望
软件质量越来越被人们重视, 测试驱动的开发技术被人们所接受, 软件测试已不再简单的是软件生命周期中的一部分。随着技术的发展, 测试技术将被更多的应用于项目开发之中, 而未来的软件开发更多的是以测试为目的的开发, 通过工具的自动化测试功能, 保证开发人员的代码质量和整个系统的质量。通过自动化测试与人工测试相结合, 更快更好的完成测试工作, 对于测试人员, 可能更多的是需要考虑如何持续改进, 这也就是进行质量管理的目标所在。
摘要：随着计算机硬件的飞速发展, 应用范围的扩大, 软件研发的数量也急剧增长且涉及各个领域, 软件日益增长的需求使得研发的矛盾也越来明显, 引发了软件危机, 在这样的情况下, 软件工程的软件测试部分显得愈发重要, 1993年的IEEE是这样定义软件测试的:“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程, 即将工程化应用于软件中”。软件测试就是在软件投入使用之前, 对软件的需求分析、设计规格说明和系统编码的最终复审。所以, 软件测试不止是为了测试程序, 需求分析、概要设计、详细设计和流程设计都是软件测试的对象。
关键词：软件测试,测试技术,测试工具,信息化管理
参考文献
[1]陈会霞, 周利华.关于软件测试的浅议[J].中国测试技术, 2005 (04) .
[2]王晓华.软件测试技术应用研究[J].国防科技工业, 2012 (03) .
[3]钟百成, 张言上.关于软件测试技术的探讨[J].数字技术与应用.2012 (02) .
测试软件测试 篇5
作者：网络转载 发表于：[ 2011-11-21 13:19:48 ]有个测试同仁让我帮她看看她的简历，看完简历后我的直觉就是“这位测试同仁两年的测试白干了”。简历是一块敲门石，但这块敲门石是什么材质的，恐怕人见人智，然而什么样的简历才能是一块金质敲门石呢，下面是我的一个些个人见解，希望能给正在或正准备寻找更好发展机会的测试同仁们有所帮助。
针对在测试行业中已经有所感悟的人-凸现项目经验优势：在公司允许的范围内，把你参与的项目做一个简单的介绍。比如你参与的项目的体系结构，实现技术等等。这些东西能在一定程度上体现你对测试项目了解的程度，熟知程度，从而也能体现出你的经验到底有哪些。比如，我们可以在我们的项目介绍中告诉对方我们采用的4层架构：数据库，中间件，webservice，客户端，采用的c/s模式等等，如果你觉得可以，我们列举我们的数据库采用的是什么，中间件采用的是什么等等，在简单描述了项目之后，你可以非常坦诚的告诉你所求职的公司，在这个项目中你主要负责的部分，比如主要负责哪个层次的测试，主要负责的是测试执行还是测试设计等等。
对测试能力的描述。这一块很多人喜欢一概罗列，其实在我看来这是个大忌。一概罗列通常并不能体现出一个人的能力，有些人走得是测试管理路线，他擅长的一定是流程流程方面的掌控能力，有些人是走性能测试路线，他擅长的一定是具体的某个或者某些工具的使用。千万不要把自己描述成一个无所不能的，这在我看来，往往是一个无所特长的人。
如果可以，请加入一些测试方面的独特见地。我非常不喜欢的就是一旦问什么，都是书上的一套东西搬出来了，其实书本与现实有时有很大的差别，适时的表现出自己的独特见地，能证明你是一个活学活用的人，这样的人在任何一个单位都非常的吃香。
针对测试新人，切记“诚实的原则”：有些人可能没有吸引人眼球的学历，毕业院校，但请你大方的写出来，大胆的告诉你求职的公司，只有你认可自己，才能希望别人认可你，如果你加入这家公司，你也可以硬气的工作。学历，毕业院校可能成为你面试过程中的一点障碍，可是学历，毕业院校只能证明你的过去，并不能代表你的未来。现在大部分公司更认可一个人的能力，学历，毕业院校只是你一点出彩的地方而已。
开心小测试：测试你的性取向 篇6
穿黑色皮衣的人，你认为这两个人是男是女呢？
1、两个都是男性。
2、前座是男性，后座是女性。
3、前座是女性，后座是男性。
4、两个都是女性。
女人的结论：
1、你是个百分百的正常女人，你喜欢的异性亦属男人中的男人，甚具男子气概，值得你完全信赖的男性是你理想中的另一半。
2、你虽然没有同性恋倾向，但你对同性间的友情极为重视，相反，你对异性交往并没有憧憬，只希望在适婚年龄随便找个人结婚。
3、现在虽没同性恋倾向，但对目前的恋情极为不满，你不认为男性必须保护女性，相反，一个看来不太可靠的男性反而是你的理想对象。
4、你虽看似是满足于与异性的交往模式，但在你内心，对女同性恋者总有着一点爱情的憧憬。
男人的结论：
1、你有些潜在的同性恋倾向，你觉得与异性交往是一件十分麻烦的事，相反地，你非常珍惜与同性之间的友情。
2、你可算是一个思想传统的男人，所以你不单不能接爱同性恋的想法，在生理上亦无法认同。
3、你虽没有同性恋倾向，但却有点恋母情意结，你喜欢一些体格强健的异性，认为即使这世界由女权主导也没半点问题。
探究软件测试技术与测试管理 篇7
社会经济和科学技术的不断发展极大地促进了国内应用软件的进一步壮大和发展,并在互联网信息时代中占据重要的市场地位。尽管如此,我国应用软件的技术水平相对于国际市场还存在一些提高空间,产生差距的主要原因是软件测试还不成熟。因此,在新时期的背景下,要使应用软件得到进一步的发展和提升,必须要从软件测试方面入手。本文主要研究软件测试技术与测试管理,进而为软件质量的提升提供重要保障。
2软件测试技术和具体方法
2.1测试软件说明书
检查说明书是软件检测技术的重要环节,为后续软件检测环节做好充分的准备。首先,对软件说明书采用高级检查与属性检查的方式。从软件测试的实质上看,测试软件说明书的目的不是要快速找到软件存在的漏洞或者问题,而是在某一高度上对软件的整体情况进行审视,进而找到软件存在的根本性问题。在基础上,检测人员要站在客户的角度上检查软件,检查被检测的软件是否符合客户的要求,在这个层面上对软件说明书的各个属性进行测试。其次,明确标准和规范。在软件测试技术中,标准与规范具有一定的差异性,标准比规范更具确定性,在实际的软件测试过程中,测试人员要对软件说明书进行观察,先要检查软件说明书是否符合标准,即公司要求、行业规定、国家标准以及硬件网络标准等条件。最后,在检查环节中,测试人员要身检查软件的规模和复杂性以及可靠性,检查软件是否严格按照质量标准计划要进行研发制造的,明确软件的可靠程度,进而对软件的质量进行有效的控制。
2.2等价类划分
在实际的软件测试中,测试人员要选择最具代表性的案例来对软件进行功能和各项性的测试,在进行选择测试案例的过程中,测试人员可以利用等价类划分的方式来实施软件测试。等价类划分主要是解决如何选择适当的数据子集来代表整个数据集的问题,通过降低测试的数目去实现“合理性”覆盖,覆盖了更多的可能数据,以发现软件心存的缺陷。有效等价类指对于软件测试来说,可以合理地输入数据构成,进而反映出测试数据的集合,利用等价类划分可检查软件是否实现了软件说明书预先规定的各项功能以及性能。就一般意义上来说,等价类划分可以是一个,也可以是多个,根据软件的输入域分布成若干部分,然后从每个部分中选取少数有代表性数据当做数据测试的测试用例,形成软件输入域的集合。
2.3数据测试
软件主要是由数据与程序两部分组成,在数据中有键盘输入和鼠标单机以及硬盘文件等部分构成,程序则是软件可以操作的流程、转换以及逻辑运算。在测试数据的过程中,测试人员要检测输入信息和返回结果,还要保证在过程计算中结果的准确性。进行数据测试过程中有以下测试技术:第一,边界条件测试。在进行边界条件测试中要先对临近边界的数据进行测试和分析,也就是对最后的合法数据进行测试,之后依次测试超过软件边界的一些非法数据,并不断探索软件的测试边界,进而发现软件测试边界,找出软件中“隐身”的各种问题和障碍。第二,通过默认、空白以及无等方法来进行软件测试,也就是说,在输入界面中,输入错误的信息或者是输入空值的情况下,点击回车键,有些软件就会产生错误提示或者是其他情况,这样的情况下一般是由于测试人员忽略了对软件说明书的检查引起的。第三,利用非法、错误以及垃圾数据对软件进行测试,测试人员可以利用这样的数据信息输入,找出软件现存的问题和漏洞,进而提高软件测试技术的水平和效率。
2.4软件状态测试
软件状态测试主要是利用软件的各种状态来检查软件的逻辑性,以及使用流程的准确性和可靠性,状态测试可在以下三方面中进行测试:一是测试人员要让软件进入一个全新的状态,检查软件在进入新状态时的反应和逻辑程序,进而测试软件的稳定性和逻辑性。二是测试人员测试软件从一种状态中迅速转变为另一种状态,主要测试软件在状态切换中的反应速度和灵敏度,并注意观察在转换过程中软件需要的输入数据以及转换条件。三是在进入或者是退出某一状态时,软件需要的设置条件以及最终结果。
2.5黑盒实验
黑盒实验主要在软件接口位置进行,也就是说,黑盒实验是在软件外部进行,不考虑软件结构特点以及逻辑流程。黑盒实验软件测试技术主要是将软件视为黑盒子,测试人员可以根据黑盒子的相关操作说明进行,具体检查软件实际功能是否满足软件说明书上的标准和规定,包括遗漏功能、访问权限错误以及数据结构等方面的错误。在进行黑盒实验的过程中,测试人员要制定科学的测试用例,进而引导整个黑盒实验软件测试过程,尽可能保证测试流程的计划性、目的性和有序性,提高软件测试的效率和质量。
2.6白盒实验
相当于黑盒实验来说,白盒实验更加倾向于软件测试中的细节处理,在软件的细微之处进行检查。因此,白盒实验的优势在于可以让测试人员了解软件的具体结构以及逻辑流程,同时可以通过这些信息的了解和掌握,对测试用例进行有效设计和测试,测试软件程序中的逻辑路径。在进行白盒实验的过程中,测试人员要根据各个检查点对软件程序进行测试,确定软件在测试中的实际状态与预期状态的差距,以便于对软件进行进一步完善和优化。
2.7灰盒实验
灰盒实验主要存在于黑盒实验和白盒实验的中间节点,也就是说灰盒实验具备黑盒实验和白盒实验的共同特点和功能,灰盒实验不仅可以测试软件接口处的信息准确性,还可以测试软件内部结构以及逻辑流程。虽然具有二者共同的优势,但是不具备二者的极致性。灰盒实验没有白盒实验对结构和程序测试的完整性和细致性,只是根据一些具有代表性的特征来测软件内部结构和程序的完整与详细。因此,灰盒实验的主要用途是在黑盒实验测试不出任何问题的情况下,先使用灰盒实验要测试软件的问题,提高软件测试的质量和效率。
3软件测试管理
3.1采用B/S结构
B/S结构可以在网络服务器中实现对软件的测试,促进软件测试的自动化和现代化,测试人员可以在任何时间和地点进行软件的测试,打破了传统软件测试管理在时间和空间上的局限性。测试人员可以利用互联网登录到软件工作页面中,输入测试人员的账号与密码登录网页进行软件的测试,给测试人员的工作带来了很大的便利,提高软件测试效率和质量。
3.2测试资源共享
在进行软件测试管理中,软件开发企业要提供测试用例以及软件缺陷等数据库,软件开发的技术人员可以具有测试用例以及软件缺陷等数据库的的访问权限,在这样的环境下,测试人员可以利用测试管理系统实现测试资源共享,利用以往软件测试管理的实践经验,在现有软件测试管理的基础上不断地进行优化和完善,提高软件测试的技术水平和管理水平,为高品质软件的研发提供打下坚实的基础。
3.3加强工作人员的沟通
所有软件测试的工作人员可以在任意时间地点查看测试资料、成功用例和软件缺陷等信息,可以针对软件测试信息数据进行讨论,并积极发表自己的意见,从而有效增强软件测试相关工作人员的团队能力和协作精神,营造一个良好的工作氛围。
4结束语
综上所述,软件测试对软件整体质量和性能的展现具有非常重要的意义和作用。本文首先对软件测试技术和软件测试管理进行了分析,其次对软件测试技术中出现的问题提出了具体方法。对于软件测试和管理人员具有一定的参考价值。
参考文献
[1]黄莹.软件测试技术与测试管理[J].工业控制计算机,2013(05):36-37+47.
[2]林天华.软件测试技术及其管理工具的研究与实现[D].华北电力大学(北京),2014.
[3]罗霄.基于过程的软件测试管理技术及支持工具的研究[D].西北大学,2013.
[4]梁巧清,范耀明.分析软件测试技术与测试管理[J].电子技术与软件工程,2016(11):80.
分析软件测试技术与测试管理 篇8
1软件测试管理的概述
1.1软件测试管理的内容与目标
软件测试管理的实质在于跟踪与管理各测试阶段中的相关计划与流程, 并将测试管理的相关结果向系统研发职员与管理职员举行反馈, 同时要求凭据软件系统中的缺陷天生相应的陈诉。测试管理的内容重要包罗对过程的测试、对职员的测试以及对事情产物的测试。此中在管理测试过程方面重要考量软件的应用环境与测试是否具备有用性, 在此底子上做好后期测试过程的革新。在管理测试职员方面, 需对软件职员的事情状态等相关数据举行分析与网络, 果断是否与预期测试目标相符合。而在管理事情产物测试方面重要对测试软件产物举行分析与丈量并从中获取可以大概为决议计划提供参考的数据信息。因此, 软件测试管理的目标实质是控制与管理整个测试流程, 以此保证软件产物的质量。
1.2软件测试管理重要观点分析
软件测试过程中涉及的观点重要包罗测试用例、缺陷以及协划一方面。此中的测试用例可细化为相关的数据与所得出的结果, 用于果断测试结果是否与测试计划目标相符合, 确定软件应用步伐中是否存在影响正常运行的题目。而缺陷的观点, 很多研发职员每每以Bug代指软件开发过程中存在的题目, 从狭义角度分析指为由步伐编写过程孕育发生的题目, 而在广义上以为软件应用利用过程中出现的错误。而对协同的观点, 凭据以往学者将其应用于盘算机中的界说为对空间漫衍与时间分散支持的同时, 使软件各部门派合互助。
2以P-TMS为例的软件测试管理系统分析
2.1从需求跟踪管理角度出发
举行需求跟踪管理过程中所分析的重要为用户原始需求, 此中的测试用例会合所包罗的用例具有肯定的联系关系性, 且对应测试用例每每存在肯定的缺陷题目。但值得注意的是很多需求项无需利用测试用例, 不必对其跟踪管理。别的, 在需求跟踪过程中, 由于用户对软件项目标需求差别阶段会存在肯定的变革, 要求构建需求变动流程, 详细过程包罗对需求变动的申请, 在此底子上订定变动的决议计划, 末了在落实阶段需对测试用例重新计划并修改测试用例库。
2.2从测试用例管理角度出发
软件测试事情的成败很大水平上受测试用例管理的影响。详细管理过程中起首需对其构造布局举行分析, 保证此中的上下级系统、子系统、功效模块以及测试用例集等设置公道, 通常各功效模块中每每包罗很多功效项, 而功效项中聚集部门测试用例集, 各测试用例集又存在很多测试用例。其次, 由于被测软件项目存在功效相似或同样的环境, 具有同样的测试要求。对此可引用复用技术, 测试功效项或需求项雷同的软件过程中便可在测试用例库中探求对应的测试用例完成测试过程。
2.3从缺陷管理角度出发
软件生命周期内无论研发阶段或利用阶段都存在肯定的缺陷题目, 要求做好缺陷跟踪管理事情。软件项目测试管理中的相关职员都可对存在Bug向测试主管提交, 而测试职员便需做好缺陷状态以及管理缺陷题目标相关数据统计, 以使项目希望环境可被实时掌握。同时, 应做好项目缺陷的分类, 如步伐题目、数据处置处罚中的错误、编码范例性题目、接口错误、内存管理、系统性能等方面, 在此底子上针对每种范例缺陷提出相应的管理方案并存档与缺陷方案库中, 再次出现该类缺陷时便可从方案库中找到对应管理方法。
3关键技术在软件测试管理中的应用
凭据前文中对P-TMS软件测试管理系统的分析, 在现实计划测试管理系统过程中需重点做好重要功效模块的计划事情。此中在计划重要功效模块过程中要求将模块笼罩整个测试管理过程中, 详细包罗项目范围管理模块、需求项管理模块、测试用例模块、实行计划模块、测试用例模块、管理缺陷的模块、天生报表与系统团体管理模块等。而在计划数据库过程中需凭据相应的模块内容, 保证各模块间的相关数据融于数据库系统中。这种计划测试款力模块的关键技术重要表如今以下几方面。
3.1状态流转技术的应用
状态流转技术的提出重要针对软件中存在的缺陷题目, 计划过程中思量到软件开发与应用的脚色以及详细职责内容。同时, 在现实处置处罚缺陷中除举行状态转换中的相关信息外, 其他很多活动信息都具有显着的缺陷属性, 对此需保证到处置处罚关键的缺陷处置处罚都需创建在前一关键处置处罚完成的底子上。
3.2前置测试的关键技术应用
前文在计划构建测试管理系统过程中应用的重要为前置测试技术, 其在应用过程中重要思量到软件在开发初期便通过测试管剃头现此中存在的题目, 制止开发中缺陷较多, 有利于软件开发质量的进步, 也便于后期维护事情。而除应用前置测试技术外, 现实构建测试管理系统中也应用测试驱动开发相关理念, 为各测试管理关键提供保障。
3.3测试信息共享的关键技术应用
软件测试管理过程中的测试信息共享重要表如今测试用例信息以及缺陷信息的共享。在测试用例信息方面可充实发挥测试用例库的作用, 要求计划职员将差别范例的测试用例存储于测试用例库中。同时, 在计划测试用例库中也可引入复用技术, 对需求项或功效雷同的测试用例接纳直接复用的方法。别的, 在缺陷信息共享方面, 可将差别范例的缺陷以及相应的分析管理方法存于缺陷方案库中。使软件中出现雷同缺陷时, 可在缺陷方案库中探求对应的管理方案。
4结语
软件质量的保证需充实发挥软件测试管理的作用。通过文中基于过程的软件测试管理系统计分剖辨, 要求在现实构建过程中注意应用状态流转技术、前置测试技术、信息共享以及度量测试过程与结果的相关技术, 并保证测试管理系统中个模块如项目管理模块、测试的计划以及管理缺陷等模块都可发挥应有的结果, 如许才可有用监督测试管理的全过程, 为软件质量提供坚固的保障。
摘要：随着科学技术的快速发展, 对软件质量也提出更高的要求。而软件质量的保证重要得益于有用的测试管理, 以往软件测试过程中重要会合在软件编码测试方面, 轻忽对软件项目开发的全过程举行分析。对此要求对庞大的软件测试项目构建美满的测试管理流程, 从软件测试管理中促进软件应用质量的进一步进步。文章重要对软件测试管理的根本概述、P-TMS软件测试管理系统的研究计划以及所应用的关键技术举行探析。
关键词：软件测试,管理过程,关键技术
参考文献
[1]张英.软件测试过程管理控制的研究[J].南昌航空工业学院学报, 2015 (02) .
[2]张涑贤.软件过程质量管理[M].科学出版社, 2008.
布线测试之进场测试 篇9
布线系统的进场测试主要分为裸线缆测试、跳线测试、模块测试和外部串扰测试。模块测试由于技术复杂目前主要应用于实验室技术模型, 而其他三种则是目前布线系统常见的进场测试技术。那么如何在施工前对这些因素进行定性定量的检查?下面本文将分为线缆的测试、跳线测试及外部串扰测试做一个详细的介绍。
1 施工前测试:整箱线缆测试
目前, 绝大部分数据中心的布线系统由光纤和双绞线组成。光纤主要用于连接存储设备及服务器;双绞线主要用于交换设备和服务器的物理连接。双绞线的使用占数据中心布线系统的70%～80%。双绞线本身质量的好坏直接影响到数据中心布线系统的质量, 保障双绞线质量是提高布线系统质量的关键点。
考虑到数据中心传输数率的要求, 大部分的甲方会要求工程实施方使用著名品牌或市面上口碑较好的线缆。但在市面上充斥着各种品牌的线缆, 价格差距非常大, 质量也差距甚远。客户在订购双绞线时, 经常会出现这样的情况, 客户要求是某品牌的线缆, 商家往往会问需要哪种品牌线缆:质量一般的, 比较好的或者是最好的?虽然双绞线线缆的核心技术掌握在一些大的生产厂商手中, 但是仅从外观基本的样式, 仿制很容易实现, 如果不是专业人士从外观上大品牌产品和假线很难看出差异, 这也是造成了假线泛滥的原因之一。价格的差异很大一部分是材料的使用, 很多不正规厂商为了节约材料成本, 会在铜芯中添加一些铝、铁等其他一些廉价金属, 使高频信号在传输的时候有较大的阻碍, 尤其影响传输速率。还有一些工艺上的差异, 比方说双绞线4对线芯, 为了使相互之间的串扰变小, 平衡线对间干扰, 要求每对线芯的绞距不一致。越高频率传输时, 线对间的相互干扰也就越大。
所谓的“一般某品牌”, “较好某品牌”还是“真正的品牌”, 都是客户在线缆采购时无法用肉眼去判断的。甲方由于对布线市场的不了解, 在安装前无法得知使用线缆的质量。因此, 会有一些不良的乙方通过低价中标, 同时为了追求利益最大化而使用假冒的名牌线缆。所以甲方需要一些有效的手段去监督乙方, 乙方也需要证明给甲方所使用的材料质量。
2 如何进行线缆进场测试
所幸的是在布线行业的标准早已有了对线缆本身质量的标准, 如TIA 568B、ISO11801。客户在完成线缆选型后, 在工程方送来的线缆中按一定的比例抽取若干条100m长的线缆进行抽测。抽测的比例从2%～20%不等, 这与采购产品总数量、甲方合同检测比例约定和甲方对产品质量的关注程度有很大关系。客户在做线缆测试, 必须使用能够支持TIA 568B中线缆测试标准的测试仪表, 例如“DTX1800电缆分析仪”+“电缆测试适配器“LABA”一对+DTX-REFMOD模块, 在选取100m的双绞线后, 可以通过以下步骤完成安装前的线缆测试。
(1) 设备校准。使用仪器自带的校准模块校准主机和远端, 消除测试仪器之间的误差。
(2) 接入专用线缆测试适配器。在主机和远端上分别插入LABA MN模块。
(3) 接入被测线缆如图1所示。
(4) 选取测试标准。在主机中选取专用于双绞线的专用测试标准, 以6A线为例, 选取TIA Cat.6A cable 100m (LA) 。
(5) 开始测试。仪器按照标准自动完成所以测试项目, 9秒后查看测试结果, 双绞线是否合格。
(6) 生成测试报告。由于DTX系列仪表支持数字信号处理技术, 通过傅立叶的反变换及变换, 将频域信号转变成时域信号, 从时域切除100m线两端端接的强干扰信号后, 重新转换成频域曲线, 从而精确的完成标准测试, 鉴定线缆的性能。
3 施工前测试:跳线测试
在数据中心的布线系统中, 大量的使用跳线来实现交换机设备的快捷互联或者服务器的连接。经常性的插拔及反复的使用, 质量差的跳线往往会使跳线成为数据中心的故障点。有经验的数据中心维护人员会适时的丢弃一些反复使用多次的跳线, 替换成新跳线。
随着数据中心数据量的大量增加, 布线系统传输带宽的要求也提高, 6类线及6类以上链路的使用, 在数据中心已经开始普及。维护人员发现, 跳线越来越多的成为故障点。有时候刚替换一根全新的6类跳线也会是整条链路的瓶颈, 而且有经验的维护人员自己做的跳线有80%都会出现各种问题。跳线本身距离较短, 大部分的跳线不超过5m, 10m以上的跳线算是长跳线。因此, 线缆本身对跳线质量影响较小, 而水晶头及其端接的质量是跳线测试的关键。简而言之, 双绞线在插入水晶头的时候, 发生较大形变, 例如绞在一起的线对被分开等, 这些都会使线缆的特性发生突变。比如回波损耗等, 最终使得水晶头成为高速率传输的瓶颈。不用说手工制作的跳线, 很多著名厂商直接用机器压制的跳线也有较高的不合格比例。曾经有机会测试了10根某品牌6类跳线, 其中一条跳线不合格, 而另外几条都是刚刚卡着合格线过, 留下余量非常小。因此, 无论是厂商出场的跳线还是手工做的跳线都必须进行安装前测试, 从而保障数据中心布线系统的质量。
4 跳线测试的误区:用通道测试代替跳线测试
目前在业内, 有不少的集成商或工程施工方用通道的测试模块去检测跳线。测试结果令人满意, 几乎是没有不通过的。其实, 刚才谈到跳线的故障点往往处在水晶头上而不是线缆上。但标准中规定了通道测试模型是不包括链路两端水晶头的, 也就是说一起在做通道测试的时候会自动扣除链路两端水晶头的影响。哪么对于5m、10m长的线缆自然就很容易通过测试, 而真正的跳线测试是包含测试跳线两端水晶头的质量。
5 如何做跳线测试
5.1 6类跳线测试
其实对于6类跳线, TIA及ISO标准委员会早已有了相关的参数及测试设备规定。在6类线刚进入市场后, 关于6类跳线的水晶头及模块各个厂家都有自己的做法。考虑到公平, 标准委员会找到一个第三方的模块, SMP生产的模块, 可以较好的兼容各个厂家的水晶头。此标准委员会把第三方的模块 (SMP) 放入测试规范中, 因此, 在做6类跳线测试的时候, 必须使用SMP的模块适配器。通过DTX1800+SMP跳线适配器的配合, 通过以下步骤完成6类跳线的测试。
(1) 设备校准。使用仪器自带的校准模块校准主机和远端及其适配器, 消除测试仪器之间的误差。
(2) 接入专用6类跳线测试适配器。在主机和远端上分别插入SMP模块。
(3) 接入被测线缆。
(4) 选取测试标准。在主机中选取专用于双绞线的专用测试标准, 以3m长的6类跳线为例, 选取TIA Patch Cord cat.6 3.0m。
(5) 开始测试。仪器按照标准自动完成所以测试项目, 9秒后查看测试结果, 跳线是否合格。
(6) 生成测试报告。
5.2 6A、7类跳线测试
对于6A、7类跳线, 由于ISO标准委员 (TIA只做了6A跳线标准) 会已经出台了其相应的测试标准参数, 但尚未规范测试模块, 因此并无测试规范。目前, 业内比较通用的是使用FLUKE的DTX-1800+LABA SET+DTX-REFMOD完成测试。测试流程依据标准跳线测试进行。
6 施工前测试:外部串扰测试
由于数据中心数据量大, 对布线系统带宽要求很高。标准6类线的最高传输频率是250MHz, 而在使用6A线的时候, 也就是10G传输时, 最高传输频率要求达到500MHz。在如此高的频率下, 对线缆本身的物理特性参数和施工工艺有着极为挑剔的要求。尤其当传输速率达到10G时, 线缆本身的质量, 连接跳线的质量及同捆线线缆之间的相互干扰 (6包1的捆扎方式) , 都成为影响链路传输性能的重要因素。这时干扰信号不仅仅来源于各线对之间的干扰, 相邻的双绞线之间也会产生较为严重的干扰, 从而影响网络传输的质量。因此在10G及以上传输速率的布线系统中, 在相应规范测试完成的基础上, 增加外部串扰测试。在实际的布线系统, 尤其是数据中心, 高密度布线系统, 线缆与线缆之间的外部串扰会更加明显。因此, 在工程实施前外部串扰也必须验证的一个指标。
在一般的综合布线系统, 由于配线架等安装设施都将六根线束作为最小捆绑单元, 线捆绑扎的时候都是6包1或者11包1在高密度的数据机房, 可能会采用更大的捆绑单元。所以考虑使用11包1施工前测试。由于外部干扰测试周期较长, 施工后的验收测试一般只选取5个捆扎单元。在施工前, 可以测试一个捆扎单元进行模拟。目前, 也可采用“DTX-1800线缆认证测试仪”+“10GKit测试套件”完成外部串扰测试。
7 如何测试外部串扰
第一步:对捆扎单元内所有线缆进行常规的通道和永久链路测试;保存测试结果;通过USB数据通信线, 连接电脑;将结果导入电脑上安装的LINKWARE软件。
第二步:在电脑上安装“AxTalk”;找到每捆测试线缆中, 选择最长或者一些连接器间隔最近的链路作为“被干扰线缆”;选择一条“干扰线缆”;在“干扰线缆”上加信号释放干扰, 每次加一根, 轮换所有“干扰链路”测试PS ANEXT和PS AACR-F;操作测试软件, 对“被干扰线缆”进行PS ANEXT测试和自动计算;操作测试软件, 对“被干扰线缆”进行PS AACR-F测试自动计算。
柔性测试探索测试新空间 篇10
近日，北京中科泛华测控技术有限公司公开推出了酝酿已久的“柔性测试”技术的新理念。“柔性测试”技术由泛华测控率先提出，它是以多种测试相关应用技术为基础，为满足复杂、多样化的测试测量需求的变化而开发的系统化技术。它整合了虚拟仪器、测试测量、机电一体化、网络通信及软件等多种技术;既面向应用，又专注于测试系统的创建和发展。
“柔性测试”技术以测试系统的各种需求为关注目标，重点是要解决测试过程中的手段问题，更多的是着重于应用层技术，通过多种技术应用的经验积累，形成各种系统集成的应用经验模块，通过模块化的测试设备增加了测试系统的可移植性，进而实现测试系统可扩展满足更多测试应用需求。“柔性测试”技术的最大特点是适用性、灵活性和可扩展性，它将测试测量解决方案或系统的实现作为一个整体来考虑，根据测试要求和测量对象从应用出发来规划完整的测试平台，完成仅使用常规测试测量技术难以实现的测试系统，为各种测试测量需求提供完整的解决方案。“柔性测试”保证了原有测试系统通过构建时的特别设计，以实现系统在多个领域中的复用。
泛华测控总经理左毅表示，“柔性测试”技术是在测控泛华公司成功运作十年的技术经验积累基础上，结合了相关领域的最新技术发展，充分考虑到市场需求而提出的测试新理念。“柔性测试”技术将作为公司的技术支撑，促进公司发展的一致性方向，最终引领公司继续前行!
测试软件测试 篇11
关键词： TDLAS； 激光气体遥测仪； Visual Studio 2005开发环境； 工装平台
中图分类号： TN 253 文献标志码： A doi： 10.3969/j.issn.1005-5630.2016.03.004
文章编号： 1005-5630（2016）03-0209-07
Abstract： Laser gas remote sensing instrument is a kind of new type instrument which can analyze and detect average concentration of CH4 in the detecting area （for example， transmission pipeline， ceiling， wall and so on） with an advanced technology called tunable diode laser absorption spectroscopy（TDLAS）. Laser gas remote sensing instrument with good performance has been widely applied in many dangerous areas. At present， however， the testing process of manufacturing testing system extremely complex， time-wasting and inefficient， completely manually operate. The purpose of this paper is to design and develop an automatic testing software combined with related practice， to improve work efficiency. The study harvest of this paper lies in designing a simple， practical and stable PC testing software. Now， this software helps people to work on product line quickly and accurately complete testing process.
Keywords： TDLAS； laser gas remote sensing instrument； Visual Studio 2005； work platform
引 言
随着社会的发展，生产技术水平的不断提高，钢铁冶金、气体管道传输、化工等行业生产力需不断提高，但必须保障生产安全。基于可调谐半导体激光吸收光谱（TDLAS）技术的激光气体遥测仪已经成为提高生产效率、保障安全生产的重要仪器。如此的社会需求激起了国内外仪表厂商的极大的研究兴趣，激光遥测仪表的市场竞争愈演愈烈。
20世纪90年代后期，随着半导体激光器的大规模生产及科学研究的应用，TDLAS技术得到了迅速发展。21世纪初期，该技术逐渐被国内的研究者关注，现在已有很多企业推出了激光气体遥测仪，并投入使用，同时，国内也制定了激光器产品及分析仪器的相关国标。但是大多数国标也只是针对激光器产品准则与分析仪器通用准则，对整机测试系统的设计与研究并没有深入。整机测试系统包括硬件和软件部分，本文主要设计软件部分的自动化实现。
1 激光气体遥测仪整机测试研究
1.1 激光气体遥测仪检测气体的原理
激光气体遥测仪是基于红外吸收光谱原理，采用可调谐半导体激光吸收光谱技术（TDLAS）设计而成的，TDLAS技术主要是利用可调谐半导体激光器的窄线宽和波长随注入电流改变的特性实现对分子的单个或几个距离很近且很难分辨的吸收线进行测量，它是一种高分辨率、高速度、高灵敏度的单线吸收光谱技术，通过改变半导体激光器的工作电流或工作温度等参数以调谐激光的输出波长，使仪器内的激光器输出特定波长的光束，扫描被测气体（甲烷气体）以获得某一条或一簇吸收谱线的吸收光谱，通过分析该吸收光谱进而获得被测气体的浓度信息[1-4]。
1.2 激光气体遥测仪系统及整机测试系统
1.2.1 激光气体遥测仪表系统
仪表主要由如图1所示的4部分组成，测量时通过将一束激光指向泄漏点，得到一簇吸收谱线的吸收光谱，依次通过接收光汇聚及校准单元、信号驱动与校准单元，最后将被测气体平均浓度信息显示在仪器界面。
1.2.2 整机测试系统
整机测试系统主要由如图2所示的3部分组成，上位机是整个系统最为重要的部分，协调控制整个系统协同工作。上位机发送命令控制激光遥测仪设置自身参数，并读取浓度测量值等其他参数。质量流量计为测试流程提供所需的校准气。
当前，对激光气体遥测仪表进行整机测试时，只能根据工艺文件手动操作，操作过程相对复杂、费时、而且很容易出错，为了解决这个问题，提高测试效率，本文设计一种自动化测试软件，不仅能够解决手动测试时存在的问题，提高测试的准确度，而且可同时连接多台仪表进行测试，既可节约校准气体又可提高测试效率。
1.3 整机测试过程
激光气体遥测仪整机测试流程必须较全面地涵盖所有需要测试的项目，根据测试工艺合理划分多个测试项。整机测试是对一台激光气体遥测仪表性能的全面检测，各个测试项必须要求明确，测试方法适当，各个测试项之间相互独立，测试项顺序合理安排，以保证仪表性能的完整检测。整机测试流程如图3所示，测试过程中资源分配情况如下所述。
（1） 激光气体遥测仪：接收上位机发送的通讯命令，并完成相应的操作，然后对上位机作出应答。
（2） 上位机：根据测试项流程发送通讯命令，使仪表做相应操作，获取仪表信息，从而判断仪表性能。
（3） 质量流量计：控制测试过程中气路，保证测试过中零气、标气按所需比例通入。
2 整机自动化测试软件设计
2.1 整机自动化测试软件需求
根据激光气体遥测仪的整机测试流程、测试工艺，分析得到自动化测试软件主要需求。该软件主要包括几部分，即工装配置、信息管理、测试管理、测试项目管理，每部分具体叙述如下。
（1） 工装配置：整机测试前，进行网络配置和流量计的配置，包括需要连接到多台仪表、两台质量流量计MKS等所需的网络信息；仪表和流量计的相关属性。
（2） 信息管理：实时显示测试过程提示信息；保存测试结果信息；界面实时显示浓度趋势等。
（3） 测试管理：可以同时连接多台激光气体遥测仪表（>=1）、单个测试项测试、多个测试项组合测试等。
（4） 测试项目管理：内部信噪比、纠偏系数、纠偏阈值、调零标定、探测下限、输出波动与重复性、示值引用误差。
2.2 整机自动化测试软件的整体架构
该软件由平台层、业务层、界面层构成；平台层使用FPI上位机软件部目前使用的开发平台；业务层依赖平台层开发，主要包括系统配置模块、运行时设备管理模块、辅助功能模块等；界面层依赖业务层和平台层开发，实现具体用户交互处理，各层次主要关系如图4所示。
该自动化测试软件将在.NET平台下借助Visual Studio 2005开发工具采用C#语言开发。Visual Studio 2005是一套完整、高效、人性化的集成开发环境（IDE），C#是微软公司针对.NET Framework设计的一种面向对象的高级程序设计语言，是一种安全的、稳定的、简单的、优雅的，同时兼顾系统开发和应用开发的最佳实用语言，提供的类型安全、版本控制、垃圾收集等功能能够有效协助程序员快速高效开发应用程序[6-8]。
2.3 整机自动化测试软件中各主要模块
界面层依赖业务层、平台层开发，具体模块不做详细介绍。
2.3.1 平台层各主要模块
2.3.1.1 xml文件管理模块
该模块是上位机的基础模块，应用程序使用xml文件来配置信息或保存信息。该模块主要类关系如图5所示，主要由以下几部分组成。
VarConfig：变量配置管理器，与Var.xml对应。
ConstConfig：常量配置管理器，与Const.xml对应。
BaseNode：xml配置节点的基础类，用于加载与保存各个模块的xml文件。
IdNameNode：BaseNode类的子类，xml的节点，必须包含id和name字段。
NodeList：管理xml文件中的所有子节点，包含一系列IdNameNode。
Property：IdNameNode类的子类，必须包含value字段的配置节点类型。
2.3.1.2 通讯管理模块
该模块主要依据PortManager.xml文件管理与上位机通讯交互设备的通讯链路。
该模块中主要的接口关系如图6所示，对应功能如下所述。
IConnector：抽象的开关器，包括打开、关闭、连接状态。
IReceivable：抽象的接收器。
IBus：抽象的物理链路，能够读取、写入字节流。
IPort：抽象的协议层，继承自IConnector和IPortOwner，能够发送、接收字节流对象。
IPortOwner：抽象协议层的上层对象，继承自IReceivable。
该模块中主要的类及其功能如下所述，主要关系如图7所示。
BaseBus：抽象类，总线基类，实现IBus接口，各物理链路必须继承该类以实现各个业务。
BasePort：协议层基类，实现IPort接口，各协议层必须继承该类以实现各个业务。
BusPort：BasePort的子类，关联物理链路与协议层的桥梁。
Pipe：继承IdNameNode类，表示一条通讯链路，用于链路的创建、删除、打开、关闭，用于通讯指令的发送、接收。
PortManager：BaseNode的子类，表示一个通讯链路管理器，与PortManager.xml对应。
2.3.1.3 仪器管理模块
该模块主要根据Instrument.xml文件，管理与上位机通讯交互的设备信息，该模块主要类如图8所示，其功能如下所示。
Instrument：继承自IdNameNode类，表示一个设备信息。
InstrumentManager：继承自BaseNode类，表示一个设备信息管理器，与InstrumentManager.xml文件相对应。
2.3.2 业务层各主要模块
2.3.2.1 通讯封装模块
该模块主要借助已经开发的相应工具，针对不同的通讯命令生成其相关的通讯方法，提供通讯调用，主要由获取通讯命令结果方法组成，对应平台层的通讯管理模块，主要模块如图9所示。
通讯封装模块封装了与上位机通讯的各个设备通讯协议与通讯指令，激光气体遥测仪表与上位机的通讯报文由帧头、目标地址信息、源地址信息、命令码、命令扩展码、数据信息区、校验区、帧尾组成。
2.3.2.2 设备管理模块
该模块提供后台处理类，完成系统体系结构中的各个设备的逻辑封装，完成其信息的后台记录，提供与具体设备的交互方法，提供设备相关结果信息的处理功能。类关系如图10所示。
RuntimeInstrumentManager表示运行时仪器管理类，RuntimeInstrument表示运行时仪器抽象类，RuntimeCH4表示仪器。
2.3.2.3 系统配置模块
该模块主要根据MultiBEManager.xml管理上位机的通信协议类型与物理链路类型，提供物理总线、通信协议以及设备与PortManager.xml、InstrumentManager.xml的配置方法。该模块中主要类及其功能如下所示。
Bus：继承自IdNameNode类，表示一种物理链路信息，一种物理链路可支持多种通讯协议，一个物理链路端口只能使用一种通讯协议，该类中，impBus表示物理链路对象，propertyCreaterClass表示物理链路通讯参数的xml配置方法对象，ententes表示物理链路所支持的通讯协议集合。
Entente：继承自IdNameNode类，表示一种通讯协议，该类中，instrumentTypes表示通讯协议所支持的设备类型、impProtocol表示在通讯链路管理模块中的通讯协议栈对象、propertyCreaterClass表示通讯协议栈的xml配置方法对象。
MultiBEManager：继承自BaseNode，与MultiBEManager.xml配置文件对应，表示一种链路协议管理器。
InstrumentUtil：用于修改并保存仪器的相关属性。
PortUtil：进行端口管理、pipe设置。
2.3.2.4 辅助功能模块
该模块主要实现整机测试项目的管理，包括各个测试项具体实现、测试项管理器（ProdTestManager）设计、多台仪表同时测试管理器（MultiProdTestManager）设计、测试状态、波形信息控制等。
3 总 结
仔细分析软件需求，然后撰写需求规格说明书、概要设计说明书，最后开始软件开发，现已完成该整机自动化测试软件，并且该软件已运用到了实际操作中，测试界面如图11所示（以同时连接两台仪表为例），从图可看出该软件界面能够实时准确地显示测量浓度趋势；同时该软件还可将采集到的数据以excel形式保存在相应的文件夹，供后续查看。二期工作在原有功能的基础上增加保存波形图、读取整测过程中对应全部参数并导出等功能。
参考文献：
[1] 俞大海，顾海涛，陈人，等.用于干熄焦循环气检测的在线激光气体分析仪[J].自动化仪表，2007，28（S）：108-109，112.
[2] 俞大海，闻路红，王兴华，等.基于DLAS技术的激光气体分析仪的在线应用[J].燃料与化工，2009，40（5）：14-17.
[3] BARBUT L，VINOGRADOVI，DURRYG，et al.TDLAS a laser diode sensor for the in situ monitoring of H2O，CO2 and their isotopes in the Martian atmosphere[J].Advances in Space Research，2006，38（4）：718-725.
[4] LINSB，ZINNP，ENGELBRECHTR，et al.Simulation-based comparison of noise effects in wavelength modulation spectroscopy and direct absorption TDLAS[J].Applied Physics B，2010，100（2）：367-376.
[5] 赵裕繁.激光气体分析仪整机测试系统设计[D].杭州：杭州电子科技大学，2012.
[6] WATSONK，NAGELC.C#入门经典[M].4版.齐立波，译.北京：淸华大学出版社，2008：3-9.
[7] HOFFMANK，KRUGERL.C#.NET技术内籍[M].董梁，高猛，译.北京：淸华大学出版社，2006：25-36.
[8] NAGELC，EVJENB，GLYNN J.C#高级编程[M].6版.李铭，译.北京：清华大学出版社，2008：1-21.
测试软件测试 篇12
关键词：软件测试流程,KPI,考核体系,教学体系
1 软件测试重要性及KPI考核体系构建意义
软件测试是保证软件质量的一重要手段,其在软件生命周期中的重要性日益凸显。IT企业对软件测试人才需求量不断增多,软件测试岗位迅速扩张。
基于软件测试人才需求旺盛的现状,推进基于KPI的多元化绩效考核体系的管理模式并在试点企业中试行和同步改进,将有助于最大限度地调动工程师的工作热情、提高效率。此外,高校软件测试人才的培养往往注重知识的提升、技术的锻炼,而易忽视综合素质的培养。据企业测试人才绩效考核体系的要求,映射到软件测试体系化教学中,进一步优化软件测试教学体系,改进教学知识与技能架构,从而提升高校人才培养及实习就业质量,校企对接更加紧密。
2 软件测试KPI考核现状及应对策略
2.1 科学管理技能尚有不足
IT企业管理层往往为技术出身,具有技术背景和深厚技术功底做支撑,但对于企业管理、团队管理领域大多未经历过系统的学习,故在管理技能和技巧上较为欠缺。据了解,一些测试经理仅关注软件缺陷的发现与跟踪,在程序员提交完整系统后才开展测试工作,从而忽略了规范化的软件测试流程及需求评审、测试计划制订、测试用例设计、测试环境构建、测试实施、测试总结与评估等关键环节的管理与人员技能的考核,与一线岗位工作内容严重脱节。
2.2 不同岗位同标准导致KPI指标雷同
不同岗位工作内容及考查点存在差异,应依据软件测试工程师、自动化测试工程师、性能测试工程师、测试组长、测试经理等分岗位、分级别制定不同层次的考核标准。否则无法高效引导,指导各岗位履行岗位职责。
2.3 考核评价人的单一性与考核全面性欠缺
大多企业对于基层测试人员的KPI考核仅依靠直接领导的评价意见,此考核较片面,应全方位、多角度比较,同步综合直接领导、部门经理、同部门乃至同项目组员工等量化评分,并参考其他部门员工是否有负面意见等开展考核;亦应结合“员工自评”方式,给予自主辩解环节,进一步提高考核评价的客观性、准确性,使考核评价结果更具说服力。
2.4 考核沟通机制与制度透明化不健全
就现状而言,多数测试工程师往往仅知被考核了,对具体考核指标及措施等全然不知,此状况不利于测试工程师改进和提升,也会降低被考核人对考核结果的信任性。
建议就制定出的KPI考核体系,开展基层交流讨论、修订与完善、公示及反馈等环节;推广绩效考核管理系统的应用,“个人”考核结果实现系统可视化,实现透明化的同时又明确了工程师改进方向;并行“阶段考核”及“年终考核”,且融入年终述职环节,增设“绩效面谈”流程,进一步调动测试人员的积极性,加强考核的行为导向作用。
3 软件测试KPI考核体系构建
KPI考核体系的构建,重中之重在于KPI关键业绩指标的选定,合理的KPI指标是企业绩效管理和改进的关键,本文重点结合企业软件测试核心工作流程对KPI指标进行选取及考核方式规划。构建测试工程师KPI考核体系如表1所示,具体分析如下。
一是“测试执行”考核项:主要针对测试执行情况进行考核,细化为6项考核点:①提交有效BUG数量:基本考核指标,取被考评者所参与项目中当月或同一考核阶段中所提交BUG数与当月总BUG数之比,本条计分方式为:10×(个人BUG数量/总BUG数量)。②提交BUG的质量:重要考核标准,无效BUG提交数量过多,说明员工测试基础欠扎实,本条计分方式为:10×(有效BUG数量/总BUG数量)。③提交BUG的严重等级比例:按公司质量规范中对BUG严重等级的分类,排序权重为A至E,权重越高、BUG比例越高,得分越高。④提交BUG的规范性:涉及BUG描述是否清晰且可否复现,BUG严重程度是否正确,BUG相关附件是否提交等。⑤回归BUG数量:考评期间回归BUG数之和。⑥执行用例数量:考评期间执行用例数之和。
二是“文档编写与用例设计”考核项:主要针对测试流程中关键文档的制定与测试用例设计质量进行考核,细化为4项考核点:①测试用例数量;②设计用例的质量;③外部文档制作规范性(用户手册、系统帮助等);④内部文档规范性(测试计划、评审报告、测试报告等)。
三是“专业技能”考核项:主要针对测试工程师的实践能力及操作成熟度进行考核,体现为2项考核点:①测试工具掌握程度;②测试环境搭建能力。
四是“工作态度”考核项:非技术性考核指标,重点考核测试工程师职业素养与品质,细化为4项考核点。①工作积极性:工作的速度,完成工作的迅速性、时效性,有无浪费时间或拖拉现象。②沟通能力:与各方面关系协调,说服他人及人际交往的能力。③学习创新共享能力:改进工作的主动性及效果,主动研究新技术,并积极与团队共享。④执行力:对公司及上线领导的战略、决策、计划的执行程度。
五是“其他”考核项:为上述各项考核的补充和完善,进一步检验测试工程师日常基本工作规范,激励工程师具备良好的客户服务意识等,主要涉及出勤、奖励、惩罚3项考核点。
此外,对于软件测试管理层岗位,亦应对接日常测试管理及质量管理等岗位职责,分层制定KPI考核指标。①工作完成情况。涵盖本部门当月实际工作完成情况、部门人员工作分配与考核、工作日志等考核指标。②测试技术改进情况。涵盖新技术研究与应用、团队培训等考核指标。③部门配合协调情况。涵盖沟通协调、意见收集及反馈等考核指标。
4 高校软件测试教学体系优化与改进
以科学合理的考核体系为基准,进一步改进和规范化软件测试课程体系,融入KPI考核中涉及的实战技能和职业素质等培养要求。技术层面和职业素养层面,进一步提升应用技术型人才的企业适应能力及职业素养。
5 结论
综上所述,对接企业测试流程探究了软件测试KPI考核体系,此体系亦于部分软件企业测试团队中进行试行,取得一定效果,在一定程度上调动了企业测试团队的工作热情、提高工作效率;此外依托企业测试人才KPI考核体系的各项要求,映射到日常软件测试体系化教学中,进一步优化教学课程体系,并在部分高校中进行了订单班式培养,在提升应用型人才培养质量上得到校企双方充分肯定。
参考文献