Abstract:
A method for automatic testing of a piece of software for a mobile device including the following steps: deriving from a description a formalized description, the description includes possible sequences of events of the software and a range for at least one input parameter of the software, the description being used for an implementation of the software; generating from the formalized description a test description; adapting the test description for the mobile device for which the software is to be tested; translating the test specification in a language assigned to the mobile device such that a test described by the test specification can be performed on the mobile device. The method for automatic testing further relates to a corresponding device.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to PCT Application No. PCT/EP2015/054955, having a filing date of Mar. 10, 2015, the entire contents of which are hereby incorporated by reference. 
     
    
     FIELD OF TECHNOLOGY 
       [0002]    The following relates to a method and a device for automatic testing of a piece of software for a mobile device. 
       BACKGROUND 
       [0003]    Testing of software is important to ensure that the software meets the requirements set and works correctly. However, a comprehensive testing is laborious and thus costly. Hence, the efforts in testing correlate also with the price for which the software can be sold. 
         [0004]    Mobile applications are often offered at a very low price and consequently for mobile applications only basic testing is performed in-house. Then, for the majority of their testing needs, further testing is performed by the users of the application, which is referred to as “crowd testing”, which is done only after distribution to some customers. 
       SUMMARY 
       [0005]    An aspect relates to offering a possibility for comprehensive testing of mobile applications. 
         [0006]    Embodiments of the invention relate to a method for automatic testing of an application or software on a mobile device. Thereby the following steps are performed: 
         [0007]    From a description of the software a formalized description is derived which can then be used for generating from the formalized description a test description or test case. 
         [0008]    The description has been used for an implementation of the application or software. This means in particular, that the set of sequences that has been designed in the software can be used also for the testing, i.e. the same description is used for implementation and testing. Further the description comprises a range for at least one input parameter of the application. Range can include only one possibility for the parameter or a variety of possibilities for the parameter. 
         [0009]    The test case or test description constructed from the formalized description is translated in a language assigned to the mobile device such that the test case can be performed on the mobile device. Mobile device is understood in this context such, that the test case can be performed on a physical mobile device itself or in an environment simulating a mobile device. 
         [0010]    Further, an adaption of the test description in relation to the respective mobile devices, for which the software is intended and on which it should be tested takes place. This is particularly important as there is a much bigger variety in mobile devices than it is e.g. for fixed installed workstations. For example, size and shape of the display differ strongly as well as number, position, assignment and function of hard keys or buttons. 
         [0011]    According to an advantageous embodiment the further step of importing, via an input interface, a description comprising the possible sequences or orders of events which can occur during execution of the application. 
         [0012]    Preferably, according to various embodiments, the adaption can take place after having derived the formalized description or/and generating the test description or/and translating the test specification or combined with any of these steps. 
         [0013]    Embodiments of the invention further relate to a corresponding device for automatic testing and a software product. 
         [0014]    One advantage is, that, by using this approach the effort and costs for a comprehensive test design can be reduced. Further it can be ensured that all possible paths of a piece of software or an application have been tested, thus the test coverage and consequently the quality of an application is increased considerably in comparison to crowd testing or and “into the wild testing” methods, where no test concept is used. 
     
    
     
       BRIEF DESCRIPTION 
         [0015]    Some of the embodiments will be described in detail, with reference to the following figures, wherein like designations denote like members, wherein: 
           [0016]      FIG. 1  describes a schematic for producing automatically a test case for a mobile device. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    In the following an example for iOS, the Apple operating system is described. Of course, embodiments of the invention can be applied to any operating system: 
         [0018]    It is one aspect of embodiments of the invention that software descriptions or system models described e.g. for iOS by so called storyboards are used to automatically derive UML (unified modellings language) test models, which describe behavior, i.e. the possible sequences that can be pursued by a software program, and data, i.e. one or more input parameters with respective range at one or more positions of the sequences. The UML test models are then used to automatically generate test descriptions. 
         [0019]    A storyboard is a visual representation of the user interface of an iOS application. It shows screens of content and the connections between those screens. Thus, a storyboard is composed of a sequence of scenes, i.e. a screen with content. The scenes are connected by segue objects. Further the interface may be specified by controls, which are used to trigger the segues or connection path between the screens. 
         [0020]    Thus, a storyboard can contain all the possible screens of the respective application for a mobile device and therefore designates every sequence, which is designed or planned to occur in the mobile application. Thus the use of storyboards, which cover the whole software program, helps to increase the test coverage and consequently to improve the quality of the testing. 
         [0021]    The test descriptions can be used to manually execute the tests on a variety of mobile devices or on a simulator, or to automatically derive executable test scripts such as cucumber recipes, which can be directly run on the devices or on the simulator. 
         [0022]      FIG. 1  visualizes an embodiment where a test case for a device using iOS as operating system, is produced. 
         [0023]    In a first step  1  a description of sequences of events that can be pursued within the application or software program are retrieved. As said above, in the framework of iOS the description can be realized by storyboards S and a data model. A storyboard may e.g. depict the content of a graphic display. Thus each storyboard S may describe an event and the data model DM corresponding to that storyboard S a set of parameters used in the context of the storyboard S and the range which each of the parameters can assume. 
         [0024]    In a second step  2  this description is imported to a derivation unit DU, which derives from the informal description a formalized description or logical diagram. According to a preferred embodiment an UML (unified modeling language) diagram is produced. According to an advantageous embodiment there is an automatic import of workflow information and test data, i.e. categories. According to an embodiment the deriving unit DU is combined with a generating unit GU. According to another embodiment a tedeso tool is used for this combined unit. 
         [0025]    In step  3  further refinement, e.g. adjustment of models, adding of data etc., takes place in the derivation unit DU. E.g. choices e.g. to partitions, pre- or post conditions can be added and further data are bound to the workflow, i.e. a definition takes place at which position of the workflow or event in the program certain parameter are required. 
         [0026]    In addition, should the data imported in step  2  not be sufficient to run the tests on the physical devices, additional test data required for the test execution are introduced and thus the model or formalized description is extended. In particular, refinements are made to adapt the formalized description of the program for individual physical devices. E.g. the parameters describing the position of a touch on the touch display are adapted to the size and shape of the display of an individual mobile device to be tested. Another example is the consideration of keys or/and button of the mobile device to be tested. 
         [0027]    In some embodiments no further refinement is needed or desired, thus step  3  is omitted. 
         [0028]    In some other advantageous embodiments the adaption takes place additionally or only later during or after generating a test description or translating. 
         [0029]    In a fourth step  4  from the formalized description a test description is generated in a generating unit GU and transferred to a translating unit TU where the data are translated into a target language that can be run on the device to be tested. For an embodiment using an iOS operating system a “cucumber” tool may be used, which supports a variety of programming languages, such as Ruby, Java, C++. Thus a further adaption to the device to be tested takes place, namely which language a device supports. According to advantageous embodiment an automatic export of cucumber scenarios is used.
   In  FIG. 1  the deriving unit DU and generating unit GU are depicted as one unit. According to other embodiments they are formed as separated units.   
 
         [0031]    In a fifth step  5  a refinement of the translated formalized description or test description takes place. For some embodiments further refinement is not required or desired and therefore step  5  may be omitted. According to another embodiment cucumber receipts are created manually or automatically. 
         [0032]    In a sixth step  6  testing based on the test description is performed, either on a physical device, e.g. an iOS smartphone, or on a simulator for the respective operating system, e.g. an iOS simulator. 
         [0033]    One advantage of embodiments of the invention is the integration of several advanced test techniques, such as TDD or Test-driven Development, BDD or Behavior-driven Development, and MBT or Model-based Testing, and placing them in the context of mobile testing towards creating a new, systematic, automated, and tool-supported method for testing mobile applications, which heavily capitalizes on reusing existing artifacts from the development phase. The support by corresponding tools is important, as, for instance many organizations active in this field lack systematic methods and adequate tools for mobile testing. Thus, the existing tool support at each test level and the interface to other engineering disciplines such as development and requirements engineering is a further advantage. 
         [0034]    Further, difficulties in reusing tests, which are among the top challenges in the area of mobile testing, can be overcome, as the test can be adapted for a variety of mobile devices. This is particularly important as for small applications or software programs for mobile devices, which are sold at a low prize, cost effectiveness is an issue. In addition, speeding up the test design allows selling earlier tested products which is very often the key success factor. 
         [0035]    As mentioned above, the embodiments build upon the systematic reuse of system models created by default during the design phase, e.g. storyboards or/and data model. This system models might be used for various types of devices, because by concentrating on information from the design phase of the software to be tested, test cases can be produced without starting from the execution of the program on a specific device. This offers the above mentioned possibility of adaption to various devices: For example if a test started from the GUI of an android device, e.g. a smartphone, for simulating a touch at a certain position with the coordinates (x,y), e.g. in order to select something , would require to generate or simulate an input at this position. This is often referred to as “capture and replay”. However, if a different device with a smaller or bigger display was used, also the position of a touch would have to be created at a different position in order to perform the wanted selection. 
         [0036]    Also, softkeys might be defined differently for different devices. In addition, also hardware and structural components can be affected, e.g. if a selection or change has to be made with a hardware key or button and different hardware keys are used with different devices. 
         [0037]    In such a way, the method improves on the current state of the art by automating the test design phase, increasing the test coverage and in this way providing higher product quality. 
         [0038]    According to the described embodiments the mobile devices, for which the software is intended, are such as smart phones tablet etc. The invention is not limited thereon but can be applied in the context of industry automatization with mobile production devices, such as robots. In this field a correct functioning of the individual components is very important. Reducing the costs for the necessary testing effort to ensure this correctness is therefore an important advantage. 
         [0039]    Although embodiments of the present invention have been described in accordance with preferred embodiments and with iOS as an operating system, it is obvious for the person skilled in the art that modifications or combination between the embodiments, fully or in one or more aspects, are possible in all embodiments. Instead of storyboards, as used for iOS mobile applications, other descriptions of the application or piece of software to be tested may be used. Also advantageous embodiments start right from the UML (unified modeling language) descriptions which also cover the possible paths or sequences that can be taken by the software. 
         [0040]    In particular it is also applicable for other operating systems, such as Android, Windows OS, Bada, PalmOS, webOS, or MeeGo. 
         [0041]    Although the present invention has been disclosed in the form of preferred embodiments and variations thereon, it will be understood that numerous additional modifications and variations could be made thereto without departing from the scope of the invention. 
         [0042]    For the sake of clarity, it is to be understood that the use of “a” or “an” throughout this application does not exclude a plurality, and “comprising” does not exclude other steps or elements.