CN110851370A

CN110851370A - Program testing method and device, and storage medium

Info

Publication number: CN110851370A
Application number: CN201911143151.1A
Authority: CN
Inventors: 董永清; 孙良木; 潘温
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2019-11-20
Filing date: 2019-11-20
Publication date: 2020-02-28
Anticipated expiration: 2039-11-20
Also published as: CN110851370B

Abstract

The disclosure relates to a program testing method and device and a storage medium. The method in the embodiment of the disclosure comprises the following steps: in the process of running the mixed-mode mobile application, obtaining a test instruction; adding a test file independent of program file settings of the mixed-mode mobile application to the program file in response to the test instruction; running a program file containing the test file, wherein the program file calls the test file to run when running to a test node; and determining a corresponding test result based on the operation result of the program file. According to the technical scheme provided by the embodiment of the disclosure, the test file related to the automatic test and the program file can be independently set, and the test file is loaded in the program file based on the test instruction during the test, so that the test efficiency is improved.

Description

Program testing method and device, and storage medium

Technical Field

The present disclosure relates to information processing technologies, and in particular, to a program testing method and apparatus, and a storage medium.

Background

Hybrid apps (mixed-mode mobile applications) are a new application form based on a mobile phone hardware platform, and are an application type between web-apps (web applications) and native-apps (native applications). The Hybrid app has the advantages of good user interaction experience of native-apps and the advantages of cross-platform development of web-apps, does not need to be downloaded and installed, and can bring smooth application experience. In the development process of the Hybrid app, program testing occupies an important position, but an efficient and convenient testing method for the Hybrid app program is still lacking at present.

Disclosure of Invention

The disclosure provides a program testing method and device and a storage medium.

According to a first aspect of the embodiments of the present disclosure, there is provided a program testing method, including:

in the process of running the mixed-mode mobile application, obtaining a test instruction;

adding a test file independent of program file settings of the mixed-mode mobile application to the program file in response to the test instruction;

running a program file containing the test file, wherein the program file calls the test file to run when running to a test node;

and determining a corresponding test result based on the operation result of the program file.

In some embodiments, the test file comprises: an application level test file and a page level test file; the program file includes: an application-level file and a page-level file; the adding, in response to the test instruction, a test file set independently of a program file of the mixed-mode mobile application to the program file includes:

responding to the test instruction, and determining the type of the currently running program file as the application-level file or the page-level file;

if the type of the currently running program file is the application level file, adding the application level test file to the application level file;

and if the type of the currently operated program file is the page-level file, adding the page-level test file to the page-level file.

In some embodiments, said adding said application-level test file to said application-level file comprises:

adding an application level test file and interface information applied to a global environment of the mixed-mode mobile application to the application level file.

In some embodiments, the application level test file comprises: the system comprises a test framework for providing a test function and an assertion library for judging whether a test result is correct or not; the interface information includes: an operating system native interface; wherein the operating system native interface comprises: an interface for obtaining operating system native parameters to which the mixed-mode mobile application belongs.

In some embodiments, the page level test file comprises: the adding the page-level test file to the page-level file comprises:

and adding the test case file to the page-level file.

In some embodiments, the running a program file containing the test file comprises:

running a page-level file containing the test case file; wherein, the test case file comprises: returning a conditional instruction and/or page run time information;

when the page-level file runs to the return condition instruction and/or when the running time of the page-level file exceeds the time indicated by the page running time information, the running of the page-level file is stopped and the page is returned to the first page of the mixed-mode mobile application.

In some embodiments, the home page comprises: presetting a page list to be tested; the running of the program file containing the test file further comprises:

and entering and operating the page level file of the next test page according to the entry of the next test page in the page list to be tested.

In some embodiments, the adding a test file to the program file that is independent of the program file settings of the mixed mode mobile application includes:

determining an abstract syntax tree AST operated by the program file according to the program file;

updating the AST according to the test file;

and generating an updated program file according to the updated AST.

According to a second aspect of the embodiments of the present disclosure, there is provided a program testing apparatus including:

