CAPS entreprise provides software developers with an easy access to manycore systems thanks to its flagship product HMPP™ (Heterogeneous Multicore Parallel Programming).
Based on C and FORTRAN directives, HMPP offers a high level abstraction of hybrid programming that fully leverages the computing power of stream processors without the complexity associated with GPU programming.
The HMPP product validation criteria are many and various (with regard to the supported languages, the behavior of the directives, in relation to the OS, with regard to performance,...). So, a validation infrastructure has been developed based on internal tools and hudson projects for the control and the pretty-print of reports.
The PerfPublisher plug-in scans for xml tests reports defined in the administration panel and generates trend graphs, computes stats and underline regressions and modifications. The xml files must be generated by your own testing tool.
The following features are provided by this plug-in:
Any xml report file, must be validated by the following DTD : DTD report.
Each "build" can contain multiple Xml reports, representing a part of the repository of tests you have executed on your project. The results will be included in the computation of statistics as a comprehensive analysis but also more specifically, as sub-reports analysis (by category and by name of file).
The contents of XML files has been developed to be as generic as possible. The aim of this plugin is to integrate all your test results and to generate an efficient quality metric defining the current health of your project. For this metric to be effective, we have been providing a report format adapted to a large number of types of tests. (We should say, "we tried to...")
A report is structured around the following key elements:
From a point of view a little bit more technical, these tests are considered as members of a file and more generally, of a category. However, each test is independent of others. It possess its own definition, and especially its own execution context. However, we mention that a forthcoming features, will provide case simplifications of writing and reporting through mechanisms of factorizations.
You can provide a large amount of information on each test in order to characterize them.
Of course a test can have a complete description. And furthermore, a test ban be considered as "boken" with the EXECUTION_STATUS attribute (yes|no). A broken test, is test that you know should exists but you've have disabled it.
But it can also be "targeted". That is, you can set it a target of testing, one or more keywords describing the purpose of the test. For example, in the case of a test solution for a web application, you can set the targets tested by languages
Let's deal now with the context of the implementation of a test. Experiments run on your machine, which can be dedicated, and which can intervene heavily on results such as performances or just for a test repository adapted to the notion of integration. You have the ability to describe this context using the following tags.
Let us focus now on the representation of test results. A test can have multiple output data. A simple test may called "boolean". That is, it just indicate whether or not the test succeed (or failed).
In addition to this type of result, a test can provide important informations such that its compilation time, execution time or performance that it could have measured.
The tool xml-generator (xml-generator.jar) generates exemples of valid reports.
The current release is available in the download section. This plug-in is developed and maintained by Georges Bossert. Please use the Hudson mailing lists or issue tracker to ask questions, create feature request or bug reports.
This plugin is provided as it is. CAPS entreprise provides no warranty on the correction of errors or its support.
Skip to end of metadata Go to start of metadata