Was ist Unit -Test, Integrationstest, Rauchtest, Regressionstest?

Question

Was ist Unit -Test, Integrationstest, Rauchentest, Regressionstest und was sind die Unterschiede zwischen ihnen? Und welche Tools kann ich für jeden von ihnen verwenden?

Zum Beispiel verwende ich JUNIT und NUNIT für Tests und Integrationstests in Einheit. Gibt es Rauchentest- oder Regressionstestwerkzeuge?

Answer 1

• Gerätetest: Geben Sie einen Punkt des Vertrags einer einzelnen Methode einer Klasse an und testen Sie sie. Dies sollte einen sehr engen und gut definierten Bereich haben. Komplexe Abhängigkeiten und Interaktionen in die Außenwelt sind stumpf oder verspottet.

• Integrationstest: Testen Sie die korrekte Interoperation mehrerer Subsysteme. Es gibt dort ein ganzes Spektrum, vom Testen der Integration zwischen zwei Klassen bis hin zur Prüfung der Integration in die Produktionsumgebung.

• Rauchtest (auch bekannt als Überprüfung): Ein einfacher Integrationstest, bei dem wir nur überprüfen, ob das zu testende System aufgerufen wird, kehrt es normal zurück und sprengt nicht.

  • Rauchtests ist sowohl eine Analogie zur Elektronik, bei der der erste Test beim Aufschalten einer Schaltung auftritt (wenn es raucht, ist es schlecht!) ...
  • ... und, offenbar, mit Installation, wo ein Pfeifensystem buchstäblich durch Rauch gefüllt und dann visuell überprüft wird. Wenn etwas raucht, ist das System undicht.

• Regressionstest: Ein Test, der geschrieben wurde, als ein Fehler behoben wurde. Es stellt sicher, dass dieser spezifische Fehler nicht wieder auftritt. Der vollständige Name ist "Nicht-Regressionstest". Es kann auch ein Test sein, der vor dem Ändern einer Anwendung durchgeführt wurde, um sicherzustellen, dass die Anwendung das gleiche Ergebnis liefert.

Dazu werde ich hinzufügen:

• Abnahmeprüfung: Testen Sie, dass eine Funktion oder ein Anwendungsfall korrekt implementiert ist. Es ähnelt einem Integrationstest, aber mit Schwerpunkt auf den Anwendungsfall und nicht auf die beteiligten Komponenten.

• Systemtest: Testen Sie ein System als Black Box. Die Abhängigkeiten von anderen Systemen werden während des Tests häufig verspottet oder gestoppt (ansonsten wäre es eher ein Integrationstest).

• Überprüfung vor dem Flug: Tests, die in einer produktionsähnlichen Umgebung wiederholt werden, um das Syndrom "Builds auf meinem Maschinen" zu lindern. Oft wird dies durch einen Akzeptanz- oder Rauchtest in einer Produktion wie Umgebung erfasst.

Answer 2

• Gerätetest: Ein automatischer Test zum Testen der internen Arbeiten einer Klasse. Es sollte ein eigenständiger Test sein, der nicht mit anderen Ressourcen zusammenhängt.
• Integrationstest: Ein automatischer Test, der in einer Umgebung durchgeführt wird, so ähnlich wie Unit -Tests, jedoch mit externen Ressourcen (DB, Datenträgerzugriff)
• Regressionstest: Nachdem Sie neue Funktionen oder Fehlerbehebungen implementiert haben, testen Sie Szenarien, die in der Vergangenheit funktionierten. Hier decken Sie die Möglichkeit ab, in der Ihre neuen Funktionen vorhandene Funktionen brechen.
• Rauchprüfung: Erste Tests darüber, welche Tester zu dem Schluss kommen können, ob sie weiterhin getestet werden.

Answer 3

Jeder hat leicht unterschiedliche Definitionen und es gibt oft Grauzonen. Jedoch:

• Einheitstest: Funktioniert dieses eine kleine Bit (so isoliert wie möglich)?
• Integrationstest: Arbeiten diese beiden (oder mehr) Komponenten zusammen?
• Rauchentest: Hängt dieses ganze System (so nah wie möglich wie möglich ein Produktionssystem) einigermaßen gut zusammen? (IE sind wir einigermaßen zuversichtlich, dass es kein Schwarzes Loch erzeugt?)
• Regressionstest: Haben wir versehentlich irgendwelche Fehler, die wir zuvor behoben hatten, erneut eingeführt?

Answer 4

Eine neue Testkategorie, die ich gerade bewusst wurde, ist das:

Kanarische Test

EIN Kanarische Test ist ein automatisierter, nicht zerstörerischer Test, der ist regelmäßig laufen in einem LIVE Umwelt, so dass, wenn es jemals fehlschlägt, etwas wirklich Schlimmes passiert ist.

