Computer Laboratory Practical – I Part (A)
Vidya Pratishthan's
College of Engineering
Department of Information Technology
LABORATORY MANUAL
B.E. (I.T.)
COMPUTER LAB PRACTICES-I
LABORATORY
STAFF: Prof. P. T. RAUT
Teaching Scheme
Theory: 00 hrs/week
Practical: 04 hrs/week/batch
Examination Scheme
Term work: 50 marks
Practical Exam: 50 Marks
1
Computer Laboratory Practical – I Part (A)
INDEX
COMPUTER LABORATOTY PRACTICES-I
(PART A: OOMD) LABORATORY
Sr. No.
Name of the Assignment
1
Prepare Software Requirement Specification and Use Case
Diagram.
2
CRC (Class Responsibility Collaborator), Class Diagram, and
Composite Structure Diagram.
3
Design Sequence and Communication Diagram.
4
Design Activity Diagram.
5
Design State Machine Diagram.
6
Design Component Diagram.
7
Design Deployment Diagram.
8
Design Package Diagram.
9
Design Interaction Overview Diagram.
2
Computer Laboratory Practical – I Part (A)
Assignment No: 1
Title: Software Requirement Specification and Use Case Diagram.
________________________________________________________________
Aim: Prepare software requirement specification for mini project. Identify major
requirements/functionality of system using Use Case Diagram.
What is a Software Requirements Specification?
SRS – a requirements specification for a software system – is a complete
description of the behavior of a system to be developed. It includes a set of use
cases that describe all the interactions the users will have with the software. In
addition to use cases, the SRS also contains non-functional requirements. Nonfunctional requirements are requirements which impose constraints on the design
or implementation (such as performance engineering requirements, quality
standards, or design constraints).
Software requirements is a sub-field of software engineering that deals with the
elicitation, analysis, specification, and validation of requirements for software.
SRS is providing basically an organization's understanding (in writing) of a
customer or potential client's system requirements and dependencies at a
particular point in time (usually) prior to any actual design or development work.
It's a two-way insurance policy that assures that both the client and the
organization understand the other's requirements from that perspective at a given
point in time.
Template for SRS is as follows:
1.0 Introduction
This section provides an overview of the entire requirement document. This
document describes all data, functional and behavioral requirements for
software.
1.1 Goals and objectives
Overall goals and software objectives are described.
1.2 Statement of scope
A description of the software is presented. Major inputs, processing
functionality and outputs are described without regard to implementation
detail.
3
Computer Laboratory Practical – I Part (A)
1.3 Software context
The software is placed in a business or product line context. Strategic
issues relevant to context are discussed. The intent is for the reader to
understand the 'big picture'.
1.4 Major constraints
Any business or product line constraints that will impact the manner in
which the software is to be specified, designed, implemented or tested are
noted here.
2.0 Usage scenario
This section provides a usage scenario for the software. It organized information
collected during requirements elicitation into use-cases.
2.1 User profiles
The profiles of all user categories are described here.
2.2 Use-cases
All use-cases for the software are presented.
2.3 Special usage considerations
Special requirements associated with the use of the software are
presented.
3.0 Data Model and Description
This section describes information domain for the software
3.1 Data Description
Data objects that will be managed/manipulated by the software are
described in this section.
3.1.1 Data objects
Data objects and their major attributes are described.
4
Computer Laboratory Practical – I Part (A)
3.1.2 Relationships
Relationships among data objects are described using an ERD- like form.
No attempt is made to provide detail at this stage.
3.1.3 Complete data model
An ERD for the software is developed
3.1.4 Data dictionary
A reference to the data dictionary is provided. The dictionary is maintained
in electronic form.
4.0 Functional Model and Description
A description of each major software function, along with data flow or class
hierarchy (OO) is presented.
4.1 Description for Function n
A detailed description of each software function is presented. Section 4.1
is repeated for each of n functions.
4.1.1 Processing narrative (PSPEC) for function n
A processing narrative for function n is presented.
4.1.2 Function n flow diagram
A diagram showing the flow of information through the function and
the transformation it undergoes is presented.
4.1.3 Function n interface description
A detailed description of the input and output interfaces for the
function is presented.
4.1.4 Function n transforms
A detailed description for each transform (subfunction) for function
n is presented. Section 4.1.4 is repeated for each of k transforms.
5
Computer Laboratory Practical – I Part (A)
4.1.4.1 Transform k description (processing narrative,
PSPEC)
4.1.4.2 Transform k interface description
4.1.4.3 Transform k lower level flow diagrams
4.1.4.4 Transform k interface description
4.1.5 Performance Issues
Special performance required for the subsystem is specified.
4.1.6 Design Constraints
Any design constraints that will impact the subsystem are noted.
4.2 Software Interface Description
The software interface(s)to the outside world is(are) described.
4.2.1 External machine interfaces
Interfaces to other machines (computers or devices) are described.
4.2.2 External system interfaces
Interfaces to other systems, products or networks are described.
4.2.3 Human interface
An overview of any human interfaces to be designed for the
software is presented.
4.3 Control flow description
The control flow for the system is presented with reference to Section 5.0
of this document.
6
Computer Laboratory Practical – I Part (A)
5.0 Behavioral Model and Description
A description of the behavior of the software is presented.
5.1 Description for software behavior
A detailed description of major events and states is presented in this
section.
5.1.1 Events
A listing of events (control, items) that will cause behavioral change
within the system is presented.
5.1.2 States
A listing of states (modes of behavior) that will result as a
consequence of events is presented.
5.2 State Transition Diagrams
Depict the overall behavior of the system.
5.3 Control specification (CSPEC)
Depict the manner in which control is managed by the software.
6.0 Restrictions, Limitations, and Constraints
Special issues which impact the specification, design, or implementation of the
software are noted here.
7.0 Validation Criteria
The approach to software validation is described.
7.1 Classes of tests
The types of tests to be conducted are specified, including as much detail
as is possible at this stage. Emphasis here is on black- box testing.
7.2 Expected software response
7
Computer Laboratory Practical – I Part (A)
The expected results from testing are specified.
7.3 Performance bounds
Special performance requirements are specified.
8.0 Appendices
Presents information that supplements the Requirements Specification
8.1 System traceability matrix
A matrix that traces stated software requirements back to the system
specification.
8.2 Product Strategies
If the specification is developed for a product, a description of relevant
product strategy is presented here.
8.3 Analysis metrics to be used
A description of all analysis metrics to be used during the analysis activity
is noted here.
8.4 Supplementary information (as required)
8
Computer Laboratory Practical – I Part (A)
Use Case Diagram
Theory:
Use case diagrams depict:




Use cases: A use case is narrative textual description of functionality from
end user point of view. It describes a sequence of actions that provide
something of measurable value to an actor and is drawn as a horizontal
ellipse.
Actors: An actor is a person, organization, or external system that
initiates a Use Case. It plays a role in one or more interactions with your
system. Actors are drawn as stick figures.
Associations: Associations between actors and use cases are indicated
in use case diagrams by solid lines. An association exists whenever an
actor is involved with an interaction described by a use case.
Associations are modeled as lines connecting use cases and actors to
one another.
System boundary boxes (optional): You can draw a rectangle around
the use cases, called the system boundary box, to indicate the scope of
your system. Anything within the box represents functionality that is in
scope and anything outside the box is not. System boundary boxes are
rarely used, but use them to identify which use cases will be delivered in
each major release of a system as shown in figure 1.1.
Figure 1.1
9
Computer Laboratory Practical – I Part (A)
Steps for preparing Use Case Diagrams:
1. Start by identifying as many actors as possible.
2. Ask how the actors interact with the system to identify an initial set of use
cases.
3. Connect the actors with the use cases with which they are involved. If
actor supplies information, initiates the use case, or receives any
information as a result of the use case, then there should be an
association between them.
Relationships in Use Case Diagram:
1. Actor Generalization: Actor generalization factors out behavior common
to two or more actors into a parent actor.
2. Use Case Generalization: Actor generalization factors out behavior
common to two or more actors into a parent actor.
3. <<include>>: The <<include>> relationship between use cases allows
you to include behavior of one use case into the flow of another use case.
4. <<extend>>: The <<extend>> relationship provides a way to insert new
behavior into an existing use case. The base use case provides a set of
extension points that are hooks where new behavior may be added, and
the extension use case provides a set of insertion segments that can be
inserted into the base use case at these hooks.
10
Computer Laboratory Practical – I Part (A)
Fig 1.2 is Use case diagram showing the reuse opportunities of use cases in the
context of system “Enrollment of Student for Course in University” shows the
three types of relationships between use cases -- extends, includes, and
inheritance -- as well as inheritance between actors
Figure 1.2
11
Computer Laboratory Practical – I Part (A)
Assignment No: 2
Title: CRC (Class Responsibility Collaborator), Class Diagram, and Composite
Structure Diagram.
________________________________________________________________
Aim: Identify analysis classes using CRC model and prepare class diagram to
describe structural view of project/system. Design structured classes using
Composite Structure diagram.
CRC (Class Responsibility Collaborator):
Theory:
Terms and concepts:
A Class Responsibility Collaborator (CRC) model is a collection of standard index
cards that have been divided into three sections, as depicted in figure 2.1. A
class represents a collection of similar objects, a responsibility is something that
a class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities.
Figure 2.1
CRC Analysis procedure:
CRC analysis should always be used in conjunction with noun/verb analysis of
use cases, requirements, glossary, and other related documentation.
CRC is run as two-phase activity:
12
Computer Laboratory Practical – I Part (A)
Phase 1: Brainstorm-gather the information.
The participants are OO analysts, stakeholders, and domain experts. The
procedure is as follows:
1. Accept all ideas as good ideas.
2. Record ideas but do not debate.
3. Name the things that operate in their business domain. For example,
student, instructor.
4. State responsibilities that those things might have.
5. Try to identify classes that might work together.
Phase 2: Analyze information.
1. Analysis class represents abstraction in the problem domain as well as
key business.
2. If a note logically seems to be a part of another note, mark it as
attribute.
To prepare class diagram, perform following steps:
1. Identify the mechanism that represents some function or behavior of
the part of the system you are modeling.
2. Identify classes, interfaces, and other collaborations that participate in
collaboration. Identify the relationships among these things.
3. Use scenarios to walk through these things.
4. Populate these things with their contents.
Terms and concepts in Class diagram:






