ASSIGNMENT-1

1) a. Explain the principles of test case desin?.

a) Software testing is an extremely creative and intellectually challenging task. When testing
follows the principles given below, the creative element of test design and execution rivals
any of the preceding software development steps.
1. Testing shows the presence of bugs
Testing an application can only reveal that one or more defects exist in the application,
however, testing alone cannot prove that the application is error free. Therefore, it is
important to design test cases
2)Exhaustive testing in impossible
Unless the application under test (UAT) has a very simple logical structure and limited input, it
is not possible to test all possible combinations of data and scenarios. For this reason, risk and
priorities which find as many defects as possible
3)Early Testing:
The sooner we start the testing activities the better we can utilize the available time. As soon as
the initial products, such the requirement or design documents are available, we can start testing.
It is common for the testing phase to get squeezed at the end of the development lifecycle, i.e.
when development has finished, so by starting testing early, we can prepare testing for each level
of the development lifecycle
4. Defect clustering
During testing, it can be observed that most of the reported defects are related to small number
of modules within a system. i.e. small number of modules contain most of the defects in the
system. This is the application of the Pareto Principle to software testing: approximately 80% of
the problems are found in 20% of the modules
5. The pesticide paradox
If you keep running the same set of tests over and over again, chances are no more new defects
will be discovered by those test cases. Because as the system evolves, many of the previously
reported defects will have been fixed and the old test cases do not apply anymore. Anytime a
fault is fixed or a new functionality added, we need to do regression testing to make sure the
new changed software has not broken any other part of the software. However, those regression
test cases also need to change to reflect the changes made in the software to be applicable and
hopefully fine new defects
6. Testing is context dependent

Different methodologies, techniques and types of testing is related to the type and nature of the
application. For example, a software application in a medical device needs more testing than a
games software. More importantly a medical device software requires risk based testing, be
compliant with medical industry regulators and possibly specific test design techniques. By the
same token, a very popular website, needs to go through rigorous performance testing as well
as functionality testing to make sure the performance is not affected by the load on the servers.
7. Absence of errors fallacy
Just because testing didnt find any defects in the software, it doesnt mean that the software is
ready to be shipped. Were the executed tests really designed to catch the most defects? or where
they designed to see if the software matched the users requirements? There are many other
factors to be considered before making a decision to ship the software.
b) b. List out various dichotomies and Explain?
Testing versus Debugging: The phrase Test and Debug is treated as a single word.
TESTING
1) The purpose of testing is to show that a
program has bugs.

DEBUGGING
1) The purpose of debugging is find the error or
misconception that led to the programs failure
and to design and implement the program
changes that correct the error.

2)Testing starts with predictable outcomes

2)Debugging cannot be predicted
3)Testing can be planned and scheduled
3)Debugging cannot be scheduled
4)Testing is programs failure
4)Debugging is programmers ability
5)Testing is not possible without design
5)Debugging is not possible without program
knowledge
knowledge
6)Test execution can be easy or automated
6)Debugging cannot be automated
Function versus Structure: Tests can be designed from a functional or structural point of view.
In functional testing the program or system is treated as a black box.
BLACK BOX TESTING: Here we dont know the internal functionality. We know only about
the input and the outcome.
In structural testing it looks at the implementation details, as programming style, control method,
source language, database design and coding details. The structural testing is also called as White
Box testing.
Functional bugs can be removed easily.
WHITE BOX TESTING: Here inter functionality is considered.
Structural bugs are hard to remove.
Designer versus Tester:

DESIGNER
1)Designing depends on a systems structural
details

TESTER
1) Tester, test-team member or test designer
contrast to the programmer and program
designer
2) The more you know about the design, the
2) Testing includes unit testing to unit
likelier you are to eliminate useless tests.
integration, component testing to component
integration, system testing to system
integration.
Modularity versus Efficiency: Both tests and systems can be modular. A module is a discrete,
well defined small component of a system. The smaller the component, the easier is to
understand but every component has interface with other components and all component
interfaces are sources of confusion. Smaller the component less the bugs. Larger components
reduce external interfaces but have complicated internal logic that may be difficult or impossible
to understand. Testing can and should likewise be originated in to modular components, small,
independent test cases have the virtue of easy repeatability.
Small versus Large: Programming in the large means constructing programs that consist of
many components written by many different persons.
Programming in the small is what we do for ourselves in the privacy of our own office or
as homework exercises in an undergraduate programming course.
Qualitative changes occur with size so it must to perform testing methods and quality criteria.
Builder versus Buyer: Just as programmers and testers can merge and become one, so can builder
and buyer.
i) The builder, who designs for and is accountable to.
ii) The buyer, who pays for the system in the hope of profits from providing services to.

