1 / 18

Software Component Substitutability through Black-Box Testing

Software Component Substitutability through Black-Box Testing. Andrés Flores. Macario Polo. aflores@uncoma.edu.ar. macario.polo@uclm.es. Alarcos Group Escuela Superior de Informática Universidad de Castilla-La Mancha Ciudad Real, España.

harlan-paul
Download Presentation

Software Component Substitutability through Black-Box Testing

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. Software Component Substitutabilitythrough Black-Box Testing Andrés Flores Macario Polo aflores@uncoma.edu.ar macario.polo@uclm.es Alarcos GroupEscuela Superior de InformáticaUniversidad de Castilla-La Mancha Ciudad Real, España GIISCo GroupDepartment of Computer ScienceUniversity of Comahue Neuquén, Argentina

  2. Motivation • Upgrades of Components  Updates of Component Systems • Replacement: upgrades or other OTS • Maintain stability of current systems • Evaluate replacement components • Easy the identification of compatibility Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  3. Approach • Complement regular compatibility analysis by means of Component Testing Criteria based on the Observability testing metric • Given a component Cand a candidate upgrade K, they should match in domain and range, and also on each mapping pair (input,output) Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  4. Approach – Three Phases Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  5. Sample: Java Calculator • K JCalc from http://sourceforge.net • C JCalculator Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  6. Component Behaviour TS 1st • TS goal: to check that a candidate component Kcoincides on behaviour with an original component C. • each test case: a set of calls to C's services, with an oracle to determine acceptance or refusal • Component Integration Testing Criteria: • all-Interfaces (all-Methods) • all-Events (including all-exceptions) • all–Context-dependence • intra-/inter-component dependence Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  7. Component Behaviour TS (cont.) 1st • Component Behaviour TS: intra-component dependence • operational sequences  RegEx • Alphabet: names of components services. • RegEx  general pattern protocol of use for a component interface • By reflection Java component interfaces are collected to automate Test Case generation Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  8. Sample: TS for JCalculator 1st • We use the testoojtool  some settings: • Protocol of use: • Service sequences: length of expressions, minimum 8, derives 20 Test templates:4 expressions with 1 math service and16 with an extra iteration for the '+' operator. Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  9. Sample: TS for JCalculator 1st Exceptions Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  10. Sample: TS for JCalculator 1st • test values are combined with 20 test templates (services sequences) and constraints files (pre/postcode). • testoojprovides four algorithms: each choice, antirandom, pairwise, and all-combinations. • In this case we have decided on all-combinations • each combination is a test case  a testing method into a test driver file. • 468 test cases were generated into a class called TestJCalculator1 Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  11. Sample: TS for JCalculator 1st Pre-code (setAdd) Pre-code (evalExpression) Post-code (evalExpression) Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  12. Interface Compatibility 2nd To compare interfaces syntactically, three cases for services: • Exact match: two services must have identical signature, i.e. return type, service name, and for parameters and exceptions: amount, type and order. • Near-Exact match: similar to previous, butorder is relaxed for parameters and exceptions. • Soft match: similar to previous, butservice name is ignored and for exceptionsit is relaxed to existence of any. Outcome: a matching list with characterizedservices correspondences Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  13. Sample: JCalculator-JCalc 2nd Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  14. Test-based Semantic Compatibility 3rd • Purpose: to find services from candidate K exposing similar behaviour with the original component C. • Implies to run the Component Behaviour TS for C (1st phase), against K • Syntactic matching list (2nd phase),is used to build a set of wrappers for component K. • Wrappers are adapters (adapter pattern) • Interface mutation: operators to change service invocationsand parameter values • To reduce amount of wrappers, starts with stronger matching cases (exact-match). Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  15. Sample: run JCalculator TS on JCalc 3rd • Semantic compatibility: JCalculator–JCalc • Set of Wrappers: would be 286 in size. • we decided to initially analyzed specific cases ofInterface Mutation to manually create 30 wrappers: • 1 wrapper with the true services correspondence (like those marked with '*' for putInBuffer service. • 2 wrappers with variation on putInBuffer service (the rest of soft-matches). • 3 wrappers with variation on the math services and based on the three previous wrappers. • Four groups of 6 wrappers varying the setExpression service and taking the three previous groups. Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  16. Conclusions • Focused on Maintenance: Component systems are updated by integrating upgraded components. • Testing criteria used to describe components behaviour to analyse compatibility • Similar to Regression testing: TS reduction strategies to expose faults on targeted pieces.Need to identify changes on versions (upgrades). • We assume only information collected by reflection. • Candidate components could be other OTS • Purpose: not finding faults, but analyse compatibility. TS= valid configurations. Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  17. Future Work • Important to get a reduced TS: depends on the combination algorithm, and alternative strategies, like Mutation. • Other issue: subtyping (built-in) now was added, changing the cases for Interface compatibility. • Wrappers: need to enhance the syntactic Interface Matching,we are experimenting with other aspects to reduce the set size. • Wrappers analysis: being adjusted to set a proper threshold,not always possible 100% successful on tests. • More experimentation to properly validate de whole approach. Andres Flores - Macario Polo --- STV'07 - December, 5th 2007

  18. Software Component Substitutabilitythrough Black-Box Testing Thanks Andrés Flores Macario Polo aflores@uncoma.edu.ar macario.polo@uclm.es Alarcos GroupEscuela Superior de InformáticaUniversidad de Castilla-La Mancha Ciudad Real, España GIISCo GroupDepartment of Computer ScienceUniversity of Comahue Neuquén, Argentina

More Related