CN110851370B

CN110851370B - Program testing method and device and storage medium

Info

Publication number: CN110851370B
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: 2024-04-26
Anticipated expiration: 2039-11-20
Also published as: CN110851370A

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: acquiring a test instruction in the process of running the mixed mode mobile application; in response to the test instruction, adding a test file set independently of a program file of the mixed mode mobile application to the program file; running a program file containing the test file, wherein the program file calls the test file to run when running to a test node; based on the running result of the program file, a corresponding test result is determined. According to the technical scheme provided by the embodiment of the disclosure, the test files related to the automatic test and the program files can be independently set, and the test files are loaded in the program files based on the test instructions 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 app (Hybrid mobile application) is a new application form based on a mobile phone hardware platform, and is an application type between web-app (web application) and native-app (native application). Hybrid app has the advantages of good user interaction experience of active-app and cross-platform development of web-app, does not need to be downloaded and installed, and can bring smooth application experience. In the development process of Hybrid app, program testing takes an important role, but a test method for the Hybrid app program with high efficiency and convenience 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 embodiments of the present disclosure, there is provided a program testing method, including:

acquiring a test instruction in the process of running the mixed mode mobile application;

In response to the test instruction, adding a test file set independently of a program file of the mixed mode mobile application to the program file;

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

Based on the running result of the program file, a corresponding test result is determined.

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:

Determining the type of a currently running program file as the application-level file or the page-level file in response to the test instruction;

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 running program file is the page-level file, adding the page-level test file to the page-level file.

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

application level test files and interface information applied to the global environment of the mixed mode mobile application are added to the application level files.

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

In some embodiments, the page level test file includes: test case files, the adding the page level test files to the page level files, comprising:

the test case file is added to the page level file.

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

Operating a page-level file containing the test case file; the test case file comprises the following components: returning conditional instructions and/or page run time information;

When the page-level file is running to the return conditional instruction, and/or when the page-level file running time exceeds the time indicated by the page running time information, the running of the page-level file is suspended and returned to the home page of the mixed-mode mobile application.

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

And entering and operating a page level file of the next test page according to an inlet of the next test page in the page list to be tested.

In some embodiments, the adding a test file set independently of a program file of the mixed mode mobile application to the program file comprises:

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 embodiments of the present disclosure, there is provided a program testing apparatus, comprising:

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

an adding module, configured to respond to the test instruction, and add a test file set independently of a program file of the mixed mode mobile application to the program file;

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

and the determining module is used for determining a corresponding test result based on the running 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 running program file as the application-level file or the page-level file;

The first adding sub-module 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 sub-module is used for adding the page-level test file to the page-level file if the type of the currently running program file is the page-level file.

In some embodiments, the second adding sub-module is specifically configured to:

In some embodiments, the page level test file includes: the second adding sub-module is specifically configured to:

the test case file is added to the page level file.

In some embodiments, the run module comprises:

the first operation submodule is used for operating the page-level file containing the test case file; the test case file comprises the following components: returning conditional instructions and/or page run time information;

And the suspension submodule is used for suspending the operation of the page-level file and returning to the first page of the mixed mode mobile application when the page-level file is operated to the return conditional instruction and/or when the operation time of the page-level file exceeds the time indicated by the page operation time information.

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

and the second operation submodule 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 page list to be tested.

In some embodiments, the adding module includes:

a second determining submodule, configured to determine, according to the program file, an abstract syntax tree AST operated by the program file;

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

and the generating sub-module 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 comprising at least: a processor and a memory for storing executable instructions capable of executing on the processor, wherein:

the processor is configured to execute the executable instructions that perform the steps of any of the program testing methods described above when the executable instructions are executed.

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 steps in any of the program testing methods described above.

The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects: through the steps in the method, the automatic test of the mixed mode mobile application is realized, and the independent test can be carried out on the content to be tested based on the test instruction. In addition, because the test file is independently arranged from the program file, the influence of the test file on the program file is reduced, and each program module 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 of the 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 flowchart illustrating a program test method according to an exemplary embodiment.

FIG. 2 is a flowchart illustrating another program test method according to an exemplary embodiment.

FIG. 3 is a flowchart illustrating yet another program test method according to an exemplary embodiment.

Fig. 4 is a flowchart illustrating a method of setting a test file according to an exemplary embodiment.

Fig. 5 is a block diagram illustrating a program testing apparatus according to an exemplary embodiment.

Fig. 6 is a block diagram showing a physical structure of a program testing apparatus according to an exemplary embodiment.

Detailed Description

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

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

Step S101, acquiring a test instruction in the process of running the mixed mode mobile application;