Classes
Responsibilities
Associations
Inheritance relationships
Composition associations
Interfaces
Classes:
An object is any person, place, thing, concept, event, screen, or report applicable
to your system. A class is a representation of an object and, in many ways, it is
simply a template from which objects are created. Classes form the main building
blocks of an object-oriented application.
Class can be represented as rectangle with maximum four compartments. First
compartment- Class Name, Second compartment
- Attributes Third
compartment – Operations, Fourth compartment – Responsibilities.
13
Computer Laboratory Practical – I Part (A)
Syntax:
1. For attribute
Visibility Attribute_name : Attribute_type = initialValue
2. For operation
Visibility name( direction parameter_Name: parameter_type
= initialValue ): return_type
Responsibilities:
Classes are typically modeled as rectangles with three sections: the top section
for the name of the class, the middle section for the attributes of the class, and
the bottom section for the methods of the class. The initial classes of your model
can be identified in the same manner as they are when you are CRC modeling, as
will the initial responsibilities (its attributes and methods). Figure 2.2 shows
Student and address (Conceptual class diagram)
Figure 2.2
Associations:
Objects are often associated with, or related to, other objects. Associations are
modeled as lines connecting the two classes whose instances (objects) are
involved in the relationship.
While modeling associations in UML class diagrams, show them as a thin line
connecting two classes, as seen in Figure 2.3. Associations can become quite
complex; consequently. The label, which is optional, although highly
recommended, is typically one or two words describing the association.
14
Computer Laboratory Practical – I Part (A)
Figure 2.3
The multiplicity of the association is labeled on either end of the line, one
multiplicity indicator for each direction (Table 2.1 summarizes the potential
multiplicity indicators). Multiplicity indicates how many objects are involved in
relationship at particular point in time.
Indicator
0..1
1
0..*
1..*
N
0..n
1..n
Meaning
Zero or one
One only
Zero or more
One or more
Only n (where n > 1)
Zero to n (where n >
1)
One to n (where n >
1)
Table 2.1
Inheritance Relationships i.e. Generalization/Specialization
Similarities often exist between different classes. Very often two or more classes
will share the same attributes and/or the same methods. To reduce the overhead
of writing the same code repeatedly, use a mechanism that takes advantage of
these similarities. Inheritance is that mechanism. When A inherits from B, we say
A is the subclass of B and B is the superclass of A. Person is superclass,
Student and Professor are subclasses as shown in Figure 2.4.
15
Computer Laboratory Practical – I Part (A)
Figure 2.4
Composition Associations:
Sometimes an object is made up of other objects. For example, an airplane is
made up of a fuselage, wings, engines, landing gear, flaps, and so on. Figure 2.5
presents an example using composition, modeling the fact that a building is
composed of one or more rooms, and then, in turn, that a room may be
composed of several sub rooms (you can have recursive composition). In UML
2, aggregation would be shown with an open diamond.
Figure 2.5
16
Computer Laboratory Practical – I Part (A)
Figure 2.6 is the conceptual class diagram for system “Enrollment of Student for
Course in University”
Figure 2.6
17
Computer Laboratory Practical – I Part (A)
Composite Structure Diagram
Theory:
Composite structure diagram is used to model
1. Structured classifiers/classes
2. Collaboration
Elements of Composite structure diagram:
Structured Classifiers: A structured Classifier is a classifier that has an internal
structure. This structure is modeled as parts that are joined with connectors. The
interaction of structured classifier with its environment is modeled by its
interfaces and ports.
Part has:
1. Role name: a descriptive name for the role that instances play in the
context of the structured classifier.
2. Type: only instances of this type (or subtype of this type) can play a role.
3. Multiplicity: the number of instances that can play the role at any point in
time.
Connectors: It represents communication links between the instances of classes
participating in internal structure. Figure 2.7 shows example of named connector.
Link between Pedal and a Wheel is a connector named “c”, which is a chain.
Figure 2.7
Ports: A way to offer functionality from composite structure to external
environment without exposing internal details of how that functionality is realized.
Port
is
collection
of
required
and
provided
interfaces.
CreditCardVerificationSystem with required (IAccountServices) and provided
(ICreditCardProcessor) interfaces as shown in figure 2.8
18
Computer Laboratory Practical – I Part (A)
.
Figure 2.8
Port has port name and visibility. When port is drawn overlapping the boundary
of the classifier, it is public (required and provided interfaces are public). If the
port rectangle is shown inside the classifier boundary then the port has either
protected (default) visibility or private visibility.
UML 2.0 allows you to have multiple connectors leading from a port to different
internal elements. However it doesn’t specifies what happens when
communication is received at that port. This is modeler’s decision. Some possible
solutions are to forward the communication to all connectors, forward based on
priority, forward on round robin basis, or simply randomly choose a connector.
Figure 2.9 shows an example of using a port with multiple connectors.
Figure 2.9
Structured Classes: A Structured Class has the extra constraint that it owns all
of its parts. connectors, and ports. It has implicit containment relationship with
them. Let us look an example of using structured classes in practice. Suppose
library management system has the following constraint:
1. There are two types of Borrower, StudentBorrowers and StaffBorrowers
2. StudentBorrowers can have maximum of four books on loan
simultaneously.
3. StaffBorrowers can have maximum of eight books on loan simultaneously.
19
Computer Laboratory Practical – I Part (A)
4. Only one librarian can logged on to system at a time – it is single user
system.
Figure 2.10 shows a structured classifier LibraryManager satisfying above
constraint using composite structure diagram.
Figure 2.10
20
Computer Laboratory Practical – I Part (A)
Assignment No: 3
Title: Sequence and Communication Diagram.
________________________________________________________________
Aim: Design sequence and communication diagram to describe dynamic nature
of system.
Theory:
UML sequence diagrams model the flow of logic within your system in a visual
manner, enabling you both to document and validate your logic, and are
commonly used for both analysis and design purposes.
Sequence diagrams are typically used to model:
1. Usage scenarios. A usage scenario is a description of a potential way
your system is used. The logic of a usage scenario may be part of a use
case, perhaps an alternate course.
2. The logic of methods. Sequence diagrams can be used to explore the
logic of a complex operation, function, or procedure.
3. The logic of services. A service is effectively a high-level method, often
one that can be invoked by a wide variety of clients.
Elements of sequence Diagram:
1. Interactions:
a. Interactions are simply units of behavior of classifier.
b. This classifier, known as the context classifier, provides context
for the interaction.
2. Lifelines:
Lifeline represents a single participant in an interaction shown as
rectangle connected with vertical line.
3 Messages:
A message represents a specific kind of communication between
two lifelines in an interaction. Different forms of messages
i] calling an operation – a call message
ii] creating or destroying an instance – a creation or
destruction message
iii] sending a signal
21
Computer Laboratory Practical – I Part (A)
4 Activations:
Activations are thin rectangles on the dashed line below the
lifeline to indicate when a particular lifeline has the focus of
control. These activations are called as activation bars or
execution occurrences or focus of control.
5 Combined Fragments:
To represent a particular sequence of event occurrences that has
special constraints or properties, combined fragment is used.
UML allows placing the interaction fragments in a container. Each
combined fragment is made up of an interaction operator.
Combined fragment is shown as rectangle, with the interaction
operator in a pentagon in the upper left and the interaction
operands inside the rectangle. Fig 3.1 shows syntax for combined
fragment.
Figure 3.1
22
Computer Laboratory Practical – I Part (A)
Interaction operators used in sequence diagram are shown in table 3.1.
Operator Long Name
opt
option
alt
loop
alternatives
loop
Semantics
There is single operand that executes if the condition
is true(like if …then)
The operand whose condition is true is executed. The
keyword may be used in place of Boolean expression
(like select….case)
This has a special syntax
Loop min, max[condition]
break
break
ref
par
critical
seq
reference
parallel
critical
weak
sequencing
strict
strict
sequencing
neg
negative
ignore
ignore
consider consider
Loop min times, then while condition is true, loop(maxmin) times
If guard condition is true, the operand is executed, but
the rest of enclosing interaction
The combined fragment refers to another interaction
All operands execute in parallel
The operand executes atomically without interruption
All operands execute in parallel subject to the
following constraint:
Events arriving on same lifeline from different
operands occur in the same sequence as the
operands occur. This gives rise to weak form of
sequencing – hence the name
All operands execute in strict sequence
The operand shows invalid interactions use this when
you want to show interactions that must not happen
Lists messages that are intentionally omitted from the
interaction- the names of ignored messages are
placed in braces in a comma- delimited list after the
operator name, (e.g. m1, m2, m3)
Lists messages that are intentionally included in the
interaction- the names of messages are placed in
braces in a comma- delimited list after the operator
name
Table 3.1
23
Computer Laboratory Practical – I Part (A)
Types of messages used in sequence diagram are shown in table 3.2 with its
notation.
Syntax
aMessage (aParameter )
Name
Synchronous message
aMessage (aParameter )
Asynchronous message
Message return
«destroy»
Object destruction
Found message
Lost message
Table 3.2
To prepare sequence diagram, perform following steps:
1. Set the context for interaction, whether it is a system, subsystem,
operation, or class or one scenario of a use case or collaboration.
2. Set the stage for interaction by identifying which objects play a role in the
interaction. Lay them out on sequence diagram from left to right, placing
the more important to the left and their neighboring objects to the right. .
3. Set the lifeline for each object.
4. Optionally, for important messages, you can draw a dotted line with an
arrowhead pointing back to the originating class instance; label the return
value above the dotted line. We should include the return value lines
because it shows the extra details and makes it easier to read.
24
Computer Laboratory Practical – I Part (A)
Figure 3.2 shows sequence diagram for printing student record/transcript in
the context of system “Enrollment of Student for Course in University”.
Figure 3.2
25
Computer Laboratory Practical – I Part (A)
Communication Diagram:
A communication diagram emphasizes the organization of the objects that
participate in the interaction.
To prepare Communication diagram, perform following steps:
1. Place objects that participate in the interaction as the vertices in a
graph.
2. Render the links that connect these objects as arcs of these graphs.
3. Display these links with the messages that object send and receive.
Two features that distinguish communication diagram from sequence diagram:
1. Path: To indicate one object is linked to other. Attach a path
stereotype to the far end of al link.(such as <<local>> or <<global>>
indicating that designated object is local or global to the sender)
2. Sequence Number: To indicate the order of message, prefix the
message with number (starting with the message numbered 1)
increasing monotonically for each new message in the flow of control
(2, 3, and so on). Use Dewey decimal numbering to show nesting of
messages. (1 is the first message; 1.1 is the first message nested in
message 1; 1.2 is the second message nested in message 1; and so
on). Figure 3.3 shows use of path and sequence no. in communication
diagram.
Figure 3.3
26
Computer Laboratory Practical – I Part (A)
Here is message notation:
[sequenceNumber:] methodName(parameters) [: returnValue]
Figure 3.4
Figure 3.5 shows communication diagram for displaying a seminar details screen
or page in the context of system “Enrollment of Student for Course in University”
Figure 3.5
27
Computer Laboratory Practical – I Part (A)
Assignment No: 4
Title: Activity Diagram.
________________________________________________________________
Aim: Design Activity diagram to describe dynamic nature of system.
Theory:
Activity diagram:
Activity diagrams are typically used for:
 Business process modeling, for modeling the logic captured by a single
