I'm using UFT/BPT for API and GUI Testing, everything works fine, I have business components which are in flows which are used in Business-Process, I run the Business-Process from Test Lab - ALM, here I have a problem with big times on runs.
EX: Business-Process Test
Component 1:
Start: 18:17:48
End: 18:17:48
Component 2:
Start: 18:18:00
End: 18:18:01
Component 3:
Start: 18:18:12
End: 18:18:13
Component 4:
Start: 18:18:24
End: 18:18:24
Conclusion:
After Component 1 it's ended and Component 2 it's started are 12 seconds between.
Component 2 and Component 3: 11 seconds
Component 3 and component 4: 11 seconds
Why it's stay so much between components?
Experiencing the same starting with UFT 15+, I got the official reply that since the new version has sooo many new powerful features it is to be considered normal for some things to take more time with the new version.
Which of course is not a good reply, but that´s what I have been officially told by my support source.
So if you have a short test calling 10 components which all need 2 seconds to do their job, you used to execute such test in 10*2=20 seconds, and now it will take 10*2+20*10=220 seconds. For that additional 0 (from 20 to about 200 seconds), you get absolutely nothing in return. Great deal? Oooookay...
I think this should be fixed, naturally. There is no good reason why calling a component should have an oberhead of 9-15 seconds (SECONDS!).
But what can you do if you are using standard software packages that get messed up by the devs over the years? You can waste your time with support, but you will achieve nothing. So what can you do?
Nothing, except for migrating elsewhere :(
And I think it´s a shame. I wish SO user Motti (ex-UFT dev) would see this and clarify, but, well, he cannot be everywhere :)
Related
I have the next test plan in JMeter:
on the screenshot you can see the settings for the 1st ThreadGroup, wich has 50% of common amout of request in test plan (in each Thread Group are 10 different subrequests placed).
So, +1 request per second is added in average using these settings.
Then I ran this test and saw this picture (Error % column):
I save errors in file and all these errors have the same text:
<sample t="30129" lt="0" ts="1356710138314" s="false" lb="WebService(SOAP) Request 1" rc="000" rm="**Connection reset**" tn="jp#gc - Stepping Thread Group1 3-247" dt="text" by="0"/>
Server's cpu screenshot:
and for database:
After the errors have appeared my comp started work slowly and slowly (although the errors stopped to appear further)...
And in the same time the server's cpu progressively dropped to 0.
Could you tell me, please,
What is the reason of this error?
Have I reached the server timeout? (Because Max is more than 30s in the table).
UPD. I have rerun test with next settings: 1000 users per 02:46:40 (+1 Thread Group per 10 second and 10 requests inside each new Thread in the Loop).
I.e. I have reduced the time of test and total Thread Groups by 2 times, but save intensivity of Thead's adding.
The results are the same (including cpu usage on the server).
I've received the error «Connection reset» after 990 thread started. There are screenshots:
Any idea?
First, WebService(SOAP) Request is not the best way to test Webservices in JMeter, it will be deprecated in upcoming 2.9 version.
HTTP Sampler is the one to choose as it performs much better.
Second, Connection Reset means your server has cut connection. It could be coming from the CPU which seems high but it's not sure.
If what you call "my comp" is the computer hosting JMeter started working slowly then your JMeter instance is overwhelmed by the number of threads (2003 or more?) you've configured. It can come from a lot of factors, read this:
http://www.dzone.com/links/see_how_to_make_jmeter_run_thousands_of_threads_w.html
On the MIT App Inventor (similar but not the same to Scratch), I need to create a timer that can be reset when an action happens to complete an App. But, I have been unable to find a way to make a resetable timer. Is there a way using this piece of software? This is a link to the App Inventor.
The first 4 blocks are the codes for when the player interacts/clicks one of the 4 colored boxes.
The last block is the code outside of the 4 .Click blocks.
Btw. there is a lot of redundancy in your blocks, see Enis' tips here how to simplify this...
If you want to reset the clock, just set Clock.TimerEnabled = false and then set
Clock.TimerEnabled = true again and the clock will restart
see also the following example blocks (let's assume, you have a clock component and the timer interval is 10 seconds)
in the example I reset the clock after 5 seconds and as you can see, the clock starts from the beginning...
You can download the test project from here
three fan-related variables are defined in https://developer.nest.com/documentation/api#has_fan
has_fan (r/o, boolean)
fan_timer_active (r/w, boolean)
fan_timer_timeout (r/o, iso8601)
i suspect that fan_timer_timeout should be read-write; however, when i PUT
{"fan_timer_active": true, "fan_timer_timeout": "2014-09-30T01:07:29Z"}
i get back
No write permission(s) for field(s): fan_timer_timeout
none of the examples (on the SDK site) actually change the fan, so no guidance there.
the "non-public API" from "the early days" would have you do this:
fan_timer_duration = seconds
fan_timer_timeout = time-since-epoch-in-seconds + seconds
fan_timer_timeout isn't documented on the SDK site; however, doing that yields
No write permission(s) for field(s): fan_timer_duration,fan_timer_timeout
could someone clue me in as to what i need to send to get the fan to spin for the next 15 minutes?
many thanks!
The user configures the fan time duration in the Nest app or on the device, the API only provides a way to trigger a fan event.
It seems that fan time duration is a global setting, and would affect turning on the fan manually at the thermostat, hence why it is read only in the API. (Avoids user confusion)
I have following problem with tracking of Magento purchase on Google Analytics (custom theme, different from default checkout process).
My goal settings are following: http://db.tt/W30D0CnL, where step 3 equals to /checkout/onepage/opc-review-placeOrderClicked
As you can see from funnel visualization ( http://db.tt/moluI29d ) after step 2 (Checkout Start) there are a lot of exits toward /checkout/onepage/opc-review-placeOrderClicked which is setted as step 3, but step 3 reporting always 0.
Is there something that I'm missing here?
I've found the problem. Apparently second point (/checkout/onepage) was fired even on the third step.
When I changed it to regex match (/checkout/onepage$) everything started to work.
I'm having trouble chasing down a new bug in my BB app. I would like to gain understanding of the Console logging output that RIM provides.
Background is: I can't get it to break on simulator, so am running a JDE-4.5-compiled app on a Torch device. Using on-device debugging through Eclipse (on Windows).
Some minutes into running the app, I can get it to crash - there are lots of web service calls happening all the time, with lots of UI updates to rows in a list. When the app crashes, Eclipse does not catch the exception.
I have inspected the system log (ALT-lglg) but there are really a lot of messages in there, mostly referring to the message/event loop. However, I can find no reference to my code in them. I will further investigate the log (having downloaded it thanks to Max Gontar on Blackberry console output). However, with this current post I am asking more about the interpretation of the console output, rather than general BB debugging tips.
The output on crash is the regular popup box saying:
Uncaught exception: Application ITrack(307) is not
responding; process terminated
Question is: How do I interpret the attached console output - specifically I feel that the VM:... lines might hold some useful info, but I can find no resources with Google on their meaning?
Below the console output (separated with comments from what I already understand):
-My debug output - web service complete, JSON logged. Previous lines on console are almost all similar to this - this is the app running correctly:
Response received: 5
{"lng":"28.256607055664063","lat":"-25.828020095825195","zip_postal":"","city":"Pretoria","town":"Pretoria","road":"Alandale Street","suburb":"Elardus Park","region":"Gauteng","country":"South Africa"}
response success: 5
-CRASH!!!:
VM:ECTTv=1,w=0
Application ITrack(307) is not responding; process terminated
-These lines are somehow related to one of the errors - I see them duplicated in the device log:
[0 2]
0 2
-<SNIP> - 0 2 gets repeated 62(!) times:
0 2
3d 3501
0 2
0 2
0 2
0 2
3d 3502
0 2
-<SNIP> - 0 2 gets repeated another 31 times:
-This part gives some info on the Objects that are being used as Thread locks at the time of the crash. More info is required.
VM:THMNx=177,r=0x19965800,t=java.lang.Object
VM:THMNx=147,r=0x19966400,t=net.rim.vm.Message
VM:THMNx=177,r=0x20AC00,t=CHAR[]
VM:THMNx=147,r=0x197CD000,t=net.rim.vm.MessageQueue
VM:THMNx=138,r=0x228D8800,t=net.rim.device.cldc.io.proxyhttp.ClientProtocol
VM:THMNx=129,r=0x22718C00,t=net.rim.device.cldc.io.proxyhttp.ClientProtocol
-This part I know nothing about.
VM:THDRr=native
VM:THDLv=0
VM:ECTTv=0,w=0
-App has crashed, system is cleaning up and returning to Home Ribbon screen:
AM: Exit ITrack(307)
ApplicationManagerImpl.processExited : process process switching to background: pid=307
Process ITrack(307) cleanup started
Process ITrack(307) cleanup done
AM: Foreground is requested: net_rim_bb_ribbon_app(109)
TID:unable to execute in the app com.mix.ITrack.main.Application#1a29405e|java.lang.Object#7fbc2b0a|-1
FocusHistory: Focus gained; App ITrack; Component com.mix.ITrack.shared.mix.ui.controls.DynamicRowListField
FocusHistory: Focus lost; App ITrack; Component net.rim.device.apps.internal.ribbon.launcher.ApplicationAreaGridField
FocusHistory: Focus gained; App net_rim_bb_ribbon_app; Component net.rim.device.api.ui.component.ButtonField
AM: Foreground is set: net_rim_bb_ribbon_app(109)
ApplicationManagerImpl.setForegroundProcess : calling notifyApplicationSwitch to switch to foreground: process=net_rim_bb_ribbon_app(109) pid=109
Is there any info in here that looks useful to someone with more experience on BB than I have?
Has anyone any info on interpreting the VM:... lines?
(Please note I am not asking for general BB debugging advice, as there are already some great answers on stackoverflow about that. However I would love to this 'mysterious' RIM logging code.)
to start off: according to this BlackBerry forum answer by klyubin, the lines starting with VM:THMNx= refer to the locks being held at the time of the crash.