What versions of chrome are compatible with loadrunner 11.52 on windows?
I saw a post that said version 26 was supported, but Im looking to record using chrome version 13 on windows 7
NB: Browser version is mandated by the project.
NNB: Assume playback is browser agnostic - as the commands generated will send the raw HTTP(S) requests to the target server, without any UI
All versions when using the proxy recording model.
I just recorded again , and quit before I got the site up (so recorded for about 4 minutes with an empty chrome screen and a spinning timer) to see what Loadrunner recorded - I got web_url, web_add_cookie & web_custom_request for google safebrowsing & related api - ...
Unless you work for Google or have their expressed written permission then you do not use automated tools against their site. This is why the sample applications exist. Or, you may download and install onto a server you own, control, manage, ... any of the thousands of open source applications which are available on the market.
Pointing an automated tool at a site you don't own, manage or control is no different than driving down the street and shooting at parked cars, homes and signs just because they are there and you can. Pointing a performance testing tool at the same is akin to pointing a piece of field artillery at someone's home. This is something you do not engage in as a performance test professional.
Related
I know that the most Iconic feature of PWA are
Service Worker: which make user can use the app offline from cached resources
Add To Home Screen: With this feature, user can add a shortcut of the app on their mobile home screen, to get a experience like interacting with a Native App(But there still a huge different, in my opinion)
etc.
However, I can do like all of them on about 6/7 years ago by using the HTML5 technology at that time, I know that service worker comes recently but there also was "HTML5 App Cache, as well as the Local Storage, Indexed DB, and the File API specifications." can do similar things.
Is there anyone can explain what's the difference between PWA and HTML5 webapps? or they are just the in term of same? or a similar concept but different implementation? or PWA is the (next gen/extension) of HTML5 webapp?
I might have some misunderstanding on PWAs, since I am new to this term, Thanks.
If keep it simple PWA is ordinary site with 3 additional features.
responsive design - site should look well on all devices
manifest.json - site must have general description about itself stored in manifest.json
caching - site must work offline
I believe 1 and 2 is easey. And 3 is realy what PWA is all about. So the question is: how we can provide offline support?
First problem is how we can get our initial .html .css and .js files without internet connection? Answer is: we should use service worker or App Cache. But App Cache has a lot of problems and probably will be deprecated, in other hand service worker under developement and become better each month. You can read more about their difference here.
Second problem is how we can get server data without internet connection? We should store most vital data somwhere. But after we get our .js file from cache we have access to Local Storage, Indexed DB etc. So we can store vital data in any of this storage while we online and get it back from them when we offline. It is totally up to you how you will handle that.
I believe there no cleare and strict defentiton for PWA and HTML5 webapp (at least for now). So you can asume it is the same but today PWA is more common word.
I can test my addin in Excel for Windows / Online, but can't test it from a Mac and iPad because I don't have that setup and don't have plans to acquire it.
I'm being rejected because of Mac tests by the team, and I'm unable to fix the errors.
Is there any way to cap Macs from the manifest file and don't make them avaible to Mac users when they browse the store?
Office Web Add-ins are designed to work across the entire Office platform. As such, there isn't a mechanism for enabling the add-in by platform.
In the end, these add-ins are just web apps that run within a browser context. If you're running into a blocker on a single platform, posting those questions on Stack Overflow would be a reasonable next-step. Generally browser specific issues are well known by the community here and can be quickly answered.
There are also several vendors that offer cloud-based Mac access. MacinCloud for example has a $1 per hour option (you pre-pay for 30 hours so it's a $30 investment). I've used this service myself for testing add-ins.
I'm trying to record a script with LoadRunner but nothing happens...
I'll try to be more specific: I create a new web-based script (Web - HTTP/HTML) because I want to record actions taken into IE.
I start doing things in IE and then stop the recording.
What I expect is to find into "Action" the code that describes what I've just done in IE but nothing appears: "Action"contains only the return.
Any idea about what could be the issue?!
EDIT: I'm not recording any HTTPS action...
Have you engaged in any activity in IE which connects to a server across the HTTP protocol, submitting requests and pulling responses? if not, then you should not expect to see anything recorded.
There are also all sorts of permutations of 64 bit IE, of specific release numbers, versus your 32 bit recording engine of LoadRunner and specific release numbers, plus your credentials and any conflicts from antagonistic antivirus that could come into play.
The sample applications are your control set, such as the sample flights reservation system. If you cannot record against that site with your version of LoadRunner then you have a conflict in one of the following
Failed Installation
Wrong Credentials
Conflicting Antivirus (disable for testing)
version conflicts (see requirements for your version of LoadRunner)
64 bit IE and 32 bit VUGEN (see proxy model for recording)
You may try local proxy recording.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
Is it possible to build an application inside in browser? An application means:
1 Where there is connection (online mode) between the browser and an remote application server:
the application runs in typical web-based mode
the application stores necessary data in offline storage, to be used in offline mode (2)
the application sync/push data (captured during offline mode) back to the server when it is resumed from offline mode back to online mode
2 Where there is no connection (offline mode) between the browser and an remote application server:
the application will still run (javascript?)
the application will present data (which is stored offline) to user
the application can accept input from user (and store/append in offline storage)
Is this possible? If the answer is a yes, is there any (Ruby/Python/PHP) framework being built?
Thanks
Yes, that is possible.
You need to write the application in Javascript, and detect somehow whether the browser is in offline mode (simplest is to poll a server once in a while). (Edit: see comments for a better way to detect offline mode)
Make sure that your application consists of only static HTML, Js and CSS files (or set the caching policy manually in your script so that your browser will remember them in offline mode). Updates to the page are done through JS DOM manipulation, not through the server (a framework such as ExtJS http://www.extjs.com will help you here)
For storage, use a module such as PersistJS ( http://github.com/jeremydurham/persist-js ), which uses the local storage of the browser to keep track of data. When connection is restored, synchronize with the server.
You need to pre-cache images and other assets used, otherwse they will be unavailable in offline mode if you didn't use them before.
Again: the bulk of your app needs to be in javascript, a PHP/Ruby/Python framework will help you little if the server is unreachable. The server is probably kept as simple as possible, a REST-like AJAX API to store and load data.
The "Let's Take This Offline" chapter in Mark Pilgrim's (online) book Dive Into HTML5 is a very nice overview of writing offline web apps with HTML5 technologies.
Note: Since Mark Pilgrim's original Dive Into HTML5 link seems to be down.
Copies can now be found here among other places.
Jake Archibald wrote "The offline cookbook". A modern (9 December 2014) and nice approach with ServiceWorker:
http://jakearchibald.com/2014/offline-cookbook/
The answer in 2018 is to leverage the service worker, and to build a Progressive Web App:
https://developers.google.com/web/progressive-web-apps/
i was looking for this also, i found out abt HTML5 Offline Web Apps. havent tried it tho
Users of typical online Web applications are only able to use the applications while they have a connection to the Internet. When they go offline, they can no longer check their e-mail, browse their calendar appointments, or prepare presentations with their online tools. Meanwhile, native applications provide those features: e-mail clients cache folders locally, calendars store their events locally, presentation packages store their data files locally.
Have a look at Google Gears, http://code.google.com/apis/gears/. Although they have been phased out in favour of HTML5. However, it seems that what is being pushed as HTML5 is Google Gears.