Step S102, responding to the test instruction, and adding a test file which is set independently of a program file 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;

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

Here, the Hybrid mobile application, i.e., hybrid app, is interposed between the web-app and the active-app, is run by the cloud, and displays the result of the run on the terminal, and receives a control instruction from the terminal. Both fast applications and applets etc belong to this type of mixed-mode mobile application.

The user of the mixed mode mobile application is ready to use without downloading the install application package. The mixed mode mobile application framework is deeply integrated in an operating system of the terminal equipment, seamless connection between user demands and application services can be formed on the level of the operating system of the terminal equipment, and many functions which can only be used in the active-app but not in the web-app can be realized conveniently in the mixed mode mobile application, so that the performance experience of the active-app can be enjoyed. The mixed mode mobile application front end can also be used for receiving a mixed mode mobile application running instruction. For example, if a click operation for the mixed-mode mobile application is received based on the mixed-mode mobile application front-end, a procedure of specifically performing 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 in a network architecture constructed based on the mixed-mode mobile application platform and the mixed-mode mobile application front end.

The mixed-mode mobile application can be divided into a component tree (DOM), a style (CSS), a logic (JS code) from a data perspective; the package file can be divided into a configuration file (manifest. Json), a global file (App. Js) and a page file (page) from composition, and the package file is a package file rpk after the program is packaged, and the package file is an Application program (App) 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, each of which may need to be tested individually during testing. Furthermore, after completing a test, a retest may be required for a different program module. Therefore, if the test file is directly and fixedly written into the program file, unnecessary test actions may need to be executed every time the test is performed, and the test efficiency is low.

Thus, the above steps provide an implementation of an automated test that enables mixed-mode mobile applications. And (3) independently setting the test file carrying the test related instruction codes in a file packet of the mixed mode mobile application, calling the test file if test execution is received in the running process of the mixed mode mobile application, adding the instruction codes in the test file into a program file to be tested, and obtaining a corresponding test result as a running result.

Here, the test instruction may be obtained from a command in a command line tool of the terminal, and the 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; if the test instruction is not obtained, 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 and an assertion library, the test framework being a set of test instructions for providing a simulated mixed-mode mobile application base function. And injecting a test framework into the program and running, which is equivalent to automatically executing the appointed function of the mixed mode mobile application, and 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 designated position, if the return value is the same as the preset value in the assertion library, the operation is considered to be correct; if the return value is different from the value preset in the assertion library, the operation is considered to be wrong.

The test file may also include a preset test case file. The test case file includes one or more test cases, which are test schemes for one or some functions of the program file, including: test targets, test environments, input data, test scripts, etc. When the program file calls the test case, the program file operates according to the test scheme set in the test case, and finally outputs a corresponding result. After the test case is executed, the output result is the one-time 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 independent test can be carried out on the content to be tested based on the test instruction. In addition, because the test file is independently arranged from the program file, the influence of the test file on the program file is reduced, and each program module 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 of the 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, 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:

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 currently running program file is the page-level file, adding the page-level test file to the page-level file.

Mixed-mode mobile applications are typically presented in the form of multiple pages, with different pages typically being implemented by separate program files or program modules, i.e., by page-level files. In addition, the program file further comprises an application-level file provided with global parameters, interface information and other contents. For application level files and page level files, different test files may be added to achieve automated testing. That is, the program files include at least two types of subfiles, namely, an application-level file and a page-level file.

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

If the type of the sub-file currently running is a page-level file, the page-level test file is added to the page-level file, and a test is performed. 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, so that more flexible tests 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, application program interface) in a global environment so that a call may be made in the global of the program file during the test; a native interface of the terminal operating system may also be included so that native parameters may be obtained at test time.

For a program file with an application level, the program mainly comprises information such as functional parameters and instructions applied to the whole world, 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 with preset test functions. In the above embodiments, the test framework and the assertion library have been described, and the functions of the native interface are described, which will not be described herein.

the test case file is added to the page level file.

Because of the program files of the page level, different pages have different information such as functions, attributes, parameters and the like. 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, etc., in the form of dynamic switch tabs. These pages of different functions may have different types of properties, such as layout, style, etc. of the page; but may also have different parameters such as display brightness parameters, etc. Therefore, it is necessary to set different test cases for different pages and perform a test by the test cases. Thus, the page level test file includes the test case file. The test cases have been described in the above embodiments, and will not be described in detail here.

When the page-level file runs, a page is generated, and information in the page is loaded; when an operation instruction of closing the page or switching the page is received, the page is destroyed and returned to the first page.

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

