Professional Documents
Culture Documents
Unit 5
Unit 5
PART-A
11. What are the two major goals considered for integrated testing?
To detect defects that occur on the interfaces of units.
To assemble the individual units into working subsystems and finally a complete system that is ready
for system test.
Mapping Designs to Code Collection Classes in Code One-to-many relationships are common.
For example, a Sale must maintain visibility to a group of many SalesLineItem instances, as shown
in Figure In OO programming languages, these relationships are usually implemented with collection
of object.
Mapping Designs to Code Collection Classes in Code For example, the Java libraries contain
collection classes such as ArrayList. Using ArrayList, the Sale class can define an attribute that
maintains an ordered list of SalesLineItem instances.
Test-Driven Development and Refactoring
Test-Driven Development (TDD) An excellent practice that applicable to the UP iterative
methods is test-driven development (TDD) or test-first development. In this practice, unit testing
code is written before the code to be tested, and the developer writes unit testing code for all
production code.
Test-Driven Development (TDD) In OO unit testing TDD-style, test code is written before the class
to be tested. The test is written first, imagining the code to be tested is written.
Test-Driven Development (TDD) Advantage The unit tests actually get written: Human nature is
such that avoidance of writing unit tests is very common, if left as an afterthought.
Test-Driven Development (TDD) Advantage Programmer satisfaction leading to more consistent test
writing: In the traditional style, a developer first writes the production code, informally debugs it,
and then as an afterthought is expected to add unit tests, it doesn't feel satisfying. This is test-last
development. However, if the test is written first, we feel a worthwhile challenge and question in
front of us: Can I write code to pass this test? And then, after the code is cut to pass the tests, there is
some feeling of accomplishment meeting a goal
Test-Driven Development (TDD) Advantage Clarification of detailed interface and behavior:
Consider your state of mind if you write the test for an object first: As you write the test code, you
must imagine that the object code exists. you must think through the details of the public view of the
method, its name, return value, parameters, and behavior. That reflection improves or clarifies the
detailed design.
Test-Driven Development (TDD) Advantage Provable, repeatable, automated verification:
Obviously, having hundreds or thousands of unit tests that build up over the weeks provides some
meaningful verification of correctness. And because they can be run automatically, it's easy.
Writing tests starts to really feel like it's paying off as the size of the application grows.
Test-Driven Development (TDD) Advantage The confidence to change things: In TDD, there will
eventually be hundreds or thousands of unit tests and a unit test class for each production class. Get
confidence to change things
Test-Driven Development cycle (TDDC) Add a test: In test-driven development, each new feature
begins with writing a test. To write a test, the developer must clearly understand the feature's
specification and requirements. This may also be a modification of an existing test. This is a different
feature of test-driven development versus writing unit tests after the code is written: it makes the
developer focus on the requirements before writing the code
Test-Driven Development cycle (TDDC) Run all tests and see if the new one fails: This validates
that the test is working correctly and that the new test does not mistakenly pass Write some code:
The next step is to write some code that causes the test to pass. The new code written at this stage is
not perfect. That is acceptable because later steps improve
Test-Driven Development cycle (TDDC) Run tests: If all test cases now pass, the programmer can be
confident that the code meets all the tested requirements. Refactor code: Now the code should be
cleaned up as necessary. Change the code for passing the test to where it logically belongs. Remove
any duplication you can find. Make sure that variable and method names represent their current use.
Test-Driven Development cycle (TDDC) Repeat: Starting with another new test, the cycle is then
repeated to push forward the functionality.
Refactoring Refactoring is a structured, disciplined method to rewrite or restructure existing code
without changing its external behaviour, applying small transformation steps combined with re-
executing tests each step.
Refactoring The essence of refactoring is applying small behaviour preserving transformations one at
a time. After each transformation, the unit tests are re- executed to prove that the refactoring did not
cause a regression (failure). Therefore, there's a relationship between refactoring and TDD. All those
unit tests support the refactoring process.
Refactoring The activities and goals of refactoring include: remove duplicate code improve clarity
make long methods shorter remove the use of hard- coded literal constants etc.
2. Discuss in detail about OO Integration testing and OO System testing. (N/D 2016) 16Mrks
(N/D 2017) 6Mrks
INTEGRATION TESTING
It is a level of software testing where individual units are combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.
Definition by ISTQB
integration testing: Testing performed to expose defects in the interfaces and in the interactions
between integrated components or systems. See also component integration
testing, system integration testing.
component integration testing: Testing performed to expose defects in the interfaces and
interaction between integrated components.
system integration testing: Testing the integration of systems and packages; testing interfaces to
external organizations (e.g. Electronic Data Interchange, Internet).
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink
cartridge and the ballpoint are produced separately and unit tested separately. When two or more
units are ready, they are assembled and Integration Testing is performed. For example, whether the
cap fits into the body or not.
Method
Any of Black Box Testing, White Box Testing and Gray Box Testing methods can be used.
Normally, the method depends on your definition of ‘unit’
Tasks
Integration Test Plan
o Prepare
o Review
o Rework
o Baseline
Integration Test Cases/Scripts
o Prepare
o Review
o Rework
o Baseline
Integration Test
o Perform
When is Integration Testing performed?
Integration Testing is the second level of testing performed after Unit
Testing and before System Testing.
Who performs Integration Testing?
Developers themselves or independent testers perform Integration Testing.
Approaches
Big Bang is an approach to Integration Testing where all or most of the units are combined together
and tested at one go. This approach is taken when the testing team receives the entire software in a
bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well,
the former tests only the interactions between the units while the latter tests the entire system.
Top Down is an approach to Integration Testing where top-level units are tested first and lower level
units are tested step by step after that. This approach is taken when top-down development approach
is followed. Test Stubs are needed to simulate lower level units which may not be available during
the initial phases.
Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper-
level units step by step after that. This approach is taken when bottom-up development approach is
followed. Test Drivers are needed to simulate higher level units which may not be available during
the initial phases.
Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and
Bottom Up approaches.
SYSTEM TESTING
It is a level of software testing where a complete and integrated software is tested. The purpose of
this test is to evaluate the system’s compliance with the specified requirements.
Definition by ISTQB
system testing: The process of testing an integrated system to verify that it meets specified
requirements.
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and
the ballpoint are produced separately and unit tested separately. When two or more units are ready,
they are assembled and Integration Testing is performed. When the complete pen is integrated,
System Testing is performed.
Method
Usually, Black Box Testing method is used.
Tasks
System Test Plan
o Prepare
o Review
o Rework
o Baseline
System Test Cases
o Prepare
o Review
o Rework
o Baseline
System Test
o Perform
When is it performed?
System Testing is the third level of software testing performed after Integration Testing and before
Acceptance Testing.
Who performs it?
Normally, independent Testers perform System Testing.
Definition by ISTQB
system testing: The process of testing an integrated system to verify that it meets specified
requirements.
Analogy
During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and
the ballpoint are produced separately and unit tested separately. When two or more units are ready,
they are assembled and Integration Testing is performed. When the complete pen is integrated,
System Testing is performed.
Method
Usually, Black Box Testing method is used.
Tasks
System Test Plan
o Prepare
o Review
o Rework
o Baseline
System Test Cases
o Prepare
o Review
o Rework
o Baseline
When is it performed?
System Testing is the third level of software testing performed after Integration Testing and before
Acceptance Testing.
Who performs it?
Normally, independent Testers perform System Testing.
4. Discuss about the comparison between OO Integration testing and OO System testing.(A/M
18)(7 Marks)
Traditional testing methods are not directly applicable to OO programs as they involve OO
concepts including encapsulation, inheritance, and polymorphism. These concepts lead to issues,
which are yet to be resolved. Some of these issues are listed below.
1. Basic unit of unit testing.
The class is natural unit for unit test case design.
The methods are meaningless apart from their class.
Testing a class instance (an object) can validate a class in isolation.
When individually validated classes are used to create more complex classes in an application
system, the entire subsystem must be tested as whole before it can be considered to be
validated(integration testing).
2. Implication of Encapsulation.
Encapsulation of attributes and methods in class may create obstacles while testing. As methods are
invoked through the object of corresponding class, testing cannot be accomplished without object.
In addition, the state of object at the time of invocation of method affects its behavior. Hence, testing
depends not only on the object but on the state of object also, which is very difficult to acquire.
3. Implication of Inheritance.
Inheritance introduce problems that are not found in traditional software.
Test cases designed for base class are not applicable to derived class always (especially, when
derived class is used in different context). Thus, most testing methods require some kind of
adaptation in order to function properly in an OO environment.
4. Implication of Genericity.
Genericity is basically change in underlying structure.
We need to apply white box testing techniques that exercise this change.
i.)Parameterization may or may not affect the functionality of access methods.
ii.)In Tableclass, elemType may have little impact on implementations of the access methods of the
Table. Example: generic (parameterized class) class Tableclass(elemType) int numberelements;
create(); insert(elemType entry); delete(elemType entry); isEmpty() returns boolean;
isentered(elemType entry) returns boolean; endclass
But UniqueTable class would need to evaluate the equivalence of elements and this could vary
depending on the representation of elemType. Example: class UniqueTable extends Table
insert(elemType entry); endclass;
5. Implications of Polymorphism
Each possible binding of polymorphic component requires a seperate set of test cases.
Many server classes may need to be integrated before a client class can be tested.
It is difficult to determine such bindings.
It complicates the integration planning and testing.
6. Implications for testing processes
Here we need to re-examine all testing techniques and processes.
6. How is class test different from conventional testing? Explain with an example. (N/D 2017)
7Marks
Conventional testing focuses on input-process-output, whereas class testing focuses on each
method, then designing sequences of methods to exercise states of a class
1. Conventional testing: It is nothing but validation i.e. testing done while executing the code.
Unconventional testing: It is Verification, which involves verification of docs, code etc.
2. Conventional testing: is a sort of testing in which the test engineers will check the developed
application or its related parts are working according to the requirements or not.
Unconventional testing: is a sort of testing in which Quality Assurance people will check each and
every role in the organization from the Initial Phase of SDLC to the end.
3. In Conventional testing, the developed components of the application are checked by the tester for
whether they are working according to the expectations of the consumers or not.
A typical Unconventional testing starts from the coding phase of the systems development life
cycle.
4. Unconventional testing keeps a track of the whole software development process on the basis of the
quality assurance principles i.e.whether or not the software has been developed according to the
guidelines and specifications provided by the client company.
The Conventional testing is focused more up on the functionality of the software system or
application
It is concluded that Conventional testing is nothing but a similar initiative of quality
management system. Unconventional testing is to just by looking at the name that it doesn’t follow
any conventions.
7. What is integration testing? Explain the same with respect to object oriented system. (N/D
2017) 13M
Integration testing is a level of software testing where individual units are combined and
tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used
to assist in integration testing. The software testing phase in which individual software modules are
combined and tested as a group. It occurs after unit testing and before validation testing.
Purpose of Integration Testing:
The purpose of integration testing is to verify the functional, performance, and reliability between
the modules that are integrated.
Integration Strategies: Big-Bang Integration
Big Bang Integration Testing is an integration testing strategy wherein all units are linked at once,
resulting in a complete system. When this type of testing strategy is adopted, it is difficult to isolate
any errors found, because attention is not paid to verifying the interfaces across individual units.
Big Bang Integration - WorkFlow Diagram
Big Bang Testing is represented by the following workflow diagram:
The above diagrams clearly states that Modules 1, 2 and 3 are available for integration, whereas,
below modules are still under development that cannot be integrated at this point of time. Hence,
Stubs are used to test the modules. The order of Integration will be:
1,2
1,3
2,Stub 1
2,Stub 2
3,Stub 3
3,Stub 4
Testing Approach:
+ Firstly, the integration between the modules 1,2 and 3
+ Test the integration between the module 2 and stub 1,stub 2
+ Test the integration between the module 3 and stub 3,stub 4
Each component at lower hierarchy is tested individually and then the components that rely upon these
components are tested.
Bottom Up Integration - Flow Diagram
The order of Integration by Bottom-down approach will be:
4,2
5,2
6,3
7,3
2,1 and 3,1
Testing Approach :
+ Firstly, Test 4,5,6,7 individually using drivers.
+ Test 2 such that it calls 4 and 5 separately. If an error occurs we know that
the problem is in one of the modules.
+ Test 1 such that it calls 3 and If an error occurs we know that the problem is
in 3 or in the interface between 1 and 3
Though Top level components are the most important, yet tested last using this strategy. In Bottom-
up approach, the Components 2 and 3 are replaced by drivers while testing components 4,5,6,7. They
are generally more complex than stubs.
Integration Testing is a phase in software testing in which standalone modules are combined and
tested as a single entity.
During that phase, the interface and the communication between each one of those modules are tested.
There are two popular approaches for Integration testing which is Top down Integration Testing and
Bottom up Integration Testing.
In Hybrid Integration Testing, we exploit the advantages of Top-down and Bottom-up approaches.
As the name suggests, we make use of both the Integration techniques.
A third variant of the wizard page visualized the options in a dependency hierarchy (fig 4). Users
were now able to see that
"Generic IDE Support" is a requirement for "Eclipse Plugin", "IntelliJ IDEA Plugin", and "Web
Integration", and
There is no dependency between IDE issues and the remaining options like e.g. testing support or
source layout.
On the other hand some users found it confusing that they could not select "Eclipse Plugin" right
away, but instead had to check "Generic IDE Support" first. Overall, users felt that variant 2
supported them best, followed by variant
9. Discuss the various types of testing strategies in object oriented environment. (A/M 2018)
responsibility of the quality-assurance team. The team often uses system tests as regression tests
when assembling new releases.
Object-Oriented Testing Techniques:
Grey Box Testing:
The different types of test cases that can be designed for testing object-oriented programs are called
grey box test cases. Some of the important types of grey box testing are:
State model based testing: This encompasses state coverage, state transition coverage, and state
transition path coverage.
Use case based testing: Each scenario in each use case is tested.
Class diagram based testing: Each class, derived class, associations, and aggregations are tested.
Sequence diagram based testing: The methods in the messages in the sequence diagrams are tested.
Techniques for Subsystem Testing:
The two main approaches of subsystem testing are:
Thread based testing: All classes that are needed to realize a single use case in a subsystem are
integrated and tested.
Use based testing: The interfaces and services of the modules at each level of hierarchy are tested.
Testing starts from the individual classes to the small modules comprising of classes, gradually to
larger modules, and finally all the major subsystems.
Categories of System Testing:
Alpha testing: This is carried out by the testing team within the organization that develops software.
Beta testing: This is carried out by select group of co-operating
customers.
Acceptance testing: This is carried out by the customer before accepting the deliverables.
Black-box testing:
Testing that verifies the item being tested when given the appropriate input provides the expected
results.
Boundary-value testing:
Testing of unusual or extreme situations that an item should be able to handle.
Class testing:
The act of ensuring that a class and its instances (objects) perform as defined.
Component testing:
The act of validating that a component works as defined.
Inheritance-regression testing:
The act of running the test cases of the super classes, both direct and indirect, on a given subclass.
Integration testing:
Testing to verify several portions of software work together.
Model review:
An inspection, ranging anywhere from a formal technical review to an informal walkthrough, by
others who were not directly involved with the development of the model.
Path testing:
The act of ensuring that all logic paths within your code are exercised at least once.
Regression testing:
The acts of ensuring that previously tested behaviors still work as expected after changes have been
made to an application.
Stress testing:
The act of ensuring that the system performs as expected under high volumes of transactions, users,
load, and so on.
Technical review:
A quality assurance technique in which the design of your application is examined critically by a
group of your peers. A review typically focuses on accuracy, quality, usability, and completeness.
This process is often referred to as a walkthrough, an inspection, or a peer review.
User interface testing:
The testing of the user interface (UI) to ensure that it follows accepted UI standards and meets the
requirements defined for it. Often referred to as graphical user interface (GUI) testing.
White-box testing:
Testing to verify that specific lines of code work as defined. Also referred to as clear-box testing.
10. Outline the object oriented testing strategies. (N/D 2019)
While there are efforts underway to develop more automated testing processes from test
models of the object model characteristics (for example states, data flows, or associations), testing is
still based on the creation of test cases and test data by team members using a structural (White Box
Testing) and/or a functional (SeeBlack Box Testing) strategy.
Overview of Object Orientated Unit Testing-Implications of Object Oriented Testing
Once a class is testing thoroughly it can be reused without being unit tested again UML class state
charts can help with selection of test cases for classes Classes easily mirror units in traditional
software testing
Objective of OO is to facilitate easy code reuse in the form of classes .
To allow this each class has to be rigorously unit tested due to classes potentially used in
unforeseeable ways when composed in new systems
Example: A XML parser for a web browser
Classes must be created in a way promoting loose coupling and strong cohesion
CLASS TESTING:
Class testing is testing that ensures a class and its instances (objects) perform as defined. (Source:
Object Testing Patterns).When designing a society of classes, an excellent goal is to structure classes
so they can be tested with a minimum of fuss.
After all, a class that requires compiling the application, starting the application, logging into the
application, navigating to a particular point in the application ...will likely not get rigorously tested.
In computer programming, unit testing is a software testing method by which individual units of
source code, sets of one or more computer program modules together with associated control data,
usage procedures, and operating procedures, are tested to determine whether they are fit for use.
Intuitively, one can view a unit as the smallest testable part of an application. In procedural
programming, a unit could be an entire module, but it is more commonly an individual function or
procedure.
In object-oriented programming, a unit is often an entire interface, such as a class, but could
be an individual method.
Unit tests are short code fragments created by programmers or occasionally by white box testers
during the development process. It forms the basis for component testing. Ideally, each test case is
independent from the others.
Substitutes such as method stubs, mock objects, and test harnesses can be used to assist testing a
module in isolation. Unit tests are typically written and run by software developers to ensure that
code meets its design and behaves as intended.
OO INTEGRATION TESTING:
Research confirms that testing methods proposed for procedural approach are not adequate for OO
approach.
Ex. Statement coverage
OO software testing poses additional problems due to the distinguishing characteristics of OO.
Ex. Inheritance
Testing time for OO software found to be increased compared to testing procedural software.
Typical OO software characteristics that impact testing
State dependent behavior
Encapsulation
Inheritance
Polymorphism and dynamic
Binding
Abstract and generic classes
Exception handling
Procedural software
unit = single program, function, or procedure Object oriented
software unit = class
unit testing =intra-class testing
integration testing = inter-class testing
cluster of classes dealing with single methods separately is usually too expensive (complex
scaffolding), so methods are usually tested in the context of the class they belong to.
The process of testing object oriented systems begins with a review of the object-oriented analysis
and design models.
Once the code is written object-oriented testing (OOT) begins by testing "in the small" with class
testing (class operations and collaborations).
As classes are integrated to become subsystems class collaboration problems are investigated.
Finally, use-cases from the OOA model are used to uncover software validation errors.
OOT similar to testing conventional software in that test cases are developed to exercise the
classes , their collaborations, and behavior.
OOT differs from conventional software testing in that more emphasis is placed assessing the
completeness and consistency of the OOA and OOD models as they are built.
OOT tends to focus more on integration problems than on unit testing.
Object-Oriented Testing Activities
Review OOA and OOD models
Class testing after code is written
Integration testing within subsystems
Integration testing as subsystems are added to the system
Validation testing based on OOA use-cases
Testing OOA and OOD Models
OOA and OOD cannot be tested but can review the correctness and consistency.
Correctness of OOA and OOD models Syntactic Semantic judged by ensuring that proper modeling
conventions and symbolism have been used based on the model's conformance to the real world
problem
Consistency of OOA and OOD Models
Assess the class-responsibility-collaborator (CRC) model and object-relationship diagram review
system design (examine the object-behavior model to check mapping of system behavior to
subsystems, review concurrency and task allocation, use use-case scenarios to exercise user interface
design).
Test object model against the object relationship network to ensure that all design object contain
necessary attributes and operations needed to implement the collaborations defined for each CRC
card
Review detailed specifications of algorithms used to implement operations using conventional
inspection techniques.
Object-Oriented Testing Strategies
‰ Unit testing in the OO context
Smallest testable unit is the encapsulated class or object
Similar to system testing of conventional software
Do not test operations in isolation from one another
Driven by class operations and state behavior, not algorithmic detail and data flow
across module interface
Complete test coverage of a class involves
-Testing all operations associated with an object
- Setting and interrogating all object attributes
- Exercising the object in all possible states
11. Describe in detail the Test Case Design for OO Software.(N/D 2019)
Each test case should be uniquely identified and be explicitly associated with a class to be tested
State the purpose of each test
List the testing steps for each test including:
list of states to test for each object involved in the test
list of messages and operations to exercised as a consequence of the test
list of exceptions that may occur as the object is tested
list of external conditions needed to be changed for the test
supplementary information required to understand or implement the test