the acquisition module is used for acquiring a test instruction in the process of running the mixed-mode mobile application;

the adding module is used for responding to the test instruction and adding a test file which is independent of the program file setting of the mixed mode mobile application into the program file;

the running module is used for running a program file containing the test file, wherein the program file calls the test file to run when running to a test node;

and the determining module is used for determining a corresponding test result based on the operation result of the program file.

In some embodiments, the test file comprises: an application level test file and a page level test file; the program file includes: an application-level file and a page-level file; the adding module comprises:

the first determining submodule is used for responding to the test instruction and determining the type of the currently operated program file as the application-level file or the page-level file;

the first adding submodule is used for adding the application level test file to the application level file if the type of the currently running program file is the application level file;

and the second adding submodule is used for adding the page-level test file to the page-level file if the type of the currently operated program file is the page-level file.

In some embodiments, the second adding submodule is specifically configured to:

In some embodiments, the page level test file comprises: the test case file, the second adding submodule, is specifically configured to:

and adding the test case file to the page-level file.

In some embodiments, the execution module includes:

the first operation sub-module is used for operating the page-level file containing the test case file; wherein, the test case file comprises: returning a conditional instruction and/or page run time information;

and the stopping submodule is used for stopping the running of the page-level file and returning to the first page of the mixed-mode mobile application when the page-level file runs to the return condition instruction and/or when the running time of the page-level file exceeds the time indicated by the page running time information.

In some embodiments, the home page comprises: presetting a page list to be tested; the operation module further comprises:

and the second operation sub-module is used for entering and operating the page-level file of the next test page according to the entry of the next test page in the list of pages to be tested.

In some embodiments, the adding module comprises:

the second determining submodule is used for determining the abstract syntax tree AST operated by the program file according to the program file;

an update sub-module for updating the AST according to the test file;

and the generation submodule is used for generating an updated program file according to the updated AST.

According to a third aspect of embodiments of the present disclosure, there is provided a program testing apparatus, the apparatus including at least: a processor and a memory for storing executable instructions operable on the processor, wherein:

the processor is used for executing the executable instructions, and the executable instructions execute the steps in any program testing method.

According to a fourth aspect of embodiments of the present disclosure, there is provided a non-transitory computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, implement the steps of any of the program test methods described above.

The technical scheme provided by the embodiment of the disclosure can have the following beneficial effects: through the steps in the method, the automatic test of the mixed-mode mobile application is realized, and the content to be tested can be independently tested based on the test instruction. In addition, because the test files are independently set from the program files, the influence of the test files on the program files is reduced, and the program modules can be independently tested. The test file can be applied to the global environment and can be called by different program files. Because the test file is not directly written into the program file, but is not limited to the use independent file of the specific program file, the coverage of the test is improved, and the flexibility and the practicability of the test are effectively improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

FIG. 1 is a flow chart illustrating a method of program testing according to an exemplary embodiment.

FIG. 2 is a flow chart illustrating another method of program testing according to an exemplary embodiment.

FIG. 3 is a flow chart illustrating yet another method of program testing according to an exemplary embodiment.

FIG. 4 is a flowchart illustrating a setup method of a test file according to an example embodiment.

Fig. 5 is a block diagram illustrating a configuration of a program test device according to an exemplary embodiment.

FIG. 6 is a block diagram illustrating a physical structure of a program test device according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.

FIG. 1 is a flow chart illustrating a method of program testing according to an exemplary embodiment, as shown in FIG. 1, including the steps of:

step S101, in the process of running the mixed mode mobile application, a test instruction is obtained;

step S102, responding to the test instruction, and adding a test file independent of the program file setting of the mixed mode mobile application into the program file;

step S103, running a program file containing the test file, wherein the program file calls the test file to run when running to a test node;

and step S104, determining a corresponding test result based on the operation result of the program file.

Here, the Hybrid-mode mobile application, i.e., the Hybrid app, is between the web-app and the native-app, is executed by the cloud, displays an execution result on the terminal, and receives a control instruction from the terminal. Fast applications, as well as applets, etc. are among this type of mixed mode mobile application.

