Software testing
-
Upload
balamurugank-kalibalamurugan -
Category
Technology
-
view
106 -
download
0
Transcript of Software testing
![Page 1: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/1.jpg)
Software Testing
![Page 2: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/2.jpg)
Software Testing The objective of software testing is
to find greatest possible number of errors with a manageable amount of effort applied over a realistic time span
![Page 3: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/3.jpg)
Testing Objectives1. 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.
![Page 4: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/4.jpg)
Testing Principles All tests should be traceable to
customer requirements Tests should be planned long before
testing begins. Testing should begin “in the small”
and progress toward testing “in the large.”
Exhaustive testing is not possible. To be most effective, testing should
be conducted by an independent third party.
![Page 5: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/5.jpg)
Characteristics of Testing
Testability Software testability is simply how easily [a computer program] can be tested.
Operability. "The better it works, the more efficiently it can be tested.“
Observability. "What you see is what you test.“
Controllability. "The better we can control the software, the more the testing can be automated and optimized.“
Decomposability. "By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting."
![Page 6: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/6.jpg)
Simplicity. "The less there is to test, the more quickly we can test it.“
Stability. "The fewer the changes, the fewer the disruptions to testing.“
Understandability. "The more information we have, the smarter we will test."
![Page 7: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/7.jpg)
Testing Strategy Any Testing strategy must
incorporate Test planning Test case design Test execution Resultant data collection and evaluation
![Page 8: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/8.jpg)
Generic Characteristics of S/W Testing Strategy
To perform effective testing, a software team should conduct effective formal technical reviews. By doing this, many errors will be eliminated before testing commences
Testing begins at the component level and works "outward" toward the integration of the entire computer-based system.
Different testing techniques are appropriate at different points in time.
Testing is conducted by the developer of the software and (for large projects) an independent test group.
Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.
![Page 9: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/9.jpg)
Attributes of a “good” test: A good test has a high probability of
finding an error. A good test is not redundant. A good test should be “best of
breed” A good test should be neither too
simple nor too complex.
![Page 10: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/10.jpg)
Verification and Validation
Verification refers to the set of activities that ensure that software correctly implements a specific function.
Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
Verification: "Are we building the product right?"Validation: "Are we building the right product?"
![Page 11: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/11.jpg)
SQA activities of Verification and validation
Formal Technical Reviews Quality And Configuration Audits Performance Monitoring Simulation, Feasibility Study Documentation Review Database Review Algorithm Analysis, Development Testing Qualification Testing Installation Testing
![Page 12: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/12.jpg)
Developer versus Tester Who knows the program better than its
developers? The software engineer creates a computer
program, its documentation, and related data structures.
The role of an independent test group (ITG) is to remove the inherent problems associated with letting the builder test the thing that has been built.
The developer and the ITG work closely throughout a software project to ensure that thorough tests will be conducted.
While testing is conducted, the developer must be available to correct errors that are uncovered.
![Page 13: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/13.jpg)
![Page 14: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/14.jpg)
![Page 15: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/15.jpg)
Software Testing Strategy - Spiral
![Page 16: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/16.jpg)
Spiral view of Testing Strategy
Unit testing begins at the vortex of the spiral and concentrates on each unit (i.e., component) of the software as implemented in source code.
Testing progresses by moving outward along the spiral to integration testing, where the focus is on design and the construction of the software architecture.
Taking another turn outward on the spiral, we encounter validation testing, where requirements established as part of software requirements analysis are validated against the software that has been constructed.
Finally, we arrive at system testing, where the software and other system elements are tested as a whole
![Page 17: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/17.jpg)
![Page 18: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/18.jpg)
Procedural view of Testing Strategy
![Page 19: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/19.jpg)
![Page 20: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/20.jpg)
Strategic Issues Specify product requirements in a
quantifiable manner long before testing commences.
State testing objectives explicitly. Understand the users of the software and
develop a profile for each user category. Develop a testing plan that emphasizes
“rapid cycle testing.” Build “robust” software that is designed
to test itself. Use effective formal technical reviews as
a filter prior to testing. Conduct formal technical reviews to
assess the test strategy and test cases themselves.
Develop a continuous improvement approach for the testing process.
![Page 21: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/21.jpg)
Unit Testing
![Page 22: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/22.jpg)
![Page 23: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/23.jpg)
![Page 24: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/24.jpg)
![Page 25: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/25.jpg)
Integration Testing Strategies
Incremental Integration Top-down Integration
Depth-First Integration Breadth-First Integration
Bottom-Up Integration Non-Incremental Integration
![Page 26: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/26.jpg)
Integration Process Steps
1. The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module.
2. Depending on the integration approach selected (i.e., depth or breadth first), subordinate stubs are replaced one at a time with actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with the real component.
5. Regression testing (Section 18.4.3) may be conducted to ensure that new errors have not been introduced.
![Page 27: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/27.jpg)
![Page 28: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/28.jpg)
Depth-First IntegrationDepth-First IntegrationDepth-First Integration
Integrating Path : M1 – M2 – M5 – M8
![Page 29: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/29.jpg)
Breadth-First Integration
Integrating Path : M2 – M3 – M4
![Page 30: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/30.jpg)
Bottom-up Integration
![Page 31: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/31.jpg)
Bottom-up IntegrationA bottom-up integration strategy may be
implementedwith the following steps:1. Low-level components are combined into
clusters (sometimes called builds) that perform a specific software sub-function.
2. A driver (a control program for testing) is written to coordinate test case input and output.
3. The cluster is tested.4. Drivers are removed and clusters are
combined moving upward in the program structure.
![Page 32: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/32.jpg)
![Page 33: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/33.jpg)
Regression Testing Each time a new module is added as
part of integration testing, the software changes. New data flow paths are established, new I/O may occur, and new control logic is invoked.
Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects.
![Page 34: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/34.jpg)
Smoke Testing Smoke testing is an integration
testing approach that is commonly used when “shrinkwrapped” software products are being developed.
It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess its project on a frequent basis.
![Page 35: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/35.jpg)
Benefits of Smoke Testing
Integration risk is minimized. The quality of the end-product is
improved. Error diagnosis and correction are
simplified. Progress is easier to assess.
![Page 36: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/36.jpg)
The following criteria and corresponding tests are applied
for all test phases:
Interface integrity. Internal and external interfaces are tested as each module (or cluster) is incorporated into the structure.
Functional validity. Tests designed to uncover functional errors are conducted.
Information content. Tests designed to uncover errors associated with local or global data structures are conducted.
Performance. Tests designed to verify performance bounds established during software design are conducted.
![Page 37: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/37.jpg)
Validation Testing Testing focuses on user-visible
actions and user-recognizable output from the system.
Validation succeeds when software functions in a manner that can be reasonably expected by the customer.
Reasonable expectations are defined in the Software Requirements Specification - a document that describes all user-visible attributes of the software.
![Page 38: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/38.jpg)
Validation Test CriteriaValidation should ensure
Functional requirements are satisfied
Behavioral characteristics are achieved
Performance requirements are attained
Documentation is correct Usability, Transportability,
Compatibility, Error recovery and Maintainability are met
![Page 39: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/39.jpg)
Alpha and Beta Testing Software product builders use a
process called alpha and beta testing to uncover errors that only the end-user seems able to find.
The alpha test is conducted at the developer's site by a customer.
The beta test is conducted at one or more customer sites by the end-user of the software.
![Page 40: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/40.jpg)
System Testing System testing is actually a series of
different tests whose primary purpose is to fully exercise the computer-based system.
Software is incorporated with other system elements (e.g., hardware, people, information), and a series of system integration and validation tests are conducted.
![Page 41: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/41.jpg)
Types of System Testing Recovery testing is a system test
that forces the software to fail in a variety of ways and verifies that recovery is properly performed.
Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration.
Performance testing is designed to test the run-time performance of software within the context of an integrated system.
![Page 42: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/42.jpg)
Stress Testing Stress tests are designed to confront
programs with abnormal situations. Stress testing executes a system in a
manner that demands resources in abnormal quantity, frequency, or volume.
Examples:(1) special tests may be designed that generate
ten interrupts per second, when one or two is the average rate
(2) input data rates may be increased by an order of magnitude to determine how input functions will respond,
(3) test cases that require maximum memory or other resources are executed,
![Page 43: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/43.jpg)
Stress Testing Stress testing is done to evaluate a
system beyond the limits of specified requirements or resources, to ensure that system does not break.
The product is overloaded deliberately to simulate the resource crunch and to find out the behavior
Stress testing helps in understanding how the system can behave under extreme situations (insufficient memory, inadequate hardware)
![Page 44: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/44.jpg)
Stress testing In stress testing, the load is generally
increased through various means such as increasing the number of clients, users and transactions.
When the load keeps on increasing, the product reaches a stress point when some of the transactions start failing due to resources not being available. The failure rate may go up beyond this point.
To continue the stress testing, the load is slightly reduced below this stress point to see whether the product recovers and whether the failure rate decreases appropriately
This exercise of increasing/decreasing the load is performed two or three times to check for consistency in behavior and expectations.
![Page 45: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/45.jpg)
MTTR (Mean Time to Recovery)
Stress point
Increasing load
Decreasing load
Failure rate
The time required for the product to quickly recover from the failures is represented as MTTR
![Page 46: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/46.jpg)
Guidelines for Stress testing
The following guidelines can be used to select the tests for stress testing Repetitive tests Concurrency Magnitude Random variation
![Page 47: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/47.jpg)
Debugging Debugging is not testing but always
occurs as a consequence of testing. Debugging occurs as a consequence
of successful testing. When a test case uncovers an error,
debugging is the process that results in the removal of the error.
![Page 48: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/48.jpg)
Debugging Process
![Page 49: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/49.jpg)
Testing Types
![Page 50: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/50.jpg)
WHITE-BOX TESTING White-box testing, sometimes called
glass-box testing, is a test case design method that uses the control structure of the procedural design to derive test cases.
The software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once,(2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, (4) exercise internal data structures to ensure their validity.
![Page 51: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/51.jpg)
WHITE-BOX TESTING
Static testing
Desk Checking
Code Walkthrough
Code Inspection
Structural Testing
Code Coverage
Statement coverage
Path coverage
Condition coverage
Function coverage
Code complexity
Cyclomatic complexity
Unit / codeFunctional
testing
![Page 52: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/52.jpg)
Static Testing Static testing is a type of testing which
requires only the source code of the product, not the binaries and executables
To find out whether The code works according to the functional
requirements The code has been return in accordance with
the design developed The code for any functionalities has been
missed out The code handles errors properly
![Page 53: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/53.jpg)
Static testing by humans Sometimes human find errors that computers
cannot. Ex: two variables with similar names and the programmer used a wrong variable by mistake in an expression
Multiple humans read and evaluate identifies more problem identified upfront than a computer could
Human evaluation of the code can compare it against the specification
Human evaluation can detect many problems at one go and tries to identify the root cause
A proactive method of static testing minimizes the delay in identification of the problem
![Page 54: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/54.jpg)
Desk checking Manually done by the author of the code for
correctness checking Desk checking done before compiling and
executing Done by comparing the code with the design or
specification When error found, author applies the
correctness for error on spot Completely relies on author’s thoroughness and
skills No structured method or formalism to ensure
completeness No maintaining of a log or checklist Only effective for coding errors but not for
incorrect understanding of requirements. This is because the developers might not have domain knowledge required to understand the requirements.
![Page 55: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/55.jpg)
Code walkthrough It is a group-oriented method It is a informal method Set of people look at the program
and question the author. The author explains the logic of the
code and answers the questions. Unanswered questions are noted
down and author finds the answer.
![Page 56: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/56.jpg)
Code Inspection It is a formal method The focus is to detect all faults, violations
and other side effects Code inspection starts when author made
sure the code is ready after desk checking and walkthrough.
Members of the meeting: The author of the code Moderator: formally runs the inspection
according to the process Inspectors: Provides review comments for the
code Scribe: takes detailed notes during the meeting
and circulates them to the inspection team
![Page 57: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/57.jpg)
Structural testing Structural testing takes into account the
code, code structure, internal design and how they are coded
Structural testing run by computer on the built product whereas in static testing is done by humans just using the source code.
A given portion of the code is exercised if a test case causes the program to execute that portion of the code when running the test
![Page 58: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/58.jpg)
Unit/code functional testing
Quick check by developer before subjecting the code to more extensive code coverage testing or code complexity testing.
Developer performs this tests knowing the input variable and the corresponding expected output variables
Developer can build a “debug version” of the product by putting “intermediate print statements” and making sure the program is passing thro the right loops and iterations the right no. of times
Testing the product under a debugger or an IDE by setting “break points” at any functions or instructions.
All the above fall under the “debugging” category rather than “testing” category
![Page 59: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/59.jpg)
Code coverage testing Code coverage testing involves
designing and executing test cases and finding out the percentage of code that is covered by testing.
Program constructs Sequential control flow Two-way decision statements (if then
else) Multi-way decision statements ( switch) Loops ( while do, repeat until and for)
![Page 60: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/60.jpg)
Statement coverage Refers to writing test cases that execute each
of the program statements More the code is covered, the better is the
testing of the functionalities Test cases can be designed to run through top
to bottom Exceptions might make the test case not
covering all the statements To cover all the statements for “if constructs”,
one test case for then part and one for else part should be designed
Switch statement is reduced as multiple “if constructs”
![Page 61: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/61.jpg)
Statement coverage ( cont…)
For better statement coverage for loop constructs, test cases should be Skip the loop completely, so that the
situation of the termination condition being true before starting the loop is tested
Exercise the loop between once and the maximum number of times, to check all possible “normal” operations of the loop.
Try covering the loop, around the boundary of n – that is, just below n, n and just above n
![Page 62: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/62.jpg)
Path coverage In path coverage, program is split
into number of distinct path A program can start from the
beginning and take any paths to its completion
Path coverage provides a stronger condition of coverage than statement coverage as it relates to the various logical paths in the program rather than just program statements
![Page 63: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/63.jpg)
Condition coverage All the conditions may not get
evaluated, even though the right path is chosen.
Example:
If (mm<1 || MM>12)
true
false
Valid month
invalid month No. of Paths = 2A – BA – C
The path A – B has two conditions to be tested and therefore need two test cases
![Page 64: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/64.jpg)
Function coverage Identifies how many program
functions are covered by test cases The requirements of the product are
mapped into functions during the design phase and each of the functions form a logical unit.
Example: Inserting a row in a database
![Page 65: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/65.jpg)
BASIS PATH TESTING Basis path testing is a white-box
testing technique The basis path method enables the
test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths.
Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.
![Page 66: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/66.jpg)
Flow Graph Notation Flow graph is a simple notation for the
representation of control flow. Each circle, called a flow graph node,
represents one or more procedural statements.
The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows.
Areas bounded by edges and nodes are called regions.
When counting regions, we include the area outside the graph as a region
![Page 67: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/67.jpg)
Cyclomatic Complexity Cyclomatic complexity is a software
metric that provides a quantitative measure of the logical complexity of a program.
Cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.
![Page 68: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/68.jpg)
Flow graph Example
![Page 69: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/69.jpg)
Independent Path
path 1: 1-11path 2: 1-2-3-4-5-10-
1-11path 3: 1-2-3-6-8-9-
10-1-11path 4: 1-2-3-6-7-9-
10-1-11
![Page 70: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/70.jpg)
Cyclomatic complexityComplexity is computed in one of three ways:1. The number of regions of the flow graph correspond
to the cyclomatic complexity.2. Cyclomatic complexity, V(G), for a flow graph, G, is
defined asV(G) = E - N + 2
where E is the number of flow graph edges, N is the number of
flow graph nodes.3. Cyclomatic complexity, V(G), for a flow graph, G, is
also defined asV(G) = P + 1
where P is the number of predicate nodes contained in the flow graph
G.
![Page 71: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/71.jpg)
Computing Cyclomatic complexity
1. The flow graph has four regions.
2. V(G) = 13 edges - 11 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.
![Page 72: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/72.jpg)
Graph Matrices A graph matrix is a square matrix
whose size (i.e., number of rows and columns) is equal to the number of nodes on the flow graph. Each row and column corresponds to an identified node, and matrix entries correspond to connections (an edge) between nodes.
![Page 73: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/73.jpg)
Graph Matrices
![Page 74: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/74.jpg)
Graph Matrices
![Page 75: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/75.jpg)
CONTROL STRUCTURE TESTING
Condition Testing Condition testing is a test case design method
that exercises the logical conditions contained in a program module.
E1 <relational-operator> E2where E1 and E2 are arithmetic expressions and
<relational-operator> is one of the following: <, ≤, =, ≠ (nonequality), >, or ≥.
A compound condition is composed of two or more simple conditions, Boolean operators, and parentheses.
![Page 76: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/76.jpg)
Loop Testing
![Page 77: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/77.jpg)
BLACK-BOX TESTING Black-box testing, also called
behavioral testing, focuses on the functional requirements of the software.
Black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.
![Page 78: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/78.jpg)
BLACK-BOX TESTING Black-box testing attempts to find
errors in the following categories:(1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or
external database access, (4) behavior or performance errors,(5) initialization and termination
errors.
![Page 79: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/79.jpg)
Equivalence Partitioning Equivalence partitioning is a black box
testing technique to minimize number of permutation and combination of input data.
In equivalence partitioning, data is selected in such a way that it gives as many different out put as possible with the minimal set of data.
If software behaves in an identical way for a set of value, then the set is termed as equivalence class or a partition.
It can be assumed safely that functionality of the software will be same for any data value from the equivalence class or partition.
![Page 80: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/80.jpg)
Equivalence Partitioning Steps in Equivalence Partitioning
Identifying equivalence classes or partition
Picking one value from each partition for the complete coverage.
Equivalence classes may be defined according to the following guidelines:1. If an input condition specifies a range, one valid
and two invalid equivalence classes are defined.2. If an input condition requires a specific value,
one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined.
![Page 81: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/81.jpg)
Example For example, consider a very simple
function for awarding grades to the students. This program follows the following guideline to award grades Marks 00 – 39 ------------ Grade D Marks 40 – 59 ------------ Grade C Marks 60 – 70 ------------ Grade B Marks 71 – 100 ------------ Grade A
![Page 82: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/82.jpg)
Example Based on the equivalence partitioning
techniques, partitions for this program could be as follows Marks between 0 to 39 - Valid Input Marks between 40 to 59 - Valid Input Marks between 60 to 70 - Valid Input Marks between 71 to 100 - Valid Input Marks less than 0 - Invalid Input Marks more than 100 - Invalid Input Non numeric input - Invalid Input
Now even if you take only one data value from these partitions, your coverage will be good.
![Page 83: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/83.jpg)
Boundary Value Analysis Boundary value analysis leads to a selection
of test cases that exercise bounding values. Boundary value analysis is a test case
design technique that complements equivalence partitioning.
Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class.
Boundary value analysis is the technique of making sure that behavior of system is predictable for the input and output boundary conditions.
Defects could be introduced at the boundaries very easily.
![Page 84: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/84.jpg)
Example " Input should be greater than equal
to 10 and less than 50" Probably you will write something
like if (input >=10 AND input <50) then do some else do some thing else.
![Page 85: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/85.jpg)
ExampleAccording to this input values from 10 to 49 are valid, but if you make mistake in specifying the conditions, following things can happen input >10 AND input <50 -------> Input value 10 in
invalid now. input <=10 AND input <50 -------> Input value 9 is
valid now. input >=10 AND input <=50 -----> Input value 50
is valid now input >=10 AND input >50 -----> Input value 49 is
invalid now.
we should have following test cases for boundaries9, 10, 11 and 48, 49, 50
lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1, upper_boundary, upper_boundary + 1
![Page 86: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/86.jpg)
Guidelines for BVA1. If an input condition specifies a range
bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b.
2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested.
3. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
![Page 87: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/87.jpg)
Testing for Specialized Environment
![Page 88: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/88.jpg)
Testing for Specialized Environment
Testing GUI Testing Client / Server Architecture Testing Documentation and Help
facilities Testing Real-time Systems. Testing Websites
![Page 89: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/89.jpg)
Testing GUI Graphical user interfaces (GUIs) present
interesting challenges for software engineers.
Because of reusable components provided as part of GUI development environments, the creation of the user interface has become less time consuming and more precise.
The complexity of GUIs has grown, leading to more difficulty in the design and execution of test cases.
Finite state modeling graphs may be used to derive a series of tests
Due to the large number of permutations associated with GUI operations, testing should be approached using automated tools.
![Page 90: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/90.jpg)
Testing Client/Server Architecture
Difficulties of C/S Testing Distributed nature of client/server
environments, The performance issues associated with
transaction processing, The potential presence of a number of
different hardware platforms, The complexities of network
communication, The need to service multiple clients
from a centralized (or in some cases, distributed) database,
The coordination requirements imposed on the server
![Page 91: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/91.jpg)
Testing of C/S occurs at three levels
1. Individual client applications are tested in a “disconnected” mode; the operation of the server and the underlying network are not considered
2. The client software and associated server applications are tested in concert, but network operations are not explicitly exercised.
3. The complete Client/Server architecture, including network operation and performance, is tested.
![Page 92: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/92.jpg)
Testing approaches for C/S
Application function test The functionality of client application is tested
Server tests Co-ordination and data management functions of
the server are tested Database tests
The accuracy and integrity of data stored by the server is tested
Transaction tests A series of tests are created to ensure that each
class of transactions is processed according to the requirement
Network communication tests These tests verify that communication among the
nodes of the network occurs correctly and that message passing, transactions, and related network traffic occur without error.
![Page 93: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/93.jpg)
Testing Documentation and Help Facility
Errors in documentation can be as devastating to the acceptance of the program as errors in data or source code.
Nothing is more frustrating than following a user guide or an on-line help facility exactly and getting results or behaviors that do not coincide with those predicted by the documentation
![Page 94: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/94.jpg)
Phases of documentation testing
Documentation testing can be approached in two phases.
1. review and inspection, examines the document for editorial clarity.
2. live test, uses the documentation in conjunction with the use of the actual program.
![Page 95: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/95.jpg)
The following questions should be answered during both
phases:
Does the documentation accurately describe how to accomplish each mode of use?
Is the description of each interaction sequence accurate?
Are examples accurate? Are terminology, menu descriptions, and
system responses consistent with the actual program?
Is it relatively easy to locate guidance within the documentation?
Can troubleshooting be accomplished easily with the documentation?
![Page 96: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/96.jpg)
Questions (cont…) Are the document table of contents and
index accurate and complete? Is the design of the document (layout,
typefaces, indentation, graphics) conducive to understanding and quick assimilation of information?
Are all software error messages displayed for the user described in more detail in the document? Are actions to be taken as a consequence of an error message clearly delineated?
If hypertext links are used, are they accurate and complete?
If hypertext is used, is the navigation design appropriate for the information required?
![Page 97: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/97.jpg)
Testing for real-time systems
Many real-time applications are time-dependent, asynchronous nature
The test case designer have to consider white- and black-box test cases but also event handling (i.e., interrupt
processing), the timing of the data, the parallelism of the tasks (processes)
that handle the data.
![Page 98: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/98.jpg)
Strategy for Real-Time testing
Task testing. Testing of real-time software is to test each
task independently. Task testing uncovers errors in logic and
function but not timing or behavior. Behavioral testing Inter-task testing. System testing.
Software and hardware are integrated and a full range of system tests (Chapter 18) are conducted in an attempt to uncover errors at the software/hardware interface.
![Page 99: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/99.jpg)
Testing Web applications Dimension of Quality
Content Function Structure Usability Navigability Performance Compatibility Interoperability Security
![Page 100: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/100.jpg)
Testing Strategy The content model for the web application
is reviewed to uncover errors The interface model is reviewed to ensure
that all use-case can be accommodated The design model for the Webapp is
reviewed to uncover navigation errors The user interface is tested to uncover
errors in presentation and navigation mechanics
Selected functional components are unit tested
Navigation throughout the architecture is tested
![Page 101: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/101.jpg)
The WebApp is implemented in a variety of different environmental configurations that is tested for compatibility with each configuration
Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or within the environment
Performance tests are conducted The WebApp is tested by a controlled
and monitored population of end-users
![Page 102: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/102.jpg)
Test Planning A WebApp test plan identifies
A task set to be applied as testing commences
The work products to be produced as each testing task is executed
The manner in which the results of testing are evaluated
![Page 103: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/103.jpg)
Testing Process The testing process for WebApp
begins with tests that exercise content and interface functionalities that id immediately visible to end-users
As testing proceeds, aspects of the design architecture and navigation are exercised
Finally the focus shifts to tests that exercise technological capabilities that are not always apparent to end-users
![Page 104: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/104.jpg)
Testing Process
Component designArchitecture design
Navigation design
Content design
Aesthetic design
Interfacedesign Component
Testing
NavigationTesting
Interface TestingContent
Testing
Configuration Testing
PerformanceTesting
SecurityTesting
User
Technology
![Page 105: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/105.jpg)
Content Testing attempts to uncover errors in content
Interface Testing exercises interaction mechanisms and
validates aesthetic aspects of the user interface
Navigation Testing applies use cases, derived as part of the
analysis activity, in the design of test case Component Testing
Exercise content and functional units within the WebApp.
![Page 106: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/106.jpg)
Configuration Testing Attempts to uncover errors that are specific to
a particular client or server environment Security Testing
Incorporates a series of tests designed to exploit vulnerabilities in the WebApp and its environment
Performance Testing Encompasses a series of tests that are
designed to assess How WebApp response time and reliability are
affected by increased user traffic Which WebApp components are responsible for
performance degradation and which usage chracteristics cause degradation to occur
How performance degradation impacts overall WebApp objectives and requirements
![Page 107: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/107.jpg)
Testing Interface Mechanism
Links Forms Client-side scripting Dynamic HTML Pop-up windows CGI scripts Streaming content Application specific interface
mechanism
![Page 108: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/108.jpg)
Usability Test Usability testing evaluates the
degree to which users interact effectively with the WebApp and the degree to which the WebApp guides users’ action, provides meaningful feedback, and enforces a consistent interaction approach
![Page 109: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/109.jpg)
Usability Test categories Interactivity Layout Readability Aesthetic Display characteristics Time sensitivity Personalization Accessibility
![Page 110: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/110.jpg)
Component level Testing Also called function testing Focuses on a set of tests that
attempts to uncover errors in WebApp functions Equivalence Partitioning Boundary value analysis Path testing
![Page 111: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/111.jpg)
Navigation Testing Navigation links Redirects Bookmarks Frames Site maps Internal search engines
![Page 112: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/112.jpg)
Security Testing Security elements
Firewalls Authentication Encryption Authorization
![Page 113: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/113.jpg)
Performance Testing Load Testing
Real world loading is tested at a variety of load levels and in a variety of combinations
Stress Testing Loading is increased to the breaking
point to determine how much capacity the WebApp environment can handle
![Page 114: Software testing](https://reader036.fdocuments.us/reader036/viewer/2022081604/587b5d1c1a28ab38258b4de5/html5/thumbnails/114.jpg)