qileilove

　　Java流程控制包括顺序控制、条件控制和循环控制。

　　顺序控制，就是从头到尾依次执行每条语句操作。条件控制，基于条件选择执行语句，比方说，如果条件成立，则执行操作A，或者如果条件成立，则执行操作A，反之则执行操作B。循环控制，又称为回路控制，根据循环初始条件和终结要求，执行循环体内的操作。

　　实际上，不管是各种控制，归根结底，就是做事情的步骤性的表现方式，有的是顺序的，有的是条件的，还有的是控制的。从广义上来思考，都是具有顺序性的完成工作。

　　Java的条件控制主要形式如下：

　　1）if(condition){statement}

　　2）if(condtion){statement1} else {statement2}

　　3）switch(condition){case condition1:statement1;break;.....default:statement}

　　4）上述形式的组合与嵌套

　　Java的循环控制主要形式如下：

　　1）while(condtion){statement}

　　2）do {statement} while(condtion);

　　3）for(initialCondition;circleCondition;iterator){statement}

　　4）上述形式的组合与嵌套

　　为了更加直观地认识和理解Java流程控制，分别编写了简单的实例代码。

　　1） 顺序控制实例代码如下：

　　运行结果如下所示：

　　俗话说的好，“万丈高楼平地起”。由此观之，只有打好扎实地根基，才能筑造出稳健地高楼。对于我们学习和实践技术，也是同一个理。

　　本文有序地归纳了java语言基础细节，一是作为学习上的总结，二是避免触犯同样地错误，三是希望与同道之人交流、探讨和完善。

　　1、一个类定义前可以放置3类语句，分别为package、import和class语句，并且在一个Java源文件中有且只有一个被声明为public的类。

　　2、Java语言中规定，标识符不能使用规定的关键字和保留字，并且必须以一个字母、美元符号或下划线开头，随后的字符只能是字母、美元符号、下划线或数字。

　　3、Java中存在两种变量：成员变量和局部变量（又称自动变量）。成员变量即类所拥有的变量，可以由系统自动初始化，赋予其一个默认值；而局部变量即方法所拥有的变量，它不能自动初始化，必须为其指定初始值。若不给予初始化，编译会出错。

　　4、数组在通过new语句创建以后，系统会根据其声明类型自动为每一个数组元素赋予一个默认初始值。

　　5、main()方法是一个Java应用程序的入口。为了创建一个应用程序，必须在其类中定义一个main()方法。其完整的定义语法如下：

　　public static void main(String[] args){ }

　　或者

　　public static void main(String args[]){ }

　　其中参数数组用于从命令行中获取用户参数。

　　例如：java Test  a  bc  efg

　　则有args[0] = “a”

　　args[1] = “bc”

　　args[2] = “efg”

　　6、Java语言中规定用来指定数组的长度的数值类型只能是字节型、短整型或者整型，而不能是长整型。

　　7、字符型值的初始化值是数值0，而不是一个字符’0’，而字符’0’的值为48。

　　8、Java语言中规定，声明一个一维数组可以采用以下两种形式之一：

　　Datatype[] arrayName;

　　或者

　　Datetype arrayName[];

　 　9、Java中垃圾回收（garbage collection）站负责收回废弃对象所占用的内存资源，程序员不需要明确释放掉的对象，尽管可以把一个引用设置为null。程序员可以使用 Runtime类的gc()方法或System类的gc()方法通知运行垃圾回收站，而非强制执行。若是系统中可用的内存过低，系统也会自动运行垃圾回收 站释放掉废弃对象所占用的内存资源供其他对象使用。

　　10、数组是通过length属性域获得数组的长度信息，而字符串是通过调用length()方法获得其长度信息。

　　关于Java语言基础细节上的归纳暂且罗列上述十点，在后续的学习与实践中将进一步扩展与完善，也希望阅读之人能够多提建议。

　　关键词：协议测试；互操作性测试；计算机网络协议

　　1、引言

　 　随着网络以及通信技术的快速发展，网络更加普及，协议测试也显的越来越重要。协议测试技术的目的就是保证通信协议正确实现以及确保不同的通信设备之间可 以正确互联。对于商业测试而言协议测试技术非常具有实用价值，得到了广泛的应用。目前除了一致性测试有国际标准外，其他测试技术还未有国际标准。故此协议 测试技术的理论化、标准化工作有待深入研究。本文在介绍协议测试技术的基础上重点探讨一致性测试和互操作性测试以及它们之间的关系。

