Am 1. April 2021 17:32:46 MESZ schrieb Krister Nilsson
<[email protected]>:
>Hi Felix!
>
>
>
>The requests/responses that fails, trigger the assertion and sets
>last_sample_ok = false, always do that. (Checked upto 1000 consecutive
>times.)
>
>The requests/responses that fails, trigger the assertion and sets
>last_sample_ok = true, always do that. (Checked fewer times but I’m
>quite sure.)
>
>
>
>The latter of these two is of course the problem.
>
Which is which in the picture?
One of the loops has three, while the other has two samplers. Could that be the
difference?
>
>
>Regarding differences between the ones that behaves ok and the ones
>that do not, I see none in the View Results Tree. Just differing
>characters like tx id, but no principal difference.
How are the whole controllers configured?
Felix
>
>
>
>I cannot post a simple test plan, but perhaps the screen shot below
>shows you what is going on!?
>
>The purpose is to find a "customer id" that gives a response which
>matches the regexp, and I want that to be the case for each request in
>one while loop. (This customer id will later on be used in another
>test, this is just a brute trial-and-error way of finding the test data
>for that test.) If each response is OK I will write the test data to a
>file and continue to the next group of requests in the test plan, i.e.
>to the next while loop.
>
>
>
>[cid:[email protected]]
>
>
>
>BR
>
>/Krister
>
>
>
>-----Ursprungligt meddelande-----
>Från: Felix Schumacher <[email protected]>
>Skickat: den 1 april 2021 15:21
>Till: [email protected]
>Ämne: Re: Response assertion seems to not always set
>JMeterThread.last_sample_ok correctly
>
>
>
>
>
>Am 01.04.21 um 13:43 schrieb Krister Nilsson:
>
>> Hello!
>
>>
>
>> I have a testplan sending several different HTTP requests. After each
>I have a "Response assertion". Some of the HTTP requests turns up RED
>(i.e. failed) correctly in the View Results Tree due to the assertion
>but I can see, by logging that the variable JMeterThread.last_sample_ok
>is not set to false for some of them. That is, for some of the failing
>requests it is set to false as expected, but for some it is set to
>true, even though it should and has failed.
>
>>
>
>> The "Response assertions" are set identically for all and the
>response code is also the same, 200, for all of them. The response
>content are not identical for them, but they have in common the they do
>no match the Contains pattern (.*from>\d{4}-\d{2}-\d{2}.*) .
>
>>
>
>> Is there a common configuration mistake made by many for this, or is
>there a known fault or some other explanation?
>
>
>
>Can you post a simple test plan that exhibits the described behaviour?
>
>
>
>Are they always failing/succeeding or is it a bit more flaky?
>
>
>
>Can you see other differences in a View Results Tree element, when you
>compare the failed/succeeded results?
>
>
>
>Felix
>
>
>
>>
>
>> Med vänlig hälsning
>
>> Krister Nilsson
>
>> ____________________________________________________________
>
>>
>
>> Krister Nilsson / översteprest, prestandatest
>
>>
>
>> IT Fond konto och teknisk plattform
>
>> Telefon direkt 010-454 21 97, mobil 072-210 21 97
>
>>
>[email protected]<mailto:krister.nilsson@pensions<mailto:[email protected]%3cmailto:krister.nilsson@pensions>
>
>> myndigheten.se>
>
>>
>
>> Pensionsmyndigheten,
>
>> Telefon vxl 0771-771 771, fax 08-658 13 00,
>
>>
>www.pensionsmyndigheten.se<http://www.pensionsmyndigheten.se/<http://www.pensionsmyndigheten.se%3chttp:/www.pensionsmyndigheten.se/>>
>
>>
>
>>
>
>> P Överväg miljöpåverkan innan du skriver ut detta e-brev.
>
>>
>
>>
>
>
>
>---------------------------------------------------------------------
>
>To unsubscribe, e-mail:
>[email protected]<mailto:[email protected]>
>
>For additional commands, e-mail:
>[email protected]<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