Beispiele könnten sein:

• Es gibt Daten, die immer nur in Dev/Test verfügbar sein sollten.
• Hat ein Hintergrundprozess nicht ausgeführt
• Kann sich ein Benutzer anmelden

Answer 5

Apokryphe historische Trivia: "Rauchprüfung" stammt aus der U -Boot -Ingenieurwesen (von der Sanitärerung geerbt), wo wörtlicher Rauch in den Rumpf gepumpt wird, um zu sehen, ob etwas davon wieder herauskam, was eher ein dramatisches Versagen für ein U -Boot wäre!

Answer 6

Antwort von einer der besten Websites für Software -Testtechniken:

Arten von Softwaretests - Vollständige Liste Klicken Sie hier

Es ist eine ziemlich lange Beschreibung, ich werde es hier nicht einfügen. Aber es kann für jemanden hilfreich sein, der alle Testtechniken kennenlernen möchte.

Hoffe es wird hilfreich sein :)

Answer 7

Unit -Test: Überprüfen Sie, ob die bestimmte Komponente (dh Klasse, Klasse) erstellt oder geändert wurde. Dieser Test kann manuell oder automatisiert sein, bewegt sich jedoch nicht über die Grenze der Komponente hinaus.

Integrationstest: Überprüfen Sie, ob die Wechselwirkung bestimmter Komponenten wie entworfen funktioniert. Integrationstests können auf Einheitenebene oder Systemebene durchgeführt werden. Diese Tests können manuell oder automatisiert werden.

Regressionstest: Überprüfen Sie, ob neue Defekte nicht in den vorhandenen Code eingeführt werden. Diese Tests können manuell oder automatisiert werden.

Abhängig von Ihrem SDLC (Wasserfall, RUP, Agile usw.) können bestimmte Tests in „Phasen“ durchgeführt werden oder alle gleichzeitig mehr oder weniger durchgeführt werden. Beispielsweise können Unit -Tests auf Entwickler beschränkt sein, die dann den Code für Integrations- und Regressionstests an Tester übergeben. Ein anderer Ansatz könnte jedoch Entwickler haben, die Unit -Tests durchführen und ein gewisses Maß an Integrations- und Regressionstests (unter Verwendung eines TDD -Ansatzes zusammen mit kontinuierlicher Integration sowie automatisierten Einheiten- und Regressionstests).

Der Toolsatz hängt weitgehend von der Codebasis ab, aber es gibt viele Open -Source -Tools für Unit -Tests (JUNIT). HPs (Mercury) QTP oder Borlands Silktest sind beide Werkzeuge für automatisierte Integrations- und Regressionstests.

Answer 8

unit test: testing of individual module or independent component in an application is known to be unit testing , the unit testing will be done by developer.

integration test: combining all the modules and testing the application to verify the communication and the data flow between the modules are working properly or not , this testing also performed by developers.

smoke test IN smoke test they check the application in shallow and wide manner, In smoke testing they check the main functionality of the application , if there is any blocker issue in the application they will report to developer team , and developing team will fix it and rectify the defect, and give it back to testing team and now testing team will check all the modules to verify tat changes made in one module will impact the other module or not. IN SMOKE TESTING the test cases are scripted

regression testing executing the same test cases repeatedly to ensure tat the unchanged module does not cause any defect. REGRESSION TESTING comes under functional testing

Answer 9

REGRESSION TESTING-

"A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software."

Answer 10

Unit testing is directed at the smallest part of the implementation possible. In java this means you are testing a single class. If the class depends on other classes these are faked.

When your test calls more than one class, its an integration test.

Full test suites can take a long time to run, so after a change many teams run some quick to complete tests to detect significant breakages. For example, you have broken the URIs to essential resources. These are the smoke tests.

Regression tests run on every build and allow you to refactor effectively by catching what you break. Any kind of test can be regression test, but I find unit tests are most helpful finding the source of fault.

Answer 11

Unit test: Verifying that particular component (i.e.,class) created or modified functions as designed. This test can be manual or automated but does not move beyond the boundary of the component.

Integration test: Verifying that the interaction of particular components function as designed. Integration tests can be performed at the unit level or the system level. These tests can be manual or automated.

Regression test: Verifying that new defects are not introduced into existing code. These tests can be manual or automated.

Depending upon your SDLC (waterfall, rup, agile, etc) particular tests may be performed in 'phases' or may all be performed, more or less, at the same time. For example, unit testing may be limited to developers who then turn the code over to testers for integration and regression testing. However another approach might have developers doing unit testing and some level of integration and regression testing (using a TDD approach along with continuous integration and automated unit and regression tests).

Answer 12