The user of the mixed mode mobile application does not need to download the installation application package, i.e. point-and-play. The mixed-mode mobile application framework is deeply integrated in an operating system of the terminal equipment, seamless connection between user requirements and application services can be formed on the operating system of the terminal equipment, a plurality of functions which can be used only in the native-app but not in the web-app can be realized conveniently in the mixed-mode mobile application, and performance experience of the native-app can be enjoyed. The operation of the mixed mode mobile application is executed by the mixed mode mobile application platform, and the operation result is displayed at the front end of the mixed mode mobile application, and the front end of the mixed mode mobile application can also be used for receiving the operation instruction of the mixed mode mobile application. For example, if a click operation for the mixed-mode mobile application is received by the mixed-mode mobile application-based front end, the specific execution of the click operation is performed by the mixed-mode mobile application platform. Therefore, the process of actually running the mixed-mode mobile application is mainly implemented based on a network architecture constructed by a mixed-mode mobile application platform and a mixed-mode mobile application front end.

Mixed-mode mobile applications can be divided into component trees (DOM), styles (CSS), logic (JS code) from a data perspective; the components of the mobile Application can be divided into a configuration file (manifest. json), a global file (App. js) and a page file (page), and the programs are packaged to form rpk packaged files, wherein the packaged files are Application programs (apps) of the mixed-mode mobile Application.

A package of mixed mode mobile applications may contain a plurality of different program files, i.e. different program modules, which may need to be tested separately for each program module at the time of testing. Furthermore, after one test is completed, a retest may need to be performed for a different program module. Therefore, if the test file is directly fixed in the program file, unnecessary test operations may need to be performed every time the test is performed, and the test efficiency is low.

Thus, the above steps provide an implementation of automated testing for mixed mode mobile applications. And in the running process of the mixed mode mobile application, if test execution is received, calling the test file, adding the instruction codes in the test file into a program file to be tested, and obtaining a corresponding test result after running.

Here, the test instruction may be obtained from a command in a command line tool of the terminal, and a tester may input the test instruction in the command line according to actual requirements. In the running process of the mixed-mode mobile application, if the test instruction is obtained, automatically adding a preset test file into a program file; and if the test instruction is not acquired, continuing to execute each program module in the program file and realizing the corresponding function of the mixed-mode mobile application.

The test file may include a test framework, which is a collection of test instructions to provide basic functionality for simulating mixed mode mobile applications, and a predicate library. And injecting a test framework in the program and running the test framework, namely automatically executing the specified function of the mixed-mode mobile application, and then judging whether the running result is wrong or not in an assertion mode. The assertion library is a set of preset assertion instructions, and when the program runs to a specified position, if a return value is the same as a preset value in the assertion library, the program is considered to run without errors; if the return value is different from the value preset in the assertion library, the operation is considered to be wrong.

The test files may also include preset test case files. The test case file comprises one or more test cases, and the test cases are test schemes for one or some functions of the program file, and the test schemes comprise: test target, test environment, input data, test script, etc. When the program file calls the test case, the test case is operated according to the test scheme set in the test case, and finally a corresponding result is output. And after the test case is executed, outputting a result, namely a test result of the current test.

Through the steps in the method, the automatic test of the mixed-mode mobile application is realized, and the content to be tested can be independently tested based on the test instruction. In addition, because the test files are independently set from the program files, the influence of the test files on the program files is reduced, and the program modules can be independently tested. The test file can be applied to the global environment and can be called by different program files. Because the test file is not directly written into the program file, but is not limited to the use independent file of the specific program file, the coverage of the test is improved, and the flexibility and the practicability of the test are effectively improved.

In some embodiments, the test file comprises: an application level test file and a page level test file; the program files include application-level files and page-level files. As shown in fig. 2, in the step S102, adding, in response to the test instruction, a test file set independently from a program file of the mixed-mode mobile application to the program file includes:

step S201, responding to the test instruction, and determining the type of the currently running program file as the application-level file or the page-level file;

