Load Runner scripting, Scenario based query - performance-testing

I want to ask question on one scenario of loadrunner scripting, there is one e-commerce site and we need to purchase a t-shirt of different color, we have recorded the script but while replaying we need to modify a script in such a way that user should select a t-shirt randomly and depend on t-shirt it should pick a random color as well, how to implement this logic in load runner script. Kindly help me to know logic of it.

Related

Using PhantomJS to print user activity

In the company where I work there are many agents making calls and entering information into our system. I would like to know if it is possible for a boss to take a screenshot of the user's screen at any time of the day to know what activity the user is doing.
I know this can be done with PhantomJS, but I think it's used to make a screenshot of an external website.
Thank you in advance for any response.
Actually what you are looking for is an application called TimeSnapper. It records your screen every few seconds, and it also categorizes active applications/urls so it can calculate a productivity score.

Revit Addins that Run in the Background/Always

Is there a way to create a Revit macro/add-in that will be running constantly. My employer is curious if I can write a program that makes a piece of equipment (for example a lighting fixture) a different color if it is not circuited/not connected to a circuit.
Let me know if there is a way or if there is a completely different method I could use to achieve this task.
Be straight with me, because I am willing to make an add-in that you still have to run every time to check the parts for circuitry. But obviously, the background running add-in would be nicer... Thanks!
Possible a couple different ways.
Best way is probably Updaters.
Fall back would be Idling/External Events.
But generally if you want to update something dynamically based on when things change, Updaters are the way to go. I believe that there are samples in the SDK.
There is a much simpler way to do this. You can use a filter in your view to change the color, or other properties, if the element isn't circuited.
In Visibility Graphics, Filter Tab, Create a new filter, for category select Light Fixtures, for the filter criteria, select Circuit Number, for the comparison, choose Less Than, use the value .
This will match fixtures that haven't been powered & fixtures that have been powered but not assigned to a panel.

How to ease updating inferno with web performance test scripts

Updating can performance test script e.g. with LoadRunner can take a lot of time and be quite frustrating. If there has been some updates with the applications, you usually have to run the script and then find out what has to be changed, update and run again and so on. Does anyone have some concrete best practices how to ease this updating inferno? One obvious thing is good communication with developers.
It depends on the kind of updates. If the update is dramatic, like adding new fields for user to fill in, then, someone has to manually touch up the test scripts.
If, however, the update is minor, for example, some changes to the hidden fields or changes to the internal names of user-facing fields, then it's possible to write a script that checks the change and automatically updates the test script.
One of the performance test platforms, NetGend, automatically takes care of the hidden fields and the internal names of user-facing fields so it's very easy to create a script to performance-test a HTML form. Tester only needs to fill in the values that he/she would have to enter using a browser, so no correlation is necessary there. Please send me a message if you need to know more about it.
There are many things you can do to insulate your scripts from build to build variability. The higher up the OSI stack you go the lower the maintenance charge, but the higher the resource cost for the virtual user type. Assuming changes are limited to page level resources and a few hidden fields here and there for web sites or applications, then you can record in HTML mode. You blast the EXTRARES sections as the page parser in HTML mode will automatically parse the page and load the page resources even without an explicit reference - It can be a real pain to keep these sections in synch if you have developers who are experimenting quite a bit.
Next up, for forms which have a very high velocity in terms of change consider the use of a web_custom_request() for the one form. You can use correlation statements to pick up all of the name|value pairs as needed and build the form submit dynamically. There will be a little bit more up front work for this but you should have pay offs at around the fourth changed build where you would normally have been rebuilding some scripts.
Take a look at all of the hosts referenced in your code. Parameterize all of these items. I have a template that I use for web virtual users which pairs a default value and the ability to change any of the host names via the control panel extra attributes section. Take a look at the example for lr_get_attrib_string() for how you might implement the pickup and pair that with a check for NULL and a population with a default value in your code
This is going to seem counter intuitive, but comment your script heavily for changes that are occurring often so you know where to take the extra labor change up front to handle a more dynamic data set.
Almost nothing you do with any tool can save you from struuctural changes in the design and flow of the app, such as the insertion of a new page in the workflow, but paying attention to the design on the high change pages, of which there are typically a small number, can result in a test code with a very long life.
Of course if your application is web services based then there is a natual long life to the use of exposed public services. Code may change on the back end of the service, but typically the exposed public interface is very stable.

Developing Online multiplayer management game

I wish to create a college project on a simple online multiplayer management game which will involve players setting orders for the day/week and then obtaining profits. Being a relative beginner I am unable to figure out the architecture required for this task.
As far as I am concerned I would be needing the following things:
A text interface to display the status of ongoing events and to set orders in a web browser.
A certain application that would calculate the results every minute and update the database.
A database
Sorry for being so newbish, but any advice or links or books on how to proceed will do.
Please comment if any more information is required.
Any programming language would be fine. Pick a lang / arch you or someone in your group are familiar with. I'm mostly a PHP/ZF, Linux, Postgres guy. So I would...
Write a little ZendFramework app to collect your user's data and save to postgres database. I'd host it on a little Linux server. I like slicehost.com $20/mon, but there are cheaper. Or make friends with someone with a server.
Then for the update of the orders, use a cron job to run every minute. If the update process is complex, use another PHP script, else just straight SQL.
Why do you need to run updates every minute? Are people going to be updating it that often, if they are making orders for a day or week?
I would start with deciding on the equations that will be used in your model.
Then, that will help decide what you need in the database, to give the parameters to the model.
Then, once you have the database, you need to get information from the user, so decide what you need from the user.
For example you should have some random event that will make certain items go up or down in demand, or have resources become more common.
So, you may want to have information in the database that lists what each product is composed of.
If the model will have external information, or, if it is based on what others make, so, for example, last week shoes were not produced, so those that made shoes made a profit. This week everyone is making shoes, so there is too many, so the price went down.
This is why I think starting with your model, and testing your assumptions is the first step.
Any language, system, database will work well, just do what you feel comfy with. When you design the UI, do you want it to look fine on iphones and the Blackberry Razor? Then that will have a big impact on how you design the UI.

In agile dev, how do you organize user stories? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
How do you go about organizing user stories?
What I did was this for a web application:
Made a title for a web page like 'index', then listed all the stores the user can do on this page.
I continued on for all the pages.
Is this the most effective way?
I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:
As a [role] I need [capability] so that [desired outcome].
A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:
Concern: Some Activity
Context: When doing such and such
Observation: This thing should be added to the database
Observation: The thing should get a new unique ID
Observation: The thing should be related to that thing
Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)
It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):
Concern: Finding Stores
Context: When looking for a product with the best price
Observation: The web page should display a grid of store thumbnails that contain the users search product
Observation: The stores should be sorted such that those with the lowest price appear near the top of the page
Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for
The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.
Concern: Retrieving Stores
Context: When searching for Store entities containing a specific Product
Observation: A collection of StoreResultDetail should be returned
Observation: The collection of stores may be empty
Observation: Each StoreResultDetail should contain the store name
Observation: Each StoreResultDetail should contain the price of the Product
Observation: Each StoreResultDetail should contain the URL of the store's web site
Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site
The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.
Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.
Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.
In our shop, we write up Use Cases. Examples of Use Cases:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).
From the use cases, we then begin to sketch up web pages.
You can also make Use Case diagrams:
I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.
I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.
Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.
We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.

Resources