use case or usage scenario, or for modeling the detailed logic of a
business
rule.
 Business processes modeling in which several objects participate.
Elements of Activity Diagram:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Initial node: The filled in circle is the starting point of the diagram. An
initial node isn’t required although it does make it significantly easier to
read the diagram.
Activity final node: The filled circle with a border is the ending point. An
activity diagram can have zero or more activity final nodes.
Activity: It is sequence of actions. The rounded rectangles represent
activities that occur. An activity may be physical, such as Inspect Forms,
or electronic, such as Display Create Student Screen.
Flow/edge. The arrows on the diagram. .
Fork. Splits a single flow into more concurrent flows. A black bar with one
flow going into it and several leaving it. This denotes the beginning of
parallel activity.
Join. Synchronizes multiple flows into one flow. A black bar with several
flows entering it and one leaving it. All flows going into the join must reach
it before processing may continue. This denotes the end of parallel
processing.
Condition. Text such as [Incorrect Form] on a flow, defining a guard
which must evaluate to true in order to traverse the node.
Decision. A diamond with one flow entering and several leaving. The
flows leaving include conditions.
Merge. A diamond with several flows entering and one leaving. The
implication is that one or more incoming flows must reach this point until
processing continues, based on any guards on the outgoing flow.
Partition. Partitions are used to organize responsibilities of particular
object in the system, partitions, also called swimlanes, indicating who/what
is performing the activities
28
Computer Laboratory Practical – I Part (A)
11.
Flow final. The circle with the X through it. This indicates that the
process stops at this point.
Advanced Elements of Activity Diagram:
1. Connector: Use connectors to break long edges that are hard to follow or
to untangle the edges that cross. Connector syntax is as shown in figure
4.1 each outgoing connector must have exactly one incoming connector
with the same label.
Figure 4.1
2. Interruptible activity regions: Interruptible activity regions are regions of
an activity that are interrupted when a token traverses an interrupting
edge. Interruptible activity regions give a way to model interrupts and
asynchronous events. Figure 6.2 shows a simple Log On activity that has
an interruptible region shown as dashed rectangle with rounded corner.
3. Exception Handling: Exception handling in activity diagram is modeled
using exceptions pins, protected nodes and exception handlers. Exception
pin can be represented as small equilateral triangle. Figure 4.2 shows
exception handling.
29
Computer Laboratory Practical – I Part (A)
Figure 4.2
4. Expansion nodes: Expansion nodes allow you to show how a collection
of objects is processed by a part of activity diagram called an expansion
region. Expansion node is an object node that represents a collection of
objects flowing into or out of an expansion region. The expansion region is
executed once per input element. The type of output collection at expansion
node must match type of input collection. In Figure 6.3 expansion region
accepts a set of Student objects. It processes each of these objects in turn
(mode = iterative) and outputs a set of processed Student objects.
Figure 4.3
30
Computer Laboratory Practical – I Part (A)
5. Streaming: An action is said to be streaming if it can produce output
while it is processing input.
6. <<centralBuffer>>: Central buffer node provides a place to specify
queuing functionality for data processing between object nodes. A central
buffer node takes input from several object node sources and offers them
along several object node outputs.
Figure 4.4
7. <<datastore>>: Data store node is a special type of central buffer node
that copies data that passes through it. It indicates that all the interactions
logged to an external database. When an order is placed, the information
regarding the sale is stored in the customer database before the item is
shipped as shown in figure 6.6.
Figure 4.5
To prepare activity diagram, perform following steps:
5. Establish the focus for the work flow. For complex or huge system it is
difficult to show all interesting workflows in one diagram, then prepare
more than one diagrams as required.
6. Select the business objects that have high level responsibilities for parts of
the overall workflow. Create a swimlane for each important business
object.
31
Computer Laboratory Practical – I Part (A)
7. Identify the preconditions of the workflow’s initial state and the
postconditions of the workflow’s initial state to decide boundaries
workflow.
8. Beginning at workflow’s initial state, specify the activities and actions that
take place over time and render them in tha activity diagram as either
activity states or action states.
9. For complicated actions or sets of actions that appear multiple times,
collapse these into activity states, and provide separate activity diagram
that expands on each.
10. Render the transitions that connect these activity and action states. Start
with sequential flows in the workflow first, next consider branching, and
only then consider forking and joining.
32
Computer Laboratory Practical – I Part (A)
Assignment No: 5
Title: State Machine Diagram.
________________________________________________________________
Aim: Design State Machine diagram to describe dynamic nature of system.
Theory:
State Machine:
UML state machine diagrams are used for modeling life cycle history of a single
reactive object as a finite state machine. UML state machine diagrams depict the
various states that an object may be in and the transitions between those states.
Elements of State Machine:
1. State: A condition or situation during the life of an object during which it
satisfies some condition, performs some activity, or waits for some event.
2. Event: The specification of noteworthy occurrence that has location in
time and Space.
3. Transition: The movement from one state to another in response to
event.
Types of state machines:
1. Behavioral state machines: Behavioral state machines use states,
transitions, and events to define the behavior of context classifier.
Behavioral state machines can only be used when the context classifier
has a behavior of some sort to be modeled.
2. Protocol state machines: Some classifiers for example, interfaces and
ports, have no behavior. They simply define a usage protocol. It says
nothing about implementation of the behavior.
Types of event:
1. Call event: A call event is a request for a specific operation to be in
invoked on an instance of the context class.
2. Signal event: A signal is package of information that is sent
asynchronously between objects.
3. Change event: A change event is specified as a Boolean Expression. All
values in Boolean expression must be constants, globals, or attributes or
operations of the context class.
33
Computer Laboratory Practical – I Part (A)
Figure 5.1
4. Time event: Time events are usually indicated by keywords when and after
as shown in figure 5.2
Figure 5.2
34
Computer Laboratory Practical – I Part (A)
Table 5.1 showing elements in state machine along with their notation
Table 5.1
Composite state: Composite state is a state that contains nested states. These
nested states are organized into one or more state machines, called
submachines. Each submachine exists in its own region within composite state
icon. Regions are just areas of the state icon separated by dashed lines.
Figure 5.3
35
Computer Laboratory Practical – I Part (A)
Types of composite states:
1. Simple composite state: Simple composite state is a state that contains
a single region.
2. Orthogonal composite state: Orthogonal composite state is a state that
has more than one region as shown in Figure 5.4
Figure 5.4
Figure 5.5 depicts complete life cycle of seminar object in the context of
system “Enrollment of Student for Course in University”
Figure 5.5
36
Computer Laboratory Practical – I Part (A)
Assignment No: 6
Title: Component Diagram.
________________________________________________________________
Aim: Design Component diagram to show organization and dependencies.
Theory:
Component diagram:
Component diagram is a diagram that shows the organization of and
dependencies among a set of components; Component diagrams address the
static implementation view of a system.
Elements of Component Diagram:
1. Component: A physical and replaceable part of a system that conforms to
and provides a realization of a set of interfaces. A component represents a
modular part of system that encapsulates its contents and whose
manifestation is replaceable within its environment.
2. Interface: A collection of operations that are used to specify a service of
class or a component. Two types of interfaces: provided interface and
required interface. A set of interfaces realized by classifier is known as its
provided interface. When a classifier requires one or more interfaces for
its operations, these are known as its required interfaces. Component and
its interfaces are shown in figure 6.1.
Figure 6.1
3. Dependency, generalization, association, and realization
relationship:
37
Computer Laboratory Practical – I Part (A)
To prepare component diagram especially for executable system, perform
following steps:
1. Identify the set of components to model. These are components that live
on one node or the distribution of these sets of components across all the
nodes in the system.
2. Consider the stereotype of each component in this set.
3. For each component in this set, consider its relationships to its neighbors.
Table 6.1 summarizes several design principles for improving the quality of
packages or components.
Principle
Acyclic
Dependencies
Common Closure
Common Reuse
Dependency
Inversion
Open-Closed
Release-Reuse
Equivalency
Stable
Abstractions
Stable
Dependencies
Description
Allow no cycles in the dependencies graph between
components. For example disallow A è B è C è A because
it includes a cycle.
The classes of a component should be closed together
against the same kinds of changes. A change that affects a
class within a component should not affect classes outside
that component. In other words your components should
be cohesive in that sweeping changes across several
components are not required.
The classes in a component are reused together. If you
reuse one class in a component you reuse them all. This is
another principle addressing cohesion.
Abstractions should not depend on details, instead details
should depend on abstractions.
Software elements should be open for extension but closed
for modification.
The granule of reuse is the granule of release. In other
words you should not reuse only part of a released software
element.
A component should be as abstract as it is stable. A
component should be sufficiently abstract so that it can be
extended without affecting its stability.
Depend on the direction of stability – If component A
depends on component B, then B should be more stable
(e.g. less likely to change) than A.
Table 6.1
38
Computer Laboratory Practical – I Part (A)
Figure 6.2 is the Component diagram for system “Enrollment of Student for
Course in University”
Figure 6.2
39
Computer Laboratory Practical – I Part (A)
Assignment No: 7
Title: Deployment Diagram.
________________________________________________________________
Aim: Design deployment diagram to describe structural view of system.
Theory:
A UML 2 deployment diagram depicts a static view of the run-time configuration of
processing nodes and the components that run on those nodes. In other words,
deployment diagrams show the hardware for your system, the software that is
installed on that hardware, and the middleware used to connect the disparate
machines to one another.
Elements of Deployment Diagram:
1. Node. The node represents a type of computational resource upon which
artifacts can be deployed for execution.
There are two standard stereotypes for nodes.

