java接口测试(java后端面试题)
这篇文章给大家聊聊关于java接口测试，以及java后端面试题对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
java测试的类型是什么它的联系与区别
java测试的类型？
黑盒测试？白盒测试？灰盒测试？
白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（STatement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。
·判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖（DECision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
·条件覆盖在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（ConDItion Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是独立的。
黑盒测试
也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
黑盒测试的优点
1.基本上不用人管着，如果程序停止运行了一般就是被测试程序CRASh了
2.设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因
黑盒测试的缺点
1.结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
2.没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
3.就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的tEStcase造成的问题。这些在堆的问题中表现的更为突出。
灰盒测试介于白盒测试与黑盒测试之间
接口测试方案怎么写
问题一：如何做接口测试对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例；
用例设计：
1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能
2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果
3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑
4：进行容错及健壮性测试
5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
6：对于一些接口，需要进行多线程测试
问题二：接口测试应该怎么做对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。
接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码，所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。
输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长；
功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。
逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。
问题三：软件测试方法的接口测试接口测试的英文是interface testing，接口测试测试系统组件间接口的一种测试。接口测试的好处：由于接口测试代码本身就是用junit（当然接口的类型不同，不一定是Junit来实现）来实现的，是属于自动化测试的范畴，因此必定也包含自动化测试所固有的优势。1）提高测试质量软件开发的过程是一个持续集成和改进的过程，而每一次的改进都可能引进新bug,因此当软件的一部，或者全部修改时，都需要对软件产品重新进行测试。其目的是要验证修改后的产品是符合需求的，而当没有自动化测试代码时，往往会由于各种各样的原因，回归不充分，导致bug遗漏。2）提高测试效率软件系统的规模越来越大，功能点越来越多，开发人员的自测或者测试人员的人工测试非常耗时和繁琐，势必导致测试效率的低下，而自动化测试正好解决这些耗时繁琐的任务，在对外接口功能不变的情况下，达到了一次编写，永久使用的效果。3）提高测试覆盖通过手工测试很难测试到一些更深层次的异常和安全的问题，通过一些辅助的一些测试工具，能分析出代码的覆盖率，通过覆盖率的提高来提高测试的深度。4）更好地重现软件缺陷由于每次执行都是相同的代码，一旦代码出错，必定回归出错5）更好定位错误由于接口测试是一种自下向上的测试，因此一量出错，非常容易定位出错，不向系统测试那样了，一旦有Bug，需要几层验证之后才能确定出错位置6）降低修改bug的成本接口测试基本和开发人员的编码平行工作，因此发现问题会比系统测试早很多，因此减少了修改bug的成本。7）增进测试人员和开发人员之间的合作关系，测试工程师为了更好地开展工作，需要对开发技术有深入的理解和实践，有了与开发工程师更多的交流。8）降低了项目不能按时发布的风险由于接口测试很早就介入，在提交给系统测试前对项目代码的核心模块已经做了详尽的测试，必定加速系统测试的时间，由此来保证项目的按时发布。9）提升测试人员的技能。做接口测试必须了解开发人员的开发流程和一些开发技能，也需要了解测试工具的一些使用方法和一些测试思想，提升了测试人员的技术附加值，提高了自身的竞争力。10）促使项目开发过程的规范化要进行接口，需要完善的文档进行保障，没有测试文档，接口测试将寸步难行，接口测试将增加开发过程规范化产出，而规范化产出也保证了项目质量。
问题四：如何做好接口测试？ sgbtmy：基于selenium的自动化框架开发，我主要是想问一下，你的框架除了前台的自动化，后台的数据的测试是否集成在你的测试框架中？小刀：你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的测试用例需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。不知道是否解答了你的疑问，如果没有，请你指出，谢谢你。 tjy688：你们做接口测试的流程一般是怎么样的？小刀：接口测试的流程其实和功能测试的流程类似，因为接口测试依赖的主要对象也是需求说明书，所以，最初的流程就是参与需求讨论，评审需求。需求确定以后，开发会根据需求进行接口设计，会产出接口定义，在开发设计过程中，有能力的话，可以给出一些针对设计的建议，提高可测性，针对需求及设计，进行测试计划，测试设计，然后还需要和配管确定测试环境相关的事情。在开发完成接口定义之后，就根据需求文档及接口定义进行测试用例设计，测试用例设计主要从业务场景，功能，以及异常测试几个方面考虑。测试用例设计完成后，针对测试用例进行评审，然后，如果开发代码部分可测时，即可进入测试了，因为是部分可测，可能会使用到mock方法。已有测试代码时，就要进行测试代码的持续集成了，我们是使用hudson来进行持续集成的在项目结束后，会对每个项目进行总结。如果有问题，请指出，我们一起讨论。 xinhuayw：我想了解一下你们现在是怎样保证项目测试用例的重复运行的。小刀：对于接口测试来说，项目测试用例的重复运行首先是表现在单个测试用例的独立性方面的，也就是说，每一个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其他任何测试用例的，并且这个测试用例执行完毕后，对系统来说，也是没有任何痕迹的，这样就保证了每个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还需要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还需要做到测试用例的及时更新，在这个方面，我们是做接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须全部执行通过。 csun888：什么是接口测试，基础知识什么的讲讲吧！小刀：你好，接口可以分下面几种 1、系统与系统之间的调用，比如银行会提供接口供电子商务网站调用，或者说，支付宝会提供接口给淘宝调用 2、上层服务对下层服务的调用，比如service层会调用DAO层的接口，而应用层又会调用服务层提供的接口，一般会通过 3、服务之间的调用，比如注册用户时，会先调用用户查询的服务，查看该用户是否已经注册。而我们所要做的接口测试，先要了解是基于哪一种类型的接口测试，不同类型的接口测试方法可能是不一致的，总体来说，不管是那种类型，我们只要把被测接口当做是服务方，而把我们的测试手段当做是客户方，我们的目的就是，通过我们的测试手段，去验证服务端满足了他声明提供的功能。至于说到具体的测试方法，协议的接口测试，一般会用jmeter去测试，jmeter的好处是不用写测试代码，直接使用jm......>>
问题五：如何做好接口测试你好，个人理解的你所说的后台的数据的测试是指的是对数据的校验，不知理解的是否正确，那么根据这个理解，我的解释是，在我们框架中，增加了很多的功能方法用来帮助进行自动化脚本的编写和结果校验，其中就包括后台数据校验方法，当我们的
测试用例需要在后台进行数据校验的时候，调用这些数据校验方法即可。相当于是，前台页面操作的自动化是封装selenium的方法去操作页面，而对后台数据的校验是通过增加功能方法来实现的，可以理解为不同的两部分，但是在编写测试脚本的似乎，根据测试用例的设计，这两部分都可以拿过来使用。
问题六：怎么做接口测试，概念及常用方法小结关于接口测试做些WEB与PC/移端相关该属于客户端与WEB端通信接口测试
问题七：如何做接口测试对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例；
用例设计：
1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能
2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果
3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑
4：进行容错及健壮性测试
5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
6：对于一些接口，需要进行多线程测试
问题八：java编写接口测试DEMO 10分嗯 URLconnection或者应用 apache的开源包
问题九：联调测试方案以及测试报告如何编写？集成测试，又称组装测试、联合测试、联调测试、子系统测试、部件测试。不同的称呼而已，侧重点在于模块间接口的正确性、各模块间的数据流和控制流是否按照设计实现其功能、以及集成后整体功能的正确性。写集成测试方案的建议：1）依据SRS和集成测试计划来编写，无冲突2）阐明测试对象3）划分测试层次4）确定测试策略5）根据策略细化测试项6）根据系统的需求，可能需要接口分析写集成测试报告的建议：1）集成测试概述2）集成测试时间、地点、人龚）集成测试环境4）总结和评价5）遗留问题报告6）附件以上只是本人对编写集成测试方案和集成测试报告的一些建议，具体内容可以根据项目进行补充，具体格式可以自由发挥。
问题十：如何写测试用例 java测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。
测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例编写准备
1
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2
根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
测试用例制定的原则
1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
用例覆盖
1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。
6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
7可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
8可移植性：在不同操作系统及硬件配置情况下的运行性。
测试方法
1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
测试用例的填写
1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。
Jacks:Java兼容性测试,开放源码之路
什么是 Jacks？ Jacks测试套件检查 Java编译器是否符合 JLS（Java语言规范）它由大量小测试案例组成每个测试都侧重于 JLS中特定的部分 Eric Blake为 Jacks项目作出了很大贡献他从面向细节领域描述了这种类型测试的好处通过生成带有指定编译行为的小测试案例然后将每个案例的执行自动化编译器作者或调试者可以快速找出 Java源码到字节码转换中存在的问题
开发 Jacks背后的概念是要简化对多编译器或多编译器配置所运行的测试（例如对上两个发行版的 Jikes和 Javac的 JDK发行版所进行的一组测试）如果手工进行您必须重复地设置环境变量然后根据所期望的结果来检查测试结果而通过使用 Jacks只需要更改到存放测试的目录调用 Jacks框架然后表明应该使用哪个编译器配置
Sun没有履行对 Java开发者所做的承诺激发了 Jikes小组对 Jacks项目的设置和运行 Sun再三声明它会把 Java JCK（Java Compatibility Kit）和相关 Java技术交到一个标准主体的手中但因为这还没有实现从事 Java项目的开发者就不能使用 JCK来对日常的开发进行回归测试当面对由于不合理的许可证限制而导致的代码人为不足时他们倾向于用新的更完善的系统来替换旧系统这就是发生在 Jacks上的故事（尽管 Jacks由 developerWorks主持它受 GPL而非 IBM Public License约束）
使用 Jacks
Jacks是以 Tcl编写的因此需要确保拥有 Tcl（需要版本来确保具有 tcltest扩展和 Unicode支持这两者都是 Jacks所必需的）可以下载用于 Windows的安装程序和用于 Red Hat x的 RPM也可以更方便地从源代码中构建如果您不知道到什么地方下载请参阅本文稍后的参考资料部分如果使用的是 Red Hat很可能已安装了 Tcl
安装了 Tcl后需要从 CVS取出 Jacks然后通过将编译器路径名包括在要测试的编译器的 Jacks _setup配置文件中来配置 Jacks对于每个希望支持的配置都需要一个 _setup文件例如 Jacks带有 javac_setup文件需要编辑该文件来为 javac设置路径 Eric Blake说最困难的部分是断定如何测试 Jikes因为我在环境中已设置了 JIKESPATH但我想出了要在 jikes_setup配置文件中更改什么内容一切都很顺利
从 CVS模块中取出 Jacks源代码
setenv CVSROOT:pserver:anoncvs@:/usr/cvs/jikes cvs login
paswsd anoncvs
cvs checkout jacks
可以对数量不限的编译器或编译器配置使用 Jacks要除去某一编译器的配置只需要删除其 _setup文件
从 CVS中取出源代码后就需要在路径中包括顶层 Jacks目录这样才能运行 Jacks shell脚本为谨慎起见最初运行 shell脚本时应该不带任何自变量以确保每项都经过正确配置
% jacks
如果一切正常将看到 Jacks脚本所接受的命令行选项的清单如果收到错误请检查在路径中是否能找到可执行文件 tclsh Windows用户需要直接运行 tclsh并将 jacks tcl自变量在一般标志之前传递给它还应该考虑安装 Cygwin UNIX兼容性层这样象 Unix用户一样您就可以使用提供的 shell脚本来运行 Jacks了下面的指令假设您使用的是 shell脚本
对于测试示例需要使用 Jikes编译器来运行给定子目录中的所有测试命令如下
% cd tests/jls/packages/package declarations/unnamed packages
% jacks jikes
开发新的回归测试
开发新的 Jacks测试案例非常简便照 Eric Blakes的话说基本上您设计一个简单的源文件来测试问题将它放在特定的 Jacks格式中然后运行 Jacks如果编译器结果与所期望的结果不一样它打印出错误这里是 Jacks主页上教程中有关添加新测试案例的一例
// File SynchronizedInterface java public synchronized interface SynchronizedInterface{}使用 Jikes编译时生成以下错误
% jikes SynchronizedInterface java
Found semantic error piling SynchronizedInterface java:
public synchronized interface SynchronizedInterface{}
<>
*** Error: synchronized is not a valid interface modifier
如果很快看一下 JLS的第节会发现 synchronized在该上下文中不是合法的修饰符如果尝试使用早期发行版 JDK中的 Javac编译器来编译相同的类则不会生成错误（该错误在稍后的发行版中得到修正）
% javac SynchronizedInterface java
现在既然问题得以重现可以通过以下步骤来对 Jacks测试套件添加回归测试案例
了解应该将测试案例放在哪个目录中
编写回归测试
在 Jacks框架中运行新测试
tcltest框架中回归测试的格式是
tcltest::test NAME DESCRIPTION{ MANDS
} EXPECTED_RESULT
这是 JLS第节中的第一个测试所以 NAME是
该测试案例在目录 tests/jls/interfaces/interface declarations/interface modifiers（位置基于 JLS节的名称）中
DESCRIPTION可以是任何想要的内容
MANDS一节包含了所有 Tcl命令但大多数情况只需要 Jacks中的 saveas和 pile方法
saveas命令使用两个自变量文件名和将保存到文件中的数据
saveas SynchronizedInterface java \{public synchronized interface SynchronizedInterface{}}pile命令使用任意数量的命令行自变量并将它们传递给 Java编译器它将返回 PASS FAIL或 WARN来表明编译器的退出状态
EXPECTED_RESULT是希望从 pile命令获得的结果
在该接口示例中编译应该不成功因此完整的回归测试应该类似于
tcltest::test{should generate error on synchronized interface}{ saveas SynchronizedInterface java \
{synchronized interface SynchronizedInterface{}}
pile SynchronizedInterface java
} FAIL检验结果
运行测试并检查结果是完全自动的因此可以真正地休息一下看看出现的结果 Jacks框架在测试目录中递归下降运行它所找到的所有测试
如果一切正常就不打印任何消息如果测试失败将打印有关失败的描述如 Mo Dejong在清单中显示的那样该例演示了 Javac中因为第一个构造器调用第二个构造器第二个又调用第一个所造成的错误 JLS规定这是非法的（第节）因此如果检测到这种情况 Java编译器必须用信号通知该错误
让我们看看 Jikes对于同一测试案例是如何做的在清单中我们将使用 Jacks中的一些特性可以让您将模式作为 Jacks脚本的第三个自变量传递将跳过那些名称与模式不匹配的测试案例在这个小案例中模式就是测试案例的名称在该例中请注意我们所感兴趣的那个测试案例是如何通过的其它测试案例是如何跳过的上面的输出表明在 Javac编译器中找到的错误在 Jikes中并不存在
尽管人类可读的结果非常有用但在您有许多要处理的测试案例的情况下它们很快就会变得非常难于管理 Jacks最近庆祝了一个重要的里程碑现在它包含了逾个 JLS独立测试案例有了这么多的测试案例没人能够记住在某一时刻哪些案例通过了哪些又失败了但不用害怕 Jacks包括了一系列记录和测试结果分析特性能够随时间跟踪测试结果这是一项关键特性因为它为 Java编译器开发者提供了一种跟踪错误修正状态和可能回归的方法
如何编写 Jacks以及为什么使用 Tcl
当实现例如 Jacks这样的测试套件时脚本语言是个很自然的选择而使用 Tcl也有以下几个原因
Tcl是开放源码因此在今后的一段时间内仍然会继续存在
易于安装不需要编译脚本
易于读写脚本语言远比 C/C++更易于掌握
易于使用字符串处理和常规规则表达式特性
高度可移植在比 Java多的平台上运行
过去十年中成功地在几千个组织中使用过
具有讽刺意味的是它曾是 Sun项目:)
Mo DeJong说 Jacks最了不起的一个特性是自生成文档在 Jacks主页上您可以找到到达测试案例索引页面的链接这些页面列出了所有可用的测试案例它以几种有用的方式进行索引和交叉引用可以方便地通过名称查找测试案例也可以通过现有测试来发现某个 JLS章节的内容是多么完善 Tcl高度动态的语言特性使自记录测试案例的实现更容易
到目前为止 Jacks支持以下几种 Java编译器
JDK（和也可以使用但已经过时了）
Jikes IBM的开放源码 Java编译器
Kaffe利用了 Kopi编译器
GCJ到 gcc的 Java前端
随处改进 Java编译器
Jacks最初着重只为 Jikes项目提供编译器测试原来的目标是要替换为 Jikes创建的自制测试系统但这个初衷由于太难建立和使用而被放弃了人们很快发现如果测试套件变得更常规一些就可以为其它 Java编译器项目使用这样将会导致已提交测试案例在数量上的增加至少让其它 Java专家评估一下正确性测试案例也并无大碍
Jikes项目自然大大利用鉴了 Jacks但 GCJ和 Kopi编译器项目又如何呢？Tom Tromey Red Hat的常任 Java领导者已经意识到了 Jacks开发对于 GCJ项目的作用 Jacks对于 GCJ项目已经有了实际意义每当我在进行前端编译器更改时就会运行 Jacks并定期使用 Jacks查找 GCJ中的错误我发现添加测试是桩小事框架非常易于使用考虑也很周到
lishixinzhi/Article/program/Java/Javascript/201311/25464
END，本文到此结束，如果可以帮助到大家，还望关注本站哦！