Unit -3 Software Engineering
ADARSH B.C.ACOLLEGE -HADDAD
BCASEM-5
Subject : Software Engineering
Unit:-3 Coding & Testing
❖
Testing Methods
❖Levels of Testing
❖Testing Fundamentals(error,
fault,failure)
❖Programming Practice
PREPARED BY : KRUPALI BHATT 1
Unit -3 Software Engineering
Levels of Software Testing
oftware Testing is anactivity performed toidentifyerrorsso thaterrors canbe
S
removed to obtain a product with greater quality. To assure and maintain the
quality of software and torepresentthe ultimate reviewofspecification, design,
and coding, Software testing is required. There are different levels of testing:
1. UnitTesting:
In this type of testing, errorsare detectedindividually fromeverycomponent or
unit byindividually testing thecomponentsor unitsof softwaretoensure thatif
they are fit for use by the developers. It is the smallest testable part of the software.
2 . Integration Testing:
Inthistesting,twoormoremoduleswhichareunittestedareintegratedtotesti.e.
techniqueinteractingcomponentsandarethenverifiediftheseintegratedmodules
work as per the expectation or not and interface errors are also detected.
3. System Testing:
In system testing, complete and integrated software's are tested i.e. all the
system elements forming the system is tested as a whole to meet the
requirements of the system.
4. Acceptance Testing:
I tisakindoftestingconductedtoensurewhethertherequirementsoftheusersare
fulfilledpriortoitsdeliveryandthesoftwareworkscorrectlyintheuser'sworking
environment.
hese testing can be conducted at various stages of software development. The
T
levels of testing along with the corresponding software development phase is
shown by the following diagram -
PREPARED BY : KRUPALI BHATT 2
Unit -3 Software Engineering
LEVELS OF TESTING
hile performing the software testing, following Testing principles must be
W
applied by every software engineer:
The requirements of customers should be traceable and identified by all
different tests.
lanningof teststhat howtestswillbeconductedshouldbedonelongbeforethe
P
beginning of the test.
he Pareto principle can be applied to software testing - 80% of all errors
T
identified during testingwilllikely betraceableto20% of allprogram modules.
Testing should begin "in the small" and progress toward testing "in the large”.
Exhaustive testing which simply means to test all the possible combinations of
data is not possible.
esting conductedshouldbe mosteffective andfor thispurpose,an independent
T
third party is required.
PREPARED BY : KRUPALI BHATT 3
Unit -3 Software Engineering
Testing Method:-
Black-Box Testing
hetechniqueoftestingwithouthavinganyknowledgeoftheinteriorworkingsof
T
the application is called black-box testing.
Thetester is obliviousto thesystemarchitectureanddoesnothaveaccesstothe
source code.
ypically,whileperformingablack-boxtest,atesterwillinteractwiththesystem's
T
user interface by providing inputs and examining outputs withoutknowing how
and where the inputs are worked upon.
The following table lists the advantages and disadvantages of black-box testing.
Advantages
Well suited and efficient for large code segments
Code access is not required.
learly separates user's perspective from the developer’s perspective through
C
visibly defined roles.
large number of moderately skilled testers can test the application with no
A
knowledge of implementation,programming language,or operating system.
Dis-Advantages
imited coverage, since only a selected number of test scenarios is actually
L
performed.
I nefficienttesting,duetothe factthatthetesteronlyhaslimitedknowledgeabout
an application.
PREPARED BY : KRUPALI BHATT 4
Unit -3 Software Engineering
Blind coverage ,since the tester cannot target specific code segments or error areas.
The test cases are difficult to design.
White-Box Testing
hite-boxtestingisthedetailedinvestigationofinternallogicandstructureofthe
W
code. White-box testing is also called glass testing or open-box testing.
I nordertoperformwhite-boxtestingonanapplication,atesterneedstoknowthe
internal workings of the code.
he tester needs to have a look inside the source code and find out which
T
unit/chunk ofthecode is behaving inappropriately.
The following lists the advantages and disadvantages of white-box testing.
Advantages
sthetesterhasknowledge ofthe sourcecode, itbecomesveryeasytofindout
A
which type of data can help in testing the application effectively.
IT helps in optimizing the code.
xtra line of code can be removed which can bring in hidden defects.
E
Due to this tester’s knowledge about the code ,maximum coverage is attained
during test scenario writing.
Dis- Advantages
PREPARED BY : KRUPALI BHATT 5
Unit -3 Software Engineering
ue to the fact that a skilled tester is needed to perform white-box testing ,the
D
costs are increased.
ometimes itis impossible tolookintoeverynookandcornertofindouthidden
S
errors that may create problems ,as many paths will go untested.
I t is difficult to maintain white-box testing ,as it requires specialized tools like
code analyzers and debugging tools.
Grey-Box Testing
rey-box testing is a technique to test the application with having a limited
G
knowledge of the internal workings of an application. In software testing, the
phrase the more you know, the better carries a lot of weight while testing an
application.
asteringthe domainofa systemalways givesthe tester anedgeoversomeone
M
with limited domain knowledge. Unlike black-boxtesting, wherethetester only
tests the application's user interface;in grey-box testing, thetester hasaccess to
design documents andthedatabase. Havingthis knowledge,a testercan prepare
better test data and test scenarios while making a test plan.
Advantages
Offers combined benefits of black-box and white-box testing wherever possible.
ray box testers don’t rely on the source code, instead they rely on interface
G
definition and functional specifications.
PREPARED BY : KRUPALI BHATT 6
Unit -3 Software Engineering
asedonthelimitedinformationavailable,agray-boxtestercandesignexcellent
B
test scenarios especially around communication protocols and data type handling.
The test is done from the point of view of the user and not the designer.
Dis-Advantages
incetheaccesstosourcecodeisnotavailable,theabilitytogooverthecodeand
S
test coverage is limited.
The test can be redundant if the software designer has already run a test case.
esting every possible input stream is unrealistic because it would take an
T
unreasonable amount of time therefore ,many program paths will go untested.
A Comparison of Testing Methods
he following table lists the pointsthat differentiateblack-boxtesting, grey-box
T
testing, and white-box testing.
Black-Box Testing Grey-Box Testing White-Box Testing
he internal working of
T he tester has limited
T ester has full knowledge
T
an application need not knowledge of internal of the internal working of
been known working of the the application.
application.
lso known as closed
A lso known as
A lso known as clear box
A
box testing,data-driven translucent testing ,as the testing , structural testing
testing or functional tester has limited or code based testing.
testing. knowledge of the inside
of the application
Performed by end user Performed by end users Normally done by testers
PREPARED BY : KRUPALI BHATT 7
Unit -3 Software Engineering
a nd also by testers and a nd also by testers and and developers.
developers. developers.
esting is based on
T esting is done on the
T I nternal working are
external expectations- basis of high level fully known and the
internal behaviour of the database diagrams and tester can design test data
application is unknown. data flow diagrams. accordingly.
I t is exhaustive and the artly time consuming
P he most exhaustive and
T
least time consuming. and exhaustive. time consuming type of
testing.
ot suited for algorithm
N ot suited for algorithm
N uited for algorithm
S
testing. testing. testing.
his can only be done by D
T ata domain and internal D ata domain and internal
trial and error method. boundaries can be tested boundaries can be better
,if known. tested.
Testing Fundamentals (errors, fault & failure):
e have used the intuitive meaning of the term error to refer to problems in
W
requirements, design, or code.
ometimes error,fault, andfailure are usedinterchangeably, andsometimesthey
S
refer to different concepts.
We follow the IEEE definitions for these terms.
PREPARED BY : KRUPALI BHATT 8
Unit -3 Software Engineering
RROR:-
E
The term error is used in two different ways.
I treferstothediscrepancybetweenacomputed,observed,ormeasuredvalueand
the true, specified, or theoretically correct value.
hat is,error refersto the differencebetween theactualoutputofasoftwareand
T
the correct output.
I n this interpretation, error isessentially ameasure of thedifferencebetweenthe
actual and the ideal.
rror is also used to refer to human action that results insoftwarecontaining a
E
defect or fault. This definition is quite general and encompasses all the phases.
AULT:-
F
Fault is a condition that causes a system to fail in performing its required function.
faultis the basicreasonfor softwaremalfunctionand issynonymous withthe
A
commonly used term bug.
he term error is also often used to refer to defects (taking a variation of the
T
second definition of error).
I nthisbookwewillcontinuetousethetermsinthemannercommonlyused,and
no explicit distinction will be made between errors and faults, unless necessary.
I tshouldbenotedthattheonlyfaultsthatasoftwarehasare"designfaults";there
is no wear and tear in software.
AILURE:-
F
Failure is the inability of asystemor component toperformarequired function
according to its specifications.
PREPARED BY : KRUPALI BHATT 9
Unit -3 Software Engineering
software failure occursifthe behavior of the softwareis different from the
A
specified behavior.
ailures may be caused due to functional or performance reasons. A failure is
F
produced only when there is a fault in the system.
owever, presence of afaultdoes notguarantee afailure. In other words, faults
H
have the potential to cause failures and their presence is a necessary but not a
sufficient condition for failure to occur.
ote that the definition does not imply that a failure must be observed. It is
N
possible that a failure may occur but not be detected.
otealsothatwhat iscalleda "failure"isdependentontheproject,anditsexact
N
definition is often left to the tester or project manager.
orexample,isamisplacedlineintheoutputafailureornot?Clearly,itdepends
F
on the project; some will consider it a failure and others will not.
akeanotherexample.Iftheoutputisnotproducedwithinagiventimeperiod,is
T
it afailureor not?Forareal-timesystemthismaybeviewedasafailure,butfor
an operating system it may not be viewed as a failure.
his means that there can be no generaldefinition offailure,and itisup tothe
T
project manager or end user to decide what will be considered a failure for
reliability purposes.
otethatintheexampleofamisplacedline,adefectmightberecorded,andeven
N
corrected later, but its occurrence might not be consideredafailure.
herearesomeimplicationsofthesedefinitions.Presenceofanerror(inthestate)
T
implies thatafailure musthave occurred,andtheobservanceofafailureimplies
that a fault must be present in the system.
PREPARED BY : KRUPALI BHATT 10
Unit -3 Software Engineering
owever, the presence of a fault does not imply that a failure must occur. The
H
presenceofafaultinasystemonlyimpliesthatthefaulthasapotentialtocausea
failure to occur.
hether a fault actually manifests itself in a certain time duration depends on
W
many factors.
his means that if we observe the behavior of a system for some time duration and
T
we do not observe any errors, we cannot say anything about the presence or
absence of faults in the system.
I f, on the other hand, we observe some failure in thisduration,wecan say that
there are some faults in the system.
here are direct consequences of this on testing. In testing, system behavior is
T
observed, and by observing the behavior of a system or a component during
testing, we determine whether or not there isafailure.
ecause of this fundamental reliance on behavior observation, testing can only
B
reveal the presence of faults, not their absence.
yobserving failuresof thesystemwecan deducethepresenceoffaults;butby
B
notobservingafailureduringourobservation(ortesting)intervalwecannotclaim
that there are no faults in the system.
n immediate consequenceof thisisthatitbecomeshardtodecideforhowlong
A
we should test a system without observing any failures before deciding to stop
testing. This makes "when to stop testing" one of the hard issues in testing.
uring the testing process, only failuresareobserved, bywhichthe presenceof
D
faults is deduced.
hat is,testingonlyrevealsthepresenceoffaults.Theactualfaultsareidentified
T
by separate activities, commonly referred to as "debugging." In other words, for
identifying faults, after testinghas revealed thepresenceof faults,the expensive
task of debugging has to be performed.
PREPARED BY : KRUPALI BHATT 11
Unit -3 Software Engineering
hisisoneofthereasonswhytestingisanexpensivemethodforidentificationof
T
faults, compared to methods that directly observe faults.
Programming Practice:
xperience developer follow number of programming practice orruleswhichtypically
E
derive from hard learned lesions.
I f best programming practice is used in the wrong context can cause more harm than
good.
he practice listed below are not all inclusive , and should not be used without due
T
consideration.
Keep the lifetime of variable as short as possible.
eep the scope of variable as short as possible to avoid confusion and to ensure
K
maintainability.
Use variables and functions for one and only one purpose.
When writing classes avoid the use of public variable.
hen creating an object , create the object as late as possible and destroyed them as
W
early as possible.
Use only one transaction scheme such asMTSorSQL.
Do not open data connection using a specific users credit.
Develop and use error handling methods.
e careful when declaring objectsuchasADODB,recordsetinsteadofjustrecordset
B
(to avoid name conflict.)
seareturnstatementinstoredprocedurethathelptoknowwhethertheprocedurework
U
properly.
PREPARED BY : KRUPALI BHATT 12
Unit -3 Software Engineering
Use early binding techniques whenever possible.
se switch statement whenever the repeat checking of a common variable instead of
U
if…then statement.
Release object reference explicitly.
To continue or break the set of code use the continue and break keyword in loop.
Includes library and header files at a starting of file.
larity and simplicity of expression: the programsshould be design in such a
C
manner so that the objectives of the program is clear.
aming: In a program you are required to name themodule , processes, and
N
variable and so on. care should be taken that the naming style should be
representative.
For Example: a=3.14*r*r
Area of circle=3.14*radius*radius;
odule size:The module size should be uniform. Thesize of the module should not
M
be too small or big. If the module size is to large , it is not generally functionally
cohesive. If the module size is to small, it leads to unnecessary overheads.
odule interface:A module with a complex interfaceshould be carefully
M
examined.
ide-effects:when a module is invoked, it sometimeshas a side-effect of modifying
S
the program state. such side-effect should be avoided where as possible.
ser-defined types: Make heavy use of user-definedatatype like enum, class,
U
structure, and union. These datatypes make your program code easy to write and
easy to understand.
PREPARED BY : KRUPALI BHATT 13
Unit -3 Software Engineering
esting:Deep nesting of loops and conditions greatlyharm the static and dynamic
N
behavior of a program. It also becomes difficult to understand the program logic, so
it is desirable to avoid deep nesting.
I nformation hiding:the information secure in thedata-structures should be hidden
from the rest of the system where possible. Information hiding can decrease the
coupling between modules and make the system more maintainable.
ontrol constructs: it is desirable that as much aspossible single entry and single
C
exit constructs used.
PREPARED BY : KRUPALI BHATT 14
