毕业设计外文文献—面向大众的Java性能测试.docx

《毕业设计外文文献—面向大众的Java性能测试.docx》由会员分享，可在线阅读，更多相关《毕业设计外文文献—面向大众的Java性能测试.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、附录A外文翻译一原文局部Java Performance Testing For The Masses Be. Petr StefanAnalysisTo improve the process of performance testing by microbenchmarks, we want to understand the present testing workflow with its strengths and weaknesses first. The data about contemporary and past workflow patterns can be obtai

2、ned in several ways: scanning sources of open-source projects,surveying open-source developers, surveying software companies,analyzing questions about performance on developer websites. Open-source projects allow everyone to view the irsource code an dinvestigate the used frameworks in detail. This

3、allows us to collect the relevant data about how the performance testing frameworks are used in many applications. The major platform for open-source projects is GitHub l, but GitLab2, BitBucket3 or SourceForge4 also have a significant user base. Our choice is to use the biggest platform available.

4、GitHub provides a web API to find projects matching given criteria, so projects using the Java language can be program matically discovered and saved for further processing.The results of a developer survey depend on the willingness of the developers to answer the questionnaire. A crucial part is to

5、 target only those developers who made or altered some of the performance tests. They can provide sensible results about how they are testing the performance, how are the results processed, why were the used tools chosen, etc. The questionnaire needs to be fairly short in order not to take too much

6、time from the developers. We made a small survey to complement our knowledge about the open-source testing and to support the results from the GitHub projects.In case of a company survey,we do not believe that we could entice more than a few software corporations to provide meaningful responses with

7、 quality results to meet the demands of this text. Similar imprecise results are expected from analyzing questions on Q&A websites such as StackOverflow5, where the quality differs extensively as shown by paper 11. Thus these two types of analysis are not pursued further.A serious question concerns

8、the validity of our results on a wider scale if proprietary code is omitted. We guess that the proprietary code could be slightly more tested, but it is hard to get real evidence for comparison. Open-source software 佳实践。直接在移动设备上运行，但它可能无法在最新版本的Caliper上运行。 将Caliper包含到工程中的通常方法是通过Maven依赖项。编译之后，由提供的 类启动度

9、量。结果自动上传到web归档文 件，并以JSON格式保存到本地文件系统。整个测量时间由框架本身控制。Caliper 的Maven依赖项片段如清单1.4所示。ContiPerfContiPerfl6是一个实用程序，用于编写类似于常规单元测试的性能测试。性 能测试是JUnit框架测试的扩展，同样的代码可以用于这两种目的。受支持的注 释可以定义度量属性和对结果的期望。每次调用度量值都会生成一个带有静态数 据可视化的HTML报告，原始值可以以CSV格式导出。该设施是在2010年至 2015年间开发的。从那时起就没有任何活动的迹象。清单1.5中是一个简单的 ContiPerf基准测试。该工具可以很容易地

10、与Maven构建系统集成。在测试目标 上执行框架的依赖项片段如清单L6所示。JapexJapexl7是另一个使用类似JUnit框架的哲学编写微基准测试的工具。但是 Japex并不是JUnit的直接扩展。测试套件配置在XML文件中定义，输出包括带 有图表的HTMLreports和带时间戳的XML结果。对于每个经过测试的算法，都 必须存在一个单独的Java“驱动程序类”，包括带有控制方法（如prepare、预热、 run或finish）的代码。这个工具是在2005年到2011年开发的，现在似乎被抛弃 了。甚至工程网站也无法访问。一个包含两个算法 （XDriver, YDriver）和两个测试用例（

11、具有不同参数）的测试套件的例如配置是 presentedinlisting 1.7o测试可以由Maven插件执行，Maven插件可以作为依赖项 添加到pom.xml文件中，如清单1.8所示。JMHJMH18是一个用于编写和分析微基准测试的Java工具。它是Open JDK工程 的一局部，由Oracle公司支持。性能测试与JUnit测试类似，只是使用了一组 不同的注释。清单1. 9显示了一个例如基准测试。测试配置在运行时可以使用注 释或命令行参数进行高度定制。推荐的基准测试工程是从JMH Maven原型创立 的。此过程设置适当的依赖关系，并允许使用所有测试和WH代码构建一个自包 含的JAR包。这

12、对于在单独的计算机上进行测量是有用的。结果可以保存为人类可读的文 本或机器可读的格式之一，CSV、SCSV和JSON。来自可选JVM分析器的第三方数 据可以在 darymetricsintotheresults 上包含 assec。可 以使用 acustom mainmethod和Java API来调整框架，但是灵活性和简单的统一用法将会丧失。 该工程始于2013年，并一直在积极开展。一个用户社区为Gradle、Jenkins、 IntelliJ IDEA和其他工程创立了许多插件。development has some specifics 12 compared to commercial