<<device>>: the node represents a type of typical device such as
PC or server.
 <<execution environment>>: the node represents a type of
execution environment for software such as an Apache web server
or the JBoss EJB container.
2. Artifact: An artifact represents the specification of a concrete, real-world
thing such as the source file BankAccount.java. Artifacts are deployed on
nodes. Figure 7.1 shows Node - AppServer1 and artifact - .jar files
Some examples of artifacts are:





Source files
Executable files
Scripts
Database tables
Documents
40
Computer Laboratory Practical – I Part (A)
Figure 7.1
To prepare deployment diagram especially for embedded system, perform
following steps:
1. Identify the devices and nodes that are unique to your system
2. Provide visual cues, especially for unusual devices, by using the UML’s
extensibility mechanisms to define system specific stereotypes with
appropriate icons.
3. Model the relationships/connections among these processors and devices
in a deployment diagram.
4. As necessary, expand on any intelligent devices by modeling their
structure with a more detailed deployment diagram.
41
Computer Laboratory Practical – I Part (A)
Figure 7.2 is the Deployment diagram for system “Enrollment of Student for
Course in University”
Figure 7.2
42
Computer Laboratory Practical – I Part (A)
Assignment No: 8
Title: Package Diagram.
________________________________________________________________
Aim: Design package diagram to group the elements in the system.
Theory:
Packages are UML constructs that enable you to organize model elements into
groups, making your UML diagrams simpler and easier to understand. Packages
are depicted as file folders and can be used on any of the UML diagrams,
although they are most common on use-case diagrams and class diagrams
because these models have a tendency to grow.
The following is an example of a usecase package diagram.
Elements contained in a package share the same namespace. Therefore, the
elements contained in a specific namespace must have unique names.
43
Computer Laboratory Practical – I Part (A)
Packages can be built to represent either physical or logical relationships. When
choosing to include classes in specific packages, it is useful to assign the classes
with the same inheritance hierarchy to the same package. There is also a strong
argument for including classes that are related via composition, and classes that
collaborate with them, in the same package.
Packages are represented in UML 2.1 as folders and contain the elements that
share a namespace; all elements within a package must be identifiable, and so
have a unique name or type. The package must show the package name and
can optionally show the elements within the package in extra compartments.
Package Merge
A «merge» connector between two packages defines an implicit generalization
between elements in the source package, and elements with the same name in
the target package. The source element definitions are expanded to include the
element definitions contained in the target. The target element definitions are
unaffected, as are the definitions of source package elements that don't match
names with any element in the target package.
Package Import
The «import» connector indicates that the elements within the target package,
which in this example is a single class, use unqualified names when being
referred to from the source package. The source package's namespace gains
access to the target classes; the target's namespace is not affected.
NestingConnectors
The nesting connector between the target package and source packages shows
that the source package is fully contained in the target package.
44
Computer Laboratory Practical – I Part (A)
Assignment No: 9
Title: Interaction Overview Diagram.
________________________________________________________________
Aim:.Design Interaction Overview Diagram for the system.
Theory:
Interaction Overview Diagram represents interactions using a simplification of the
activity diagram notation. Interaction Overview Diagrams can help you visualize
the overall flow of control through a diagram. However, they don’t show detailed
message information.
UML 2 interaction overview diagrams are variants on UML activity diagrams
which overview control flow. The nodes within the diagram are frames instead of
the normal activities which you would see on an activity diagram. There are two
types of frame shown: interaction frames which depict any type of UML
interaction diagram (sequence diagram, communication diagram, timing diagram,
interaction overview diagram) or interaction occurrence frames which indicate an
activity or operation to invoke.
You can embed interactions or interaction occurrences inside an interaction
overview diagram if it is helpful to see message details for a subset of the overall
interaction.
Several sequence diagram concepts are supported in interaction overview
diagrams as following:
 Show combined fragment using decision node and merge node.
 Show parallel interactions by using a fork node and join node.
 Show loops as cycles in the activity diagram.
 Show names of the lifelines involved in an interaction using the keyword