The home page refers to a home page of the fast application, and corresponds to a page created by the application-level file, and the home page may include information such as a page list, interface information applied to the global, and the like.

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 shorter, a shorter lifecycle may be set to promote the testing rate.

After the page-level file of a page completes the test, the page returns to the first page based on the above page runtime information or the return conditional 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 setting the application level test file corresponding to the home page, the pages to be tested can be specified and are identified in the list in turn. When the page-level file of one page is tested and returned to the first page, the entry of the next test page can be determined according to the identification 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 testing of different page files in the mixed mode mobile application can be completed, and the operation can be skipped for page-level files without testing, so that the testing efficiency is effectively improved.

determining an 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 parsed into an abstract syntax tree to embody the syntax structure of the program file. And then adding the code edits in the corresponding test files to the abstract syntax tree to generate updated program files. At this time, the updated program file contains 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 then a corresponding test result can be obtained according to the information in the test file.

The disclosed embodiments also provide the following examples:

Functional testing of Web development can account for 30% to 50% of the time required for the entire development process, and even higher. Therefore, the ability to achieve efficient automated testing is a key factor in improving the efficiency of technology development.

Frames such as karma/jest/mocha are often used in Web front-end development, and are matched with a chai assertion library for automatic testing. Typically, the test tasks are run and completed by means of an api provided by the node. Js environment or browser environment. However, in the fast application hybrid development, due to the lack of a corresponding environment and a corresponding api, automatic testing cannot be performed by the framework in cooperation with the assertion library.

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

1. A field is set in the command line for determining within the compilation tool whether to introduce automated testing.

2. And introducing a test framework, and exposing the api of the test library in a global environment to ensure the access of the test cases in the running process.

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

4. And respectively introducing corresponding control codes in the life cycle corresponding to the pages according to different pages, and instantiating the test framework.

5. A list of pages that need to be automatically tested is set. And when the test starts, entering a quick application home page, and then entering pages to be tested in sequence.

6. After the test case is completed, returning to the first page, and then entering the next page to perform the test case.

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

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

The implementation scheme is as follows:

in order to ensure the independence of the automation test capability, the automation test module needs to be independently abstracted into a Loader (program module), wherein the Loader is a JavaScript module exported as a function. The Loader runner will call this function and then import the result or resource file generated by the last Loader. The NODE_TEST command of the command line is extracted by a hap-tool (a packaging compiling tool matched with a quick application), and when the value of the NODE_TEST command is Y, an automatic TEST Loader is introduced.

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

If the current script is an app. Js file, then a test framework and predicate library are injected. For example: mocha test frameworks and chai predicate libraries. And meanwhile, native capability provided by native methods is encapsulated and exposed to a global environment for global access.

If the current script is a page-level script and the page is in the test list, a test case file under a test directory (test directory) corresponding to the src directory (source directory) is introduced. Instantiate the test framework and add return logic after test completion in onCreate (lifecycle). Here, a method of converting the test cases into AST and then regenerating the ux file may be employed. And the timeout time is set to 3000ms, so that the automatic test can be executed all the time, and the timeout time can be properly increased to ensure that the test case is normally executed if the test logic of the page is complex.

The above is the process of implementing an automated test Loader under the hap-tool. In addition, an autocase. Js file may be created in the service code directory for recording the test case list. Introducing an autocase. Js in the first page of the whole program, enabling the quick application to generate a page to be tested based on the instruction, and entering the first page to start testing.

As shown in fig. 3, the method for implementing the automated test Loader at the hap-tool 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 automation 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;

and S14, if the current script is an app.js file, analyzing the test case into an AST, introducing a test framework and an assertion library, packaging native capabilities of native, generating a new AST, and ensuring global access of the test framework and the assertion library.

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

Step S16, regenerating js file by generating package (compiling tool) based on AST generated in step S4 or step S5.

And S17, after the Loader of the current page is completed or skipped, entering the next Loader, and continuing to process js files.

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

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

S21, adding an autocase.js file (which can be dynamically generated by an fs package in a node.js environment) under the src file, wherein the autocase.js list file is included;

step S22, a file waiting for the page/home/index. Ux to be tested is introduced into a list object of an autolist. Js, and a corresponding template is written by using a fast application grammar to generate rpk file packages;

step S23, completing the function test of the current page within the timeout period, and returning to the first page after the timeout period is reached;

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

By the method in the embodiment, the automatic test modules are independently extracted, and weak coupling among the modules is ensured through command line arrangement. Automated testing is achieved by introducing mocha/chai libraries and exposing to global. Meanwhile, the ux file at the original page level is transformed, a new life cycle is inserted, and a test framework is instantiated. Therefore, development and testing efficiency is improved, and stability and testing coverage of the quick application framework are guaranteed.

