dido:public:ra:xapend:xapend.g_testing:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.g_testing:start [2021/11/08 15:58] char |
dido:public:ra:xapend:xapend.g_testing:start [2021/11/08 16:09] (current) char |
||
|---|---|---|---|
| Line 13: | Line 13: | ||
| : • Business acceptance Testing \\ | : • Business acceptance Testing \\ | ||
| : • Alpha Testing \\ | : • Alpha Testing \\ | ||
| - | : • Beta Testing | + | : • Beta Testing \\ |
| + | \\ | ||
| Source: [[https://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm]]</WRAP> | | Source: [[https://www.tutorialspoint.com/software_testing_dictionary/acceptance_testing.htm]]</WRAP> | | ||
| | [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting]] | <WRAP>**Black Box Testing** is a type of software testing in which the functionality of the software is not known. The testing is done without the internal knowledge of the products. \\ | | [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting]] | <WRAP>**Black Box Testing** is a type of software testing in which the functionality of the software is not known. The testing is done without the internal knowledge of the products. \\ | ||
| Black box testing can be done in the following ways:\\ | Black box testing can be done in the following ways:\\ | ||
| + | \\ | ||
| : 1. Syntax Driven Testing – This type of testing is applied to systems that can be syntactically represented by some language. For example- compilers and language that can be represented by context free grammar. In this, the test cases are generated so that each grammar rule is used at least once.\\ | : 1. Syntax Driven Testing – This type of testing is applied to systems that can be syntactically represented by some language. For example- compilers and language that can be represented by context free grammar. In this, the test cases are generated so that each grammar rule is used at least once.\\ | ||
| : 2. Equivalence partitioning – It is often seen that many type of inputs work similarly so instead of giving all of them separately we can group them together and test only one input of each group. The idea is to [[dido:public:ra:xapend:xapend.a_glossary:p:partition|partition]] the input domain of the system into a number of equivalence classes such that each member of class works in a similar way, i.e., if a test case in one class results in some error, other members of that class would also produce the same error. \\ | : 2. Equivalence partitioning – It is often seen that many type of inputs work similarly so instead of giving all of them separately we can group them together and test only one input of each group. The idea is to [[dido:public:ra:xapend:xapend.a_glossary:p:partition|partition]] the input domain of the system into a number of equivalence classes such that each member of class works in a similar way, i.e., if a test case in one class results in some error, other members of that class would also produce the same error. \\ | ||
| + | \\ | ||
| Source: [[https://www.geeksforgeeks.org/software-engineering-black-box-testing/]] | Source: [[https://www.geeksforgeeks.org/software-engineering-black-box-testing/]] | ||
| </WRAP> | | </WRAP> | | ||
| Line 30: | Line 31: | ||
| Source: [[https://www.browserstack.com/guide/end-to-end-testing]] | Source: [[https://www.browserstack.com/guide/end-to-end-testing]] | ||
| </WRAP> | | </WRAP> | | ||
| - | | [[dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting]] | <WRAP>**Integration Testing** is performed to test individual components to check how they function together. In other words, it is performed to test the modules which are working fine individually and do not show bugs when integrated. It is the most common functional testing type and performed as automated testing. | + | | [[dido:public:ra:xapend:xapend.a_glossary:i:integrationtesting]] | <WRAP>**Integration Testing** is performed to test individual components to check how they function together. In other words, it is performed to test the modules which are working fine individually and do not show bugs when integrated. It is the most common functional testing type and performed as automated testing. \\ |
| \\ | \\ | ||
| Generally, developers build different modules of the system/software simultaneously and don’t focus on others. They perform extensive [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting|black box]] and [[dido:public:ra:xapend:xapend.a_glossary:w:whiteboxtesting|white box]] functional [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin|verification]], commonly known as [[dido:public:ra:xapend:xapend.a_glossary:u:unittesting|unit tests]], on the individual modules. Integration tests cause data and operational commands to flow between modules which means that they have to act as parts of a whole system rather than as individual components. This typically uncovers issues with UI operations, data formats, operation timing, [[dido:public:ra:xapend:xapend.a_glossary:a:api | API]] calls, database access, and user [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interface]] operations.\\ | Generally, developers build different modules of the system/software simultaneously and don’t focus on others. They perform extensive [[dido:public:ra:xapend:xapend.a_glossary:b:blackboxtesting|black box]] and [[dido:public:ra:xapend:xapend.a_glossary:w:whiteboxtesting|white box]] functional [[dido:public:ra:xapend:xapend.a_glossary:v:vendorlockin|verification]], commonly known as [[dido:public:ra:xapend:xapend.a_glossary:u:unittesting|unit tests]], on the individual modules. Integration tests cause data and operational commands to flow between modules which means that they have to act as parts of a whole system rather than as individual components. This typically uncovers issues with UI operations, data formats, operation timing, [[dido:public:ra:xapend:xapend.a_glossary:a:api | API]] calls, database access, and user [[dido:public:ra:xapend:xapend.a_glossary:i:interface|interface]] operations.\\ | ||
| Line 39: | Line 40: | ||
| \\ | \\ | ||
| A connection that integrates two components is called an interface. This interface in the computer world could be anything like an [[dido:public:ra:xapend:xapend.a_glossary:a:api]], web services, etc. Testing of these connecting services or interfaces is referred to as Interface Testing. \\ | A connection that integrates two components is called an interface. This interface in the computer world could be anything like an [[dido:public:ra:xapend:xapend.a_glossary:a:api]], web services, etc. Testing of these connecting services or interfaces is referred to as Interface Testing. \\ | ||
| + | \\ | ||
| An interface is actually software that consists of sets of commands, messages, and other attributes, which enable communication between a device and a user. \\ | An interface is actually software that consists of sets of commands, messages, and other attributes, which enable communication between a device and a user. \\ | ||
| \\ | \\ | ||
dido/public/ra/xapend/xapend.g_testing/start.1636405087.txt.gz · Last modified: 2021/11/08 15:58 by char
