a source-based risk analysis approach for software test

8/6/2019 A Source-Based Risk Analysis Approach for Software Test

http://slidepdf.com/reader/full/a-source-based-risk-analysis-approach-for-software-test 1/17

A Source-Based Risk Analysis Approach for

Software Test Optimization

Nagaraj



Contents:

� Introduction

� Source-based risk analysis

� Proposed source-based risk model for

sof tw are test

� R esult.



Introduction:

Sof tw are test is one of the most important steps of

a sof tw are development process. It is estimatedthat sof tw are testing can take up to 50% of thetotal development cost.



SOURCE-BASED RISK ANALYSIS

� Source-based risk analysis is used to analyse theimplemented sof tw are and detect its risky elements and

components� The authors based their approach on analysing the sourcecode

by assigning a w eight to members of a set of code-relatedmetrics (such as number of function calls, variable def initions.

� Man y of the risk analysis

� and classif ication techniques base their idea on theCyclomatic Complexity introduced by McCabe [12] whichmeasures the complexit y of a source code and can be used toidentify risky (complex) components.



PROPOSED

SOURCE-BA

SED

RISKMO

DEL FOR

SOFTWARE TEST

� This approach which results in a model that can be usedto plan an optimal test for the sof tw are project.

� There are two phases to create this model:1. ComponentsClassif ication,

2. Source-BasedRisk A nalysis.



I.Components Classification Based onTheir Importance� In the f irst step business o wners and sof tw are developers

should classify the components of the sof tw are based on their

importance to the business and the functionalit y of the sof tw are.� the component classif ication process, they will only assign a number

betw een 1 and 100 to each use-case based on their importance to the business (100 w ould stand for the most important use-case). Considering the operation of each component in each usecase

sof tw are developers can use this metric to help them determine theimportance of each component and classify them.

� Developers use this metric to classify the components in 4 classes of N egligible, Marginal, Critical, Catastrophic which represent theclass of damage that can be caused by failure of each component.



II. Source-Based RiskOur approach is based on the idea presented which analyses the

source-code to determine the risk of an element of the application. We improved this technique by adding more structural observationsto the analysis process which results in a better estimation of therisk of the component-under-analysis. In [1] Static Risk Model

based on summation scheme is described as following:

V + F + D + C + P (1)

� V stands for number of variable def initions,

� F number of function calls,

� D number of decisions,

� C number

� of c-uses1 and

� P number of p-uses2. , , , , and

� are the w eighting factors which are used to gi ve either more or less emphasis to themetric components.



Procedure 1 - A procedure with one

statement in the if block

� Procedure Proc1()� {� if (condition 1)� {� statement 1;� }

� statement 2;� statement 3;� statement 4;� }



Procedure 2 - A procedure with 3

statements in the if block

� Procedure Proc2()� {� if (condition 1)� {� statement 1;� statement 2;

� statement 3;� }� statement 4;� }



Source-Based Risk

� Using the formula (1) these tw o procedures will have the same risk ; ho w ever by hav ing a closer look at these tw o procedures it can be

seen that P rocedure 2 is more risky than P rocedure 1. The reason tothat is because if condition 1 fails to operate properly, there aremore statements in P rocedure 2 that will be executed by mistake; thus it can be said that condition 1 in P rocedure 2 is more riskythan condition 1 in P rocedure 1

� From another point of v ie w it can be said that the risk of condition 1has increased the risk of statements 1, 2 and 3 in P rocedure 2 (i.e.the risk of statement 2 in P rocedure 2 is based on tw o factors, therisk of failure of statement 2 itself and the risk of failure of properexecution of condition 1).



Considering the above, w e change the formula (1) into the

follo wing equation:

� BR (n)=V +F+D +C+P+BR (2)

�In this equation BR (n) stands for the risk of block n, and

BR stands for the sum of B Rs residing inside block n. All

Xs are def ined as follo w s:

X = X BR F(n)

� BR F(n) represents the Block Risk Factor of the block n which isdefined as follo wing: In the f irst level of each procedure (or

function) BR F is 1; by entering each if statement block, BR F w ould be equal to the BR F of if statement¶s parent block incremented by 1. BR F of each loop block is equal to BR F of loop¶s parent block plus 5



We also def ine another metric called Function Risk Densityas follo wing:

FRD =FR/LOC (4)

In equation 4 FRD stands for Function Risk Density which is

obtained by calculating B R of a function and LOC stands for

Line of Code.



III.Risk-Based Testing

Af ter classif ication of components and obtaining CRD, FRD

the test phase can be planned. In the f irst step, critical components

Should be chosen to be tested.The value of this threshold should be chosen based on the size of the

project and available test time.

The test of each component should be conducted by starting with thefunctions with higher FRD. A threshold T will be chosen for each

component which will be used to select the functions to be tested; only the functions with a FRD above this threshold should be tested.



IV. RESULT



V. CONCLUSION

In this paper w e proposed an optimal approach for sof tw are test planning. Our approach maximizes the amount of risk that can be

eliminated over time and creates a model which can be used toprioritize the components to be tested. We also applied a threshold in the function level to omit the test of functions with lo w er risks. Forour future research w e plan to def ine a more precise risk model which can identify risky components more accurately . As the longterm goal, w e w ant to study different design patterns and their effects

on the components¶ risks and def ine a set of design and development rules which enhances the reliabilit y and qualit y of the sof tw areproduct.



REFERENCES[1] W . E. Wong, Yu Qi, K . Cooper, Source Code- Based Software Risk Assessing,

Proceedings of the 2005 A CM symposium on Applied computing,

pp 1485-1490, 2005.

[2] K . G. Popstojanova, Architectural-Level Risk Analysis Using UML, IEEE

Transactions on Sof tw are Engineering, vol. 29, no. 6, pp. 946-960, 2003.

[3] B. Beizer, Software Testing Techniques, N ew York, Van N ostrand Rheinhold,1990.

[4] G. Tassey, The economic impacts of inadequate infrastructure for software

testing, final report., N ational Institute of Standards and Technology,

2002.

[5] Y . Tao, A Study of Software Development P roject Risk Management,

Proceedings of the 2008 International Seminar on Future Information

Technology and Management Engineering, pp 309-312, 2008.

[6] T. M. K hoshgof taar, N. Seli ya, Y i Liu, Genetic programming-based

decision trees for software quality classification, P roceedings of the 15th

IEEE International Conference on Tools with Artif icial Intelligence, pp

374-383, 2003.

308-320, 1976.



Thank you

a source-based risk analysis approach for software test

Documents