Fig. 5 is a block diagram illustrating a program testing apparatus according to an exemplary embodiment. Referring to fig. 5, the apparatus 500 includes an acquisition module 510, an addition module 520, an operation module 530, and a determination module 540.

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

An adding module 520, configured to respond to the test instruction, and add a test file set independently of a program file 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 invokes 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 running 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 that the type of the currently running program file is an application-level file or a page-level file;

the test case file is added to the page level file.

In some embodiments, the run module comprises:

In some embodiments, the adding module includes:

And the generating sub-module is used for generating an updated program file according to the AST.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

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

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 overall operations of the apparatus 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 part of the steps of the methods described above. In addition, the processing component 601 may also include one or more modules that facilitate interactions 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, video, and the like. The memory 602 may be implemented by any type of volatile or nonvolatile memory device or combination thereof, 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 disk, or optical disk.

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

The multimedia component 604 includes a screen that provides an output interface between the device 600 and the 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 input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or slide action, but also the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 604 includes a front camera and/or a rear camera. The front camera and/or the rear camera may receive external multimedia data when the apparatus 600 is in an operational mode, such as a photographing mode or a video mode. Each front camera and/or rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

The audio component 605 is configured to output and/or input audio signals. For example, the audio component 605 includes a Microphone (MIC) configured to receive external audio signals when the apparatus 600 is in an operational mode, such as a call mode, a recording mode, and a speech recognition mode. The received audio signals may be further stored in the memory 610 or transmitted via the communication component 608. In some embodiments, the 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: homepage button, volume button, start button, and lock button.

The sensor assembly 607 includes one or more sensors for providing status assessment of various aspects of the apparatus 600. For example, the sensor assembly 607 may detect the on/off state of the device 600, the relative positioning of components, such as the display and keypad of the device 600, the sensor assembly 607 may also detect the change in position of the device 600 or one of the components of the device 600, the presence or absence of user contact with the device 600, the orientation or acceleration/deceleration of the device 600, and the change in temperature of the device 600. The sensor assembly 607 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 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 assembly 607 may also include an acceleration sensor, a gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 608 is configured to facilitate communication between the apparatus 600 and other devices in a wired or wireless manner. The device 600 may access a wireless network based on a communication standard, such as WiFi,2G, or 3G, or a combination thereof. In one exemplary embodiment, the communication component 608 receives broadcast signals 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, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.

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

A non-transitory computer readable storage medium, which when executed by a processor of a mobile terminal, causes the mobile terminal to perform the steps of any one of the program test methods provided in the above embodiments.

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

It is to be understood that the invention is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected 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:

Determining the type of a currently running program file in response to the test instruction;

adding a test file set independently of a program file of the mixed mode mobile application to the program file based on the type of the program file currently running;

The test file can be applied to the global environment of the mixed mode mobile application and is called by different program files;

The test file comprises a test framework for providing a test function and an assertion library for judging whether a test result is correct or not; the test file also comprises a test case file, wherein the test case file comprises a test scheme for one or more functions of the program file;

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 a test file set independently of a program file of the mixed mode mobile application to the program file based on a type of the program file currently running includes:

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

4. A method according to claim 3, wherein the application level test file comprises: a test framework for providing test functions and an assertion library for judging whether the test result is correct; the interface information includes: an operating system native interface; wherein, the operating system native interface comprises: and the interface is used for acquiring the native parameters of the operating system to which the mixed mode mobile application belongs.

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

the test case file is added to the page level file.

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

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

8. The method according to any one of claims 1 to 7, wherein adding a test file set up independent of a program file of the mixed mode mobile application to the program file comprises:

Updating the AST according to the test file;

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

9. A program testing apparatus, comprising:

The adding module is used for responding to the test instruction and determining the type of the currently running program file; adding a test file set independently of a program file of the mixed mode mobile application to the program file based on the type of the program file currently running;

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 file and a page level file; the adding module comprises:

11. The apparatus of claim 10, wherein the second adding sub-module is specifically configured to:

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

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

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

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

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

17. A program testing device, the device comprising at least: a processor and a memory for storing executable instructions capable of executing on the processor, wherein:

A processor is arranged to execute the executable instructions, when the executable instructions are executed, to perform the steps of the program testing method provided in any of the preceding claims 1 to 8.

18. A non-transitory computer readable storage medium having stored therein computer executable instructions which when executed by a processor implement the steps of the program testing method provided in any one of the preceding claims 1 to 8.