13、closed source development. The developer team of an open-source project is mostly distributed, without personal contact, and the contributors select the features they want to work on depending on their preferences and skills. They also have more reviewed code,better modularity,faster releases of min

14、or versions and more unified coding standards. Traditional development tends to happen in centralized teams lead by the project managers with precise design, good documentation or a fixed schedule of releases. There is no data for direct comparison of overall performance for these two types of proje

15、ct development.To understand the concept of modern tools for unit and performance testing, the representatives of the most used frameworks in the industry are presented with brief description and a usage example.Unit Testing of FunctionalityThe most important aspect of every program is its correct f

16、unctionality. Programs giving wrong results or crashing could be very harmful in some cases, not just useless. Unit testing can prevent these situations by taking every piece of code and testing its outputs for common and corner cases of inputs. The advantage of this approach is that the tests are e

17、xecuted for every new change in the code, so the bugs introduced in these changes are found instantly. Unit testing became popular and formed a standard for most projects.With the unit testing movement other projects appear to help developers keep code correct ness in mind. Most notably there are th

18、e continuousin tegration(CI) servers, which usually build the code after every push to a remote repository and execute the test code. The responsible developer is notified about failures and further actions can take place as well, for example automatic deployment is blocked. Popularrepresentativesar

19、eTravisCI6,AppVeyor7 orJenkinsCIServer8.Only two existing unit testing frameworks for Java from the list became more popular-TestNGandJUnit. The following sections give a brief overview of both of them.JUnitJUnit9 is probably the most popular unit testing framework ever* The original idea of xUnit f

20、rameworks comes from SUnit (Smalltalk unit testing framework), but the most popular representative is the Java version. Many other frameworks even for different programming languages are inspired by JUnit and try to follow asimilaruserinterface. The tests are define dbya simple annotation, Test, and

21、 in many cases this is the only requirement for the test. Inside each test, a block of code is executed and the results are checked against the expected values using assertX functions (assertTrue, assertEquals, etc.).Usually, the JUnit framework is supported by the IDE, where there are buttons to ru

22、n one or all tests and the outputs are displayed directly. Command-line use is also possible. The very active development of this project since 2000 resulted in version 5 in November 2017. An example test is in Listing 1.1.TestNGTestNGlO is a unit testing framework heavily inspired by JUnit and exte

23、nded with support for additional features like functional testing, integration testing or end-to-end testing. The testing process can be started from plugins for popular IDEs, providing visual results, or directly from the ANT, Maven and Gradle command-line build systems. The default output formats

24、are HTML and XML, but newer versions provide the Reporter API for third-party output generators as well. TestNG is still in active development which started in 2010. The unit tests are configured by multiple annotations. An example testing class is in Listing 1.2.Practice of Unit TestingThere are se

25、veral practices for writing and managing the unittests. For all of them an initial setup of testing framework of a choice is required, but both presented frameworks follows simple steps to integrate themselves into the variety of Java build systems. The next thing is to write some code and the corre

26、sponding unit tests. There are two main methods when to write the actual tests.The test-driven development (TDD) means that tests are written prior to application code, which can help to design the interfaces as well as achieve high coverageoftheunittests. Theotherwayistowritethetestsaftertheapplica

27、tion code which seems to have no obvious benefits, but it is the option used more in our opinion.When both the application code and the tests are ready, they have to be evaluated. CommonlyusedexamplesarenumerousIDEintegrationpluginswhich provide the interface for running the tests and a visual repre

28、sentation of the results. Another popular way is to use the remote CI server, where the code is regularly sent (for instance after push to version system) and evaluated in a text console. In case of failure, the reports are delivered to the author of the last change via email.These two methods can b

29、e combined so the developer usually checks the correctfunctionalityofhis/herchangesbeforeacommit,andtheCIserververifies the correctness after the push to the remote repository. The complete execution of all unit tests of functionality should take at most a few minutes.At this point the testing envir

30、onment and the evaluation workflow are set and every new code change is processed in the same way as described above. To sum up, the testing pipeline consists of writing the test and the actual code (in arbitrary order), testing own changes locally and pushing them to the remote repository, which ma

31、y trigger a check in the CI server.Performance TestingPractical performance of Java programs can be observed in two different ways - by monitoring the running application in a real deployment with real workload, or by writing synthetic tests for smaller pieces of code and monitoring predefined crite