step S202, if the type of the currently running program file is the application level file, adding the application level test file to the application level file;

step S203, if the type of the program file currently running is the page-level file, adding the page-level test file to the page-level file.

Mixed mode mobile applications are typically exposed in the form of multiple pages, with different pages typically being implemented by separate program files or program modules, i.e., through page-level files. In addition, the program files also include application level files provided with contents such as global parameters and interface information. For the application-level file and the page-level file, different test files can be added to realize automatic testing. That is, the program file includes at least two types of subfiles, i.e., an application-level file and a page-level file.

Therefore, the type of the sub-file in the currently running program file may be determined first. And if the currently running subfile type is the application level file, adding the application level test file into the application level file, and carrying out corresponding test. The application level test file can comprise a test framework and an assertion library, and can also set native interface information of a terminal operating system, so that global access is facilitated.

And if the type of the currently running subfile is a page-level file, adding the page-level test file into the page-level file, and testing. The page level test file may include a preset test case file, and a preset timeout time or timeout return instruction. To ensure the integrity of the test results, a longer timeout time may be set, for example, to 3000ms or the like.

By identifying the types of different program files, different test files can be introduced, more flexible test can be performed, and automatic execution can be realized.

The Interface information of the application level test file may include an API (application programming Interface) in a global environment, so that the Interface information may be called globally in a program file during testing; and a native interface of the terminal operating system can be further included, so that native parameters can be acquired during testing.

For a program file with the type of application level, a program mainly comprises information such as function parameters and instructions applied to the whole situation, and a general test framework can be adopted to detect the basic functions of the program file.

Therefore, the application level test file is a test framework and an assertion library of the preset test function. In the above embodiments, the test framework and the assertion library have been described, and the functions of the native interface are introduced, which are not described herein again.

and adding the test case file to the page-level file.

Since the type is a page-level program file, different pages have different information such as functions, attributes, and parameters. For example, a video playback page may be used to play a video file over a video connection; the list page provides a list of various options for the user and links to other pages; the news page may present different news in the form of dynamically switched tags, etc. These pages with different functions may have different types of attributes, such as layout, style, etc. of the page; it is also possible to have different parameters, such as a display brightness parameter, etc. Therefore, different test cases need to be set for different pages, and testing is performed through the test cases. Therefore, the page-level test file includes the test case file. The test cases have been described in the above embodiments, and are not described herein again.

When the page-level file runs, a page is generated, and information in the page is loaded; when receiving operation instructions such as closing the page or switching the page, the page is destroyed and returned to the home page.

Therefore, the life cycle of the page can be set by setting the page running time information in the test case file, when the time corresponding to the life cycle is reached after the page is generated, the test is finished, and the page can be destroyed and returned to the home page. Or, setting a specified return instruction, and when the return instruction is executed, destroying the page and returning to the home page.

The top page herein refers to a main page of the fast application, and may include information such as a page list, interface information applied to the global, and the like, corresponding to a page created by executing the application-level file.

In order to ensure that the test case can be completely executed, a longer life cycle can be set; accordingly, if the page file is short, a short life cycle can be set to increase the test rate.

When the page-level file of one page is tested, returning to the first page based on the page running time information or the return condition instruction. When the home page file is operated, the next page can be entered and operated through the entry of the next page in the page list to be tested, which is set in the home page.

Therefore, when the application level test file corresponding to the home page is set, the page to be tested can be specified and sequentially identified in the list. When the page-level file of one page is tested and returned to the home page, the entry of the next test page can be determined according to the identifier in the list, and the page-level file of the next test page is entered and operated. At this time, the page-level test file corresponding to the next test page, that is, the test case file, may be added to the page-level file, and the test case may be executed, so as to implement the test of the next test page.

By the method, the respective tests of different page files in the mixed-mode mobile application can be completed, and the operation can be skipped for the page-level files which do not need to be tested, so that the test efficiency is effectively improved.

determining AST (Abstract Syntax Tree) operated by the program file according to the program file;

updating the AST according to the test file;

and generating an updated program file according to the updated AST.

