La liste de diffusion est fermée depuis juillet 2022, mais sert toujours d'archive d'informations sur QF-Test.
Cependant, si vous souhaitez rester informé des nouveautés concernant QF-Test, vous pouvez simplement vous
abonner à la newsletter
our obtenir des informations à jour sur chaque version - y compris les versions mineures - vous pouvez
nous pouvez vous abonner au flux RSS ou nous suivre sur les médias sociaux.
Alternativement, QF-Test fournit également des informations sur la version elle-même.
Une autre source d'information est notre blog, qui contient des articles actuels sur des thèmes généraux, sur l'entreprise QFS et aussi divers "how-tos", veuillez vous
ABonner au Blog
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [QF-Test] including captured stderr or stdout from SUT scripts in the test report
Hello Michael,
you can include arbitrary messages in the report by calling
rc.logMessage with the report parameter set to true.
And you have access to the output of a process via the variable
${qftest:client.output.<name>} or, preferably, in a Server script via
rc.lookup("qftest", "client.output.<name>", false)
The argument false for the parameter expand of the rc.lookup method is
useful here to prevent QF-Test from trying to expand $(...)
expressions that might be contained in the client output.
Bringing all of this together in a Jython 'Server script' node:
client = rc.lookup("client")
output = rc.lookup("qftest", "client.output.%s" % client, false)
rc.logMessage("Output from client %s:\n%s" % (client, output), report=true, nowrap=true)
Note: The nowrap parameter produces better results for this kind of
output in the report as it results in preformatted text that doesn't
wrap the lines.
Best regards,
Greg
Michael Theurich <Michael.Theurich@?.int> writes:
> Hi,
>
> In our tests, a lot of importance is given to check the output files generated by the SUT at the
> end of each test. This is done by external shell scripts, which have already been developed
> earlier, I don’t really want to reimplement them as SUT or server scripts. In case of errors, the
> stderr or stdout contains valuable hints. This is captured nicely in the QFT logs. Is there a way
> to also include this somehow in the generated reports (similar to the screenshots) in case of
> failed tests? If not, is there a plan to include this in future versions?
>
> Thanks,
> Michael
>
> ---------------------------------------------------------------------------------
> Michael Theurich
> Monitoring Application Tools SW Engineer
>
> Telespazio VEGA Deutschland GmbH
> Provision of Engineering Support Services
>
> EUMETSAT
> Eumetsat-Allee 1
> 64295 Darmstadt
> Tel +49 6151 807-7530
> email michael.theurich@?.int
>
> _______________________________________________
> qftest-list mailing list
> qftest-list@?.de
> http://www.qfs.de/mailman/listinfo/qftest-list
--
Gregor Schmid
E: gregor.schmid@?.de
T: +49 (0)8171 38648-11
F: +49 (0)8171 38648-16
Quality First Software GmbH | www.qfs.de
Tulpenstr. 41 | 82538 Geretsried | Germany
GF Gregor Schmid, Karlheinz Kellerer
HRB München 140833
|
1. Cookies fonctionnels
Nous utilisons des cookies fonctionnels pour garantir la fonctionnalité de base du site web.
2. Cookies de performance et de statistique
Nous utilisons Matomo pour analyser et améliorer notre site web. Des cookies permettent une collection anonyme des informations qui nous aident à vous offrir un visite clair et facile à utiliser de nos pages web.
This cookie contains a unique, pseudonymized visitor ID internal to Matomo for recognizing repeat visitors.
This cookie is used to track from which website the anonymized user proceeded to any page or sub-page.
The Matomo session cookie is used to track the visitor's page requests during the session. The cookie is automatically deleted at the end of each session (website visit), at the latest after one day.
is created and should be then directly deleted (used to check whether the visitor’s browser supports cookies).
short lived cookies used to temporarily store data for the visit.
short lived cookies used to temporarily store data for the visit.
