User defined variable of the last thread overrides the predecessor thread user defined variable
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- java
- Ambito
- performance, testing
Direzione di ricerca
Inizia con i due elementi Thread Groups e User Defined Variable descritti nell’issue, utilizzando il file allegato JMeter_Bug2.docx per riprodurre il comportamento in JMeter 5.5. Traccia come viene risolto P_url quando vengono eseguiti entrambi i gruppi, quindi verifica che ogni Thread Group utilizzi il proprio valore senza che il valore del secondo gruppo sovrascriva quello del primo.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Expected behavior
The user defined variables that are defined under thread group should have the scope with in the respective thread group.
Actual behavior
When tester is having 2 scripts with 2 different login urls and the tester combines them in same test plan notice some of the general user defined variables like P_url which is different for each of the scripts fails to work as the P_url defined in the 2nd thread group overrides the P_url defined in the 1st thread group.
Steps to reproduce the problem
- User created 2 thread groups
- Each thread group has user defined variable element
- The name of variable P_url is used to parameterize the url of the request
- P_url in the thread group 1 holds the value of 1st application url
- P_url in the thread group 2 holds the value of 2nd application url
- When user runs the test notice that P_url value in thread group 1 is overwritten by 2nd application url
- Refer the document provided
JMeter Version
5.5
Java Version
openjdk-17.0.14
OS Version
Windows Server 2022 Datacenter 21H2
- Lingua principale
- Java
- Stelle
- 9.6k
- Fork
- 2.3k
- Merge medio
- 19h 29m
- PR unite (30g)
- 11
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/jmeter
-
[Bug] Typo in assertion property name: "Asserion.test_strings" missing 't'Forse già presa @waterWang l’ha presa 51 giorni fa. Apertadefect to-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
apache/jmeter#6751 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement to-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
RandomDate ignores inclusive end date and throws when start == endForse già presa @weillercarvalho l’ha presa 327 giorni fa. Apertadefect to-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
apache/jmeter#6609 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
documentation to-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
invalid wontfix
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
apache/jmeter#5770 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di apache/jmeter
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
utopia-rise/godot-jvm#1004 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
spring-projects/spring-grpc#442 ·
-
Expose numberOfPermits in RateLimiterEvent.toString() and the ratelimiterevents actuator DTOForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
resilience4j/resilience4j#2547 ·
I maintainer di solito rispondono entro 9 giorni
-
Clock.MakeDate continues execution and returns a rolled-over instant after dispatching error on invalid dateForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
mit-cml/appinventor-sources#4155 ·
I maintainer di solito rispondono entro 1 giorno