1 / 10

Structure-Based Behavior Analysis of GUIs

Structure-Based Behavior Analysis of GUIs. Christof J. Budnik budnik@adt.upb.de. Content Introduction Test Case Reduction now Challenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work. GUI system desirable properties are: + correctness + safety

asher
Télécharger la présentation

Structure-Based Behavior Analysis of GUIs

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. Structure-Based Behavior Analysisof GUIs Christof J. Budnikbudnik@adt.upb.de ContentIntroduction Test Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  2. GUI system desirable properties are: + correctness + safety Faults can occure in: + computation + events or conflicts between them + user inputs + acces on parallel opened objects Distinction between two fault classes The difficult goal of the system design is to prevent faults of the control unit that could potentially lead to such failures IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  3. Therefore we test the behaviour by: + legal inputs (EP) to fulfill the property of correctness and + illegal inputs (FEP) to fullfill the safety property User responsibilities are designed from specification and/or help functions Responsibilities are suggestive completed tasks that the user wanted to do Therefore the behavior is described by modeling such meaningful responsibilities But the number of test cases generated from this models are in no relation to the founded faults Case-study of RJB: a total of 64.00 test cases revealed only 68 faults IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  4. Test case reducing for legal inputs by: + Assembly components which are strong connected or structure symmetric components [IP,DILL] + Finding minimal sequence which cover all legal inputs (Chinese Postman Problem) [Uyar] What about test case reduction of Statecharts or other models? IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  5. But isn´t the combination of sequence and their length on what we should concern? [Belli: Pair, Triple, Quadtruple a.s.o.] And what does that mean for the illegal inputs? Does they not need to covered and tested between components? So reducing the behavior is in my opinion the wrong way for testing GUIs Reminding the results of the Case study „RJB“: The hole test cases can be divided in: + one-third for legal inputs and + two-third for illegal inputs But more than fifty percent of the FES were not executable WHY? IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  6. Let´s take a closer look on what GUIs are and how they will be designed GUIs are the Interface for the user to get in dialog with the application On the one hand the user should be offered a high flexibility in his operation But on the other hand the user want to be guided through the application A compromise must be found! IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  7. Therefore the application is designed in responsibility groups This groups are respresented by windows to get the complexity under control They distinguish between two windows: + modal: must be closed before another window can be activated + non-modal: from the current window can every other window be reached The structure of those applications are hierachical So why we don‘t use the structural information for the test case generation of FES? IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  8. First we have to identify the different window types modal:non-modal: Only events between non-modal windows, which are executable as test case for FES IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  9. Each window in turn can contain a model This model describes the interaction of the objects which are on that window Now we generate our test cases on the basis of the user responsibilities which reflects his/her behavior in combination with the structural information of the application IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

  10. Conclusion: The structure is completely independent of the model used for the behavior description The method can be used for forward- as reverse-engineering GUIs should be designed in that way for testability Future Work: Maybe risk levels can be found for the non-modal communication between windows IntroductionTest Case Reduction nowChallenge of GUI Design Using Structure for Test Case Generation Conclusion and Future Work

More Related