Software Testing
Testing can never completely identify all the defects within
software. Software testing is an investigation conducted to
provide stakeholders with information about the quality of the product or
service under test. Software testing can also provide an objective, independent
view of the software to allow the business to appreciate and understand the
risks of software implementation. Test techniques include, but are not limited
to, the process of executing a program or application with the intent of
finding software bugs (errors or other defects).
Software
testing can be stated as the process of validating and verifying that a
computer program/application/product:
§ meets the requirements
that guided its design and development,
§ works as expected,
§ can be implemented with
the same characteristics,
§ and satisfies the needs
of stakeholders.
A
primary purpose of testing is to detect software failures so that defects may
be discovered and corrected.
Functional vs non-functional Testing
Functional
testing refers to tests that verify a specific action or function of the code.
These are usually found in the code requirements documentation, although some
development methodologies work from use cases or user stories. Functional tests
tend to answer the question of “can the user do this” or “does this particular
feature work”.
Non-functional
testing refers to aspects of the software that may not be related to a specific
function or user action, such as scalability or security. Non-functional
testing tends to answer such questions as “how many people can log in at once”,
or “how easy is it to hack this software”.
Static vs. Dynamic Testing
There
are many approaches to software testing. Reviews, walkthroughs, or inspections
are referred to as static testing, whereas actually executing programmed code
with a given set of test cases is referred to as dynamic testing. Static
testing can be omitted, and unfortunately in practice often is. Dynamic testing
takes place when the program itself is used. Dynamic testing may begin before
the program is 100% complete in order to test particular sections of code and
are applied to discrete functions or modules.
Black box testing
Black-box
testing treats the software as a “black box”, examining functionality without
any knowledge of internal implementation. The tester is only aware of what the
software is supposed to do, not how it does it. One advantage of the black box
technique is that no programming knowledge is required.
White box testing
White-box
testing tests internal structures or workings of a program, as opposed to
the functionality exposed to the end-user.
Unit testing
Unit
testing, also known as component testing, refers to tests that verify the
functionality of a specific section of code, usually at the function level. In
an object-oriented environment, this is usually at the class level, and the
minimal unit tests include the constructors and destructors.
These
types of tests are usually written by developers as they work on code
(white-box style), to ensure that the specific function is working as expected.
One function might have multiple tests, to catch corner cases or other branches
in the code. Unit testing alone cannot verify the functionality of a piece of software,
but rather is used to assure that the building blocks the software uses work
independently of each other.
Integration testing
Integration
testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be
integrated in an iterative way or all together (“big bang”). Normally the
former is considered a better practice since it allows interface issues to be
localised more quickly and fixed.
Integration
testing works to expose defects in the interfaces and interaction between
integrated components (modules). Progressively larger groups of tested software
components corresponding to elements of the architectural design are integrated
and tested until the software works as a system.
Regression testing
Regression
testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, or old bugs that have
come back. Such regressions occur whenever software functionality that was
previously working correctly stops working as intended. Typically, regressions
occur as an unintended consequence of program changes, when the newly developed
part of the software collides with the previously existing code. Common methods
of regression testing include re-running previously run tests and checking
whether previously fixed faults have re-emerged. The depth of testing depends
on the phase in the release process and the risk of the added features. They
can either be complete, for changes added late in the release or deemed to be
risky, to very shallow, consisting of positive tests on each feature, if the
changes are early in the release or deemed to be of low risk.
Testing Tools
Program
testing and fault detection can be aided significantly by testing tools and
debuggers. Testing/debug tools include features such as:
§ Program monitors,
permitting full or partial monitoring of program code including:
§ Instruction set
simulator, permitting complete instruction level monitoring and trace
facilities
§ Program animation,
permitting step-by-step execution and conditional breakpoint at source level or
in machine code
§ Code coverage reports
§ Formatted dump or
symbolic debugging, tools allowing inspection of program variables on error or
at chosen points
§ Automated functional GUI
testing tools are used to repeat system-level tests through the GUI
§ Benchmarks, allowing
run-time performance comparisons to be made
§ Performance analysis (or
profiling tools) that can help to highlight hot spots and resource usage
Some of
these features may be incorporated into an Integrated Development Environment
(IDE).
No comments:
Post a Comment