　　2、协议测试技术介绍

　　目前在测试领域测试方法分为3种：白盒测试、黑盒测试和 灰盒测试。白盒测试通过每条语句至少执行一次来全面检查整个程序代码，而黑盒测试只测试软件外部可以观察到的行为，不涉及程序的内部结构。白盒测试的测试 能力非常强，但是过程过于复杂，对被测软件要求也很高。黑盒测试只关心被测软件的输入和输出，测试能力虽然弱了些，但是测试过程本身相对简单，对被测软件 要求也无特殊要求。灰盒测试是将白盒测试和黑盒测试结合起来形成的一种测试方法，吸收了两种方法的优点。在通信测试中，协议测试仅仅是一种黑盒测试，它并 不检查协议代码，而是按照协议标准，通过控制观察被测协议实现或系统的外部行为对其进行评价。协议测试技术包括四种类型的测试：①一致性测试 （Conformance Testing）：检测协议实现本身与协议规范的符合程度；②互操作性测试（Interoperability Testing）：基于某一协议检测不同协议实现间互操作互通信的能力；③性能测试（Performance Testing）：检测协议实现的性能指标（如数据传输速度、连接时间、执行速度、吞吐量、并发度等）；④健壮性测试（Robust Testing）：检测协议实现在各种恶劣的环境下运行的能力（如注入干扰报文、通信故障、信道被切断等）。

　 　在过去的通信发展中，国际标准组织主要关注协议一致性测试，故此一致性测试开展最早，也形成了很多有价值的成果，而其他三种测试仅仅作为商业测试的手段 来满足具体测试者的需求。90年代国际标准化组织ISO制订的国际标准ISO/IEC 9646（ITU-TX.290系列）——“OSI协议一致性测试的方法和框架”，描述了基于OSI七层参考模型的协议测试过程、概念和方法，相应标准见 表1。另外，还有ETSI ETS 300 406“测试和规范方法；协议一致性测试规范”。

　 　随着通信技术的发展，新的协议越来越复杂，协议一致性测试工作遇到了很多困难。在实 际测试中，一致性测试通过并不能保证互操作测试一定可以通过。所以互操作性测试相关研 究越来越受到重视。虽然互操作性测试目前还未制定国际标准，但是中国以及ETSI、ITU-T 、ISO等国际组织都开展了相应的研究工作，具体成果有：①ETSI TS 102 237“互操作测试方法和途径”；ETSI TS 202 237“互操作测试方法”；②ITU-T正在完善ITU-T Z.itfm“互操作测试框架和方法”；③ISO正在许多协议簇中增加互操作测试；④“中国通信行业标准YD/T1521-2006路由协议互操作性测试 方法”该标准主要是信息产业 部电信研究院、华为技术有限公司、中兴通讯股份有限公司参与起草，由中华人民共和国信 息产业部发布。

　　互操作测试、性能测试和健壮性测试的研究对于商业测试具有非常实用价值，得到了广泛的 应用，然而其理论化、标准化的工作还有待深入研究。

　　3、协议一致性测试与互操作性测试技术

　　一个协议实现或系统能否通过一致性测试和互操作性测试是它能否与其它实现成功互连互通 的重要保障，因此对协议实现进行一致性测试和互操作性测试是非常重要的。

　　3.1 协议一致性测试技术

　　ISO/IEC 9646对一致性定义如下：“一个一致性的实现应满足静态一致性需求 和动态一致性需求，并与协议实现一致性声明（Protocol Implementation Conformance St atements，PICS）中所声明的功能相符合。” 一致性测试主要是确定被测实现（Implement ation Under Test，IUT）是否与标准规定一致。通常利用一组测试案例序列，在一定的网 络环境下，对被测实现进行黑盒测试，通过比较IUT的实际输出与预期输出的异同，判定IUT 是否与协议描述相一致。一致性测试拓扑结构如图1。表现一致性测试的重要特征是：①被测系统（System Under Test，SUT）或被测实现定义测试边界；②测试由一个能够完全控制SUT和拥有观察SUT所有通信能力的专门测试系统实施；③测试在开方式标准接口上 执行，也就是说接口指定在协议级。

