Performance Testing | Load testing | Stress testing | |
---|---|---|---|
Domain | Superset of load and stress testing | A subset of performance testing | A subset of performance testing |
Scope | Very wide scope. Includes - Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing, etc. | Narrower scope as compared to performance testing. Includes volume testing and endurance testing. | Narrower scope as compared to performance testing. Includes soak testing and spike testing. |
Major goal | To set the benchmark and standards for the application. | To identify the upper limit of the system, set SLA of the app and see how the system handles heavy load volumes. | To identify how the system behaves under intense loads and how it recovers from failure. Basically, to prepare your app for the unexpected traffic spike. |
Load Limit | Both – below and above the threshold of a break. | Till the threshold of break | Above the threshold of break |
Attributes studied | Resource usage, reliability, scalability, resource usage, response time, throughput, speed, etc. | peak performance, server throughput, response time under various load levels (below the threshold of break), adequacy of H/W environment, the number of user app can handle, load balancing requirements, etc. | Stability beyond bandwidth capacity, response time (above the threshold of break), etc. |
Issues identified through this testing type | All performance bugs including runtime bloat, the scope for optimization, issues related to speed, latency, throughput, etc. Basically – anything related to performance! | Load balancing problems, bandwidth issues, system capacity issues, poor response time, throughput issues, etc. | Security loopholes with overload, data corruption issues at overload situation, slowness, memory leaks, etc. |