1) a. Demonstrate the transaction flows? Discuss their complications?

a) INTRODUCTION:

A transaction is a unit of work seen from a system user's point of view.

A transaction consists of a sequence of operations, some of which are performed by a
system, persons or devices that are outside of the system.
Transaction begins with Birth-that is they are created as a result of some external act.
At the conclusion of the transaction's processing, the transaction is no longer in the
tasks:

Example of a transaction: A transaction for an online information retrieval system

might consist of the following steps or system.
Accept input (tentative birth)
Validate input (birth)
Transmit acknowledgement to requester

Do input processing
Search file
Request directions from
user Accept input
Validate input
Process request
Update file
Transmit output
Record transaction in log and clean up (death)
TRANSACTION FLOW GRAPHS:

Transaction flows are introduced as a representation of a system's processing.

The methods that were applied to control flow graphs are then used for functional
testing.
Transaction flows and transaction flow testing are to the independent system tester
what control flows are path testing are to the programmer.
The transaction flow graph is to create a behavioral model of the program that leads to
functional testing.
The transaction flowgraph is a model of the structure of the system's behavior
(functionality).
An example of a Transaction Flow is as follows:

USAGE:

Transaction flows are indispensable for specifying requirements of complicated

systems, especially online systems.
A big system such as an air traffic control or airline reservation system, has not
hundreds, but thousands of different transaction flows.
The flows are represented by relatively simple flowgraphs, many of which have a
single straight-through path.

Loops are infrequent compared to control flowgraphs.

The most common loop is used to request a retry after user input errors. An ATM
system, for example, allows the user to try, say three times, and will take the card
away the fourth time.
COMPLICATIONS:
In simple cases, the transactions have a unique identity from the time they're created to
the time they're completed.
In many systems the transactions can give birth to others, and transactions can also
merge.
Births: There are three different possible interpretations of the decision symbol, or
nodes with two or more out links. It can be a Decision, Biosis or a Mitosis.
1. Decision: Here the transaction will take one alternative or the other
alternative but not both.
2. Biosis:Here the incoming transaction gives birth to a new transaction, and
both transaction continue on their separate paths, and the parent retains it
identity.
3. Mitosis: Here the parent transaction is destroyed and two new transactions
are
created

.
Mergers: Transaction flow junction points are potentially as troublesome as transaction flow
splits. There are three types of junctions: (1) Ordinary Junction (2) Absorption (3) Conjugation
1. Ordinary Junction: An ordinary junction which is similar to the junction in a control
flow graph. A transaction can arrive either on one link or the other.
2. Absorption: In absorption case, the predator transaction absorbs prey transaction. The
prey gone but the predator retains its identity
3. Conjugation: In conjugation case, the two parent transactions merge to form a new
daughter. In keeping with the biological flavor this case is called as conjugation

b) Discuss about static and dynamic anomaly detection?

Ans: Static anomaly:
i)static analysis is analysis done at compile time.
ii)It cant detect dead variables.
iii)Array errors cant be detected.
iv)Static analysis cannot detect bugs in state graphs
Dynamic anomaly:
i)Dynamic analysis is done at runtime.
ii) Dynamic analysis is done on the fly, as the program is based on intermediate values that
result from the programs execution.
c) Discuss the reasons why only the static anomaly detection is not enough?
Ans: Even with the most sophisticated technology, you will detect anomalies that are not
actionable or require immediate attention. For example, some solutions allow you to manually
configure and account for the impact of a scheduled maintenance window or load-balancing
and clustering. This alone is not enough to avoid false positives and alert noise.
Anomalies regularly occur in all types of systems. These deviations (anomalies) do not always
require operational attention but can generate a lot of noise. However, if multiple metrics are
deviating outside the learned behavior coupled with domain knowledge, then the resulting
combination requires operational attention. For example, we could be experiencing a
performance issue if the percent CPU used is deviating outside the learned bands and the
processor run queue is more than twice the number of processors. By automatically layering on
best practices to detection in our policies, Netuitive is able to alert on a real anomaly instead of
a false alarm.

Plagarism Statement: This project was written by me and in my own words, except for
quotations from published and unpublished sources which are clearly indicated and
acknowledged as such. I am conscious that the incorporation of material from other works or
a paraphrase of such material without acknowledgement will be treated as plagiarism, subject
to the custom and usage of the subject, according to the University Regulations on Conduct of
Examinations. The source of any picture, map or other illustration is also indicated, as is the
source, published or unpublished, of any material not resulting from my own experimentation,
observation or specimen-collecting.
NAME:SRINIDHI VANGARI
ROLLNO:13951A0583

DATE:2/02/2016