　　根据ITU-T X.290系列ISO/IEC-9646定义的一致性测试方法，测试标准主要包括五部分：①测试套结构和测试目的（Test Suite Structure and Test Purposes，TSS&TP）：由相关标 准而得。它们为每个测试提供一个非正式易读的描述，集中于测试意图而不是如何实现。他 们通常在协议层上定义；②抽象测试套（Abstract Test Suite，ATS）：是测试例的集合，测试例通过测试描述语言（如 TTCN、XML）描述；③协议实现一致性说明（PICS）：PICS说明被测实施的要求、能力及选项实现的情况；④协议实施附加信息（Protocol Implementation eXtra Information for Testing，PIXIT）：PIXIT提供测试必须的协议参数（例如特殊地址、计时器值等）；⑤可执行测试套（Executable Test Suite，ETS）：可以通过ATS简单快速的生成。协议一致性测试采用的工作流程如图2，其测试步骤如下：①静态测试：测试仪读取 PICS/PIXIT文件并根据协议标准进行静态测试，检查IUT参数说明 是否符合标准。②动态测试：测试仪根据PICS/PIXIT文件和ATS生成ETS，然后执行ETS对IUT进行激励/响应 测试。具体采用的测试类型包括：本地测试方式、分布式测试方式、协同测试方式和远程测 试方式。③测试报告：对测试执行产生的测试记录文件进行分析，按照测试报告描述规格生成一致 性测试报告。协议一致性测试报告记录了所有测试案例的测试结果：成功（PASS）、失败（ FAIL）、不确定（INCONCLUSIVE）。 

　　3.2 协议互操作性测试技术

　　目前互操作性测试没有标准定义，通常用于研发阶段多厂商准正式测试或者运营商的选型测 试中。互操作测试评估被测实现与相连接相似实现之间在网络操作环境中交互能力，并且完 成协议标准中规定的功能，从而确定被测设备是否支持所需要的功能。

　　在互操作测试中，被采用最多的形式是测试单位选择经一致性操作和互操作测试认可设备来 与被测设备进行互操作测试。互操作性测试拓扑结构如图3。表现互操作性测试的重要特征 是：①认可设备（Qualified Equipment， QE）和被测设备（Equipment Under Test，EUT） 来自不 同厂商（至少不同生产线）共同定义测试边界。二者可能是终端设备、网络设备或者应用软 件，也可能是一个单独设备或者若干设备组合；②互操作性测试基于用户期望的功能，并由用户控制并观察测试结果。用户（Test Driver） 可以是人工操作也可以是软件程序；③互操作性测试在功能性接口上执行和观察，也就是说接口没有指定在协议级而是功能级上 。这些接口包括人机接口（Man-Machine Interfaces，MMIs）、协议设备接口（protocol ser vice interfaces）、应用程序接口（Application Programming Interfaces ， APIs）。

　　互操作测试过程除了测试使用规范、测试设备和测试驱动与一致性测试不同以外，其它基本 与一致性测试类似。互操作测试过程主要包括两个部分：①开发互操作测试规范过程，通常由互操作者根据测试功能要点进行制定。该过程主要包 括以下内容：指定抽象测试架构、准备互操作特征声明（Interoperable Features Statemen t， IFS）草稿、声明测试套架构（Test Suite Structure， TSS）、写测试目的、写测试例、IF S定案；

　　②测试过程，主要包括以下内容：准备测试、具体测试、测试报告。

　　3.3 协议一致性测试与互操作性测试的比较

　　一致性测试和互操作测试都是测试协议实现重要而有效的方法，在某种程度上可以相互验证，但二者并不是完全一样，主要差异在于：

　　①测试目的不同，一致性测试是确定被测实现是否与标准规定一致，而互操作测试是确定被 测设备之间基于某一协议的交互能力；②测试对象不同，一致性测试的对象是设备或者系统。而互操作测试的对象是设备；③测试级别不同，一致性测试是在协议 级．而互操作测试是在功能级；④测试效果不同，一致性测试适用所有协议实现，而互操作测试主要适用于被测设备。