briley
@briley
Best posts made by briley
-
RE: What is the difference between performance load and stress testing?
-
RE: .travis.yml - What is this file for?
Travis-ci works with the github.com service, so the first step is to upload your project source code there. Except for minor technical settings (like installing hooks in a repository), the whole process is reduced to describing various options in the .travis.yml file. In it, you need to describe in what language the project is running, which versions of the language you need to use (everything is possible at once), the environment (here is an example of such a file for ruby). This file must be placed in the root of the github repository.
If the configuration is successful, then travis-ci starts continuously testing the project, displaying the current status: red (there were problems during testing), yellow (there are warnings) and green (all tests were successful). In addition to the status, you can see: an error message or a warning if something went wrong; the last commit and its author; build history, etc. In general, the interface is quite informative and understandable. In addition, travis-ci will notify you of problems by email.
-
RE: How to automate Integration testing of .Net desktop application
I have used White Framework for automating .net desktop applications. That's a good tool that you can add as a reference to your c# test project. MSTest, NUnit, xUnit are just frameworks for executing the test. You can choose any of them for running on Jenkins.
How to properly launch the required environment for testing?
You should prepare several windows build agents with installed all the software needed to run your app. These agents should be connected to Jenkins to be able to run the tests on them
Latest posts made by briley
-
RE: Wait until the page loaded Selenium Python
This should help u:
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By login_btn = WebDriverWait(driver, 500).until(EC.presence_of_element_located((By.XPATH, 'xpath of login button'))) #Waits until the login button is visible. login_btn.click()
If u don't wanna find the button by its xpath, then u can change By.XPATH to By.ID or By.CLASS_NAME.
-
RE: What to focus on when estimating a software testing task?
When you estimate software testing task you should focus on the following:
- Resources: Resources are required to carry out any project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition required for the completion of a project activity.
- Times: Time is the most valuable resource in a project. Every project has a deadline to delivery.
- Human Skills: Human skills mean the knowledge and the experience of the Team members. They affect to your estimation. For example, a team, whose members have low testing skills, will take more time to finish the project than the one which has high testing skills.
- Cost: Cost is the project budget. Generally speaking, it means how much money it takes to finish the project.
-
RE: How to automate Integration testing of .Net desktop application
I have used White Framework for automating .net desktop applications. That's a good tool that you can add as a reference to your c# test project. MSTest, NUnit, xUnit are just frameworks for executing the test. You can choose any of them for running on Jenkins.
How to properly launch the required environment for testing?
You should prepare several windows build agents with installed all the software needed to run your app. These agents should be connected to Jenkins to be able to run the tests on them
-
RE: Questions about windows software testing
Is there a difference between testing on a 32- and 64-bit OS?
The difference is very small. It exists for C ++ (although problems arise very rarely), but for Sharp, I can't even come up with a scenario to have problems. In general, in your case, you can probably not bother with this.
If I test a product under, for example, Windows 7, should I also test it with the Service Pack installed?
There is definitely no point in wasting time with a service pack. Even with every system, you don't need to test. Choose 2-3 key systems, let's say the smallest supported by your program, up-to-date, and preferably something in between. For example, WinXP-Win7-Win10.
In other systems, it is enough to simply check for problem areas - for example, in Win8 there is no Start button, for it it is worth making an alternative access to the program group. We checked it once, figured out the specific nuances, then it is not necessary to test it further.
Where can I find ISO images of the required OS versions for testing purposes (virtualization in VMware)?
Only on MSDN, of course. Well, or in some non-kosher places, which we will not name.
-
RE: .travis.yml - What is this file for?
Travis-ci works with the github.com service, so the first step is to upload your project source code there. Except for minor technical settings (like installing hooks in a repository), the whole process is reduced to describing various options in the .travis.yml file. In it, you need to describe in what language the project is running, which versions of the language you need to use (everything is possible at once), the environment (here is an example of such a file for ruby). This file must be placed in the root of the github repository.
If the configuration is successful, then travis-ci starts continuously testing the project, displaying the current status: red (there were problems during testing), yellow (there are warnings) and green (all tests were successful). In addition to the status, you can see: an error message or a warning if something went wrong; the last commit and its author; build history, etc. In general, the interface is quite informative and understandable. In addition, travis-ci will notify you of problems by email.
-
RE: Testing Levels
There are 4 typical levels of Testing in Software Testing:
Test Levels
Unit Testing
- a module is the smallest functional part of a program or application that cannot function separately only in combination with other modules. However, after the development of this module, we can already start testing and find inconsistencies with our requirements. Unit testing consists of testing this single unit as part of a program, assuming that it is only a unit.
Integration Testing
- the next level of testing, which is carried out after Unit testing. After we have tested our individual modules, we need to conduct integration testing to make sure that these modules work successfully in conjunction with each other. In other words, we test 2 or more related modules to check that the integration was successful and without obvious bugs.
System Testing
- the testing level in which we test an entire system or application that has been fully developed and is already ready for a potential release. At this level, we test the system, the application as a whole, conduct testing on all required operating systems or systems (if a desktop application) and conduct all the required tests such as functional, security testing, usability testing, performance testing, load testing, etc. ...
Acceptance Testing
- after the complete completion of the System Test, the product passes the level of Acceptance Testing, usually carried out by the customer or any other interested parties, in order to ensure that the product looks as originally required and was specified in the product requirements. Acceptance Testing can also be performed after each of the above test levels.
-
RE: "Connection refused" in nginx when doing Load testing
The problem was with my home router
He simply could not handle such a load.
The problem was solved by replacing the router -
RE: Junior QA test task
I can guess based on the cases that we gave to our testers. (We really wrote a special application for this, with bugs, and gave it to testers, but that's the case). The tester's goal is not to find bugs (strange as it may sound), but to test the functionality. Accordingly, the test case does not have to find a bug (especially if it does not exist), it must check that the entire application works as it is intended. A trivial option for authorization:
- Open authorization
- Drive in the name
- Drive in a digit
- Drive in a name of 70 thousand characters
- Drive in "nothing"
And so on .. There may not be bugs here (and should not be), but the key idea is that the functionality works.
-
RE: Testing without use of any functional requirements documentation
Yes, that's a usual situation. Try to gather more info about new functionality function specification from product owner and developers
-
RE: How to organize tests coverage in the project?
Well, if you do not have a fairy godmother, then it is obvious that to cover the project quickly enough with tests - you need either more people or more time if the number of people is constant.
It is necessary to convey to each developer the importance of tests, because as practice shows, not everyone understands that it is vital.
It's just as important to start here. You can start simple - check at least all controllers for 500 errors. It is done very simply and quickly - iterate over the array of routes and see the code returned by the client.
For version 3, we can apply, for example, another option for checking the operation of services, by analogy with controllers. You take vital services from the container, pull public methods and expect not 5 **. (well, for 4 and 5, it is of course also applicable, but with caveats if we want to use mocks)
It is also important, in my opinion, to work out the principles of testing with colleagues so that no one starts doing nonsense. At one time I was engaged in complete nonsense, testing private methods in services through Reflection, being sure that this is directly vital, but not realizing that if such a need arises, then this is a problem in the architecture.
Of course, it makes no sense to talk about maintaining a balance between fanaticism and real testing, because it all depends on the experience and the project.
However, my whole message is that in order to start, you have to start. If we are talking about the community, everyone needs to understand the importance of this event, the main thing, of course, is that the team lead, if there is any hierarchy. You also need to immediately write tests for new code. The main thing is to do it. Culture will come a little later, but it will definitely come.