1 / 26

TEST POINT ANALYSIS

TEST POINT ANALYSIS. MOHAN SINGH B.TECH(CSE. Introduction. The goal of this technique is to outline all major factors that affect testing projects and to ultimately do an accurate test efforts estimation.

adonai
Télécharger la présentation

TEST POINT ANALYSIS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TEST POINT ANALYSIS MOHAN SINGH B.TECH(CSE

  2. Introduction The goal of this technique is to outline all major factors that affect testing projects and to ultimately do an accurate test efforts estimation. On time project delivery cannot be achieved without an accurate and reliable test effort estimate. TPA is one such method which can be applied for estimating test effort in black box testing. It is a 6 step approach to test estimation and planning. We believe that our approach has a good potential for providing test estimation for various projects.

  3. METHODOLOGY • TPA Philosophy • The effort estimation technique TPA, is based on three fundamental elements. • Size of the information system to be tested. • Test strategy. • Productivity Size denotes the size of the information system to be tested. Test strategy implies the quality characteristics that are to be tested on each subsystem.

  4. TPA Model • Calculation of static test points : • St depends upon total FP of the information system and static quality characteristics of the system. • ISO 9126 has listed the following quality characteristics as static : • Functionality • Usability • Efficiency • Portability • Maintainability • Reliability Method of calculation of Static Points:- ST= (FP * Qi)

  5. Calculation of dynamic test points : • DT = FPf * Df * QD • DT = Dynamic test points. • FPf = Number of function points assigned to the function . • Df = Weighing factor for function dependent factors. • QD = Weighing factor for dynamic quality characteristics.

  6. User importance It implies how important is the function to the users related to other system functions. Rule : “about 25% of functions should be placed in the high category, 50% in normal category and 25% in low category.”

  7. Usage Intesity

  8. Interfacing It implies how much does one function affect other parts of the system. The degree of interfacing is determined by first ascertaining the logical data sets which the function in question can modify, then the other functions which access these LDSs. An interface rating is assigned to a function by reference to a table in which the number of LDSs affected by the function are arranged vertically and the number of the other functions accessing LDSs are arranged horizontally.

  9. Complexity The complexity of a function is determined on the basis of its algorithm i.e., how complex is the algorithm in a specific function. The complexity rating of the function depends on the number of conditions in the functions algorithm.

  10. Uniformity It checks the reusability of the code. A uniformity factor of 0.6 is assigned in case of 2nd occurrence of unique function, clone and dummy functions. Otherwise in all cases a uniformity factor 1 is assigned. Method of calculation of Df : the factor is calculated by adding together the rating of first-four functions dependent variables i.e., Up, Ui I and C and then dividing it by 20 (sum of median/nominal weight of these factors).

  11. CASE STUDY • Step - 1 • System study by KR V and V company : KR V and V requests a 2 day systems and requirements study to understand the scope of testing work and assess the testing requirements to arrive at TPA estimate. • User important : it was observed that 20% of the functionality of the product is of low importance to user, 60% is of medium importance and 20% is of high importance. • Usage intensity of the functions : 10% of functions are less used, 70% are medium used and 20% are extensively used. • Interfacing of Functions with other function : 50% of function are almost independent and do not interface with other functions. The remaining 50 % are highly dependent .

  12. Step -2 Environments Assessment by KR V and V company : KR V and V carried out environment assessment and noted the following: KR V and V would use query language, records and playback tools in testing. Development test plan is available from DCM data systems Ltd. But the test team is not familiar with the earlier test cases executed and results. Product is developed in 4GL with integrated databases Test environment is now for KR V and V but is similar to earlier used test environment.

  13. TPA for Case Study Dynamic test points Dt: from Eqn. 2, we have: DT =FPf* Df* QD Where FPf = Transaction FP = 600 Df = dependency factor = weighted rating on importance to user, usage Intensity, interfacing of functions, complexity of functions.

  14. Total test points (TP): • TP = DT + ST = 2444.4 + 160 = 2604.4 Productivity : 1.4 Test hours per test point Environment factor : = (Rating on 6 environment factors)/21 Planning and control allowance : = Rating on team size factor + Rating on management tools factor = 6% + 2% = 8%

  15. Total test hours : = primary test hours + 8% of primary test hours = 2953 +8% of 2953 = 3189 hours

  16. PHASE WISE BREAKUP OVER TESTING LIFE CYCLE For this case study, the breakup is an follows:

  17. PATH ANALYSIS Path analysis is a process specially developed for turning use cases into test cases. This is a tool for the testers, who are required to test applications that have use cases as required to test applications that have use cases as requirement. Each use case path is derived from a possible combination of following use case elements: Basic Course Alternate Course Exception Course Extends and Uses Relationships

  18. The advantages can be summarized as Better coverage through scientific analysis Both positive and negative test cases can be easily identified through path analysis Easier coupling of path and data Reduction of test cases. Better management of testing risks Extremely effective in identifying and correction use case errors.

  19. Path Analysis Process The path analysis process consists of following four major steps:- Draw flow diagram for the use case Determine all possible paths Analyze and rank the paths Decide which paths to use for testing.

  20. Step 1 : Draw flow diagram for the use case Use case is a textual document and hence cannot be easily analyzed. The first task is to convert this into a graphical format called flow diagram. Let us define some concepts Flow Diagram : Graphical depiction of the use case Node : the point where flow deviates or converges Branch : connection between two nodes. Each branch has a direction attached to it. Node is also where more than one branch meets.

  21. Step -2 : Determine all possible paths Beginning from the start each time, list all possible ways to reach the end, keeping the direction of flow in mind. Path ID designation : each path should be suitably designated as P1, P2 etc. Path Name : this is the sequence of branch numbers that the path comprises of. For the example given above path ID P2 has a path name of 2, 3, 4, 5. Path Description : this is a textual description of the complete sequence of user actions and system responses taking place in that path.

  22. Step-3 : Analyze and rank the paths For simple use cases, which have about 10 separate paths, it is straight forward to select all paths for testing and hence this step can be skipped. However for some complex use cases, the number of possible paths can easily exceed 50, in which case it may be necessary to select only limited paths for testing. Frequency : this attribute can have a value of 1 to 10, with 1 being least frequent and 10 most frequent. Criticality : this attribute describes how critical the failure of this path could be with 1 being least and 10 being most.

  23. Step-4 : selection of paths for testing • In order to have adequate test coverage, and minimize the risk of not testing while balancing the resources there is a need to follow some guidelines. They are as follows: • Always select flow for testing as • It is a critical functionality • If basic flow fails; there may not be much of a point in testing other paths • Basic flow should be included in sanity test suites and also in Acceptance testing

  24. Some other paths are too important to be ignored from functionality point of view. These are generally obvious from the table of paths. The path factor should be used for selecting a path among several possibilities that do not meet the above criteria. The aim here is to select a minimum set of paths which would adequately test the critical functionality while ensuring that all branches have been included in at least one path.

  25. Step-5 : Writing test cases from table of paths The table of paths provides us with adequate information for testing a use case. The path description is in fact a summary description of the test case itself and even a tester with very little experience can write test cases from that description. Before proceeding further, let me introduce one more concept here called test scenario. Any paths with a specific test data becomes a test scenario. Each path is generally associated with number of test scenarios, to adequately test the data width.

  26. THE END

More Related