　　实际测试中，一致性测试通过并不能保证互操作测试一定可以通过。具体原因表现在三方面 ：①标准方面：标准中错误与含糊内容；标准本身的兼容性问题；②实施方面：人为错误（如编程错误）；对于标准理解不同；标准本身允许不同选项；③技术方 面：通信网络使用不同流量策略；设备兼容性问题；设备配置问题。 

　　互操作测试可以证实被测系统中不同设备之间的互操作能力，但不能证实设备是否符合标准 。一致性测试可以证实设备是否符合标准，但不能保证设备之间可以互相通信。故此，互操 作测试不可能替代一致性测试，在互操作测试前必须首先进行一致性测试。一致性测试和互 操作测试是互为验证、互为补充的关系，只有把两者合理地结合才能完成完整的协议测试。

　　4、结束语

　　自90年代协议测试技术发展以来，协议测试技术得到了广泛的应用。随着计算机网络发展特 别是开放型异构网络的迅猛发展，协议测试理论和技术的研究将更加重要。协议测试并非本 文描述的那么简单，在实际测试中需要针对测试例研究测试算法和理论。我认为随着互操作 性测试优越性的体现，互操作性测试的研究将越来越重要。基于一致性测试与互操作性测试 的关系，将二者结合进行协议测试也有待进一步研究。

　　问题

　　在软件行业发展的初期，软件项目中最棘手、最紧张的时刻就是集成。单独能工作的一些模块被组装在一起，系统整体却常常失败，而且很难找到失败的原因。

　　解决办法

　　解决办法的关键在于更为频繁地进行集成。

　　它给项目带来了完全不同的感觉。项目的可见性变得好了很多，因为问题能够更快地检测出来。引入缺陷和发现缺陷之间的时间间隔变短，就更容易发现缺陷，您可以很容易地看见改变了什么，以方便找到问题的根源。当它与良好的测试程序配合时，可以大大减少缺陷的数量。结果是，开发者在调试上花的时间减少了，在增加功能上花的时间更多了，他们相信自己是在一个坚实的基础上开发软件。

　　持续集成意味着：

　　● 所有开发者都先在他们自己的工作站上执行私有构建，然后再将他们的代码提交到版本控制库中，从而确保他们的变更不会导致集成构建失败。

　　● 开发者每天至少向版本控制库提交一次代码。

　　● 集成构建每天在一台独立的计算机上进行多次。

　　● 每次构建都必须 100%通过测试。

　　● 生成可以进行功能测试的产品（如 WA R、配件、可执行程序等）。

　　● 修复失败的构建是优先级最高的事情。

　　● 某些开发者复查构建生成的报告，如编码标准报告和依赖分析报告，寻找可以改进的地方。

　　最佳实践

　　为缺陷编写测试

　　当缺陷被发现时，找出并隔离有问题的代码，为了修复缺陷，我们基本上需要破坏测试，先编写一个会失败的测试用例，然后不断执行这个测试（在修复缺陷的过程中），直到测试不再失败为止。

　　让组件测试可重复

　　数据库对于测试来说是相当沉重的依赖关系，所以您有两种选择：要么尽量地进行模拟，在尽可能长的时间内完全避免使用数据库，要么使用数据库并承受其开销。实现这种测试最容易的方法是使用某种xDbUnit 这样的数据库填充框架（如

　　针对.NET 的NDbUnit、针对 Java 的DbUnit 、针对 Python 的PDbSeed ）。这些框架将数据库的数据集抽象到 XML 文件中，然后为开发者提供细粒度的控制，即在测试过程中如何将这些数据填充到数据库中。

　　导读：Scrum团队以小著称，团队中一般只有一到两名测试人员，那么这一两名测试人员在Scrum团队中又是如何开展测试工作，起着什么样的作用呢？

　　Scrum敏捷开发有一个明显特征就是重团队，轻部门，每个团队里面包含了开发、设计、测试各种角色，Scrum团队以小著称，团队中的测试人员一般只有一到两名。

　　在传统的瀑布式开发 中，测试人员经常因进入测试阶段的条件不满足而需要较长的等待。而在Scrum敏捷开发中，测试人员需要尽可能早的开展工作，“等待”在Scrum开发的测试中已属一种错误概念。