lifelines after the name of the interaction overview diagram, followed by a
comma-delimited list of each lifeline’s name.
Following is interaction overview diagram showing System Authentication
interaction.
45
Computer Laboratory Practical – I Part (A)
46
Laboratory Manual
Computer Laboratory Practice-I
Final Year - Information Technology
Teaching Scheme
Examination Scheme
Theory : ——
Term Work: 50 Marks
Practical : 04 Hrs/Week
Practical : 50 Marks
Oral :
——
Prepared By
Prof.Bhagwat K. S.
Department of Information Technology
Vidya Pratishthan’s College of Engineering
Baramati – 413133, Dist- Pune (M.S.)
INDIA
June 2013
Table of Contents
1 Manual Testing-Black box testing
1.1 Problem Statement . . . . . . . . . .
1.2 Pre Lab . . . . . . . . . . . . . . . .
1.3 Hardware and Software Requirement
1.4 Theory . . . . . . . . . . . . . . . . .
1.4.1 Manual Testing: . . . . . . .
1.4.2 Stages: . . . . . . . . . . . . .
1.4.3 Manual testing: . . . . . . . .
1.5 Post Lab . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
1
1
2
3
3
2 Manual Testing-White box testing.
2.1 Problem Statement . . . . . . . . . .
2.2 Pre Lab . . . . . . . . . . . . . . . .
2.3 Hardware and Software Requirement
2.4 Theory . . . . . . . . . . . . . . . . .
2.4.1 White Box Testing Strategy2.5 Post Lab . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
5
5
6
3 Manual Testing-Black box testing
3.1 Problem Statement . . . . . . . . . .
3.2 Pre Lab . . . . . . . . . . . . . . . .
3.3 Hardware and Software Requirement
3.4 Theory . . . . . . . . . . . . . . . . .
3.4.1 Testing Techniques: . . . . .
3.4.2 Black Box Testing: . . . . . .
3.4.3 White Box Testing: . . . . . .
3.4.4 Test Director tool: . . . . . .
3.4.5 Planning Tests: . . . . . . . .
3.4.6 Running Tests: . . . . . . . .
3.4.7 Tracking Defects: . . . . . . .
3.5 Procedure . . . . . . . . . . . . . . .
3.6 Post Lab . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
7
7
7
8
8
9
9
10
10
11
4 Software Metrics
4.1 Problem Statement . . . . . . . . . .
4.2 Pre Lab . . . . . . . . . . . . . . . .
4.3 Hardware and Software Requirement
4.4 Theory . . . . . . . . . . . . . . . . .
4.5 Post Lab . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
16
16
18
i
TABLE OF CONTENTS
5 Ishikawas Seven tools
5.1 Problem Statement . . . . . . . . . .
5.2 Pre Lab . . . . . . . . . . . . . . . .
5.3 Hardware and Software Requirement
5.4 Theory . . . . . . . . . . . . . . . . .
5.4.1 Check sheet: . . . . . . . . .
5.4.2 Histogram: . . . . . . . . . .
5.4.3 Pareto Chart: . . . . . . . . .
5.4.4 Cause and effect diagram . .
5.4.5 Scatter Diagram: . . . . . .
5.4.6 Run Chart . . . . . . . . . .
5.4.7 Control Chart . . . . . . . . .
5.5 Post Lab . . . . . . . . . . . . . . . .
TABLE OF CONTENTS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
19
19
21
22
23
25
26
26
28
the test results
Problem Statement . . . . . . . . . . .
Pre Lab . . . . . . . . . . . . . . . . .
Hardware and Software Requirement .
Theory . . . . . . . . . . . . . . . . . .
6.4.1 Defect Tracking: . . . . . . . .
6.4.2 Introduction to Defect Report:
6.4.3 Defect Tracking . . . . . . . . .
6.4.4 Defect lifecycle . . . . . . . . .
6.5 Post Lab . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
29
29
31
32
33
33
7 Defect Tracking Report
7.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Pre Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Hardware and Software Requirement . . . . . . . . . . . . . .
7.4 Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Using Rapid Test Script wizard . . . . . . . . . . . . .
7.4.2 Using GUI-Map Configuration Tool: . . . . . . . . . .
7.4.3 Using Record-ContextSensitive mode: . . . . . . . . .
7.4.4 Using Record-Analog Mode: . . . . . . . . . . . . . . .
7.4.5 GUI CHECK POINTS-Single Property Check: . . . .
7.4.6 GUI CHECK POINTS-For Object/Window Property:
7.5 Post Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
37
37
37
38
38
38
39
39
40
6 Log
6.1
6.2
6.3
6.4
References
41
ii
List of Tables
iii
List of Figures
1.1
Test Summary Report using Excel Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Test director environment. . . . . . . . . .
Test director environment. . . . . . . . . .
Creation of New Folder . . . . . . . . . .
Creation of New Test and give name . . .
Creation of New Test and give name . . .
fill up the information in the Blank fields
Design Steps . . . . . . . . . . . . . . . .
Recording test cases . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
12
13
13
14
14
15
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Check sheet telephone interruption data
Histogram . . . . . . . . . . . . . . . . .
data table . . . . . . . . . . . . . . . . .
Pareto Diagram . . . . . . . . . . . . . .
fishbone diagram . . . . . . . . . . . . .
Run chart Diagram . . . . . . . . . . . .
control chart Diagram . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
22
23
24
25
27
28
6.1
6.2
6.3
6.4
6.5
How serious is the defect . . . . . .
How to decide priority . . . . . . .
Template of defect tracking report
Defect Tracking Log Instructions: .
Defect life cycle . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
4
Assignment 1
Manual Testing-Black box testing
1.1
Problem Statement
Write black box test cases for an application using Excel sheet
1.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
1.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.Software-Test Director.
1.4
1.4.1
Theory
Manual Testing:
Is the process of manually testing software for defects. It requires a tester to play the role of an
end user, and use most of all features of the application to ensure correct behavior. To ensure completeness of testing, the tester often follows a written test plan that leads them through a set of important
test cases.
Overview:
A key step in the process of software engineering is testing the software for correct behavior prior
to release to end users. With this informal approach, the tester does not follow any rigorous testing
procedure, but rather explores the user interface of the application using as many of its features as
1
1.4. THEORY
Manual Testing-Black box testing
possible, using information gained in prior tests to intuitively derive additional tests. The success of
exploratory manual testing relies heavily on the domain expertise of the tester, because a lack of knowledge will lead to incompleteness in testing. One of the key advantages of an informal approach is to
gain an intuitive insight to how it feels to use the application. Large scale engineering projects that
rely on manual software testing follow a more rigorous methodology in order to maximize the number
of defects that can be found. A systematic approach focuses on predetermined test cases and generally
involves the following steps.
1. Choose a high level test plan where a general methodology is chosen, and resources such as people,
computers, and software licenses are identified and acquired. 2. Write detailed test cases, identifying
clear steps to be taken by the tester, with expected outcomes. 3. Assign the test cases to testers, who
manually follow the steps and record the results. 4. Write a test report, detailing the findings of the
testers. The report is used by managers to determine whether the software can be released, and if not,
it is used by engineers to identify and correct the problems.
1.4.2
Stages:
There are several stages of manual testing. They are
1)Unit Testing: This initial stage in testing normally carried out by the developer who wrote the
code and sometimes by a peer using the white box testing technique.e.g function, procedure and class
testing
2)Integration Testing: This stage is carried out in two modes, as a complete package or as a increment to the earlier package. Most of the time black box testing technique is used. However, sometimes
a combination of Black and White box testing is also used in this stage.
3)System Testing: In this stage the software is tested from all possible dimensions for all intended
purposes and platforms. In this stage Black box testing technique is normally used.
4)User Acceptance Testing: This testing stage carried out in order to get customer sign-off of finished
product. A ’pass’ in this stage also ensures that the customer has accepted the software and is ready
for their use.
Lab Manual - Computer Laboratory Practice-I
2
VPCOE, Baramati
1.5. POST LAB
1.4.3
Manual Testing-Black box testing
Manual testing:
Manual testing means to perform manual test operations on the auto without any help of automation
tools.
Steps for manual testing:
1.Understand the functionality of application
2.Prepare the test plan
3.Write the test cases and execute on the auto.
4.Verify actual and expected results
5.Prepare the bug report
After receiving the modified build from the developer we will go for retesting and regression
testing. These processes are repeated until the bug status is closed.
Example: Electric bulb test cases:1. The bulb should be of required shape and size
2. Should be able to fitted and removed from the holder
3. Should sustain the voltage for which it is designed for
4. Should glow on switching on
5. Should not glow on switching off
6. Should glow with required illumination
7. Life of the bulb should meet the requirement
figure 1.1 shows the test summary report by using Excel Sheet.
1.5
Post Lab
Hence from this assignment students can learn how to write black box test cases for an application using
Excel sheet.
Lab Manual - Computer Laboratory Practice-I
3
VPCOE, Baramati
1.5. POST LAB
Manual Testing-Black box testing
Figure 1.1: Test Summary Report using Excel Sheet
Lab Manual - Computer Laboratory Practice-I
4
VPCOE, Baramati
Assignment 2
Manual Testing-White box testing.
2.1
Problem Statement
Perform white box testing Cyclomatic complexity, data flow testing, control flow testing
2.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
2.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.
2.4
2.4.1
Theory
White Box Testing StrategyCyclomatic complexity is a Software metric (measurement). It was developed by Thomas Mc-
Cabe and is used to measure the complexity of a program. It directly measures the number of linearly
independent paths through a program’s source code. Cyclomatic complexity is computed using a graph
that describes the control flow of the program. The nodes of the graph correspond to the commands of
a program. A directed edge connects two nodes if the second command might be executed immediately
after the first command.
Cyclomatic Complexity measures the logical complexity in the algorithm.
CC Formula=
5
2.5. POST LAB
Manual Testing-White box testing.
CC=Edges-Nodes+2
CC=Number of bounded+1
CC=Number of predicated+1
Simple example-
1. Int a, b, c
2. Read a, b
3. If a¿b
4. Then c=a-b
5. Else c=b-a
6. End if
Path-1
1-2-3-4-6
a=5, b=3
Expected result= 2
Path-2
1-2-3-5-6
a=2, b=7
Expected result= 5
Cyclomatic ComplexityEdges Node +2
6-6+2
=2
2.5
Post Lab
Hence from this assignment students can learn how to Perform white box testing Cyclomatic complexity,
data flow testing,control flow testing.
Lab Manual - Computer Laboratory Practice-I
6
VPCOE, Baramati
Assignment 3
Manual Testing-Black box testing
3.1
Problem Statement
Perform black box testing using automated testing tool (Test Director) on an application.
3.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
3.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.Software-Test Director.
3.4
Theory
3.4.1
Testing Techniques:
1. Static Testing / Reviews:
Testing of an object without execution on a computer.
2. Dynamic Testing: The process of executing a program or system with the intent of finding errors.
Sub Techniques under this are 1) Black box and 2) White Box
3.4.2
Black Box Testing:
1. Definition: Black Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is NOT known to the tester
7
3.4. THEORY
Manual Testing-Black box testing
2. Levels Applicable To: Mainly applicable to higher levels of testing:Acceptance Testing, System
Testing
3. Responsibility :Generally, independent Software Testers
4. Programming Knowledge :Not Required
5. Implementation Knowledge :Not Required
6. Basis for Test Cases: Requirement Specifications
EXAMPLE:
A tester, without knowledge of the internal structures of a website, tests the web pages by using a
browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.
3.4.3
White Box Testing:
1. Definition: White Box Testing is a software testing method in which the internal structure, design,
implementation of the item being tested is known to the tester.
2. Levels Applicable To:Mainly applicable to lower levels of testing:Unit Testing, Integration Testing
3. Responsibility :Generally, Software Developers
4. Programming Knowledge :Required
5. Implementation Knowledge : Required
6. Basis for Test Cases: Detailed Design
3.4.4
Test Director tool:
Software Automated Tool Test Director simplifies test management by helping you organize and
manage all phases of the software testing process, including planning, creating tests, executing tests,
and tracking defects. With Test Director, you maintain a project’s database of tests. From a project,
you can build test sets groups of tests executed to achieve a specific goal. For example, you can create
a test set that checks a new version of the software. As you execute tests, Test Director lets you report
defects detected in the software. Defect records are stored in a database where you can track them until
they are resolved in the software. Test Director works together with Win Runner, Mercury Interactive’s
automated GUI Testing tool. Win Runner enables you to create and execute automated test scripts.
Lab Manual - Computer Laboratory Practice-I
8
VPCOE, Baramati
3.4. THEORY
Manual Testing-Black box testing
You can include Win Runner automated tests in your project, and execute them directly from Test
Director.Test Director activates Win Runner, runs the tests, and displays the results.
The Test Director work flow consists of 3 main phases:
In each phase you perform several tasks:
1) Planning Tests 2) Running Tests 3) Tracking Defects
3.4.5
Planning Tests:
Divide your application into test subjects and build a project.
1. Define your testing goals:Examine your application, system environment, and testing resources to
determine what and how you want to test.
2. Define test subjects:Define test subjects by dividing your application into modules or functions to
be tested. Build a test plan tree that represents the hierarchical relationship of the subjects.
3. Define tests:Determine the tests you want to create and add a description of each test to the test
plan tree.
4. Design test steps:Break down each test into steps describing the operations to be performed and
the points you want to check. Define the expected outcome of each step.
5. Automate tests:Decide whether to perform each test manually or to automate it. If you choose
to perform a test manually, the test is ready for execution as soon as you define the test steps.
If you choose to automate a test, use Win Runner to create automated test scripts in Mercury
Interactive’s Test Script Language (TSL).
6. Analyze the test plan:Generate reports and graphs to help you analyze your test plan. Determine
whether the tests in the project will enable you to successfully meet your goals.
3.4.6
Running Tests:
Create test sets and perform test runs.
1. Create test sets:Create test sets by selecting tests from the project. A test set is a group of tests
you execute to meet a specific testing goal.
Lab Manual - Computer Laboratory Practice-I
9
VPCOE, Baramati
3.5. PROCEDURE
Manual Testing-Black box testing
2. Run test sets:Schedule test execution and assign tasks to testers. Run the manual and/or automated tests in the test sets.
3. Analyze the testing progress:Generate reports and graphs to help you determine the progress of
test execution
3.4.7
Tracking Defects:
1. Report defects detected in your application and track how repairs are progressing.
2. Report defects detected in the software: Each new defect is added to the defect database.
3. Track defects:Review all new defects reported to the database and decide which ones should be
repaired. Test a new version of the application after the defects are corrected.
4. Analyze defect tracking:Generate reports and graphs to help you analyze the progress of defect
repairs, and to help you determine when to release the application.
3.5
Procedure
STEP 1: Open Test Director
In figure 1.1 Test Director Environment,There is no password needed.
STEP 2: figure 1.3 Click on Plan Tests TAB and Create New folder
STEP 3: figure 1.4 Click on Plan Tests TAB and Create New folder and then click on New Test give
name MyTest then click OK.
STEP 4:figure 1.5 Click on Plan Tests TAB and Create New folder and then click on New Test give
name MyTest then click OK.
STEP 5: figure 1.6 Now fill up the information in the Blank fields about the Test Information.
STEP 5:figure 1.7 Click Design Steps=¿Click New, Now write Description and Expected, =¿ click
new write step 2 and so onfinally close
figure 1.8 is the view where the test cases recorded.
Lab Manual - Computer Laboratory Practice-I
10
VPCOE, Baramati
3.6. POST LAB
Manual Testing-Black box testing
Figure 3.1: Test director environment.
3.6
Post Lab
Hence from this assignment students can learn how to write black box test cases for an application using
Test Director tool.
Lab Manual - Computer Laboratory Practice-I
11
VPCOE, Baramati
3.6. POST LAB
Manual Testing-Black box testing
Figure 3.2: Test director environment.
Figure 3.3: Creation of New Folder
Lab Manual - Computer Laboratory Practice-I
12
VPCOE, Baramati
3.6. POST LAB
Manual Testing-Black box testing
Figure 3.4: Creation of New Test and give name
Figure 3.5: Creation of New Test and give name
Lab Manual - Computer Laboratory Practice-I
13
VPCOE, Baramati
3.6. POST LAB
Manual Testing-Black box testing
Figure 3.6: fill up the information in the Blank fields
Figure 3.7: Design Steps
Lab Manual - Computer Laboratory Practice-I
14
VPCOE, Baramati
3.6. POST LAB
Manual Testing-Black box testing
Figure 3.8: Recording test cases
Lab Manual - Computer Laboratory Practice-I
15
VPCOE, Baramati
Assignment 4
Software Metrics
4.1
Problem Statement
Calculate Software Metrics for an application using FP analysis method.
4.2
Pre Lab
Knowledge of Software Engineering .Knowledge of Software Testing.
4.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.
4.4
Theory
Select Any one system that is to be used for calculation of software metric.following is the one
system
Online Railway Reservation Management System having Description is as follows:
The Online railway Reservation application is used to reserve the seats in railway in advance for customers using the internet as the medium. Customer will browse through the railway site and reserve
seats online without having to visit the station physically.
- Allow the customer to browse the available seats for a particular destination.
- Check the availability of the seats.
- When there are no available seats, Cancel the reservation procedure or wait up to the seats become
available
16
4.4. THEORY
Software Metrics
- Check the availability of seats with first (AC),second class ,General, with 2 tiers ,3 tiers.
- Update the seats and no of customer details.
- Produce ticket with name, seat no, cost ,starting and destination address.
- Update no of seats based on no of reservations.
- Update customer account details based on payment by a customer.
- Provide Feedback mechanism where Customer can provide suggestions and complaints to the administrator.
RET1 -External Inputs = 5
-Customer details
-Seats
-Reservation Details
-Customer Payment Details
-Feedback Details
RET2-External Outputs =1
-Ticket
RET3-External Inquiries = 2
-Customer Details Request
-Seats Details Request
RET4-External Files = 0
Internal Files = 4
-Customer Database
-No of seats Database
-Customer reserved seats Database
-Seats update Database
table 4.1 Function Point Complexity Weighting:
Function-Type
Complexity
Points
External Inputs
Low(5)
3
External Outputs
Low(1)
4
External inquiries
Low(2)
3
External Files
None(0)
0
Internal Files
Low(4)
7
Unadjusted Function Point Count = 3(5) +4(1) +3(2) +7(0) +5(4)
Lab Manual - Computer Laboratory Practice-I
17
VPCOE, Baramati
4.5. POST LAB
Software Metrics
Unadjusted Function Point Count = 15+4+6+0+20
=45
table 4.2 Technical Complexity Factors
Fi
Complexity Factor
1
Does the system require reliable back up and recovery?
3/
2
Are data communication required
0/
3
Are there distributed processing functions?
0/
4
Is performance critical
4/
5
Will the system run in an existing, heavily utilized operating system
3/
6
Does the system require on-line entry?
4/
7
Does the on-line data entry require the input transaction to be built over multiple screen or operations?
3/
8
Are the master files updated on-line?
5/
9
Are the inputs, outputs, files, or inquiries complex?
0/
10
Is the internal processing complex?
2/
11
Is the code designed to be reusable
4/
12
Are the conversion and installation included in the design?
0/
13
Is the system designed for multiple installations in different organizations?
4/
14
Is the application designed to facilitate change and ease by the user?
3/
Total
Adjusted FP Count = Unadjusted FP count * VAF
Valu
-
3
FP = 60 * [0.65+0.01*35]
Function Point FP=60
4.5
Post Lab
Hence from this assignment students can learn how to Calculate Software Metrics for an application
using FP analysis method.
Lab Manual - Computer Laboratory Practice-I
18
VPCOE, Baramati
Assignment 5
Ishikawas Seven tools
5.1
Problem Statement
Prepare any two of the Ishikawas Seven tools listed below for an application.
1. The cause-and-effect or Ishikawa diagram 2. The check sheet 3. The control chart 4. The histogram
5. The Pareto chart 6. The scatter diagram 7. Stratification
5.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
5.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.
5.4
Theory
The seven basic tools according to Ishikawa are:
1)Check sheets 2) Histograms 3)Pareto diagram 4)Cause and effect diagram 5)Scatter diagram 6) Control chart 7) Run chart
5.4.1
Check sheet:
It is defined as A form or sheet used to record data
When to Use a Check Sheet:
19
5.4. THEORY
Ishikawas Seven tools
- When data can be observed and collected repeatedly by the same person or at the same location.
- When collecting data on the frequency or patterns of events,problems, defects, defect location, defect
causes, etc.
- When collecting data from a production process.
According to Ishikawa 1982, check sheets have the following functions:
-Production Process distribution checks
-Defective item checks
-Defective location checks
-Defective cause checks
-Check-up confirmation checks
-Others
Check List Example:
The figure below shows a check sheet used to collect data on telephone interruptions. The tick marks
were added as data was collected over several weeks
Figure 5.1: Check sheet telephone interruption data
Lab Manual - Computer Laboratory Practice-I
20
VPCOE, Baramati
5.4. THEORY
5.4.2
Ishikawas Seven tools
Histogram:
Histogram Defined As
-A bar graph that shows frequency data.
-Provides the easiest way to evaluate the distribution of data.
-Organizes a group of data points into user-specified ranges.
-The histogram condenses a data series into an easily interpreted visual by taking many data points and
grouping them into logical ranges.
Drawing Histograms:
- Mark class intervals on X-axis and frequencies on Y-axis. The scales for both the axes need not be
the same.
- Class intervals must be exclusive. If the intervals are in inclusive form, convert them to the exclusive
form.
-Draw rectangles with class intervals as bases and the corresponding frequencies as heights. A rectangle
is constructed on each class interval.
-If the intervals are equal, then the height of each rectangle is proportional to the corresponding class
frequency.
-If the intervals are unequal, then the area of each rectangle is proportional to the corresponding class
frequency.
Constructing a Histogram:
From a set of data compute:sum,mean (x),Max,Min,Range (max-min)
Use range to estimate beginning and end
Calculate the width of each column by dividing the range by the number of columns
Range/ no of Columns = Width
Acme Pizza Example:
Lets say the owner wants a distribution of Acmes Thursday Night Sales
Data Set from last Thursday(slices)
0212241312122434143223212212214221212212121212121222121
2112223142232221232242244122232212242124217212231211212
22122121222424
Mean = 2.032258
Max = 7
Min = 0
Lab Manual - Computer Laboratory Practice-I
21
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
Range = 7
For 7 columns what would the width be?
Range/Columns= 7/7 = 1 slice
Figure 5.2: Histogram
5.4.3
Pareto Chart:
Pareto Charts Defined As
- A Pareto chart is a bar graph.
- The lengths of the bars represent frequency or cost (time or money)
- Bars are arranged with longest bars on the left and the shortest to the right.
- In this way the chart visually depicts which situations are more significant.
Constructing a Pareto Chart
1. Decide what categories you will use to group items.
2. Decide what measurement is appropriate. Common measurements are frequency, quantity, cost and
time.
3. Decide what period of time the Pareto chart will cover: One work cycle? One full day? A week?
4. Collect the data, recording the category each time. (Or assemble data that already exist.)
5. Subtotal the measurements for each category.
6. Determine the appropriate scale for the measurements you have collected. The maximum value will
Lab Manual - Computer Laboratory Practice-I
22
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
be the largest subtotal from step
7. Mark the scale on the left side of the chart.
8. Construct and label bars for each category. Place the tallest at the far left, then the next tallest to
its right and so on. If there are many categories with small measurements, they can be grouped as other.
Example:
The information to be represented on a Pareto diagram should already have been collected in some sort
of record.
Figure 5.3: data table
The data are then displayed graphically in figure 5.4. Firstly in terms of frequency.....
5.4.4
Cause and effect diagram
Cause and Effect Diagram Defined As:
- The cause and effect diagram is also called the Ishikawa diagram or the fishbone diagram.
- The fishbone diagram identifies many possible causes for an effect or problem.
- It can be used to structure a brainstorming session. It immediately sorts ideas into useful categories.
Constructing a Cause and Effect Diagrams
Lab Manual - Computer Laboratory Practice-I
23
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
Figure 5.4: Pareto Diagram
1. First, clearly identify and define the problem or effect for which the causes must be identified. Place
the problem or effect at the right or the head of the diagram.
2. Identify all the broad areas of the problem.
i. Methods ii. Machines (equipment) iii. People (manpower) iv. Materials v. Measurement vi. Environment
3. Write in all the detailed possible causes in each of the broad areas.
4. Each cause identified should be looked upon for further more specific causes.
5. View the diagram and evaluate the main causes.
6. Set goals and take action on the main causes.
Example Cause and Effect Diagrams:
- The managing director of a weighing machine company received a number of irate letters, complaining
of slow service and a constantly engaged telephone.
- Rather surprised, he asked his support and marketing managers to look into it.
-They used the ’Four M’s’ (Manpower, Methods, Machines and Materials) as primary cause areas, and
then added secondary cause areas before adding actual causes, thus helping to ensure that all possible
causes were considered. Causes common to several areas were flagged with capital letters, and key
causes to verify and address were circled.
-On further investigation, they found that service visits were not well organized; engineers just picked
Lab Manual - Computer Laboratory Practice-I
24
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
up a pile of calls and did them in order. They consequently set up regions by engineer and sorted calls;
this significantly reduced traveling time and increased service turnaround time. They also improved the
telephone system and recommended a review of suppliers’ quality procedures.
Figure 5.5: fishbone diagram
5.4.5
Scatter Diagram:
Scatter Diagrams Defined:
Scatter Diagrams are used to study and identify the possible relationship between the changes observed
in two different sets of variables.
Constructing a Scatter Diagram:
-First, collect two pieces of data and create a summary table of the data.
-Draw a diagram labeling the horizontal and vertical axes.
.It is common that the cause variable be labeled on the X axis and the effect variable be labeled on the
Y axis.
-Plot the data pairs on the diagram.
-Interpret the scatter diagram for direction and strength.
An Example of When a Scatter Diagram Can Be Used:
A scatter diagram can be used to identify the relationship between the production speed of an operation
Lab Manual - Computer Laboratory Practice-I
25
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
and the number of defective parts made.
5.4.6
Run Chart
Run Charts Defined:
Run charts are used to analyze processes according to time or order.
following procedure is used for Creating a Run Chart
1)Gathering Data:
Some type of process or operation must be available to take measurements for analysis.
2)Organizing Data:
Data must be divided into two sets of values X and Y. X values represent time and values of Y represent
the measurements taken from the manufacturing process or operation.
3)Charting Data:
Plot the Y values versus the X values.
4)Interpreting Data
Interpret the data and draw any conclusions that will be beneficial to the process or operation.
Run charts (often known as line graphs outside the quality management field) display process performance over time. Upward and downward trends, cycles, and large aberrations may be spotted and
investigated further. In a run chart, events, shown on the y axis, are graphed against a time period
on the x axis. For example, a run chart in a hospital might plot the number of patient transfer delays
against the time of day or day of the week. The results might show that there are more delays at noon
than at 3 p.m. Investigating this phenomenon could unearth potential for improvement. Run charts can
also be used to track improvements that have been put into place, checking to determine their success.
Also, an average line can be added to a run chart to clarify movement of the data away from the average.
5.4.7
Control Chart
The control chart is a graph used to study how a process changes over time. Data are plotted in time
order. A control chart always has a central line for the average, an upper line for the upper control
limit and a lower line for the lower control limit. These lines are determined from historical data. By
comparing current data to these lines, you can draw conclusions about whether the process variation is
consistent (in control) or is unpredictable (out of control, affected by special causes of variation).
Control charts for variable data are used in pairs. The top chart monitors the average, or the centering
of the distribution of data from the process. The bottom chart monitors the range, or the width of the
Lab Manual - Computer Laboratory Practice-I
26
VPCOE, Baramati
5.4. THEORY
Ishikawas Seven tools
Figure 5.6: Run chart Diagram
distribution. If your data were shots in target practice, the average is where the shots are clustering,
and the range is how tightly they are clustered. Control charts for attribute data are used singly.
When to Use a Control Chart:
When controlling ongoing processes by finding and correcting problems as they occur.
When predicting the expected range of outcomes from a process.
When determining whether a process is stable (in statistical control).
When analyzing patterns of process variation from special causes (non-routine events) or common causes
(built into the process).
When determining whether your quality improvement project should aim to prevent specific problems
or to make fundamental changes to the process.
Control Chart Basic Procedure:
Choose the appropriate control chart for your data.Determine the appropriate time period for collecting
and plotting data.Collect data, construct your chart and analyze the data.Look for out-of-control signals
on the control chart. When one is identified, mark it on the chart and investigate the cause. Document
how you investigated, what you learned, the cause and how it was corrected.Continue to plot data as
they are generated. As each new data point is plotted, check for new out-of-control signals.When you
start a new control chart, the process may be out of control. If so, the control limits calculated from the
first 20 points are conditional limits. When you have at least 20 sequential points from a period when
Lab Manual - Computer Laboratory Practice-I
27
VPCOE, Baramati
5.5. POST LAB
Ishikawas Seven tools
the process is operating in control, recalculate control limits.
Out-of-control signals:
A single point outside the control limits. In Figure 1, point sixteen is above the UCL (upper control
limit).Two out of three successive points are on the same side of the centerline and farther than 2 s
from it. In Figure 1, point 4 sends that signal.Four out of five successive points are on the same side of
the centerline and farther than 1 s from it. In Figure 1, point 11 sends that signal. A run of eight in a
row are on the same side of the centerline. Or 10 out of 11, 12 out of 14 or 16 out of 20. In Figure 1,
point 21 is eighth in a row above the centerline. Obvious consistent or persistent patterns that suggest
something unusual about your data and your process.
Figure 5.7: control chart Diagram
5.5
Post Lab
Hence from this assignment students can learn how to prepare Ishikawas Seven tools for an given
application.
Lab Manual - Computer Laboratory Practice-I
28
VPCOE, Baramati
Assignment 6
Log the test results
6.1
Problem Statement
Log the test results in test director.
6.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
6.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk.
6.4
6.4.1
Theory
Defect Tracking:
To track defects, a defect workflow process has been implemented. Defect workflow training will be
conducted for all test engineers. The steps in the defect workflow process are as follows:
a) When a defect is generated initially, the status is set to ”New”. (Note: How to document the defect,
what fields need to be filled in and so on, also need to be specified.)
b) The Tester selects the type of defects:
-Bug
- Cosmetic
- Enhancement
29
6.4. THEORY
Log the test results
- Omission
c) The tester then selects the priority of the defect:
- Critical - fatal error
- High - require immediate attention
- Medium - needs to be resolved as soon as possible but not a showstopper
- Low - cosmetic error
d) A designated person (in some companies, the software manager; in other companies, a special
board) evaluates the defect and assigns a status and makes modifications of type of defect and/or priority if applicable.
- The status ”Open” is assigned if it is a valid defect.
-The status ”Close” is assigned if it is a duplicate defect or user error. The reason for ”closing” the
defect needs to be documented.
- The status ”Deferred” is assigned if the defect will be addressed in a later release.
- The status ”Enhancement” is assigned if the defect is an enhancement requirement.
e) If the status is determined to be ”Open”, the software manager (or other designated person)
assigns the defect to the responsible person (developer) and sets the status to ”Assigned”.
f) Once the developer is working on the defect, the status can be set to ”Work in Progress”.
g) After the defect has been fixed, the developer documents the fix in the defect tracking tool and
sets the status to .fixed,. if it was fixed, or ”Duplicate”, if the defect is a duplication (specifying the
duplicated defect). The status can also be set to ”As Designed”, if the function executes correctly. At
the same time, the developer reassigns the defect to the originator.
h) Once a new build is received with the implemented fix, the test engineer retests the fix and other
possible affected code. If the defect has been corrected with the fix, the test engineer sets the status to
”Close”. If the defect has not been corrected with the fix, the test engineer sets the status to reopen.
Defect correction is the responsibility of system developers; defect detection is the responsibility of the
test team. The test leads will manage the testing process, but the defects will fall under the purview of
the configuration management group. When a software defect is identified during testing of the application, the tester will notify system developers by entering the defect into the Defect Tracker tool and
filling out the applicable information.
Lab Manual - Computer Laboratory Practice-I
30
VPCOE, Baramati
6.4. THEORY
6.4.2
Log the test results
Introduction to Defect Report:
Defect reports are among the most important deliverables to come out of test. They are as important
as the test plan and will have more impact on the quality of the product than most other deliverables
from test. It is worth the effort to learn how to write effective defect reports.
Effective defect reports will:
-Reduce the number of defects returned from development
- Improve the speed of getting defect fixes
- Improve the credibility of test
- Enhance teamwork between test and development
Why do some testers get a much better response from development than others? Part of the answer lies
in the defect report. Following a few simple
rules can smooth the way for a much more productive environment. The objective is not to write
the perfect defect report, but to write an effective defect report that conveys the proper message, gets
the job done, and simplifies the process for everyone.
Contents:
- Defect Remarks
- Essentials for Effective Defect Remarks
-Defect Abstracts
Who reads our defect reports?
-Project Manager, Executives, Development, Customer Support, Marketing, Quality Assurance, Any
member of the Project Team
What may happen to these defects?
-The Product team cannot make the right decisions about this software error
Who reads the description part of the defect report? -Development, Project Manager, Customer
Support, Quality Assurance, Any member of the Project Team
Definitions:
Severity: - it indicate how bad the bugs and reflex is impolite on the product and on the user.
Priority: - Indicate how important it is to fix the bugs and when it should be fixed.
How serious is the defect?: figure 6.1
How to decide priority?: figure 6.2
Lab Manual - Computer Laboratory Practice-I
31
VPCOE, Baramati
6.4. THEORY
Log the test results
Figure 6.1: How serious is the defect
What we need to write in the defect report:
- What are the conditions and the Failure?
- Use the Failure info. for your Subject line
- Steps to reproduce the Software Error
- Determine the Severity and Priority
- Include the OS and build number
- Information on other conditions tested
Fields in defect report
1. Summary,2. Priority,3. Severity,4. Description,5. Reproducible(either yes or no),6. Status, 7.
Version no. etc..
Defect Tracking Log Instructions:figure 6.4
6.4.3
Defect Tracking
Monitoring defects from the time of recording until satisfactory resolution has been determined.
Lab Manual - Computer Laboratory Practice-I
32
VPCOE, Baramati
6.5. POST LAB
Log the test results
Figure 6.2: How to decide priority
6.4.4
Defect lifecycle
Bug lifecycle/Defect tracking lifecycle/change request lifecycle. Defect Tracking: - Monitoring defect
from the time of recording until satisfactory resolution has been determine
defect life cycle as shown in figure 6.5
6.5
Post Lab
Hence from this assignment students can learn how to log the test results in test director.
Lab Manual - Computer Laboratory Practice-I
33
VPCOE, Baramati
6.5. POST LAB
Log the test results
Figure 6.3: Template of defect tracking report
Lab Manual - Computer Laboratory Practice-I
34
VPCOE, Baramati
6.5. POST LAB
Log the test results
Figure 6.4: Defect Tracking Log Instructions:
Lab Manual - Computer Laboratory Practice-I
35
VPCOE, Baramati
6.5. POST LAB
Log the test results
Figure 6.5: Defect life cycle
Lab Manual - Computer Laboratory Practice-I
36
VPCOE, Baramati
Assignment 7
Defect Tracking Report
7.1
Problem Statement
Prepare defect tracking report/Bug report using defect tracking tool like Winrunner.
7.2
Pre Lab
Knowledge of Software Engineering . Knowledge of Software Testing.
7.3
Hardware and Software Requirement
Hardware-P4 machine,1GB Ram,40 GB Hard Disk,win Runner software.
7.4
7.4.1
Theory
Using Rapid Test Script wizard
- Start− >Program Files− >Win runner− >winruner
- Select the Rapid Test Script Wizard (or) create− >Rapid Test Script wizard
- Click Next button of welcome to script wizard
- Select hand icon and click on Application window and Click Next button
- Select the tests and click Next button
- Select Navigation controls and Click Next button
- Set the Learning Flow(Express or Comprehensive) and click Learn button
- Select start application YES or NO, then click Next button
37
7.4. THEORY
Defect Tracking Report
- Save the Startup script and GUI map files, click Next button
- Save the selected tests, click Next button
- Click Ok button
- Script will be generated. Then run the scripts. Run− >Run from top
- Find results of each script and select tools− >text report in Winrunner test results.
7.4.2
Using GUI-Map Configuration Tool:
- Open an application.
- Select Tools-GUI Map Configuration;Windows pops-up.
- Click ADD button; Click on hand icon.
- Click on the object, which is to be configured. A user-defined class for that object is added to list.
- Select User-defined class you added and press Configure button.
- Mapped to Class ;( Select a corresponding standard class from the combo box).
- You can move the properties from available properties to Learned Properties. By selecting Insert
button
- Select the Selector and recording methods.
- Click Ok button
- Now, you will observe Winrunner indentifying the configured objects.
7.4.3
Using Record-ContextSensitive mode:
- Create− >Record context Sensitive
- Select start− >program files− >Accessories− >Calculator
- Do some action on the application.
- Stop recording
- Run from Top; Press OK.
7.4.4
Using Record-Analog Mode:
- Create− >Insert Function− >from function generator
- Function name :( select ”invoke-application” from combo box).
- Click Args button; File: mspaint.
- Click on ”paste” button; Click on ”Execute” button to open the application; finally click on ”Close”.
Lab Manual - Computer Laboratory Practice-I
38
VPCOE, Baramati
7.4. THEORY
Defect Tracking Report
- Create− >Record-Analog.
- Draw some picture in the paintbrush file.
- Stop Recording
- Run− >Run from Top; Press ”OK”.
7.4.5
GUI CHECK POINTS-Single Property Check:
- Create− >Insert function− >Function Generator− > (Function name:Invoke-application; File :Flight
1a)
- Click on”paste” and click on ”execute” and close the window.
- Create− >Record Context sensitive.
- Do some operations and stop recording.
- Create− >GUI Check Point− >For single Property.
- Click on some button whose property to be checked.
- Click on paste.
- Now close the Flight1a application; Run− >Run from top.
- Press ”OK” it displays results window.
- Double click on the result statement. It shows the expected value and actual value window.
7.4.6
GUI CHECK POINTS-For Object/Window Property:
- Create− >Insert function− >Function Generator− > (Function name:Invoke-application; File :Flight
1a)
- Click on”paste” and click on”execute” and close the window.
- Create− >Record Context sensitive.
- Do some operations and stop recording.
- Create− >GUI Check Point− >Object/Window Property.
- Click on some button whose property to be checked.
- Click on paste.
- Now close the Flight 1a application; Run− >Run from top.
- Press ”OK” it displays results window.
- Double click on the result statement. It shows the expected value and actual value window.
Lab Manual - Computer Laboratory Practice-I
39
VPCOE, Baramati
7.5. POST LAB
7.5
Defect Tracking Report
Post Lab
Hence from this assignment students can learn how to prepare defect tracking report/Bug report using
defect tracking tool like Winrunner .
Lab Manual - Computer Laboratory Practice-I
40
VPCOE, Baramati
References
[1] Boris Beizer, ”Software Testing Techniques”, dreamTech ,
[2] Dr KVKK Prasad, ”Software Testing Tools”,dreamTech.
41