Disclosure of Invention
The invention aims to provide an automatic verification method and system for mobile phone production system software, so as to improve the efficiency and timeliness of functional verification of the mobile phone production system software.
In order to solve the technical problems, the invention provides an automatic verification method for mobile phone production system software, which comprises the following steps:
Acquiring a system software version file;
The system software version file is brushed into the mobile phone;
Reading mobile phone configuration information and matching mobile phone instruction configuration files;
analyzing the mobile phone instruction configuration file and executing the test instruction in the mobile phone instruction configuration file;
Analyzing the test return value of each test instruction to determine the test result of each test instruction and feeding back the test result to related personnel;
and judging the version according to the test result to issue a conclusion and outputting a test report.
Further, the acquiring the system software version file includes:
Placing the compiled software version file on a designated path of a server;
Checking whether a system software version file corresponding to the naming rule of the system software version file exists, and if so, indicating that the system software version file is generated.
Further, if the system software version file corresponding to the system software version file naming rule does not exist, stopping the test and notifying related personnel.
Further, the swiping the system software version file into the mobile phone includes:
Connecting a mobile phone with a computer terminal;
decompressing the system software version file and brushing the system software version file into the mobile phone.
Further, whether the mobile phone and the computer end are connected successfully is judged through the verification instruction.
Further, if the connection between the mobile phone and the computer end fails, stopping the test and notifying related personnel.
Further, if the process of brushing the system software version file into the mobile phone fails, stopping the test and notifying related personnel.
Further, the reading the mobile phone configuration information and matching the mobile phone instruction configuration file includes:
obtaining the model name of the mobile phone through a mobile phone instruction;
And obtaining the configuration file under the folder of the model name of the corresponding mobile phone, and matching successfully after the corresponding configuration file is found.
Further, if the matching of the configuration files fails, the test is stopped and related personnel are notified.
Further, the analyzing the mobile phone instruction configuration file, executing the test instruction in the mobile phone instruction configuration file, includes:
creating a configuration file copy as a test report;
And executing the test instructions in the configuration file one by one, and filling the executed test results into the configuration file copy.
Further, each test return value is compared to an expected value to determine a test result.
Further, the failure item of the test result of each test instruction is scored, and the scoring of the failure item is accumulated and compared with the set standard to determine the release result.
Further, if the score accumulation of the failed item is smaller than the set standard, the system software version file is released, and if the score accumulation of the failed item is smaller than the set standard, the system software version file is not released.
Further, a test instruction set column, an expected value column, a test return value column, a test item module responsible person column and a test instruction level column are arranged in the mobile phone instruction configuration file.
Further, the test instruction includes a device class instruction set including a basic device module loading status check for the LCD module, TP module, camera module, finger module, audio module, and Sensor module.
Further, the passing zone bit information is set in the codes of the system software, the service for carrying out functional checking and verification on the codes is defined, the bottom layer codes are monitored in the process of executing the test instruction, and if the zone bit information of each stage corresponding to the basic equipment module is passing, the loading of the corresponding basic equipment module is completed.
The invention also provides an automatic verification system for the mobile phone production system software, which is used for realizing the automatic verification method for the mobile phone production system software according to any one of the technical schemes, and comprises the following steps:
the file acquisition unit is used for acquiring a system software version file;
the system comprises a mobile phone, a system software version file and a system software version file;
the matching unit is used for reading the mobile phone configuration information and matching the mobile phone instruction configuration file;
the analysis and transmission unit is used for analyzing the mobile phone instruction configuration file to generate a test instruction and transmitting the test instruction to the mobile phone;
the analysis unit is used for analyzing the test return value of each test instruction so as to determine the test result of each test instruction and feed back the test result to related personnel;
And the report generating unit is used for judging the version issuable conclusion according to the test result and outputting a test report.
Compared with the prior art, the invention has at least the following beneficial effects:
The batch execution, result judgment and version release result confirmation of the test instructions can be automatically realized, so that the time for researching and developing manual test and the risk of missing test errors are greatly reduced, the manpower for research and development and the manpower for test are reduced, the efficiency and timeliness of functional verification of the mobile phone production system software are improved, and the accuracy of the mobile phone production system software version is also improved.
In addition, the automatic verification method of the mobile phone production system software can also be used for checking whether the devices and functions of the hardware equipment are degraded or abnormal after long-time use.
Detailed Description
The present invention will now be described with reference to the drawings, in which preferred embodiments of the present invention are shown, and in which it should be understood that those skilled in the art can modify the invention herein described while still achieving the beneficial effects of the invention. Accordingly, the following description is to be construed as broadly known to those skilled in the art and not as limiting the invention.
The invention is more particularly described by way of example in the following paragraphs with reference to the drawings. Advantages and features of the invention will become more apparent from the following description and from the claims. It should be noted that the drawings are in a very simplified form and are all to a non-precise scale, merely for convenience and clarity in aiding in the description of embodiments of the invention.
An automatic software verification method for a mobile phone production system according to an embodiment of the present invention will be described with reference to fig. 1 of the accompanying drawings.
In one embodiment, as shown in fig. 1, the method for automatically verifying the software of the mobile phone production system of the present embodiment includes the following steps:
s100: acquiring a system software version file;
s200: the system software version file is brushed into the mobile phone;
s300: reading mobile phone configuration information and matching mobile phone instruction configuration files;
s400: analyzing the mobile phone instruction configuration file and executing the test instruction in the mobile phone instruction configuration file;
S500: analyzing the test return value of each test instruction to determine the test result of each test instruction and feeding back the test result to related personnel;
s600: and judging the version according to the test result to issue a conclusion and outputting a test report.
The batch execution, result judgment and version release result confirmation of the test instructions can be automatically realized, so that the time for researching and developing manual test and the risk of missing test errors are greatly reduced, the manpower for research and development and the manpower for test are reduced, the efficiency and timeliness of functional verification of the mobile phone production system software are improved, and the accuracy of the mobile phone production system software version is also improved.
In addition, the automatic verification method of the mobile phone production system software can also be used for checking whether the devices and functions of the hardware equipment are degraded or abnormal after long-time use.
Further, in step S100, the acquiring the system software version file includes:
s110: placing the compiled software version file on a designated path of a server;
S120: checking whether a system software version file corresponding to the naming rule of the system software version file exists, and if so, indicating that the system software version file is generated.
In step S110, after the software version file is compiled by the editing server, the software version file is packaged into a flash package and placed on a designated path of the server, and the path of the software version file is configured as the server address.
In step S120, it is required to ensure that the system software version file of the item to be tested is successfully generated, so that it is required to check whether the system software version file corresponding to the naming rule of the system software version file exists, and if so, it is indicated that the system software version file is generated and downloaded to the computer. The naming rule of the system software version file can be defined by user, and for testing, the information such as the item number to be tested is usually associated into the naming rule of the system software version.
For example: the items to be tested are:
{"project":"apple","swPath":"\\software\version\factory\"，"swRegion":"global"，"swType":"flash"}
According to the naming rule of the system software version file, the line flash package which is at the beginning of the apple file and is in the global area is traversed under the factor file of the software server, and the matched file names are as follows: if a file named by the file name is detected on a designated path of the server, the file of the system software version is generated, and the file is downloaded to the computer.
If the system software version file corresponding to the naming rule of the system software version file does not exist, stopping the test and notifying related personnel, wherein the notification mode can be mail mode or other instant messaging tools such as short message and the like.
For example: if no file at the beginning of the apple can be found on the server, the result Fail of compiling the system software version is indicated, and the system software version file is not generated. If the file at the beginning of the apple can be found on the server, but the match is less than the values of swRegion and swType, then the software version is indicated as not matching. And finally, when the two types of information cannot be matched, sending failure specific information to relevant research and development personnel through mails or other instant messaging tools, and stopping testing.
In other embodiments, the system software version file may also be copied to the computer by means of a storage medium copy.
Further, in step S200, the brushing the system software version file into the mobile phone includes:
s210: connecting a mobile phone with a computer terminal;
S220: decompressing the system software version file and brushing the system software version file into the mobile phone.
In step S210, it is required to determine whether the mobile phone is connected to the computer terminal, and only after the connection is successful, the subsequent steps can be performed.
For example, whether the mobile phone is connected to the computer end can be judged by executing the adb devices command, and if the command line List of DEVICES ATTACHED is displayed as 8f2f85d after the operation, the mobile phone is successfully connected.
If the command line List of DEVICES ATTACHED is empty, or the error is returned to the no devices/emulators found after the adb shell command is executed, the mobile phone is not connected, which indicates that the connection between the mobile phone and the computer end fails, at this time, the test should be stopped and relevant research personnel should be notified of the information without equipment through mail or other instant communication tools.
In step S220, after the mobile phone confirms the connection, the decompression of the system software version file is performed, so that the space of the disk can be saved. And then brushing the brushing bag into the mobile phone through a wire brushing tool, and finally judging the state of the mobile phone to confirm that the mobile phone can be started.
For example: and (3) executing the line brush script flash_all.bat of the decompressed software package, and confirming whether an abnormality exists in the process of brushing the machine by executing the script and monitoring the return value of the script. If an exception exists, the value of 0 is returned, otherwise, the execution is continued until the last command fastboot reboot is executed, so that the mobile phone can be automatically restarted and started after the mobile phone is completely refreshed. After finishing the machine, continuously using the adb devices command to detect whether the device is connected to prevent connection interruption, and confirming that the machine is started when the value is 1 according to adb shell getprop sys.boot_ completed instruction judgment.
In one embodiment, if the process of brushing the system software version file into the mobile phone fails, or the restart or start-up fails after the system software version file is brushed, the test is stopped and relevant research and development personnel are notified through mails or other instant messaging tools.
For example: the return value is 0 in the process of brushing, and the failure code is 0x01; the code of the restarting failure of the mobile phone is 0x02; when the value of sys.boot_ completed is not 1 after the starting-up is detected within 5 minutes, the starting-up fails, the code is 0x03, and different failure codes are notified to relevant research and development personnel through mails or other instant messaging tools.
Further, in step S300, the reading the mobile phone configuration information and matching the mobile phone instruction configuration file includes:
S310: obtaining the model name of the mobile phone through a mobile phone instruction;
s320: and obtaining the configuration file under the folder of the model name of the corresponding mobile phone, and matching successfully after the corresponding configuration file is found.
Specifically, after the mobile phone is confirmed to be started, the model name information of the mobile phone is obtained through an instruction, a configuration file is obtained under a folder of the corresponding model name of the mobile phone according to the obtained information, and if the corresponding file name is found, matching is successful.
For example: the adb shell getprop ro.product.name instruction may be used to obtain the model name of the handset, and if the return value of the handset is apple, the settings.xls configuration table may be found in the tool directory "/reference/apple/".
If the apple directory or settings. Xls file cannot be found, the configuration file loading fails, after which the test should be stopped and the relevant developer notified via mail or other instant messaging tool.
For example: when the configuration file is read, the corresponding file form can not be found, or the configuration file can not be opened or loaded, and the failure of reading the configuration file is judged, and the configuration file is required to be stopped in time and is notified to relevant research and development personnel through mails or other instant messaging tools.
Further, in step S400, the parsing the mobile phone instruction configuration file, executing the test instruction in the mobile phone instruction configuration file, includes:
S410: creating a configuration file copy as a test report;
S420: and executing the test instructions in the configuration file one by one, and filling the executed test results into the configuration file copy.
In step S410, the identified and openable configuration file is copied as a test report, and executed according to each item of the header of the configuration file, and the test return value obtained after execution is filled in the corresponding position of the configuration file form, which represents that execution of an instruction is completed, and skipping is performed when a command which cannot be executed is encountered. The loop is such that a row runs to the end to complete the batch instruction test and obtain all test returns.
For example: the checked configuration settings. Xls file is copied to the "/testResult/apple/" directory and named as the apple_command_result.
The title of the table in the configuration file is analyzed, and the query fields are command column, explanation column, actual results column, testResult column, testOwner column and testPriority column, which correspond to a test instruction set column, an expected value column, a test return value column, a test complex judgment result column, a test item module responsible column and a test instruction level column respectively. In other embodiments, the test resumption result column may not be set.
Executing the first line instruction of command column, such as adb shell "getprop ro.ril. Oem.sno", test return value XB332L000534, fills this value into the corresponding line of actual results column. While explanation columns correspond to rows that have been configured with the desired values at the time of configuration: XB332L000534. And similarly, executing the instruction of the next row, filling in the test return value to the corresponding row until all the test instructions are executed and all the test return values are obtained.
The test instruction set array can be divided into a device class instruction set, a basic system class instruction set, a long and short distance class instruction set, a Power supply PMIC (Power MANAGEMENT INTEGRATED Circuit) system class instruction set, a large system class instruction set and other function class instruction sets, and the several classes of instructions are customized by the research and development depth and are highly combined with a system ROM (read only memory) so as to check whether software access and configuration have problems under the condition of perfect hardware functions.
Specifically, the device instruction set includes basic equipment module loading state checking of LCD (screen), TP (touch panel), camera, fingerprint, audio, sensor and other modules, and when the device instruction set is in initializing behavior of software loading, communication and the like, the device instruction set sets through zone bit information in the code of system software, and through judging the completion degree of each stage of the software, finally, after all stages are ensured to pass, the device function loading is considered to be completed.
For example: defining a complete service capable of carrying out functional checking and verification on codes, naming the service as lcfunctioncheck, reading a hardware IIC (Inter-INTEGRATED CIRCUIT, bus) path by a system in the process of powering on LCD/TP device hardware, setting a state probe_status as true after equipment is initialized successfully, setting mipi _status as true when the equipment is in communication with LCD hardware when mipi (Mobile Industry Processor Interface ) signals are transmitted, and judging that the two flag bits are true by the service, setting LCD_check as true when the service judges that the two flag bits are true, and executing an adb shell 'lcfunctioncheck lcdcheck' value as PASS after being started.
The Camera part is similar to the above, except that parameters of each Camera and a module loading state para_status are checked when the probe_status and mipi _status are checked, the camera_check is true after the three stages are true, and the adb shell lcfunctioncheck cameracheck value is PASS when an instruction is executed.
In the finger print, besides checking the probe_status state, a self-checking tool of a manufacturer is used to check whether various IIC paths and chip functions of the Fingerprint are normal, and when the finger print_selftest value is true, the instruction adb shell 'lcfunctioncheck fingerprintcheck' is executed as PASS.
The Audio mainly checks that the subsystem is dependent and the sound card is loaded, the adsp _status state is increased to true after the adsp subsystem is loaded successfully, the flag bit soundcard _check is increased to true when the sound card is loaded successfully, the codec_status is true after the codec part code is initialized successfully, and the execution instruction adb shell lcfunctioncheck audiocheck value is PASS.
Each device of the Sensor part comprises three parameters like adsp _status, probe_status and para_status, and when the values are true, the value of the adb shell 'lcfunctioncheck sensorcheck' is PASS.
The basic system instruction set comprises a starting state and abnormal times check of each subsystem, a fuse and signature state check, SYSTEMSERVICE loading check and abnormal times check, APP abnormal times check and the like, wherein the state check thought is to set a value of a flag bit to True to judge after the subsystem is loaded successfully, the abnormal times check is to increase independent variable statistics when corresponding service positions terminate accidentally, and the abnormal times are judged by reading abnormal times of the function check service.
For example: when the starting state of each subsystem is checked, after the adsp, modem, wcnss, tz, rpm subsystem is loaded successfully, setting the states adsp _status, modem_status, wcns_status, tz_status and rpm_status as true respectively, counting the number of subsystems_restart_count when any subsystem is restarted, and recording the names of the subsystems of which the subsystem_restart_type is. The execution instruction adb shell 'lcfunctioncheck subsystemcheck' is PASS, the adb shell 'lcfunctioncheck subsystemrestartcount' is abnormal times, and the adb shell 'lcfunctioncheck subsystemrestarttype' is a list of subsystem abnormal restarting.
SYSTEMSERVICE load and anomaly count checks may implement statistics similar to the subsystem code modification method.
The APP anomaly number checking mainly opens up independent threads to continuously count the number appanr _count and the crash number appcrash _count of anr, and counts the anomaly number through the adb shell lcfunctioncheck appanrcount and the adb shell lcfunctioncheck appcrashcount respectively.
Fuse and signature checking the status of the signature fuse is confirmed by the system's own prop getting the relevant status getprop ro.boot. Fuse state and getprop ro.boot. Secure fuse state.
The long and short distance instruction set comprises functions of WIFI and BT (Bluetooth), firmware loading state, firmware version number, GPS service starting state, diag (diagnostic port) communication state, NV (Non-Volatile Memory) traversal self-checking and the like, and the main thought is that after the firmware or the service is loaded successfully, a success flag bit is set, the diag communication state self-checking is checked through a handshake sent and received by an AT instruction, and the NV traversal self-checking completes self-checking actions through judging key NV values AT the bottom layer.
For example: WIFI and BT add wifi_fwload and bt_ fwload states in the code segment completed by loading firmware, and then add flag bits wifi_status, bt_status and gps_status in the code segment when WIFI, BT, GPS service starting is completed, and the value is true after starting is successful.
Firmware loading query instruction adb shell 'lcfunctioncheck wififirmware' of the WIFI is PASS, and firmware version query instruction adb shell 'lcfunctioncheck wififirmwareversion' of the WIFI is firmware version number. When the communication state of the diag port is inquired, an instruction 'AT' is sent to the diag interface, a return value 'ok' is received, and the communication state diag_status is judged to be true, and the value of the inquiry instruction adb shell 'lcfunctioncheck diagstatus' is PASS.
The NV self-test is to read key values of 550, 560, 4678 and the like configured in the service and then compare the key values with expected results to obtain a result of the NV self-test. The query instruction adb shell "lcfunctioncheck nvselfcheck" is a PASS.
The power supply PMIC system instruction set comprises a charging IC state check, a charging protocol check, a battery characteristic state check, OTG, USB, SDcard, SIM card function check and the like, wherein a main idea of the charging IC check is to add a flag bit in the starting state process, the charging protocol and the battery characteristic state are to read the existing node value and an expected value for matching judgment, the OTG, USB, SDcard, SIM card is used for simulating to trigger one-time interruption, and whether the function is normal is checked.
For example: when the state of the charging IC is checked, IIC communication is carried out when a kernel is started, an IIC address is read after successful communication to identify the type of the charging IC, ic_status is set to true when the IC designated by an item is identified, a designated register address is set to judge that the state ic_reg_status of the charging IC is correct to true, and when both are true, the value of adb shell lcfunctioncheck chargericstatus is PASS.
The charging protocol is mainly a charging protocol used in a test, and is a DCP protocol, the current charging protocol can be read through a system interface and automatically matched with the DCP, meanwhile, a current value is obtained, whether the current value is smaller than 500mA is confirmed, a value of charger_dcp_check is true, and an adb shell 'lcfunctioncheck chargerdcpcheck' value is PASS when the charging protocol is queried by a command.
The battery characteristic status check mainly confirms that all the battery attributes can be read and within the required range, and can be read through the standard interface in the following paths: "/sys/class/power_supply/battery", which contains information such as battery resistance, battery power, battery voltage, battery current, and battery temperature, can be read and then can be judged with a preset value, and an instruction adb shell "lcfunctioncheck batterycheck" which has all the readable attributes and can check the battery state in the range is PASS.
The OTG, USB, SDCard, SIM card implementation mode triggers an interrupt for software simulation, assigns an analog peripheral attribute to the interrupt, and finally loads the integrated software successfully with insert_status as true, thereby judging whether the basic function of the whole software part module is normal.
The large system instruction set mainly comprises the functions of system startup time monitoring, startup memory monitoring, shutdown restarting anomaly statistics, system power consumption statistics and the like, the startup time and the startup memory are monitored by judging the threshold value of each process after the system startup through dotting each stage of the system startup memory, the restarting anomaly statistics of the system is used for counting, and the power consumption difference change is monitored by using the statistics of the startup running period electric quantity.
For example: when the starting time monitoring is carried out, the following stages are split, namely ps_hold pulling up, UEFI starting, bootloader starting, kernel starting, SYSTEMSERVER starting and Launcher starting are triggered by pressing a power key, a marker bit is set in each stage through the data dotting of the stages, the current time system is acquired, and ps_hold_time, uefi_ time, bootloader _time, kernel_time, system_time and app_laboratory_time are obtained, so that the time consumption of each stage can be calculated through time difference, and the time consumption condition of the starting time in the project process can be monitored.
The method mainly comprises the steps of reading all processes after starting up through a service, recording, matching with a configurable process name and a process memory size, and identifying a newly added process and a process with a process exceeding a standard, so that daily monitoring of the memory after starting up is realized.
Shutdown restarting exception statistics is mainly performed through an exception statistics data command of a system self: "adb shell getprop sys. Boot. Reflection", the number of times and the reason of the abnormal restart can be read.
The system power consumption statistics mainly includes that after a charging function is disabled, reading/sys/class/power_supply/battery/current_now every 1 second for 1 minute, summing up 60 values, and obtaining an average value Cage by cage= Σ (c 1, c2 … c 60)/60, so that standby power consumption at the moment is obtained.
Other function instruction sets comprise various instructions which can be customized by themselves, can be used for reading more system function checks, and can be put into lcfunctioncheck service by packaging and outputting judgment results of system adb shell getprop xxx and adb shell cat xxx.
Further, in the process of executing the test instruction row by row, the computer end only fills the test return value into the corresponding position of the configuration file table, namely only carries out data backfilling operation, and does not judge the test result.
Therefore, in step S500, it is necessary to compare each test return value with the expected value to determine the test result of each test instruction, and feed back the failure term of the test result of each test instruction to the relevant developer.
For example: the first row of test instruction is adb shell 'getprop ro.ril.oem.sno', the test return value is XB332L000534, the corresponding row of explanation columns is YC222L000555, and since the test return value is inconsistent with the expected value, the corresponding row of testResult columns is marked as Fail, which indicates that the test result of the test instruction is Fail and is a failure item.
For a test instruction with a test result of Fail, testOwner information of the test instruction is read, a corresponding module responsible person is obtained, the module responsible person corresponding to the test instruction of the failure item is informed of the test result through mail or other instant messaging tools, and self-checking is carried out by the module responsible person.
In step S600, the failure term of the test result of each test instruction is scored, and the scores of the failure terms are accumulated and compared with the set standard to determine the issue result.
Specifically, if the score accumulation of the failed item is smaller than the set standard, the system software version file is released, and if the score accumulation of the failed item is smaller than the set standard, the system software version file is not released.
For example: testPriority is the test instruction level of the table in the configuration file, and can be divided into Blocker, critical, major, minor levels, and the corresponding scores are 10 points, 3 points, 1 point and 0.1 point respectively.
Among these, the four levels described above are classification schemes for problem or defect management, and the problem of the Blocker level is so serious that normal progress of the project or realization of critical functions is prevented, and it is generally required to be immediately solved to ensure that the project can proceed.
Critical level issues have a significant impact on functionality or performance, but the system can still operate in some form, while not impeding project progress, but negatively impacting user experience or business processes.
The problem of the Major level has obvious influence on the function or the performance, but does not influence the core business flow, which may influence the user experience, but the system can still operate normally, and the problem of the Major level can be arranged to be solved in project progress.
Minor-level problems have a slight impact on the user experience, but do not affect the functionality or performance, it does not typically affect the core business process, and therefore can be handled at a lower priority, and Minor-level problems may be resolved in subsequent iterations or version updates.
For example, the first row of instruction adb shell "getprop ro.ril.oem.sno" is an SN number of the verification handset, and this instruction is an optional item, and may be defined as Minor class 0.1 score through research and development evaluation; the second row of instruction adb shell funtest startapp is an instruction for opening the APP, is optional but important, and can be defined as Major class 1 score through research and development evaluation; the problem of important functional class which can allow the subsequent solution can be defined as Critical class 3; problems related to basic functions such as camera inactivity, no sound, test application flash back, etc. blocking factory production or development and debugging are defined as the Blocker class 10.
After the results of all the test instructions come out, accumulating the scores of testPriority values corresponding to the Fail items, comparing the total score value with a set standard established in the earlier stage of research and development, wherein a value smaller than the set standard is a system software version file which can be issued, a value larger than the set standard is a system software version file which cannot be issued, and then notifying the project wholesaler of the test report and the conclusion about whether the test report can be issued.
Of course, the release standards of different production stage software are inconsistent, for example, in the P0 stage, the total value of the score is <15 time-sharing release, in the P1 stage, the total value of the score is <10 time-sharing release, and in the P2 stage, the total value of the score is <1 time-sharing release. The above distribution criteria are merely illustrative, and other distribution criteria may be set.
The automatic verification method for the mobile phone production system software can improve the efficiency and timeliness of function verification of the mobile phone production system software, improve the accuracy of the mobile phone production system software version, and can also be used for checking whether the devices and functions are degenerated or abnormal after the hardware equipment is used for a long time.
In addition, based on the customization of the bottom layer of the driving code, the self-defined service capable of carrying out functional inspection and verification on the code is matched, the bottom layer code can be monitored, personalized functional inspection is more met, testing is carried out from bottom layer code fragments, and the accuracy of a test result are improved. Based on the service which can carry out functional inspection and verification on the codes and is customized, the mobile phone is automatically inspected after being started, the probability abnormality of the equipment is inspected every time, and the positioning of the probability problem is facilitated according to the inspection result.
An embodiment of the second aspect of the invention provides an automatic verification system for mobile phone production system software.
The automatic verification system of the mobile phone production system software of the embodiment of the aspect comprises:
the file acquisition unit is used for acquiring a system software version file;
the system comprises a mobile phone, a system software version file and a system software version file;
the matching unit is used for reading the mobile phone configuration information and matching the mobile phone instruction configuration file;
the analysis and transmission unit is used for analyzing the mobile phone instruction configuration file to generate a test instruction and transmitting the test instruction to the mobile phone;
the analysis unit is used for analyzing the test return value of each test instruction so as to determine the test result of each test instruction and feed back the test result to related personnel;
And the report generating unit is used for judging the version issuable conclusion according to the test result and outputting a test report.
The batch execution, result judgment and version release result confirmation of the test instructions can be automatically realized, so that the time for researching and developing manual test and the risk of missing test errors are greatly reduced, the manpower for research and development and the manpower for test are reduced, the efficiency and timeliness of functional verification of the mobile phone production system software are improved, and the accuracy of the mobile phone production system software version is also improved.
In addition, the automatic verification system of the mobile phone production system software of the embodiment can also be used for checking whether the devices and functions of the hardware equipment are degraded or abnormal after long-time use.
It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.