I face error while scripting Credit card transaction in jmeter.
Issue seems device finger print is not getting capture (which is dynamic ) .this dynamic parameter is not generated hence script fails .signature generation algorithm generates signature but jmeter fail to capture it .
As per JMeter project main page:
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever displayed at a time).
So if your fingerprint checking or signature generation algos rely on JavaScript execution in the client (browser) you won't be able to record and replay your scenario in JMeter.
The options are in:
Use a real browser, there is WebDriver Sampler which provides JMeter integration with Selenium browser automation framework, this way each thread (virtual user) will kick off a real browser and real browsers are normally capable of executing JavaScript
Replicate the logic of JavaScript in terms of fingerprint reporting or signature generation using JSR223 Test Elements and Groovy language
Related
The W3C defines the WebDriver Protocol, which can be used to automate user inputs on web pages within browsers. It can be used with external browser drivers (such as Google Chrome's Chromedriver or the FireFox Gecko Driver), and actions like button presses and hover events (and many more) can be simulated.
However, I could get the same result by just injecting some custom written JavaScript code which directly generates the events and runs them within the web page context. I could for example just create an MouseEvent instance and dispatch it to simulate a click event.
I know that the WebDriver protocol is the state-of-the-art approach to browser automation, but why is that so? What are the benefits of using a protocol which requires browser dependent driver software, when I could just open the Webpage and run injected automation code?
I would probably still need external software to open a browser instance and inject the automation code, but I don't see the need for a full browser-external interface for event automation.
Jason Huggins started building the Core mode of Selenium (the original one) as JavaScriptTestRunner wherein a javascript automation script is injected to the web application to run automation.
Same origin policy was one of the main hurdles for this mode of automation which states that to execute javascript files on a web page, the javascript file should originate from the same domain on which the web page loaded from. For example: to run javascript function from js files on www.google.com page, the javascript files must be downloaded from www.google.com web server itself. The browser prevents the user from injecting a javascript file from outside and executing it.
So how did Jason do the automation? He included the JavaScriptTestRunner in the web application under test.
Expecting testers to have access to the web server to include the JavaScriptTestRunner into the server is not practical. Also, in production servers this is big NO-GO.
RC and then the WebDriver projects then came about to tackle these issues.
With WebDriver protocol, a user only needs access to the application under test in a browser to write UI automation. There is no need to have back end server access.
WebDriver architecture is beautifully designed to have 2 objects(primarily) to achieve automation - WebDriver to control the browser and find WebElements and WebElement to perform operations on the application UI.
// Open chrome
WebDriver driver = new ChromeDriver();
// open url
driver.get("url");
// find element
WebElement someElement = driver.findElement(By.id("some-id"));
// perform operation on element
someElement.click();
no risk of conflicts with other javascript running on the page
works on resources that are not html pages, have no dom, and won't run javascript
can access features (eg. browser logs) that injected js does not have permission to run
flow control is not broken by unexpected page navigation, reload, etc
easier to deal with switching between tabs, windows, frames when your code isn't running inside one of those frames
I get this message in Jmeter when I run my testplan.
<noscript>
<p>
<strong>Note:</strong> Since your browser does not support JavaScript,
you must press the Continue button once to proceed.
</p>
</noscript>
How do I get around this issue on JMeter? When I go to the link manually in Chrome, the page/charts load fine.
I asked the UI engineer how things worked and they said when we go to the webpage
The http request returns an html
The browser reads the html and requests js files.
Thanks in advance for any help.
As per JMeter Project main page:
JMeter is not a browser
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever displayed at a time).
Browsers don't do any magic, they just execute HTTP requests and render responses. If JavaScript is being used to "draw" something on page - you should not be interested in it as it happens solely on client side.
If JavaScript is used for building i.e. AJAX requests - these are basically "normal" HTTP Requests which can be recorded using HTTP(S) Test Script Recorder and replayed via HTTP Request samplers.
If you cannot successfully replay your script - most likely you're missing HTTP Cookie Manager and/or need to perform correlation of dynamic parameter(s)
Is there any way to implement bulk/mass print in javascript/php? I searched on web and most of the answers found are for .net and java. I need to queue around 600 documents at a time. I found PECL printer library but the doc says it is only available under Windows 9.x, ME, NT4 and 2000. Does PECL library work under linux server? is it good to go with PECL library or there are any other alternatives?
Controlling the Printer in Windows is not big task as we have many win32api available or entry points can be created to do printing dynamically. As PHP is the server side and JavaScript is Client side scripting language.
Bulk Printing/Printing on Client Side without permission/notification is not possible according to me. Thus, user must authorize the printing job.
Developers have less experience for Printing under Linux. Even me don't know much but I know a way to do it. I have never tried or done it yet. Under PHP doesn't have any inbuilt function of printing/controlling things. There is no extension as such available under PHP to do so also. But under Linux there is command know as LPR (Line printer daemon protocol) which can be used under PHP to do printing, if shell_exec is authorized under PHP to execute shell commands. Command follows a:
shell_exec("lpr -P 'printer' -r 'filename.txt');
You have to go through RFC Protocol for LPR. You have to create the abstraction layer for Daemon for controlling and sending Printing Commands. A Good example for creating daemon is available here.
After going through these things, you would be able to Print documents under Linux through PHP.
Additional Question
Want to do Client Side Printing through Website/localhost
Small Answer
No, you can't control the Client Printer Directly without permission of user and that too depends on every session. So, if you want to get the access is another session you have to get the permission of user again.
Long Answer
Yes, it can be controlled with many tweaks and under certain conditions. As most of the users use windows as providing answer accordingly. But to understand the working of that you have to understand the Print Dialog internals.
Print Dialog is divided into two parts. One is Windows API and other is Printer Drivers. Windows API is the set of common code that is held by various DLL (Dynamic Link Library) that are the part Windows OS. Windows API provide a common interference allowing all Program can use that allowing all programs access to the same set of printer drivers rather than printer manufacturers having to create driver software.
Printer Drivers are created in different languages and they control the different parts of the hardware to send the instructions to printer. The main Printer Driver that control the flow are PCL5 and PostScript etc., Printer Driver changes the custom markup language that the specific printer understands.
So, basically we need the direct access to DLL and through Modern Browsers (Chrome, Firefox etc.) it is not possible but One Browser can Provide the access i.e. Internet Explore which is Part of Windows OS itself.
So, the First Condition is the User must use Internet Explorer and access through other is not known to me. Next thing to get the direct access to the API that can be done through ActiveX Control. In principle it is not dependent on Microsoft Windows, but in practice, most ActiveX controls require either Microsoft Windows or a Windows emulator. Most also require the client to be running on Intel x86 hardware, because they contain compiled code.
So, the ActiveX Controls are accessed through user prompt only. Thus, use have to manually change the control or again user has to provide the access to the web page. If the settings are changed then there is great danger to the computer as it provide access to computer hardware and other components. The computer can be hacked easily. Thus, you have to use it under great cautions. Thus, Third condition is to have a direct access to ActiveX Control.
I have used ScriptX, free version lets you set some basic parameters, see the example below:
<!-- MeadCo ScriptX -->
<object id=factory style="display:none"
classid="clsid:1663ed61-23eb-11d2-b92f-008048fdd814"
codebase="http://[your path here]/smsx.cab#Version=7.0.0.8 ">
</object>
<script>
function printWindow() {
factory.printing.header = "This is MeadCo";
factory.printing.footer = "Printing by ScriptX";
factory.printing.portrait = false;
factory.printing.leftMargin = 1.0;
factory.printing.topMargin = 1.0;
factory.printing.rightMargin = 1.0;
factory.printing.bottomMargin = 1.0;
factory.printing.Print(false);
}
</script>
I have provided the way to do it and rest you have to do according to your requirements. Once again I would tell you that kindly not change the settings of ActiveX to enable which caused great threat to user. Machine can be easily hacked and great threat to information available in computer.
The PECL printer library is for server-side printing. You have to have the printer connected to the server the script is running on.
If your clients need to do the printing, you cannot use it. You cannot do the "printer queueing" with JS alone. If you are restricted to using the browser only, best way to go about this would be loading out all the pages you want to print in one HTML page with proper CSS page breaks. But beware, there might be browser performance issues depending on the size of that one page.
Another thing you could do is convert that HTML internally to a PDF and then allow clients to print it. This doesn't allow queueing, but serves the purpose.
why don't you use css page-break-before to tell the browser that the content should be in a new page and clone the element as many time as you want
for example
.page
{
page-break-before: always;
}
<div class="page">
something to be printed in a whole page
</div>
<div class="page">
something to be printed in a whole page
</div>
<div class="page">
something to be printed in a whole page
</div>
I have created a Java program which takes some command line arguments to run. I need to make a browser extension to the program so that the program can be opened with data from the browser.
I know Javascript does not allow any local file access, but there are programs which doing the task I needed.
Examples are Internet Download Manager which has the browser extension for running it receiving command line arguments from the browser. Obviously extensions for most of the browsers including Chrome and Firefox are made using Javascript? Is there any way to do local program execution via JavaScript (I think there's a way surely)?
You can't directly run anything from your JS sandbox on client PC (just think about security risks!) There's other method however: Make your application register itself as protocol handler when it installs and use links with this protocol on your pages (think how e-mail clients serve mailto: or torrent clients serve magnet: links). Since you control both sending and receiving side, you can pass pretty much any information in those. You can find Windows example for registering a handle at MSDN. Should you need it for any other system, I'm pretty sure searching for "system_or_gui_name register protocol handler" will show you desired result among the first.
in a simple html file opened locally via firefox I need some javascript code to execute a command (maybe "ls") and get it's result in a string I can use in js/jquery to alter the page contents.
I already know this is a generally bad idea, but I have to make this little local html file capable of running several scripts without a server and without cgi.
In the past I've used to install a plugin in TiddlyWiki (www.tiddlywiki.com) to execute external commands (firefox requested authorization for every operation), so javascript can do it, but how to get command result in js after execution?
I don't believe there's any way to do this without a cooperating browser plug-in. The browser plug-in would be told what command to execute via javascript, it would go execute that command and then call you back with a callback when the results were available. This could be very dangerous as giving the browser access to your local system in almost anyway opens you up to lots of types of attacks (which is why browsers don't offer this capability).