The above steps provide an implementation of adding test files to program files. Firstly, the program file is analyzed into an abstract syntax tree to embody the syntax structure of the program file. And editing and adding codes in the corresponding test files into the abstract syntax tree to generate an updated program file. At this time, the updated program file includes various instructions and data in the test file. And finally, generating an updated program file according to the updated abstract syntax tree.

When the automatic test is carried out, the updated program file is directly operated, and a corresponding test result can be obtained according to the information in the test file.

Embodiments of the present disclosure also provide the following examples:

the functional testing of Web development can take 30% to 50% of the time required for the entire development process, and even more. Therefore, being able to implement efficient automated testing is a key factor in improving the efficiency of technology development.

The Web front-end development is commonly used in frameworks such as karma/jest/moca and the like, and is matched with a chai assertion library for automatic testing. The testing task is typically run and completed with the help of an api provided by the node. However, in the fast application hybrid development, due to the lack of the corresponding environment and the corresponding api, the automated testing cannot be performed in a manner that the framework is matched with the assertion library.

For fast application mix development, in some embodiments, testing may be performed by:

1. a field is set in the command line for determining whether to introduce an automation test within the compilation tool.

2. And introducing a test framework and exposing the api of the test library in a global environment to ensure the access of the runtime test case.

3. Encapsulating native capabilities, such as those provided by android, exposes some api that test cases need to use in a global environment.

4. Aiming at different pages, corresponding control codes are respectively introduced into the life cycles corresponding to the pages, and a test framework is instantiated.

5. And setting a page list needing automatic test. And entering a fast application home page when the test is started, and then sequentially entering pages needing to be tested.

6. And after the test case is finished, returning to the home page, and then entering the next page for testing the case.

7. And finally, counting the test passing rates of all the pages, and checking the failed test cases.

In order to improve development and testing efficiency, an automatic testing framework can be introduced in a fast application development environment, so that the stability and the testing coverage of the fast application framework are ensured.

The implementation scheme is as follows:

in order to ensure the independence of the automatic test capability, the automatic test module needs to be abstracted into a Loader (program module) which is a JavaScript module exported as a function. The Loader runner calls this function and then imports the result or resource file from the last Loader. And extracting a NODE _ TEST command of the command line through a hap-toolkit tool (a fast application matched packaging compiling tool), and introducing an automatic TEST Loader when the value of the NODE _ TEST command is Y.

The Loader logic determines whether the current script is an app.js file, which is an entry file, i.e., a global file, of an applet or a fast application.

Js file, if the current script is an app, then the test framework and assertion library are injected. For example: the mocha test framework and the chai assertion library. And meanwhile, native capability provided by native (native method) is encapsulated and exposed to the global environment for global access.

If the current script is a page-level script and the page is in the test list, introducing a test case file under a test directory (test directory) corresponding to the src directory (source directory). Instantiate the test framework within onCreate (lifecycle) and add the return logic after the test is complete. Here, a method of parsing a test case into an AST and then regenerating a ux file may be employed. Meanwhile, the overtime time is set to 3000ms, so that the automatic test can be always executed, and certainly, if the test logic of the page is relatively complex, the overtime time can be properly increased, and the test case is guaranteed to be normally executed.

The automatic Loader testing process is realized under the hap-toolkit tool. In addition, an autosase.js file can be created in the service code directory to record the test case list. And introducing an autosame.js into the first page of the whole program, so that the fast application generates a page to be tested based on the instruction, and enters the first page to start testing.

As shown in fig. 3, the method for implementing automatic Loader testing at a hap-toolkit includes the following steps:

step S11, judging whether the value of NODE _ TEST set by the command line is Y;

step S12, if the NODE _ TEST value is not Y, skipping the automatic processing Loader of the current page;

step S13, if the NODE _ TEST value is Y, judging whether the current script is an app.js file;

step S14, if the current script is an app.js file, the test case is analyzed into AST, then a test framework and an assertion library are introduced, native capability of native is encapsulated, a new AST is generated, and global access of the test framework and the assertion library is guaranteed.

