My scenario is for example in my parallel execution for 2 scenarios the application is launched in two chrome browser and two transactions are initiated. I need the the 2 transaction for which I used "transaction.getAttribute("value")" because the transaction IDs can be seen when I do inspect.
I wrote the below code but only one transaction ID is getting fetched. I am using ThreadLocal for parallel execution. I checked there are two different thread got assigned for two test.
List AlltransactionID = DriverManager.getDriver().findElements(By.id("transaction-id"));
int i = AlltransactionID.size(); // (here I am getting size=1)
log.info("Total number of Transaction ID " + i);
for(WebElement tranID : AlltransactionID){
Object transactionID = tranID.getAttribute("value");
log.info("Value is --> " + transactionID);
}
Note: I have used driver.findelements because I want to fetch the transactions IDs from the two test. Please assist
Related
I have a situation like this:
Test Plan
Thread Group 1
var A = 1 ( User parameters)
HTTP request 1
HTTP request 2
Thread Group 2
var A = 2 ( User parameters)
HTTP request 3
HTTP request 4
I know that I can use "Run Thread Groups consecutively" to make these 2 thread run parallel. However, the problem is, because they are running parallel, sometimes var A=2 got recognized in Thread Group 1, and thus make the test case fail. What I ask, is there any way that I can still run these threads parallel and still make sure that the parameter values of these threads won't affect on each other? Thank you!
You can use different name for the variable so that there is no conflict.
Something like below:-
Test Plan
Thread Group 1
var A = 1 ( User parameters)
HTTP request 1
HTTP request 2
Thread Group 2
var B = 2 ( User parameters)
HTTP request 3
HTTP request 4
From the jmeter documentation:-
If you have more than one Thread Group, make sure you use different
names for different values, as UDVs are shared between Thread Groups.
Also, the variables are not available for use until after the element
has been processed, so you cannot reference variables that are defined
in the same element. You can reference variables defined in earlier
UDVs or on the Test Plan.
Hope this helps.
This is not possible as JMeter Variables scope is limited to current Thread Group only so the situation where 2nd Thread Group is reading the values from 1st Thread Group User Parameters element is either a bug in JMeter or your test fails for a different reason. For example not having a User Parameters element in 2nd Thread Group I'm not getting anything as the variable value:
I would recommend double checking expected variable A values using Debug Sampler and View Results Tree listener combination, perhaps your configuration is vague.
Is there any way to get all the test case executed details from the multiple test cycles at a time
Currently i have some 3 Cycle IDs but I am making 3 GET API calls to get from each cycle
https://<JIRA HOST>/rest/zapi/latest/execution?projectId=<Project ID>&versionId=<Version ID>&cycleId=<Cycle ID 1>
https://<JIRA HOST>/rest/zapi/latest/execution?projectId=<Project ID>&versionId=<Version ID>&cycleId=<Cycle ID 2>
https://<JIRA HOST>/rest/zapi/latest/execution?projectId=<Project ID>&versionId=<Version ID>&cycleId=<Cycle ID 3>
Is there anyway I get all the details in one shot for Cycle ID 1 & 2 & 3
Yes, you can get execution results for multiple test cycles using Zephyr ExecutionSearchResource API and ZQL query.
Use this:
https://JIRA_HOST/restrest/zapi/latest/zql/executeSearch?zqlQuery=project="ProjectName" AND fixVersion="VersionName" AND cycleName IN ("CycleName1", "CycleName2", "Cyclename3")
The above URL facilitates to query for multiple projects or versions as well.
Reference: http://docs.getzephyr.apiary.io/#
Thanks :)
Anuj.
I am using parallel processing.
CALL FUNCTION 'ZABC' STARTING NEW TASK taskname
DESTINATION IN GROUP srv_grp PERFORMING come_back ON END OF TASK
EXPORTING
...
EXCEPTIONS
...
.
I am calling this FM inside a loop. sometimes, my records are skipped. I am not getting a desired output. Sometimes 2000 records are processed and sometimes 1000. The numbers are varying. what can be the problem ? Can you provide me some cases where records can be skipped in parallel processing ?
See the example code SAP provides: https://help.sap.com/viewer/753088fc00704d0a80e7fbd6803c8adb/7.4.16/en-US/4892082ffeb35ed2e10000000a42189d.html
Look at how they handle the resource exceptions. A resource exception means that you tried to start a new aRFC but there were no more processes available. Your program has to handle these cases. Without handling these cases the entries will be skipped. The normal handling is to just wait a little time for some of the active processes to finish, in the example program:
WAIT UNTIL rcv_jobs >= snd_jobs
UP TO 5 SECONDS.
gv_semaphore = 0.
" your internal table size.
DESCRIBE TABLE lt_itab LINES lv_lines.
LOOP AT lt_itab INTO ls_itab.
" parallel proc. -->>
CALL FUNCTION 'ZABC' STARTING NEW TASK taskname
DESTINATION IN GROUP srv_grp PERFORMING come_back ON END OF TASK
EXPORTING
...
EXCEPTIONS
...
.
" <<--
ENDLOOP.
" wait until all parallel processes have terminated. **
WAIT UNTIL gv_semaphore = lv_lines.
NOTE: You should check total parallel process count. There should be some upper limits for opened threads.
Thanks.
Good day
I'm trying to perform load testing with LoadRunner 11. Here's an issue:
I've got automatically generated script after actions recording
Need to catch Session ID. I do it with web_reg_save_param() in the next way:
web_reg_save_param("S_ID",
"LB=Set-Cookie: JSESSIONID=",
"RB=; Path=/app/;",
LAST);
web_add_cookie("S_ID; DOMAIN={host}");
I catch ID from the response (Tree View):
D2B6F5B05A1366C395F8E86D8212F324
Compare it with Replay Log and see:
"S_ID = 75C78912AE78D26BDBDE73EBD9ADB510".
Compare 2 IDs above with the next request ID and see 3rd ID (Tree View):
80FE367101229FA34EB6429F4822E595
Why do I have 3 different IDs?
Let me know if I have to provide extra information.
You should Use(Search=All) below Code. Provided your Right and left boundary is correct:
web_reg_save_param("S_ID",
"LB=Set-Cookie: JSESSIONID=",
"RB=; Path=/app/;",
"Search=All",
LAST);
web_add_cookie("{S_ID}; DOMAIN={host}");
For Details refer HP Mannual for web_reg_save_param function.
I do not see what the conflict or controversy is here. Yes, items related to state or session will definitely change from user to user, one recording session to the next. They may even change from one request to the next. You may need to record several times to identify the change and use pattern for when you need to collect and when you need to reuse the collected data from a response in a subsequent request.
Take a listen to this podcast. It should help
http://www.perfbytes.com/dynamic-data-correlation
Could you please explain me following example from "The Little Redis Book":
With the code above, we wouldn't be able to implement our own incr
command since they are all executed together once exec is called. From
code, we can't do:
redis.multi()
current = redis.get('powerlevel')
redis.set('powerlevel', current + 1)
redis.exec()
That isn't how Redis transactions work. But, if we add a watch to
powerlevel, we can do:
redis.watch('powerlevel')
current = redis.get('powerlevel')
redis.multi()
redis.set('powerlevel', current + 1)
redis.exec()
If another client changes the value of powerlevel after we've called
watch on it, our transaction will fail. If no client changes the
value, the set will work. We can execute this code in a loop until it
works.
Why we can't execute increment in transaction that can't be interrupted by other command? Why we need to iterate instead and wait until nobody changes value before transaction starts?
There are several questions here.
1) Why we can't execute increment in transaction that can't be interrupted by other command?
Please note first that Redis "transactions" are completely different than what most people think transactions are in classical DBMS.
# Does not work
redis.multi()
current = redis.get('powerlevel')
redis.set('powerlevel', current + 1)
redis.exec()
You need to understand what is executed on server-side (in Redis), and what is executed on client-side (in your script). In the above code, the GET and SET commands will be executed on Redis side, but assignment to current and calculation of current + 1 are supposed to be executed on client side.
To guarantee atomicity, a MULTI/EXEC block delays the execution of Redis commands until the exec. So the client will only pile up the GET and SET commands in memory, and execute them in one shot and atomically in the end. Of course, the attempt to assign current to the result of GET and incrementation will occur well before. Actually the redis.get method will only return the string "QUEUED" to signal the command is delayed, and the incrementation will not work.
In MULTI/EXEC blocks you can only use commands whose parameters can be fully known before the begining of the block. You may want to read the documentation for more information.
2) Why we need to iterate instead and wait until nobody changes value before transaction starts?
This is an example of concurrent optimistic pattern.
If we used no WATCH/MULTI/EXEC, we would have a potential race condition:
# Initial arbitrary value
powerlevel = 10
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: SET powerlevel 11
session B: SET powerlevel 11
# In the end we have 11 instead of 12 -> wrong
Now let's add a WATCH/MULTI/EXEC block. With a WATCH clause, the commands between MULTI and EXEC are executed only if the value has not changed.
# Initial arbitrary value
powerlevel = 10
session A: WATCH powerlevel
session B: WATCH powerlevel
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: MULTI
session B: MULTI
session A: SET powerlevel 11 -> QUEUED
session B: SET powerlevel 11 -> QUEUED
session A: EXEC -> success! powerlevel is now 11
session B: EXEC -> failure, because powerlevel has changed and was watched
# In the end, we have 11, and session B knows it has to attempt the transaction again
# Hopefully, it will work fine this time.
So you do not have to iterate to wait until nobody changes the value, but rather to attempt the operation again and again until Redis is sure the values are consistent and signals it is successful.
In most cases, if the "transactions" are fast enough and the probability to have contention is low, the updates are very efficient. Now, if there is contention, some extra operations will have to be done for some "transactions" (due to the iteration and retries). But the data will always be consistent and no locking is required.