　　测试人员应具备三方面的能力：编码，测试和分析。不同的阶段对测试的要求不同，在功能测试中偏重编程能力，在系统配置测试中偏重分析能力，Scrum团队中的测试人员需要将这三种能力融会贯通，才能适应迭代过程中的诸多变化。

　　测试是软件开发中必不可少的一部分，那么Scrum团队中测试人员又要如何开展测试工作呢？

　　首先，测试人员要尽可能早地开始测试，不要等待到功能完全做好才开始。在产品开发的过程中，新需求和新功能在迭代中不断涌现，每次迭代结束都会产生一个可工作的软件，测试人员不能等到所有迭代结束之后再开始测试，而应该尽早开始进行测试。

　　其次，测试人员要尽可能多地采用自动化测试。敏捷项 目初期，产品停留在初步设计中，产品功能不多，复杂度小，手动测试就可以保证质量。而到了中后期，因不断有新需求、新功能的加入，产品复杂度显著增大。若 仍然采用手动测试，恐怕难以覆盖产品的各个功能、非功能点，而且手工测试在面对功能诸多的产品时，就会暴露出易遗忘的缺点。因此，可以用自动化测试来提高 工作效率。

　　然后就是，测试人员要学会做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发人员。

　　最后要强调的是 ，测试人员需要转变测试等待开发的思想。测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有时候，测试人员可以成为开发人员的后备力量。当团队中需要更多的人编码时，测试人员应该站出来担当其职。

　 　开发和测试是相辅相成的。一旦基本验证测试通不过，那就说明产品违反了最初客户定义的需求，也就不能够提交。如果功能测试通不过，那么测试人员要及时与 开发人员沟通。如果是缺陷，则在每日站会中提出；如果不是，那么继续下一项工作。这个过程充分体现了Scrum敏捷开发所提倡的团队交流与合作机制，也是 体现了测试人员对于整个开发工作的重要作用。

　　摘要

　　桌面应用程序与浏览器端的自动化测试都已经历了十年的发展，无论是从工具上还是项目管理方 法论上都已经趋于成熟。而移动设备端应用程序的自动化测试近两年才刚起步，似乎一切尚处于探讨与研究阶段。但我们似乎已经看到其爆炸性的需求增长势头。可 以从这两方面着眼分析：其一，移动应用从数量上和逻辑复杂程度上的增长，以及产品发布周期的紧缩，使得快速回归测试迫在眉睫；其二，安卓系统的开放性造成 硬件厂商百家争鸣的局面，设备款式之多，迫使移动应用的兼容性测试提上日程。纵观当前智能手机两 大主流阵营iPhone与Android，似乎安卓应用开发商与设备制造商更能体会兼容性测试的切肤之痛。鉴于此，并结合传统桌面系统上的自动化测试经 验，我们在此探讨基于Android平台应用程序的关键字驱动自动化测试的可能性，并摸索一条适合在移动应用开发过程日新月异的现实情况中切实有效的实现 和实施自动化测试的路子。

　　理论基础

　　在传统的桌面应用软件与浏览器端应用的自动化测试领域，已经有相当成熟的工具可供用户选择，例如商业工具HP QTP，IBM Robot/RFT，Borland SilkTest等；开源工具如Selenium，Watir等。剖析这些工具，它们似乎都有着相同的功能结构：

　　● 对被测应用界面对象/界面元素的捕获与识别，并对其进行管理与操作；

　　● 对于测试脚本的编辑功能与语法解析功能；

　　● 对于测试数据的组织与管理；

　　● 对于脚本执行结果的分析与输出；

　　如果细说，还可以牵扯到如脚本录制功能，插件管理功能，与测试管理工具、缺陷跟踪工具的整合等内容，涵盖面相当广泛。但所有这些都是为了一个目的：模拟测试人员行为，达到功能性回归测试的目的。本文尝试从以下最关键的几点来分析自动化测试工具的核心构成部分。

　　1、关键字驱动