And step S15, if the current script is not the app.js file, processing the onCreate function of the current page, and analyzing to generate the AST. And set the timeout to 3000 ms. And ensuring the normal execution of the automatic test, and adding the logic after the execution is finished.

In step S16, the js file is newly generated by the general package (compiling tool) based on the AST generated in step S4 or step S5.

And step S17, after completing the Loader of the current page or skipping the Loader of the current page, entering the next Loader and continuing to process the js file.

And step S18, packaging the generated js files and the test code logic together to generate rpk file packages, so that the method can be applied to automatic testing of a real machine.

The implementation logic in the test code may include the following steps:

step S21, add an autosase.js file (which can be dynamically generated by fs package under node.js environment) under the src file, wherein the autosase.js list file is included;

step S22, introducing a file to be tested, namely page/home/index.ux, into a list object of autolist.js, writing a corresponding template by using fast application grammar, and generating a rpk file package;

step S23, completing the function test of the current page within the overtime time, and returning to the home page after the overtime time is reached;

and step S24, entering the next page in the list of autolist.js, and performing the step S23 until the whole test case is finished.

By the method in the embodiment, the automatic test modules are independently extracted, and the weak coupling among the modules is ensured through the command line setting. And the mocha/chai library is introduced and exposed to the whole situation, so that the automatic test is realized. Meanwhile, the ux file of the original page level is transformed, a new life cycle is inserted, and a test framework is instantiated. Therefore, the development and test efficiency is improved, and the stability and the test coverage of the quick application framework are ensured.

FIG. 5 is a block diagram illustrating a program test device in accordance with an exemplary embodiment. Referring to fig. 5, the apparatus 500 includes an acquisition module 510, an addition module 520, an execution module 530, and a determination module 540.

An obtaining module 510, configured to obtain a test instruction in a process of running a mixed-mode mobile application;

an adding module 520, configured to add, in response to the test instruction, a test file that is independent of a program file setting of the mixed-mode mobile application to the program file;

an operation module 530, configured to operate a program file including the test file, where the program file calls the test file to operate when the program file is operated to a test node;

the determining module 540 is configured to determine a corresponding test result based on the operation result of the program file.

In some embodiments, the test file comprises: an application level test file and a page level test file; the adding module comprises:

the first determining submodule is used for responding to the test instruction and determining the type of the currently operated program file as an application-level file or a page-level file;

In some embodiments, the second adding submodule is specifically configured to:

and adding the test case file to the page-level file.

In some embodiments, the execution module includes:

In some embodiments, the adding module comprises:

an update sub-module for updating the AST according to the test file;

and the generation submodule is used for generating an updated program file according to the AST.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Fig. 6 is a block diagram illustrating a physical structure of a program testing apparatus 600 according to an exemplary embodiment. For example, the apparatus 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, and so forth.

Referring to fig. 6, apparatus 600 may include one or more of the following components: a processing component 601, a memory 602, a power component 603, a multimedia component 604, an audio component 605, an input/output (I/O) interface 606, a sensor component 607, and a communication component 608.

The processing component 601 generally controls the overall operation of the device 600, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 601 may include one or more processors 610 to execute instructions to perform all or a portion of the steps of the methods described above. Further, the processing component 601 may also include one or more modules that facilitate interaction between the processing component 601 and other components. For example, the processing component 601 may include a multimedia module to facilitate interaction between the multimedia component 604 and the processing component 601.

The memory 602 is configured to store various types of data to support operations at the apparatus 600. Examples of such data include instructions for any application or method operating on the apparatus 600, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 602 may be implemented by any type or combination of volatile or non-volatile storage devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

The power supply component 603 provides power to the various components of the device 600. The power supply component 603 may include: a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the device 600.

The multimedia component 604 includes a screen that provides an output interface between the device 600 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 604 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the device 600 is in an operating mode, such as a shooting mode or a video mode. Each front camera and/or rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

Audio component 605 is configured to output and/or input audio signals. For example, audio component 605 includes a Microphone (MIC) configured to receive external audio signals when apparatus 600 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 610 or transmitted via the communication component 608. In some embodiments, audio component 605 also includes a speaker for outputting audio signals.