One type of test that seems to be worth mentioning in this thread is stress/performance/load tests which could be simply put as finding out the limits beyond which a certain piece of software breaks. Note that in terms of tooling it is essential to precisely determine the scope of what one proposes to stress tests from a system perspective. For instance in the case of a "web application" stress testing can include in its scope the web server application itself and so the tooling could intervene on that end. Here is a nice post about http load testing

Answer 13

• Integration Testing : Integration Testing is the Integrate the Another Element
• Smoke Testing : Smoke Testing is also known as build version Testing.Smoke testing is the initial testing process exercised to check whether the software under test is ready/stable for further testing.
• Regression Testing : Regression Testing is Reapeated Testing. Whether new software is effected in another module or not.
• Unit Testing : It is a White box Testing .Only Developers involve in it

Answer 14

Unit Testing:- unit testing is usually done by the developers side,where as testers are partly evolved in this type of testing where testing is done unit by unit. In java Junit test cases can also be possible to test whether the written code is perfectly designed or not.

Integration Testing:- This type of testing is possible after the unit testing when all/some components are integrated.This type of testing will make sure that when components are integrated,do they affect each others working capabilities or functionalists.

Smoke Testing:- This type of testing is done at the last when system is integrated successfully and ready to go on production server. This type of testing will make sure that every important functionality from start to end is working fine and system is ready to deploy on production server.

Regression Testing:- This type of testing is important to test that unintended/unwanted defects are not present in the system when developer fixed some issues. This testing also make sure that all the bugs are successfully solved and because of that no other issues are occurred.

Answer 15

Unit Testing: It always performs by developer after their development done to find out issue from their testing side before they make any requirement ready for QA.

Integration Testing: It means tester have to verify module to sub module verification when some data/function output are drive to one module to other module. Or in your system if using third party tool which using your system data for integrate.

Smoke Testing: tester performed to verify system for high-level testing and trying to find out show stopper bug before changes or code goes live.

Regression Testing: Tester performed regression for verification of existing functionality due to changes implemented in system for newly enhancement or changes in system.

Answer 16

Smoke and sanity testing are both performed after a software build to identify whether to start testing. Sanity may or may not be executed after smoke testing. They can be executed separately or at the same time - sanity being immediately after smoke.

Because sanity testing is more in-depth and takes more time, in most cases it is well worthed to be automated.

Smoke testing usually takes no longer than 5-30 minutes for execution. It is more general: it checks a small number of core functionalities of the whole system, in order to verify that the stability of the software is good enough for further testing and that there are no issues, blocking the run of the planned test cases.

Sanity testing is more detailed than smoke and may take from 15 minutes up to a whole day, depending on the scale of the new build. It is a more specialized type of acceptance testing, performed after progression or re-testing. It checks the core features of certain new functionalities and/or bug fixes together with some closely related to them features, in order to verify that they are functioning as to the required operational logic, before regression testing can be executed in larger scale.

Answer 17

Some good answers already but I would like further refine them:

Unit testing is the only form of white box testing here. The others are black box testing. White box testing means that you know the input, you know the inner workings of the mechanism and can inspect it and you know the output. With black box testing you only know what the input is and what the output should be.

So clearly unit testing is the only white box testing here.

• Unit testing test specific pieces of code. Usually methods.
• Integration testing test whether your new feature piece of software can intergrate with everything else.
• Regression testing. This is testing done to make sure you haven't broken anything. Everything that used to work should still work.
• Smoke testing is done as a quick test to make sure everything looks okay before you get involved in the more vigorous testing.

Answer 18

Regression test - Is a type of SW testing where we try to cover or check around the bug Fix. the functionality around the bug fix should not get changed or altered due to the Fix provided. Issues found in such process are called as Regression Issues.

Smoke Testing : Is a kind of testing done to decide whether to accept the Build/Software for further QA testing .

Answer 19

Smoke test has been explained here already and is simple. Regression test comes under integration test.

Automated tests can be divided into just 2.

Unit test and Integration Test. (this is all that matters)

I would call use the phrase "long test"(LT) for all tests like integration test, functional test, regression test, UI test , etc. And unit test as "short test".

A LT example could be, automatically loading a web page, logging in to the account and buying a book. If the test passes it is more likely to run on live site the same way(hence the 'better sleep' reference). Long = distance between web page(start) and database(end).

And this is a great article discussing the benefits of integration testing(long test) over unit testing

Answer 20

Unit tests Unit tests are very low level, close to the source of your application. They consist in testing individual methods and functions of the classes, components or modules used by your software. Unit tests are in general quite cheap to automate and can be run very quickly by a continuous integration server.

Integration tests Integration tests verify that different modules or services used by your application work well together. For example, it can be testing the interaction with the database or making sure that microservices work together as expected. These types of tests are more expensive to run as they require multiple parts of the application to be up and running.

