CN100363906C - Method for testing software unit - Google Patents
Method for testing software unit Download PDFInfo
- Publication number
- CN100363906C CN100363906C CNB2006100580322A CN200610058032A CN100363906C CN 100363906 C CN100363906 C CN 100363906C CN B2006100580322 A CNB2006100580322 A CN B2006100580322A CN 200610058032 A CN200610058032 A CN 200610058032A CN 100363906 C CN100363906 C CN 100363906C
- Authority
- CN
- China
- Prior art keywords
- test
- script
- function
- unit
- unit under
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The present invention relates to a software unit testing method which comprises the steps: step 1, a driving script is used for triggering a main function to run, and a program is controlled to run to the starting position of a driving function, wherein the driving function is called by the main function; step 2, a testing script is used for triggering the driving function to run, and a unit which is tested is called and executed in the driving function. The test of the program which is tested is controlled from the outer part by compiling and executing the scripts which comprise the driving script and the testing script. Because the testing script substitutes for the original testing program, the script is physically separated from the source program, and the script and the source program are not compiled together. Thus, when the present invention is used for testing, only the script needs to be changed, and the source program does not need to be modified.
Description
Technical field
The present invention relates to software testing technology, particularly relate to a kind of test method of software unit.
Background technology
Unit testing is the test towards the function level, and in the dsp software performance history, how to carry out unit testing effectively is a problem of making us the ten minutes headache always.Different with other development environment, dsp software does not have special automated test tool available, therefore, the dsp software unit test method that generally adopts generally is to write test procedure at present, it is compiled, loads with tested program, and whether manual single step carries out the observation test result correct.
Fig. 1 carries out schematic flow sheet for existing unit test method.
Below will consult Fig. 1 existing unit detecting method will be described.Owing to still there is not suitable automated test tool, therefore the unit test method of dsp software can only carry out one by one at test case at present, the steps include:
Write test procedure, the test procedure here comprises driving function, pile function and test case;
Test condition and observation station are set;
Test procedure is compiled, loads with tested program;
Manual single step is carried out and the observation test result.
Source program need be recompilated and load to the modification of test case, and in most cases, need to revise source program.Source program wherein comprises test procedure and tested program, and tested program comprises the unit under test that all need be tested.
Obviously, this method of testing has the defective of following several aspects at least:
1. can not be in batches and robotization, every test case all must be carried out under manual intervention, and is both inconvenient, wasted a large amount of quality time again.Especially under the more situation of test case, test duration and effect all can not get guaranteeing;
2. need constantly to write and revise driving function in the test process, and each modification all needs to recompilate and load source program, and various variablees are set, efficient is very low;
3. tested program compiles, loads with test procedure, is unfavorable for the management of version, causes the version confusion easily;
4. regression test difficulty, repeatable poor.
On the other hand, DSP is one of chip the most frequently used in the communication facilities, dsp software is ubiquitous in whole communication software, therefore how to realize automatic test on DSP, how to improve the repeatability of test, has unusual meaning for the software quality that ensures and promote on the DSP.
Summary of the invention
The objective of the invention is to, a kind of test method of software unit is provided, from the program outside test of unit under test is controlled, realize automatic test by test script and driving script.
Test method of software unit of the present invention may further comprise the steps:
Step 1 drives script and triggers the principal function operation, and control program runs to the section start of driving function, and wherein driving function is called by principal function;
Step 2, test script triggers the driving function operation, input parameter passed to unit under test in driving function and call the execution unit under test under prerequisite, wherein, required described prerequisite and the input parameter of test case sets in advance in test script.
Described prerequisite that described test case is required and input parameter comprise the output of value, input parameter and the pile function of each global variable that function relates to.
In above-mentioned steps two, under prerequisite, call and further export the unit under test execution result after carrying out unit under test.
In above-mentioned steps two, comprise that further the test script control program runs to the test case end-tag place that sets in advance.
Further comprise after above-mentioned steps two: step 3, this test case is finished, and is exported the execution result of this test case by test script.
Further comprise after the step 3 of said method: step 4, test script judge whether that in addition test case needs test, if having then turn back to step 2, otherwise finish test.
In addition, the array of the unit under test function pointer and the storage input parameter of the overall situation is set further in the test script, driving function is finished unit under test call execution under prerequisite by calling the unit under test function pointer in step 2.
In addition, before the step 1 of said method, further comprise script is carried out initialized step.
Compared with prior art, the invention has the beneficial effects as follows: the present invention is by writing and carry out script (driving script and test script), test from the outside to tested program is controlled, because this method has replaced original test procedure with test script, and script physically separates with source program, both compilings of being not together only relate to the change of script when therefore testing, need not to revise source program.
Description of drawings
Fig. 1 is the process flow diagram of existing unit detecting method.
Process flow diagram when Fig. 2 carries out the test of the single test case of single unit under test for test method of software unit of the present invention.
Process flow diagram when Fig. 3 carries out the test of a plurality of test cases of single unit under test for test method of software unit of the present invention.
Process flow diagram when Fig. 4 carries out the test of a plurality of test cases of a plurality of unit under tests for test method of software unit of the present invention.
Embodiment
The invention provides a kind of method that can on dsp chip, carry out the software unit automatic test, the script that it utilizes DSP to support is realized, by writing and carry out script, under the situation of not changing source program, program run outside sheet in the control strip, obtain test result, thereby reach the purpose of automatic test." program " mentioned among the present invention is meant the compiling link result of source program, and it is loaded into DSP the most at last and goes up execution.
Illustrate that below with reference to drawings and the specific embodiments the present invention utilizes script to realize the method for the automatic test of software unit.
Embodiment 1
[test of the single use-case of single unit under test]
As shown in Figure 2, at first consider situation the simplest, that the single use-case of single unit under test is tested.For the test of the single use-case of single unit under test, its process is:
Step 11 is at first carried out script initialization (this step is not necessarily depended on concrete script);
Step 12 drives script and triggers principal function (Main) operation, and control program runs to driving function (DriverFunc) section start, and wherein driving function is called by principal function;
Step 13, test script triggers the driving function operation, in driving function, at first input parameter is passed to unit under test, finish unit under test then and under prerequisite, call execution, export the unit under test execution result at last, the test script control program runs to the position that test case finishes (TestFuncover) label.Wherein, this prerequisite and input parameter set in advance in test script, are test case conditions needed and parameter, comprise the output etc. of value, input parameter and the pile function of each global variable that function relates to;
Step 14, test case is finished, and is exported the execution result of this test case by test script.
Because the direct global variable in the access program in script, therefore in the said process needed prerequisite of test case and input parameter and step 14 being set is easy to realize, and step 12 and 13 can realize with the corresponding command that script provides, for convenience, we suppose that this order is Proc_Goto here.If there is not the order that can directly use, also can customize very easily, as long as the label of script in can recognizer, and can be parked in the label place of any appointment.For general script, these two conditions all satisfy.This need customize similar following driving function in source program:
void?DriveFunc(void)
{
unsigned?int?Result；
/ * execution unit under test */
Result=Func1 (gPara1, gPara2); // supposition unit under test prototype be unsigned int Func1 (int Para1,
//int?Para2)；
//gPara1 and gPara2 are two global variables of int type, are used to Func1
// transmit parameter, in step 13, set with the use-case prerequisite
/ * output execution result */
LOG_printf(trace，“Func?Exec?Result:％u”，Result)；
/ * is provided with label, each use-case be finished promptly stop the * of this label place/
asm(″TestFuncOver:″)；
}
Test script then can followingly be write:
The test case of DebugFunc1All ()/Func1
{
Proc_Goto (Main); // obtain driving in order to make tested program, at source program main function call driving function
//DriveFunc, if desired, the front should also comprise the initialization of script, omits herein
Proc_Goto (DriveFunc); // carry out the driving function reference position
/***********************test?case1***********************/
/ * is provided with the prerequisite of test case 1 herein, comprise input parameter */
……
Proc_Goto (TestFuncOver); // begin to carry out from the driving function reference position, up to finding sign TestFuncOver
// till, carry out this, use-case 1 executed of unit under test finishes
/ * output test result herein */
……
}
During test, only need to carry out script function DebugFunc1All, then the test case 1 of unit under test Func1 obtains carrying out.
Embodiment 2
[tests of a plurality of test cases of single unit under test]
The test of a plurality of test cases of single unit under test is described as shown in Figure 3.For the test of a plurality of test cases of single unit under test, its process is:
Step 21 is at first carried out the script initialization;
Step 22 drives script and triggers the principal function operation, and control program runs to the section start of driving function, and wherein, driving function is called by principal function;
Step 23, test script triggers the driving function operation, in driving function, at first input parameter is passed to unit under test, finish unit under test then and under prerequisite, call execution, export the unit under test execution result at last, and the test script control program runs to the position of test case end-tag.Wherein, this prerequisite and input parameter set in advance in test script, are test case conditions needed and parameter, comprise the output etc. of value, function input parameter and the pile function of each global variable that function relates to;
Step 24, this test case is finished, and is exported the execution result of this test case by test script;
Step 25, test script judge whether that in addition test case needs test, if having then turn back to step 23, otherwise finish test.
Because the direct global variable in the access program in script, therefore in the said process needed prerequisite of test case and input parameter and step 24 are set and are easy to realize, and step 23 can realize with the corresponding command that script provides.Situation for a plurality of test cases, for can automatic test and need not to reload program, then driving function must guarantee can get back to automatically after previous use-case executes the unit under test place that is called, and this can realize by a circulation is set in driving function.
This need customize similar following driving function in source program:
void?DriveFunc(void)
{
unsigned?int?Result；
for(；；)
{
/ * execution unit under test */
Result=Func1 (gPara1, gPara2); // supposition unit under test prototype is unsigned int Func1 (int
//Para1，int?Para2)；
//gPara1 and gPara2 are two global variables of int type, are used to Func1
// transmit parameter, in step 23, set with the use-case prerequisite
/ * output execution result */
LOG_printf(trace，“Func?Exec?Result:％u”，Result)；
/ * is provided with label, each use-case be finished promptly stop the * of this label place/
asm(″TestFuncOver:″)；
}
}
The test script of a plurality of test cases then can be written as:
DebugFunclAll () // hot key is set for the test case of Func1
{
Proc_Goto (Main); // obtain driving in order to make tested program, at source program main function call driving function
//DriveFunc, if desired, the front should also comprise the initialization of script, omits herein
Proc_Goto (DriveFunc); // carry out the driving function reference position
/***********************test?case1***********************/
/ * is provided with the prerequisite of test case 1 herein, comprise input parameter */
……
Proc_Goto (TestFuncOver); // begin to carry out from the driving function reference position, up to finding sign TestFuncOver
// till.Carry out this, use-case 1 executed of unit under test finishes
/ * export herein the test result * of use-case 1/
……
/***********************test?case2***********************/
/ * is provided with the prerequisite of test case 2 herein, comprise input parameter */
Proc_Goto (TestFuncOver); // begin to carry out from sign TestFuncOver position, up to picking up this sign
// till.Carry out this, use-case 2 executeds of unit under test finish
/ * export herein the test result * of use-case 2/
Other test case of //Func1
}
At this moment, in case carry out script function DebugFunc1All, then all test cases of Func1 all obtain carrying out.
Embodiment 3
[tests of a plurality of unit under tests]
The test of a plurality of unit under tests is described as shown in Figure 4.For the test of a plurality of unit under tests, its process is:
Step 31 is at first carried out the script initialization;
Step 32 drives script and triggers the principal function operation, and control program runs to the driving function section start, and wherein, driving function is called by principal function;
Step 33, test script triggers the driving function operation, finish unit under test call execution under prerequisite by calling the unit under test function pointer in driving function, and export tested function execution result, the test script control program runs to the position of test case end-tag.Wherein, this prerequisite and input parameter set in advance in test script, are test case conditions needed and parameter, comprise the output etc. of value, function input parameter and the pile function of each global variable that function relates to;
Step 34, this test case is finished, and is exported the execution result of this test case by test script;
Step 35, test script judge whether that in addition test case needs test, if having then turn back to step 33, otherwise finish test.
From top process as can be seen, under the situation of a plurality of unit under tests, because the prototype (function name, number of parameters and type, rreturn value type) of each unit under test has nothing in common with each other, therefore, in order to make driving function can be applicable to each unit under test, realize wherein calling of unit under test being changed into by function pointer, promptly can customize the array (parameter array) of following overall situation function pointer and storage input parameter:
/ * function pointer */
int(*gpFuncPointer)(int?Para0，int?Para1，int?Para2，
int?Para3，int?Para4，int?Para5，
Int Para6, int Para7); The input parameter number of all unit under tests of // supposition
// be no more than 8, certainly, this value can be revised
/ * function input parameter */
Int gFuncPara[8]; // same, this array length should be not less than the maximum input parameter number of unit under test
And driving function can followingly be write:
void?DriveFunc(void)
{
unsigned?int?Result；
The unit under test of appointment in the script is carried out in/* circulation, every circulation primary be equivalent to carry out a use-case */
for(；；)
{
/ * execution unit under test */
Result＝(*gpFuncPointer)(gFuncPara[0]，gFuncPara[1]，
gFuncPara[2]，gFuncPara[3]，
gFuncPara[4]，gFuncPara[5]，
gFuncPara[6]，gFuncPara[7])；
/ * output execution result */
LOG_printf(trace，“Func?Exec?Result:％d”，Result)；
/ * is provided with label, each use-case be finished promptly stop the * of this label place/
asm(″TestFuncOver:″)；
}
}
In test script, when needs are tested some unit under tests, its function name need be composed to overall situation function pointer gpFuncPointer, and its desired parameters is set.For convenience, this operation can be packaged into following script function:
Proc_RunFunc(FuncName，Para0，Para1，Para2，Para3，Para4，Para5，Para6，Para7)
{
/ * be provided with function input parameter */
gFuncPara[0]＝Para0；
gFuncPara[1]＝Para1；
gFuncPara[2]＝Para2；
gFuncPara[3]＝Para3；
gFuncPara[4]＝Para4；
gFuncPara[5]＝Para5；
gFuncPara[6]＝Para6；
gFuncPara[7]＝?Para7；
/ * be provided with function pointer */
gpFuncPointer＝FuncName；
/ * operation function */
Proc_Goto(TestFuncOver)；
}
And customize following driving script:
Proc_DebugInit () // unit testing drives script function
{
/ * script initialization */
……
/ * driver operation */
Proc_Goto (main); Call driving function DriveFunc in the //main function
Proc_Goto (DriveFunc); // program is driven, and waits for the use-case execution
}
Like this, DSP automated test tool just customization finishes, it comprises a testing engineering that drives on script and the DSP, here, described driving script comprises Proc_DebugInit and two script function of Proc_RunFunc of front, testing engineering on the described DSP comprises principal function main and driving function DriveFunc, and the necessary configuration file of some other DSP engineering etc.The tester only needs all unit under tests and pile function adding engineering are also compiled together, link, load when carrying out unit testing, and the script of implementation of test cases gets final product successively then.And the common version of test script is as follows:
DebugFunc_x () //test case of Func_X, general recommendations is each unit under test customization
// one script function comprises all test cases of this unit under test
{
/***********************test?case1***********************/
/ * is provided with the prerequisite of test case 1, comprise input parameter */
……
/ * execution use-case 1*/
Proc_RunFunc (Func_x, input parameter 1, input parameter 2 ..., input parameter n);
/ * export herein the test result * of use-case 1/
……
/***********************test?case2***********************/
/ * is provided with the prerequisite of test case 2, comprise input parameter */
……
/ * execution use-case 2*/
Proc_RunFunc (Func_x, input parameter 1, input parameter 2 ..., input parameter n);
/ * export herein the test result * of use-case 2/
……
Other test case of //Func_x
}
As can be seen from the above, the core of method of testing of the present invention is: utilize directly some characteristics such as access program internal data of script, realize the variation and the input parameter transmission of unit under test by overall situation function pointer and array, at the unified driving function of source program interior customization call function pointer incessantly, externally then customize unified script unit under test and input parameter thereof are set, and drive inner once circulation of driving function execution.
Thereby, to compare with existing method of testing, this method of testing has the following advantages:
1. owing to adopt unified driving function and drive script, test case can continuously be carried out, and program run is controlled by outside test script, need not manual intervention, thereby test automation is achieved;
2. source program need not be revised in the test process, the linked source program need not be recompilated even the program of need not reloading just can make the variable that uses in the program or the content of internal memory or even program itself change, and move according to amended mode, thereby test at once more convenient, efficient is also higher;
3. certain functional unit of test procedure or when verifying certain function items, only need to compile one section test script and get final product, and test script and source program itself separate physically fully, can revise separately, preserve, thereby when source program is changed, return and also just become very simple;
4. use this technology, can reduce all kinds of problems that cause because of version management is improper, because test process need not be revised source program itself, the modification of test case can get final product by revising test script file fully, thereby can reduce a plurality of intermediate releases and the confusion that causes.
Dsp chip for different company, the script that they are supported may have nothing in common with each other, but in the past in the face of in the description of automated testing method as can be seen, as long as the type DSP and compiling debugging enironment thereof can solve following several respects problem, then this method of testing also is suitable for:
1. support to be independent of the script of source program, and can utilize script program to be applied excitation, be provided with and fetch program built-in variable, setting program startup/stop position etc. from the outside.This condition can be provided with the required prerequisite of unit under test when making test in script, driver begins to carry out from appointed positions (unit under test section start), and stop at another assigned address (global flag in the driving function), by fetch program built-in variable in script, output test result then;
2. support the variable function parameter transmission of number.This condition makes that different unit under tests can shared same general purpose function pointer, and then shared same driving function, and need not to customize driving function separately for each unit under test.
The present invention is not limited to the foregoing description, and those those of ordinary skills should drop within the claim of the present invention scope required for protection by reading behind the application simple modification, modification or equivalent that the present invention made.
Claims (9)
1. test method of software unit is characterized in that: by driving script and test script, from the program outside test of tested program is controlled, this method may further comprise the steps:
Step 1 drives script and triggers the principal function operation, and control program runs to the section start of driving function, and wherein driving function is called by principal function;
Step 2, test script triggers the driving function operation, input parameter passed to unit under test in driving function and call the execution unit under test under prerequisite, wherein, required described prerequisite and the input parameter of test case sets in advance in test script.
2. test method of software unit as claimed in claim 1 is characterized in that, described prerequisite that described test case is required and input parameter comprise the output of value, input parameter and the pile function of each global variable that function relates to.
3. test method of software unit as claimed in claim 1 is characterized in that, in step 2, calls under prerequisite and further exports the unit under test execution result after carrying out unit under test.
4. test method of software unit as claimed in claim 1 is characterized in that: in step 2, call under prerequisite and further comprise after carrying out unit under test:
The test script control program runs to the test case end-tag place that sets in advance.
5. test method of software unit as claimed in claim 3 is characterized in that: in step 2, further comprise after output unit under test execution result:
The test script control program runs to the test case end-tag place that sets in advance.
6. as each described test method of software unit of claim 1 to 5, it is characterized in that this method further comprises after step 2:
Step 3, this test case is finished, and is exported the execution result of this test case by test script.
7. test method of software unit as claimed in claim 6 is characterized in that, this method further comprises after step 3:
Step 4, test script judge whether that in addition test case needs test, if having then turn back to step 2, otherwise finish test.
8. test method of software unit as claimed in claim 7, it is characterized in that, the array of the unit under test function pointer and the storage input parameter of the overall situation further is set in the test script, and driving function is finished unit under test call execution under prerequisite by calling the unit under test function pointer in step 2.
9. test method of software unit as claimed in claim 1 is characterized in that, further comprises before the step 1 script is carried out initialized step.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100580322A CN100363906C (en) | 2006-02-28 | 2006-02-28 | Method for testing software unit |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100580322A CN100363906C (en) | 2006-02-28 | 2006-02-28 | Method for testing software unit |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1862511A CN1862511A (en) | 2006-11-15 |
| CN100363906C true CN100363906C (en) | 2008-01-23 |
Family
ID=37389945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2006100580322A Expired - Fee Related CN100363906C (en) | 2006-02-28 | 2006-02-28 | Method for testing software unit |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100363906C (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101267645B (en) * | 2008-02-29 | 2011-03-02 | 中兴通讯股份有限公司 | Automatic test method and system for service flow software development of W base station |
| CN103092750A (en) * | 2012-11-13 | 2013-05-08 | 瑞斯康达科技发展股份有限公司 | Unit testing method and device |
| CN104050081B (en) * | 2014-06-09 | 2017-09-12 | 汉柏科技有限公司 | The method and system of the static built-in function of debugging |
| CN105808421A (en) * | 2014-12-31 | 2016-07-27 | 中兴通讯股份有限公司 | White box test realization method and test control end |
| CN104698368B (en) * | 2015-04-01 | 2017-11-10 | 山东华芯半导体有限公司 | A kind of method realized chip top-layer test case and reused |
| CN107168870B (en) * | 2017-04-28 | 2021-10-29 | 福建星瑞格软件有限公司 | Method for acquiring program information during operation |
| CN112199270B (en) * | 2019-07-08 | 2024-02-27 | 腾讯科技（深圳）有限公司 | Program testing method, device, equipment and medium |
| CN111913888A (en) * | 2020-09-09 | 2020-11-10 | 中移（杭州）信息技术有限公司 | Function generation method, automatic test method, electronic device, and storage medium |
| CN117171053B (en) * | 2023-11-01 | 2024-02-20 | 睿思芯科(深圳)技术有限公司 | Test method, system and related equipment for vectorized programming |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6463552B1 (en) * | 1998-12-07 | 2002-10-08 | Lsi Logic Corporation | Scripting method and apparatus for testing devices |
| CN1499374A (en) * | 2002-11-04 | 2004-05-26 | 华为技术有限公司 | Automatic approach for unit testing |
| CN1534905A (en) * | 2003-03-31 | 2004-10-06 | 华为技术有限公司 | Intelligent business testing method based on structural unit |
| CN1632747A (en) * | 2003-12-22 | 2005-06-29 | 联想(北京)有限公司 | Software interface testing method |
| CN1641601A (en) * | 2004-01-04 | 2005-07-20 | 华为技术有限公司 | Software unit measuring method |
-
2006
- 2006-02-28 CN CNB2006100580322A patent/CN100363906C/en not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6463552B1 (en) * | 1998-12-07 | 2002-10-08 | Lsi Logic Corporation | Scripting method and apparatus for testing devices |
| CN1499374A (en) * | 2002-11-04 | 2004-05-26 | 华为技术有限公司 | Automatic approach for unit testing |
| CN1534905A (en) * | 2003-03-31 | 2004-10-06 | 华为技术有限公司 | Intelligent business testing method based on structural unit |
| CN1632747A (en) * | 2003-12-22 | 2005-06-29 | 联想(北京)有限公司 | Software interface testing method |
| CN1641601A (en) * | 2004-01-04 | 2005-07-20 | 华为技术有限公司 | Software unit measuring method |
Non-Patent Citations (1)
| Title |
|---|
| 基于XML描述的类测试框架. 李亚辉，吴宇红，陈琳.微机发展，第15卷第8期. 2005 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1862511A (en) | 2006-11-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100363906C (en) | Method for testing software unit | |
| CN103064403B (en) | A kind of ECU hardware-in-loop simulation automated testing method and system | |
| CN109213680B (en) | Automatic testing method based on embedded software simulator | |
| US9678867B2 (en) | Method for changing the software in the memory of an electronic control unit | |
| CN103309800A (en) | Automatic webpage testing method and system | |
| US7853927B2 (en) | Methods and tools for executing and tracing user-specified kernel instructions | |
| CN110908894B (en) | Visual report tool automatic testing method and device based on vuex | |
| CN108182078B (en) | Optimized missile-borne device non-dismantling software online upgrading method | |
| CN112068530A (en) | ECU (electronic control Unit) automatic testing method, system, storage medium and device | |
| CN100456260C (en) | Interpreter language debugging method and device | |
| CN109002331A (en) | Starting method, apparatus, computer equipment and the storage medium of touch screen | |
| US20050015749A1 (en) | Multiprocessor application interface requiring no utilization of a multiprocessor operating system | |
| CN109460359A (en) | A kind of software version test method and system for embedded device | |
| US9600397B2 (en) | Dynamic debugging method of a software module and corresponding device | |
| CN106528217B (en) | on-site programmable gate array program loading system and method | |
| CN113590491B (en) | Test platform and product test method | |
| CN114924737A (en) | Battery management system source code integration test method and device and electronic equipment | |
| US7640421B1 (en) | Method and system for determining context switch state | |
| US20040177344A1 (en) | Debugging method for the keyboard controller code | |
| CN110018953A (en) | Use method, storage medium, equipment and the system of python test JS code | |
| US20020169997A1 (en) | BIOS debug method | |
| CN101751492A (en) | Micro-controller and simulation system thereof | |
| US7636869B2 (en) | Program dynamically burnt system and method | |
| CN113672505A (en) | Multi-terminal interactive automatic regression testing method | |
| CN117251298B (en) | Pipeline task cyclic execution method, system, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080123 |