The I/O interface 606 provides an interface between the processing component 601 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor component 607 includes one or more sensors for providing various aspects of status assessment for the apparatus 600. For example, the sensor component 607 may detect the open/closed state of the apparatus 600, the relative positioning of components, such as a display and keypad of the apparatus 600, the sensor component 607 may also detect a change in the position of the apparatus 600 or a component of the apparatus 600, the presence or absence of user contact with the apparatus 600, orientation or acceleration/deceleration of the apparatus 600, and a change in the temperature of the apparatus 600. The sensor component 607 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. The sensor component 607 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 607 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 608 is configured to facilitate wired or wireless communication between the apparatus 600 and other devices. The apparatus 600 may access a wireless network based on a communication standard, such as WiFi, 2G, or 3G, or a combination thereof. In an exemplary embodiment, the communication component 608 receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 608 further includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, or other technologies.

In an exemplary embodiment, the apparatus 600 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

In an exemplary embodiment, a non-transitory computer readable storage medium comprising instructions, such as the memory 602 comprising instructions, executable by the processor 610 of the apparatus 600 to perform the above-described method is also provided. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

A non-transitory computer readable storage medium, wherein instructions, when executed by a processor of a mobile terminal, enable the mobile terminal to perform the steps of any of the program testing methods provided in the above embodiments.

Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

It will be understood that the invention is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims

1. A program testing method, comprising:

2. The method of claim 1, wherein the test file comprises: an application level test file and a page level test file; the program files comprise application level files and page level files; the adding, in response to the test instruction, a test file set independently of a program file of the mixed-mode mobile application to the program file includes:

3. The method of claim 2, wherein adding the application-level test file to the application-level file comprises:

4. The method of claim 3, wherein the application-level test file comprises: the system comprises a test framework for providing a test function and an assertion library for judging whether a test result is correct or not; the interface information includes: an operating system native interface; wherein the operating system native interface comprises: an interface for obtaining operating system native parameters to which the mixed-mode mobile application belongs.

5. The method of claim 2, wherein the page level test file comprises: the adding the page-level test file to the page-level file comprises:

and adding the test case file to the page-level file.

6. The method of claim 5, wherein the running a program file containing the test file comprises:

7. The method of claim 6, wherein the home page comprises: presetting a page list to be tested; the running of the program file containing the test file further comprises:

8. The method of any of claims 1 to 7, wherein adding a test file to the program file that is independent of the program file settings of the mixed-mode mobile application comprises:

updating the AST according to the test file;

and generating an updated program file according to the updated AST.

9. A program test apparatus, comprising:

10. The apparatus of claim 9, wherein the test file comprises: an application level test file and a page level test file; the program file includes: an application level program file and a page level program file; the adding module comprises:

11. The apparatus according to claim 10, wherein the second adding submodule is specifically configured to:

12. The apparatus of claim 11, wherein the application-level test file comprises: the system comprises a test framework for providing a test function and an assertion library for judging whether a test result is correct or not; the interface information includes: an operating system native interface; wherein the operating system native interface comprises: an interface for obtaining operating system native parameters to which the mixed-mode mobile application belongs.

13. The apparatus of claim 10, wherein the page-level test file comprises: the test case file, the second adding submodule, is specifically configured to: and adding the test case file to the page-level file.

14. The apparatus of claim 13, wherein the operation module comprises:

15. The apparatus of claim 14, wherein the home page comprises: presetting a page list to be tested; the operation module further comprises:

16. The apparatus of any one of claims 9 to 15, wherein the adding module comprises:

an update sub-module for updating the AST according to the test file;

17. A program testing apparatus, characterized in that the apparatus comprises at least: a processor and a memory for storing executable instructions operable on the processor, wherein:

the processor is configured to execute the executable instructions, and the executable instructions perform the steps of the program testing method provided in any one of the preceding claims 1 to 8.

18. A non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed by a processor, perform steps in a program testing method as provided in any one of claims 1 to 8.