Commit e6b22bc9 by Dinh Thanh Truc

Update BasicTesting.md

parent 6fff462a
# Basic testing
1.Specfication-based testing (black-box):have no knowledge about the system or component inside the box works, only know the input/output.
2.Structure-based testing(white-box):know the internal structure of the software to derive test cases
3.Experience-based testing:it is based on the experience of technical, business and similar systems
4.Gray-box testing: have some knowledge of the internal structure but not in detailed to design test cases and test the application from the outside
## Simple techniques
- Specfication-based testing (black box):
## Test Principals
1. Testing shows presence of defects:
Testing can show that defects are present, but cannot prove that there are no defects.
Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found,it is not a proof of correctness.
2. Exhaustive testing is impossible:
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases.
Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
3. Early testing:
Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
4. Defect clustering:
One phenomenon that many testers have observed is that defects tend to cluster. This can happen because an area of the code is particularly complex and tricky, or because changing software and other products tends to cause knock-on defects.
Testers will often use this information when making their risk assessment for planning the tests
5. Pesticide paradox:
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs.
To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
6. Testing is context dependent:
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
7. Absence-of-errors fallacy:
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations. Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.
Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
## Test levels
In the waterfall model, testing tends to happen towards the end of the project life cycle so defects are detected close to the live implementation date.
It is difficult to go back and fix the feedback. The V-model was developed to address the problem of the waterfall approach.
Within the V-model, validation testing takes place especially during the early stages, e.g. reviewing the user requirements, and late in the life cycle, e.g. during user acceptance testing.
A common type of V-model uses four test levels:
* Component testing (unit testing): Verify the function of software components (e.g. modules, programs, objects, classes etc.) that are separately testable
* Integration testing: Test interfaces between components, interactions to different parts of a system such as an operating system, file system and hardware or interfaces between systems
* System testing: Concerned with the behavior of the whole system/product. The main focus of system testing is verification against specified requirements
* Acceptance testing: Validation testing with respect to user needs, requirements, and business processes to determine whether or not to accept the system.
In practice, a V-model may have more, fewer or different levels of development and testing, depending on the project and the software product
## Testing Technique
There are many different types of software testing technique.Each individual technique is good at finding particular types of defect and relatively poor at finding other types.
Each testing technique falls into one of a number of different categories but there are two main categories: static and dynamic testing.
### - Static testing
Static testing techniques do not execute the code, it is used to test any form of document including source code, design documents and models, functional specifications and requirement specifications.
It starts early in the life cycle, generally before any tests are executed on the software so it is called non-execution technique.
By detecting defects at an early stage ( when they are documentary),it will take less effort for fixing and prevent the faillures at the late stage (Ex: acceptance testing stage).
### - Dynamic testing
With dynamic testing methods, software is executed using a set of input values and its output is then examined and compared to what is expected.It is applied as a technique to detect defects and to determine quality attributes of the code.
Dynamic techniques are divided into the following categories:
1.Specfication-based testing (black-box):you have no knowledge about the system or component inside the box works, only know the input/output.
2.Structure-based testing(white-box):you know the internal structure of the software to derive test cases
3.Experience-based testing:it is based on the experience of technical, business and similar systems
There is also the grey-box testing: It means have some knowledge of the internal structure (but not in detailed) to design test cases and test the application from the outside
#### _+Specfication-based testing (black box) technique:_
1. Equivalence partitioning:You divide a set of test conditions into groups or sets that can be considered the same ( the system handle them equivalently). We need test only one condition from each partition. If one in a parttion does not work, we assume none in that partition work. You may try more than one value from a partition.
......@@ -23,15 +91,15 @@
Ex:If you are a new customer opening a credit card account, you will get a 15% discount on all your purchases today. If you are an existing customer and you hold a loyalty card, you get a 10% discount
New * * * * * |T |T |F |F |
New* * * * |T |T |F |F |
Loyalty * * * |T |F |T |F |
Loyalty* * |T |F |T |F |
Discount % |X |15|10|X |
4. Use case testing: Use cases describe the process flows through a system based on its most likely use. This makes the test cases derived from use cases particularly good for finding defects in the real-world use of the system (i.e. the defects that the users are most likely to come across when first using the system)
- Structure-based testing(white-box):
#### _+Structure-based testing(white-box) technique:_
1. Statement coverage and statement testing:
......@@ -57,8 +125,7 @@
* Test 2: A =0, B = 25
* Test 3: A =20, B = 25
In Test 1, the value of C will be 8, so we will cover the statements on lines 1 to 4 and line 6, we have 83% statement
coverage
In Test 1, the value of C will be 8, so we will cover the statements on lines 1 to 4 and line 6, we have 83% statement coverage
In Test 2, the value of C will be 50, so we will cover exactly the same state ments as Test 1.
......@@ -94,7 +161,7 @@ coverage
This now covers both of the decision outcomes True and False.
- Experience-based testing:
#### _+ Experience-based testing technique:_
1. Error guessing:
......@@ -102,4 +169,6 @@ coverage
2. Exploratory testing:
Exploratory testing is an approach in which the test design and test execution activities are performed in parallel without formally documenting the test conditions, test cases or test scripts. It is most useful when there are no or poor specifications and when time is severely limited. It can also serve to complement other formal testing, helping to establish greater confidence in the software.
\ No newline at end of file
Exploratory testing is an approach in which the test design and test execution activities are performed in parallel without formally documenting the test conditions, test cases or test scripts. It is most useful when there are no or poor specifications and when time is severely limited. It can also serve to complement other formal testing, helping to establish greater confidence in the software.
> _Source: Foundation of software testing- Dorothy Graham_
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment