Transcript PowerPoint Sunusu

REFACTORING
&
SOFTWARE TESTING
Refactoring
Refactoring is the process of altering source code
so as to leave its existing functionality
unchanged.
The simplest example of refactoring is renaming
The name of variable including a class or package
name is changed
When the name is changed, all references to it
except for comments are automatically changed
at the same time.
Refactoring -Promote Attribute to Class
class Automabile
{ int mileage;
… }
 The integer variable mileage for used automobiles is more involved than a single int
variable
 Therefore it can be considered «Promote Attribute to Class « refactoring
class Mileage
{
int nomMilvalue=0; //shown on odometer
int engMilvalue=0; //best estimate , accounting for replacement
…..
public int compute EffectiveMileage() // to obtain estimate
{ ….}
class Automabile
{
Mileage mileage; …… }
Refactoring
Computer – Assisted
Some refactoring is computer assisted
This takes the form a wizard that interacts
with the programmer
All interactive development environments are
equipped with several refactoring wizards.
To use Rename in Eclipse, one can place the cursor on
the variable (name) and press Shift/Alt/R.
New name is name_
Using a Refactoring Wizard
Shift/Alt/R
5
Fowler’s Refactoring Taxonomy
 Big Refactorings (Fowler describes the refactoring at the
class level and have more of an architectural impact)
 Composing Methods
 Moving Features Between Objects
 Organizing Data
 Dealing With Generalization
 Simplifying Conditional Expressions
 Making Method Calls Simpler
6
Big Refactoring
Example I (Fowler’s Taxonomy)
Employee
MaintceEmp
SoftwareEmp
ClericalEmp
FulltimeSoftwareEmp
FulltimeMaintceEmp
FulltimeClericalEmp
ParttimeSoftwareEmp
ParttimeMaintceEmp
ParttimeClericalEmp
RetiredSoftwareEmp
RetiredMaintceEmp
RetiredClericalEmp

SoftwareEmp
Employee
MaintceEmp
Status
ClericalEmp
Fulltime
Parttime Retired
7
Big Refactorings (Fowler’s Taxonomy)
Example II : Convert Procedural Design to Objects
Control
startGame()
displayCharacter()
moveCharacter()
VideoGame
GameCharacter
When an object is required to control , single call to a method is required in an
appropriate object

VideoGame
start()
Minimal control may still be needed outside of the classes
GameCharacter
display()
move()
Big Refactoring
Example III: Separate Domain
from Presentation
Account
name
balance
…
displayStandard()
displayHTML()
StandardAccountGUI
display ()

Account
name
balance
…
HTMLAccountGUI
display ()
 GUI code occurs in the same class as the
computational algorithms or the data repository.
 For example The Account class my perform the computations, and also produce displays
Big Refactorings (Fowler’s Taxonomy)
Example IV: Extract Hierarchy
Project
Project

SoftwareEngineeringProject
MobileApplication
© 2010 John Wiley & Sons Ltd.
CustomerEntertainmentProject
DesktopApplication
Software Test
is a validation process
 Executing code from the application is provided with
input and the resulting output is compared with the
required output.
 Testing establishes the presence of defects but not
their absence
 Testing Early and Often means the Agile Connection
Testing: Four Main Questions
Testing requires significant time to decide what to
test, when to do so, and with what data.
 At which level conducting the testing?
–
–
–
Unit
Integration
System
 How to choose inputs?
–
–
using the specifications/use cases/requirements
using the code
 How to identify the expected output?
–
Test the predictions (oracles)
 How good test cases are?
–
When we can stop the testing activity
12
Test Phases
Acceptance Testing – This checks if the overall system
is functioning as required.
Unit testing – This is basically testing of a single
function, procedure, class.
Integration testing – This checks that units tested in
isolation work properly when put togehter.
System testing –The emphasis is to ensure that the
whole system can cope with real data, monitor
system performance, test the system’s error handling
and recovery routines.
Regression Testing – This checks that the system
preserves its functionality after maintenance and/or
evolution tasks.
13
Regression Testing: What to Retest
 Suppose that C is a body of already-tested code in an
application A.
 Suppose that A has been altered with new or changed
code N.
A
snjfgkjfdkgjkfdjgkfdj
 If C is known to depend on N
kgjdfkbvjfdkjbkfdjbk
C
Perform regression testing on C
fdjbkjdfklbjdflkbjkldf
 If C is reliably known to be completely
independent of N
There is no need to regression test C
jbkfdjblkjfdklbjfdklbj
klfdjbkldfjbkljdfkbljf
dklbjoikhkgkjkDHVD
ABFDSGKJGFJTIURjs
kjgls,al40rgnsj2340
 Otherwise
2- hhjk ghjhgj
ghjkklj;ljko fghjhjgfj
Regression test C
N
dfkbljfdklHVDABFDS
DHVDABFDSlkgt
GKJGIURjskjgl
14
g;b,kdfgjfjfjg kfdjk
What are Software Testing Types ?
Black box testing : You don't need to know
the internal design in detail or have a good
knowledge about the code for this test.
 It's mainly based on functionality and
specifications, requirements.
White box testing : This test is based on
detailed knowledge of the internal design and
code.
Tests are performed for specific code statements
and coding styles.
Black- & White-box Testing
Result
Input determined by...
… requirements
Black box
Actual output
compared with
required output
White box
Validation
of expected
behavior
…design
elements
16
Black-Box Testing
 Black-Box Testing does not take the manner in which
the application was designed or implemented
Example:
Person «a» rents « the Matrix» on May5
Person «b» rents «Gone with the Wind» on May 6
Person «a» returns «the Matrix» on May 10
 This is analogous to building an automobile and then
testing it by driving it under various conditions.
White-Box Testing
White -box tests are based on design and
implementation
If the car is built with a new design for its
automatic transmission , we would be wise to
use this knowledge
 White box testing is required
Unit Testing versus Post-Unit testing
Software applications consist of numerous parts.
Therefore the soundness of the whole depends on the
soundness of the parts
Reliable part?
Reliable?
Reliable?
Reliable ?
Reliable?
Reliable?
Reliable ?
Because of the dependence, we test software parts
thoroughly before assembling them
A process is called as unit
testing
19
Types of Post-Unit Testing
Interface testing Validates functions exposed by
modules
Integration …… combinations of modules
System whole application
Usability user satisfaction
Regression changes did not create defects in
existing code
Acceptance customer agreement that contract
satisfied
Installation works as specified once installed on
required platform
Robustness ability to handle anomalies
Performance fast enough; uses acceptable
amount of memory
20
Post-Unit Testing
Unit
Unit
…..
Unit
…..
Each of post-unit testing activities is
performed during the process of
building an application
Module
Build
…..
Module
Interface testing
…..
Unit
Unit
…..
Build
Module
Application
on test bed
Application
on final
platform
system testing
usability testing
installation testing
acceptance testing
integration testing
Unit
Regression testing throughout
21
Decide How and Where to get Test
Input
Standard test stock market data for a brokerage
application
Standard test chemical reactions for a chemical
engineering application
Standard FDA procedures for the pharmaceutical
industry
Standard test inputs for a compiler
Output from previous version of the application
Plan for Testing
 Define “units” vs. non-units for testing
 Determine what types of testing will be performed
 Determine extent












do not just “test until time expires”
prioritize, so that important tests definitely performed
Document
individual’s personal document set included?
how / when to incorporate all types of testing?
how / when to incorporate in formal documents?
how / when to use tools / test utilities?
Determine input sources
Decide who will test
individual engineer responsible for some (units)?
how / when inspected by Qality Assurance?
how / when designed & performed by third parties?
 Estimate resources
 use historical data if available
 Identify metrics to be collected
 Define, gather, use
 e.g., time, defect count, type, and source
23
Stopping Criteria for Testing
When tester has not been able to find another
defect in 5 minutes of testing
When all nominal, boundary and out-of-bounds
test examples show no defect
When a given checklist of test types has been
completed
After completing a series of targeted coverage
(e.g., branch coverage for unit testing)
When testing runs out of its scheduled time
24
Unit Testing
Unit Tests are tests written by the developers to test
functionality as they write it.
Each unit test typically tests only a single class, or a
small cluster of classes.
Unit tests are typically written using a unit testing
framework, such as JUnit (automatic unit tests).
Target errors not found by Unit testing:
- Requirements are misinterpreted by developer.
- Modules don’t integrate with each other
25
Unit Testing
Both white box and black box methods are
utilized during unit testing
White box unit tests focus on
 the internal code structure ,
testing each program statement,
every decision point and each independent path
Black box methods focus on testing the unit
without using its internal structure
Equivalence partitioning and boundary value
analysis
“At different points in the process”
Iterative Software Development
Write
acceptance
tests
Write
and
execute
unit tests
Execute
acceptance
tests
increment
+ system
“Written before”
Prioritized
functionalities
“Executed after the development”
27
Acceptance Testing versus Unit Testing
Acceptance Tests
Unit Tests
Written by Customer and Analyst.
Written by developers.
Written using an acceptance testing framework (also
unit testing framework).
Written using a unit testing framework.
(extreme programming) When acceptance tests pass,
stop coding. The job is done.
(extreme programming) When unit tests pass, write
another test that fails.
The motivation of acceptance testing is demonstrating
working functionalities.
The motivation of unit testing is finding faults.
Used to verify that the implementation is complete and
correct. Used for Integration, System, and regression
testing. Used to indicate the progress in the
development phase. (Usually as %). Used as a
contract. Used for documentation (high level)
Used to find faults in individual modules or units
(individual programs, functions, procedures, web
pages, menus, classes, …) of source code. Used for
documentation (low level)
Written before the development and executed after.
Written and executed during the development.
Starting point: User stories, User needs, Use Cases,
Textual Requirements, …
Starting point: new capability (to add a new
module/function or class/method).
28
Unit Test Methods
White-Box Methods
Statement coverage
 Test cases cause every line of code to be executed
Branch coverage
 Test cases cause every decision point to execute
Path coverage
 Test cases cause every independent code path to be executed
 Black-Box Methods
Equivalence partitioning
 Divide input values into equivalent groups
Boundary Value Analysis
 Test at boundary conditions
29