27-08-2014, 02:43 PM
Testing is a process used to help identify the correctness, completeness and quality of developed computer software. With that in mind, testing can never completely establish the correctness of computer software There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following rote procedure. One definition of testing is "the process of questioning a product in order to evaluate it", where the "questions" are things the tester tries to do with the product, and the product answers with its behavior in reaction to the probing of the tester. Although most of the intellectual processes of testing are nearly identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of the product—putting the product through its paces. The quality of the application can and normally does vary widely from system to system but some of the common quality attributes include reliability, stability, portability, maintainability and usability. Refer to
Software Testing Fundamentals
Testing objectives include
1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as yet undiscovered error.
3. A successful test is one that uncovers an as yet undiscovered error.
Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications. The data collected through testing can also provide an indication of the software.s reliability and quality. But, testing cannot show the absence of defect -- it can only show that software defects are present.
Static Testing
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Review.s, Inspection.s and Walkthrough.s are static testing methodologies.
Static testing is a form of software testing where the software isn.t actually used. This is in contrast to dynamic testing. It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors. This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.
From the black box testing point of view, static testing involves review of requirements or specifications. This is done with an eye toward completeness or appropriateness for the task at hand. This is the verification portion of Verification and Validation.
Bugs discovered at this stage of development are less expensive to fix than later in the development cycle.
Static Code Analysis
Static code analysis is the analysis of computer software that is performed without actually executing programs built from that software (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code. The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding or program comprehension.
The sophistication of the analysis performed by tools varies from those that only consider the behavior of individual statements and declarations, to those that include the complete source code of a program in their analysis. Uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behavior matches that of its specification).
Some people consider software metrics and reverse engineering to be forms of static analysis.
A growing commercial use of static analysis is in the verification of properties of software used in safety-critical computer systems and locating potentially vulnerable code.
Formal Methods
Formal methods are the term applied to the analysis of software (and hardware) whose results are obtained purely through the use of rigorous mathematical methods. The mathematicaltechniques used include denotation semantics, axiomatic semantics, operational semantics, and abstract interpretation.
It has been proven that, barring some hypothesis that the state space of programs is finite and small, finding possible run-time errors, or more generally any kind of violation of a specification on the final result of a program, is undecidable: there is no mechanical method that can always answer truthfully whether a given program may or may not exhibit runtime errors. This result dates from the works of Church, Gödel and Turing in the 1930s (see the halting problem and Rice.s theorem). As with most undecidable questions, one can still attempt to give useful approximate solutions.
Some of the implementation techniques of formal static analysis include:
Model checking considers systems that have finite state or may be reduced to finite state by abstraction;
Abstract interpretation models the effect that every statement has on the state of an abstract machine (i.e., it .executes. the software based on the mathematical properties of each statement and declaration).
Use of assertions in program code as first suggested by Hoare logic. There is tool support for some programming languages (e.g., the SPARK programming language (a subset of Ada) and the Java Modeling Language — JML — using ESC/Java and ESC/Java2).
3: Dynamic Testing
Overview
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
Dynamic testing
It is a term used in software engineering to describe the testing of the dynamic behavior of code. That is, dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time.
In dynamic testing the software must actually be compiled and run; this is in contrast to static testing. Dynamic testing is the validation portion of Verification and Validation.
Methodologies
Some of dynamic testing methodologies include:
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
4: BLACK BOX TESTING
Introduction: Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object.s internal structure
This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, one cannot be sure that all existent paths are tested.
Contents:
Testing Strategies/Techniques
Black Box Testing Strategy
Black Box Testing Example
Advantages and Disadvantages
Dimensions for Examining Testing
Testing Strategies/Techniques
Black box testing should make use of randomly generated inputs (only a test range should be specified by the tester), to eliminate any guess work by the tester as to the methods of the function
Data outside of the specified input range should be tested to check the robustness of the program
Boundary cases should be tested (top and bottom of specified range) to make sure the highest and lowest allowable inputs produce proper output
The number zero should be tested when numerical data is to be input
Stress testing should be performed (try to overload the program with inputs to see where it reaches its maximum capacity), especially with real time systems
Crash testing should be performed to see what it takes to bring the system down
Test monitoring tools should be used whenever possible to track which tests have already been performed and the outputs of these tests to avoid repetition and to aid in the software maintenance
Other functional testing techniques include: transaction testing, syntax testing, domain testing, logic testing, and state testing.
Finite state machine models can be used as a guide to design functional tests
According to Beizer the following is a general order by which tests should be designed:
1. Clean tests against requirements.
2. Additional structural tests for branch coverage, as needed.
3. Additional tests for data-flow coverage as needed.
4. Domain tests not covered by the above.
5. Special techniques as appropriate--syntax, loop, state, etc.
6. Any dirty tests not covered by the above.
Black Box Testing Strategy
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".
Black Box Testing Example
In this technique, we do not use the code to determine a test suite; rather, knowing the problem that we.re trying to solve, we come up with four types of test data
1. Easy-to-compute data
2. Typical data
3. Boundary / extreme data
4. Bogus data
Advantages and Disadvantages
Advantages of Black Box Testing
More effective on larger units of code than glass box testing
Tester needs no knowledge of implementation, including specificprogramming languages
Tester and programmer are independent of each other
Tests are done from a user.s point of view
Will help to expose any ambiguities or inconsistencies in the specifications
Test cases can be designed as soon as the specifications are complete