Le 30/09/2009 10:45, sebb a ecrit :
On 29/09/2009, Milamber <[email protected]> wrote:
Hello,
Le 28/09/2009 01:54, sebb a ecrit :
On 27/09/2009, Milamber <[email protected]> wrote:
Hello,
I works on French translation of new elements Comparison Assertion and
Comparison Assertion Visualizer. I have some questions:
* Some messages like "Response time:" aren't internationalized. I would
like do this. Which resources files must be used?
- messages.properties
or
- CompareAssertionResources.properties
CompareAssertionResources.properties is used for the
CompareAssertion GUI
messages.properties is used for any GUIs which don't implement TestBean.
For message "Response time:" in ComparisonAssertion class (which implement
TestBean) but the message is only display in ComparisonVisualizer (which not
implement TestBean), can you confirm the best resource file ? (I think
messages.properties...)
Yes, messages.properties is used for any GUIs which don't implement TestBean.
Though of course for a French translation you need to edit
messages_fr.properties.
Yes ;)
If the GUI uses a fixed string rather than a resource property, then
translation involves:
- change code to use resource
- add property to messages.properties
- add translations to messages_xx.properties
Ok, thanks for your instructions.
* In CompareAssertionResources.properties, I think
this
message isn't correct?
compareTime.shortDescription=Verify that all Samplers'
return times are within a given number of milliseconds
I think it needs to be qualified with "of each other".
That could be inferred from that fact that the assertion compares
samplers, but it would be better to be explicit.
In code, compare time behaviour verify that response time difference
between previous and current are within a given number of ms.
(But a 'break instruction' used if compare time failure is found at
first
element under the controller, other aren't never tested - that's a bug?)
I don't think so - because the first failure wins.
With this test plan :
-Thread Group (1-1-1)
|--Simple Controller
|--Loop controller (5 loops)
|--Java Sampler
|--Compare Assertion (compare content false and compare time with 100
(ms))
|--Comparison Assertion Visualizer
|--View Results Tree
loop1: response time 271 ms
loop2: response time 295 ms => success in CAV and VRT (noting display in
CAV, element tree is white)
loop3: response time 147 ms => failure in CAV and VRT (in CAV: left pane:
RT 295 and right pane: RT 147, element tree is red)
loop4: response time 284 ms => failure in CAV and VRT (because loop3
failed, no comparison with loop4 response time) (in CAV: left pane: RT 295
and right pane: RT 147 (not 284), element tree is red)
loop5: response time 275 ms => failure in CAV and VRT (because loop3
failed, no comparison with loop5 response time) (in CAV: left pane: RT 295
and right pane: RT 147 (not 275), element tree is red)
The "comparison assertion" mark as a failure all samplers within a
controller when the first test failed has been found.
Perhaps, it would be better to add a sentence in manual, because I was in
mistake by the messages in Comparison Assertion Visualizer (always same
error message)
Milamber
The code was copied from an old Java 5 development - it looked as
though it might be useful. Unfortunately, there is no documentation of
how it is intended to work.
I'm not sure now how I would expect a comparison assertion to work:
- should the first response be treated as the "good" sample, and
subsequent responses compared to it?
That is this behaviour that I expect (that I understand in my mind when
when I talk comparison)
I made this changes in patch here (and some improvements)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47907
The first is the 'good' sample and each sampler within controller is
compared to this first
- should each response be compared with the previous response? If so,
this would allow a steadily increasing (or decreasing) elapsed time
without complaining. Also, if response 3 fails when compared with
response 2, what should response 4 be compared against?
No, I don't thought this... because, for compare response time, we can
make this with a Duration Assertion.
And Content comparison, with a regexp extractor and Response assertion.
If the behaviour needs to be changed to be more useful, now is the
time to do it ... or maybe I should just remove the code again.
With some little improvements, I think that will be a good new
functionality. In all cases, we can find some ways to do (ie dynamic
time comparison / content comparison), but with this assertion and this
visualizer, we have a speed way to do this.
It's not very difficult to add a new field: Type Comparison: First
against Other(s) / Previous to Current / Mark on error at first failure
I can do this code changes, if you want.
(type list messages have to rewrite in good English)
Milamber