32、ria (execution time, consumed memory, etc.). The first method gets more real results 13, because it tracks the whole application running in its target environment work in gonreal data. The measure ments can run for alongtime, even for the whole application runtime, but on the downside a performance

33、problem may not be easy to track down to the code. On the other hand microbenchmark ing results tend to be more artificial, so drawing conclusions from them has to be done with care.The described monitoring scenario relies on profiler tools. The JVM provides support for such tools with the Java Mana

34、gement Extensions (JMX) 11. This technology provides information about performance and resource consumption on both local and remote applications running on the Javaplatform. Someofthe popular tools are JConsolel2 (a graphical tool included in the Java Development Kit (JDK), JProfilerl3 or VisualVM1

35、4. The profilers are often paid and target the enterprise environment. This kind of tools is more suitable for monitoring server applications with long uptime, than for other application types.Synthetic microbenchmarks are an alternative to profiling. They target only small pieces of code at a time,

36、 running in a loop on predefined data sets. This approach helps tracking performance during the development process when each code change can be immediately tested by the corresponding microbenchmark andeverylittledifferenceiscaptured. However, thetestingdataisoftendifferent from the real world prod

37、uction data and the workload could be different as well, soitispossiblethattheresultsdonotfullycorrespondwiththerealperformance of the application.This thesis explores only microbenchmarking because the tests run relatively shorttime,thus they can berun more often during the development process. The

38、y are often similar to the unit tests and also they tend to give more stable results than profiling. A description of some of the most popular microbenchmarking frameworks follows.CaliperCaliper 15 is a tool focused on Java microbenchmarks being developed at Google since 2008. It provides an integra

39、tion with an online results archive, which can help users with interpreting theresults,as well serve asaguide describing the best practices for the measurements. Android support allows running the tests directly on mobile devices, but it may not work in the latest version of Caliper. The simplest Ca

40、liperbench mark according to the official web tutorialisinListingl .3.The usual way to include Caliper into a project is through a Maven dependency. After compilation, the measurements are started by the provided com.google.caliper.runner.CaliperMain main class. The results are automatically uploade

41、d to the web archive and saved to the local filesystem in JSON format. The overall measurement time is controlled by the framework itself. The Maven dependency snippet for Caliper is in Listing 1.4.ContiPerfContiPerf 16 is a utility for writing performance tests alike regular unit tests. The perform

42、ance tests are extensions of the JUnit framework tests and the same code can be used for both purposes. Supported annotations can define measurement properties and expectations for the results. An HTML report with static data visualization is generated for every invocation of the measurements and th

43、e raw values can be exported in the CSV format. The utility was developed between 2010 and 2015. There is no evidence of any activity since then. A simple ContiPerf benchmark is in Listing 1.5. The tool can be easily integrated with the Maven build system. The dependency snippet for executing the fr

44、amework at the test target is in Listing 1.6.JapexJapexl7 is another tool for writing microbenchmarks with a philosophy similar to the JUnit framework. But Japex is not a direct extension of JUnit. The test suite configuration is defined in an XML file, the output includes HTMLreports with charts an

45、d timestamped XML results. For each tested algorithm, a separate Java driver class” has to exist including the code with the control methods such as prepare, warmup, run, or finish. This tool was developed in 2005 to 2011 and now seems to be abandoned. Even the project website is left inaccessible.A

46、 sample configuration for a test suite with two algorithms (XDriver, YDriver) and two test cases(with different arguments)is presented in Listing 1.7. The tests can be executed by the Maven plugin, which can be added as a dependency to the pom.xml file as shown in Listing 1.8.JMHJMH18 is a Java harn

47、ess for writing and analysing microbenchmarks. It is a part of the Open JDK project and is supported by the Oracle company. The performance tests are written like JUnit tests, only a different set of annotations is used. A sample benchmark is shown in Listing 1.9.The test configuration is highly cus

48、tomizable using annotations or commandline arguments at runtime. A recommended benchmarking project is created from the JMH Maven archetype. This procedure sets up proper dependencies and allows building a self-contained JAR bundle with all of the tests and the JMH code. This could be useful for mea

49、surements on a separate computer.The results can be saved in a human-readable text or in one of the machine readable formats, CSV, SCSV, and JSON. Third-party data from optional JVM profilers can be included assec on darymetricsintotheresults. It is possible to use acustom mainmethod and a Java API to tweaktheframework,buttheflexibility and simple uniform usage would be lost. This project started in 2013 and has been actively developed since. A community of users created many plugins for