　　关键字测试的主要思路是以面向对象的方式来管理被测应用的对象、对象的相关操作、测试数据以及这些测试数据之间的组合关系。关键字驱动是自动化测试中行之有效的方式，它可以帮助测试工程师更方便的维护测试脚本、构建复杂的业务逻辑测试用例、并节省手工测试的执行时间（尤其是在回归测试阶段）。关键字驱动主要由以下三种元素构成：

　　1）被测对象，即被测应用界面上的元素；

　　2）针对这些对象的操作，如点击（按钮）、填充（文字）、选择（单选框/多选框）；

　　3）以及基于这些操作的数值；

　　上述三种元素可以描述为以下表格：

　　或者以面向对象的文法表述为：

　　对象.操作（值）

　　该语句是关键字驱动脚本的构成基础。

　　2、对象库

　　对象库是用于储存被测应用程序界面对象（界面元素）的地方。它是关键字驱动测试工具的关键点。有了它，用户可以更容易的维护被测对象、更快速的构建测试脚本。它是如何做到这些的呢？让我们看看下面的结构：

　　● 查找软件的性能瓶颈

　 　谁都希望自己的软件性能比别人的高，所以我们不停的查找性能的瓶颈，通过代码分析，架构调整，采用新技术等，不断对产品进行优化。我们希望能够不断发现 性能瓶颈，不断消除瓶颈，使得软件的性能越来越高，测试过程作为验证性能是否达到设计要求的一个环节，采用测试程序对软件的整体或某个模块不断测试、不断 采样、不断加压，验证软件的性能表现，通过对测试结果的分析、对比等，判断是否存在某个性能瓶颈。所以性能测试的第一个目的是发现性能瓶颈，发现问题，才 有解决问题的可能性。

　　产生性能的瓶颈可能外部因素，例如网络、CPU等，对于产生性能瓶颈的外部因素，实际上是软件对这些资源的使用低效。也可能是内部因素，包括实现的算法选择、共享资源的访问、模块之间的调用和配合等。

　　● 查找性能异常

　　一个软件理想的性能表现是，在一定的环境下，性能能够在一定的水平上保持较大的压力区间，当压力超过一定的值以后，性能才下降，这个压力区间越大，代表软件能够支持的系统规模越大，性能指标具有更强的竞争力。

　 　但是事情有时候并不像我们期望的那样完美，总是会有那么一个点或者是一个小的区间的性能明显低于它的邻居的性能，在整个性能曲线上，看起来非常的不完美 和不合群，这些点或者是小的区间，就是整个软件性能表现异常的部分，如果存在这样的部分，对于软件来讲，已经不是性能瓶颈的问题了，应该定义为软件性能的 bug。

　　所以软件性能测试的另一个目的就是检验软件是否存在这样的点或区间，软件的性能表现不太正常。

　　● 检验性能的稳定性

　　一个软件的性能的完美表现，不仅仅是检验它的性能有多高，而是在满足系统的性能要求的前期下，这个性能是否能够稳定的表现出来，需要把这个性能表现放在时间轴上来衡量。

　　软件的性能的稳定性测试是选取性能的最优表现时的压力和配置，长时间运行测试实例，检验在这样的场景下，软件性能是否能够一直稳定在这样的最优值，并且系统的资源的占用没有增长的趋势。

　　性能其实也有稳定性测试。

　　● 提供性能参考指标

　　性能测试首先是发现产品的性能异常，也就是前面提到的三个性能测试目的。对于一个产品，最终的目的还是展现给用户，所以性能测试的其中一个目的就是整理出一份全面的性能测试报告。

　　性能测试报告中能够体现出软件的主要使用场景的性能表现。通过这份性能测试报告，支持人员能够给用户推荐产品的合理配置，用户可以作为系统建设的参考等。

　　● 系统容量测试

　 　我们都知道，当系统的压力达到一定值后，软件的性能会开始下降。那么对于性能开始下降的这部分结果是不是就没有参考价值了呢？我们看一个一般的用户需 求：“正常情况下满足10000用户在线，峰值能够满足15000人在线，响应时间＜1秒”。对于这样的需求，整个系统的设计，一定是按照10000用户 来设计的，这个时候的性能可以理解为系统的最优性能。如果按照15000用户来设计最优性能，投入产出比就会小。当然前提是能够满足用户的响应时间的要 求。

　　系统容量测试，实际上也是给技术人员或用户一个性能参考。