Functional tests Functional tests focus on the business requirements of an application. They only verify the output of an action and do not check the intermediate states of the system when performing that action.

There is sometimes a confusion between integration tests and functional tests as they both require multiple components to interact with each other. The difference is that an integration test may simply verify that you can query the database while a functional test would expect to get a specific value from the database as defined by the product requirements.

End-to-end tests End-to-end testing replicates a user behavior with the software in a complete application environment. It verifies that various user flows work as expected and can be as simple as loading a web page or logging in or much more complex scenarios verifying email notifications, online payments, etc...

End-to-end tests are very useful, but they're expensive to perform and can be hard to maintain when they're automated. It is recommended to have a few key end-to-end tests and rely more on lower level types of testing (unit and integration tests) to be able to quickly identify breaking changes.

Acceptance testing Acceptance tests are formal tests executed to verify if a system satisfies its business requirements. They require the entire application to be up and running and focus on replicating user behaviors. But they can also go further and measure the performance of the system and reject changes if certain goals are not met.

Performance testing Performance tests check the behaviors of the system when it is under significant load. These tests are non-functional and can have the various form to understand the reliability, stability, and availability of the platform. For instance, it can be observing response times when executing a high number of requests, or seeing how the system behaves with a significant of data.

Performance tests are by their nature quite costly to implement and run, but they can help you understand if new changes are going to degrade your system.

Smoke testing Smoke tests are basic tests that check basic functionality of the application. They are meant to be quick to execute, and their goal is to give you the assurance that the major features of your system are working as expected.

Smoke tests can be useful right after a new build is made to decide whether or not you can run more expensive tests, or right after a deployment to make sure that they application is running properly in the newly deployed environment.

source: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing

Answer 21

I just wanted to add and give some more context on why we have these levels of test, what they really mean with examples

Mike Cohn in his book “Succeeding with Agile” came up with the “Testing Pyramid” as a way to approach automated tests in projects. There are various interpretations of this model. The model explains what kind of automated tests need to be created, how fast they can give feedback on the application under test and who writes these tests. There are basically 3 levels of automated testing needed for any project and they are as follows.

Unit Tests- These test the smallest component of your software application. This could literally be one function in a code which computes a value based on some inputs. This function is part of several other functions of the hardware/software codebase that makes up the application.

For example - Let’s take a web based calculator application. The smallest components of this application that needs to be unit tested could be a function that performs addition, another that performs subtraction and so on. All these small functions put together makes up the calculator application.

Historically developer writes these tests as they are usually written in the same programming language as the software application. Unit testing frameworks such as JUnit and NUnit (for java), MSTest (for C# and .NET) and Jasmine/Mocha (for JavaScript) are used for this purpose.

The biggest advantage of unit tests are, they run really fast underneath the UI and we can get quick feedback about the application. This should comprise more than 50% of your automated tests.

API/Integration Tests- These test various components of the software system together. The components could include testing databases, API’s (Application Programming Interface), 3rd party tools and services along with the application.

For example - In our calculator example above, the web application may use a database to store values, use API’s to do some server side validations and it may use a 3rd party tool/service to publish results to the cloud to make it available across different platforms.

Historically a developer or technical QA would write these tests using various tools such as Postman, SoapUI, JMeter and other tools like Testim.

These run much faster than UI tests as they still run underneath the hood but may consume a little more time than unit tests as it has to check the communication between various independent components of the system and ensure they have seamless integration. This should comprise more that 30% of the automated tests.

UI Tests- Finally, we have tests that validate the UI of the application. These tests are usually written to test end to end flows through the application.

For example - In the calculator application, an end to end flow could be, opening up the browser-> Entering the calculator application url -> Logging in with username/password -> Opening up the calculator application -> Performing some operations on the calculator -> verifying those results from the UI -> Logging out of the application. This could be one end to end flow that would be a good candidate for UI automation.

Historically, technical QA’s or manual testers write UI tests. They use open source frameworks like Selenium or UI testing platforms like Testim to author, execute and maintain the tests. These tests give more visual feedback as you can see how the tests are running, the difference between the expected and actual results through screenshots, logs, test reports.

The biggest limitation of UI tests is, they are relatively slow compared to Unit and API level tests. So, it should comprise only 10-20% of the overall automated tests.

The next two types of tests can vary based on your project but the idea is-

Smoke Tests

This can be a combination of the above 3 levels of testing. The idea is to run it during every code check in and ensure the critical functionalities of the system are still working as expected; after the new code changes are merged. They typically need to run with 5 - 10 mins to get faster feedback on failures

Regression Tests

They usually are run once a day at least and cover various functionalities of the system. They ensure the application is still working as expected. They are more details than the smoke tests and cover more scenarios of the application including the non-critical ones.