Some specific practices for software test automation
The author talked about the automation of software testing slightly, but did not write in this article. The reason is mainly, I hope the reader first tries to consider how much doctors can have some practices, but will lead to the main embodiment of the specific example I have written. Thinking.
Because the software test has a large workload (40% to 60% of the total development time), it is very suitable for automation. Therefore, the testing improvement will have very significant results of the quality, cost and cycle of the entire development. Effect. First, talk about the design problem of test cases with graphical interfaces in the case of testing automation. Because the output display of the graphical interface is not easy to do to test the test results automation, the general practice is to establish a test case with the portion output from the graphical interface to manually run. All non-graphics outputs can be automated. Some examples of test automation are mentioned below: 1. Test case (TEST CASE, or test case): a small program is written in a programming language or more convenient script language (script language, such as Perl, etc.) to generate a large number of programs Test input (including input data and operational instructions). Or also generate standard output at a certain logic law. The input and output file name is paired in accordance with the specified, so that the procedure for automated testing and results is easy to operate. Here is a naming problem for test cases. If you make a unified planning in the project's documentation, the demand and function of software products should be a naming basis for the middle product of the subsequent development process. In this way, it will bring great convenience to document management and configuration management, making the development process of the entire product more organized and more logical. Any novice will also be easier to enter the development of the development work. 2. Perform write control of the test: Unit test or integrated tests may run multiple stand-alone. But for system testing or regression testing, it is possible to run multiple sets of machines to run simultaneously on the network. Remember such a principle, at any time during the development process, if you need to wait for the results of the test, it is a chance to shorten the development time. For a single test run, the chance to dig the potential in the test and the comparison and display of starting operations and results. Sometimes, you need to repeatedly modify the program, re-assemble and retest. In this way, each looped manual setting is very considerable to the time spent on the instruction. If you can help with Make or similar software tools, you can save a lot of time. For system testing or regression testing such a situation involving a large number of test cases, the opportunity to dig the dive is except for the use of software tools to achieve automation, how to make full use of all hardware resources. Often, even in the daytime work time, the load of each computer is not fully utilized. It is possible to save a large number of test cases to each machine and save a lot of time. In addition, the large number of system tests and regression tests are arranged to run at night and weekend, which can improve efficiency. If you don't buy a commercial tool, you should comply with regular software development requirements to develop a good software test automation tool. In practice, many automation tools developed by the company are constructed using some ready-made software tools to add their own procedures. These tools that have been developed are all tailored for the company, so it is very good. At the same time, improvements can be improved as needed without being subject to people. Of course, this requires a certain amount of human investment. When designing software automatic test tools, path control is a very important feature. The ideal use is: This tool can be run on any path location, can go to any path location to get the test case, and can also put the results of the test to any path position. Such a design allows you to operate different tests without interference with each other, or you can flexibly use the space of your hard drive, and make the backup save work is easy to control.
At the same time, software automatic test tools must be able to easily select all or part of the test case library to run, and must also be able to freely select the test-tested product or intermediate product as a test object. 3. Comparison of test results and standard output: When designing test cases, how to make it easy for this test results and standard output. The amount of output data and the data format have a direct impact on the speed of comparison. On the other hand, it is also necessary to take into account the logical correspondence and readability of the test target of the output data and test cases, which will greatly facilitate the analysis of the discovery of the analysis test, which is also conducive to the maintenance of test cases. Many times, you have to write some special software to perform a comparison of test results and standard output, because some output content may not be directly contrast (for example, records for running date time, record of running path, And the version data of the test object, etc.), you have to use the program. 4. Analysis, Classification, Record, and Notification of the test results of the unconventional test: The special software used to compare the test results and standard outputs, and often also analyzes the test results of the unachable test. Tasks for classifying, recording, and notification. "Analysis" is the possibility of finding a place where it is not anastomotive and pointed out. "Classification" includes a variety of statistical subsections, such as the location of the corresponding source program, the severity level of the error (prompt, warning, non-invalidation error, invalidation error; or other classification method), new discoveries still There is a recorded error, and so on. "Record" is filed by classification. "Notification" is an error message that actively on the "person in charge" of the test case. Here is the concept of the "person in charge" of the test case. It is used to specify the defects found when the test case is run, which developers are responsible for analyzing (sometimes the error caused by defects introduced by additional developers) and repair. When setting up a test case library, the various examples should have a designated person. The most direct notification method is to send an email from the automatic test software to the test operator and test case. The details of the email content can be flexible as needed. 5. Statistics of the total test status, the generation of reports: These are the functions whose automatic test tool. The aim is to improve the quality of process management while saving time for generating statistics. Statistical reports produced, it is best to store it to a conventional path location so that any personnel know how to check. At the same time, the statistical report can be sent to the appropriate object (such as project manager, test manager and quality assurance manager) as needed. 6. Automatic testing and development of product daily build (Build): Automatic testing should be an organic part of the entire development process. Automatic testing To rely on configuration management to provide a well-running environment, it must be closely fitted to the build of software in the development. When the product in the development reaches a certain extent, you should start a daily construction and test. This approach can make the software development status to frequent updates, as well as the defects of design and integration early. In order to make full use of time and equipment resources, automatic software construction after get off work, followed by automatic test (there are many system tests or regression tests), which is a very effective way. If the arrangement is good, when you go to work next day, the test results have been in each person's email address, waiting for the new day development. Summary: The above is just aware of software testing automation based on experience and experience. Due to the different enterprise development environment, the implementation of the product is different, and the implementation of test automation will have a big difference. I hope that everyone will master the basic spirit and ideas of this work from these specific examples, and then combine their own situation, boldly innovate. At the same time, don't forget to introduce you to your experience. I wish you all a good test.
Posted @ 2004-07-07 00:36 Netbee Read (93) | Comments (0) | Edit Collection Test, Test, Test - Software Test Theory and Practice
Test, test, test
- Software test theory and practice
Question: Test is the guarantee of the high quality product delivered successfully
Each of us will not be software testers, but they are users of certain software. By default or by default, users will feel that they have no problem. Generally don't think of such software may have problems. Users can use these software to solve the problem they need to solve. When they found the problem, they even shocked. There are many problems with the problems and the effectiveness of the test. The problems in the general software products are indeed fewer problems, but I feel that even the genuine Jinshan Express 2000 bought before, there are some obvious bugs. If the test is insufficient, then these problems will latenner in the software, wait until the user discovers, and the cost of developers will be maintained, and the cost of correcting the error is generally 40 times to 60 times the development phase.
There are some misunderstandings for testing, for example: 1 test is imagined to have problems, and then try to verify these issues. In fact, it is only a part of the situation, and the randomness is too large, but also depends on the experience of developers, the level of familiarity of the business and the extent he thinks. 2 Make time with wealthy employees to do some test surfaces to see this reflect the efficiency and flexibility of management, but in fact reflects managers' despise to test. The people who test and test have a big relationship. Test staff should be diligent and patient, good at learning, thinking, and discovery issues, careful, summarizing questions, if there is such an advantage, doing other tasks will also be excellent, so there is still a requirement, just want to like Test this work. If he is full-time, then it must be more experienced and confident. Domestic guys seem to like to make programmers. The two work is different. Different, the status is different, and the understanding of the value of self-realization is different. This is a problem that needs improvement in the industry. If you complete the task just to complete the task, you will feel satisfied if you have discovered a few questions, which is not working in any other job. 3 Test is a relatively simple job. In fact, it is not easy to do something well. There are also many related technologies and tools for testing. The problem of tested tested, perhaps through painful experiences and results may be exactly. Many experts are discussed and studied in the theory of testing.
Basic knowledge of test
Let us have a quick over again:
What is software test: Before the software is put into operation, the final review of software requirements, design specifications, and coding is a key step in software quality assurance. Tests Test: Find out potential errors and defects in software with fewer use cases, time, and manpower to ensure the quality of the system. From the type of test, the test is divided into two types: black box test and white box test. Black box test is also known as functional test or data-driven test, seeing the system as a black box, regardless of the inherent logic of the program, only checking if the functionality of the program is in line with its functional description according to the requirements of the requirements specification. White box test is also known as structural testing and logical drive testing, allowing testers to design and select test cases to design and select test cases, and test the logical path of the program. The test case consists of test input data and the corresponding output result. The quality of the test case design directly determines the effects and results of the test. From the front-reality process of testing, software testing is composed of a series of different tests. These software tests are divided into: unit test, assembly test (integration test), confirm test and system testing. The process of software development is the top of the top, the test is just the opposite, and the above processes are upstairs, gradually integrated.
Unit test (module test): Tests for each module, can design test cases from the internal structure of the program, and multiple modules can be tested parallel. Typically, the drive module and pile module should be made when the coding phase is performed. Integrated Test: On the basis of unit testing, all modules are assembled in accordance with design requirements to become a system, must be carefully planned to submit an integrated test plan, integrated test specification, and integrated test analysis report. Confirmation test: Verify that the functionality and performance of the software and other features are consistent with the requirements of the user. System Test: Place the software across the entire computer environment, including hardware and software platforms, some support software, data, and personnel, etc., a series of tests in actual operating environments. The documents of the test work mainly include: test plan, test model and use case design or specification, test analysis report, etc. From the software engineering, this is part of the software configuration. (I don't know if any report is not, just constantly playing the executive, I will write down if I see the error and problem, count is not a real test?)
Testing requires certain techniques and tools
In the use case design process, many aspects can be considered, and there are many guidance methods and techniques. Black box test case design includes:
Equivalent classification: division equivalence class - Establish test case - design case boundary value analysis: Through analysis, consider how to establish a border situation error speculation: relying on experience and intuition to speculate on various mistakes in the program, thus Targeted use cases. You can list possible errors and where possible, then select the case. Included: By painting, the constraints and restrictions are marked on the figure, and the conversion is converted into a judgment table, and then the test case is designed. This is suitable for checking various combinations of program input conditions.
Function Diagram FD: By formulating the functional description of the program, and mechanically generates a test case of functional graph.
White box test case design includes:
1 Logical override, tested in the logical structure in the program, including the following five types:
1.1 Statement Cover: Each executable statement covers at least once; 1.2 Decision overwriting (branch overwriting): Design several test cases, run the measured procedure, so that each judgment branch in the program is used to perform at least once; 1.3 Condition Cover: Design enough test cases, run the measured process, so that each of the programs per condition in the program is at least once; 1.4 Decision - Condition coverage: Design enough test case, run The measurement procedure is performed, so that all the values of each of the criteria in the program are at least once, and each possible judgment result is also performed at least once; 1.5 Condition combination test: Design enough test case, run the measurement Program, enabling all possible conditions for each of the programs to perform at least once; 1.6 Path Test: Design enough test cases, run the measured process, to overwrite all possible paths in the program.
2 basic path test
On the basis of the program control flow map, the basic executable path collection is derived by analyzing the loop complexity of the control structure, thereby designing the test case. The following five aspects: 2.1 Control flow diagram of the program: a diagram method for describing the program control flow. 2.2 Program environment complexity: MCCABE complexity metrics. From the loop complexity of the program, the number of independent paths in the base path set is exported, which is the upper bound of the number of test cases that must be performed in the program. 2.3 Export Test Example 2.4 Prepare the test case to ensure that the execution of each path in the basic path set 2.5 graphic matrix: Software tool that acts in the basic path test, using it to automatically determine a basic path set. Static analysis method of the program:
1 Generate a variety of reference tables, static error analysis
2 artificial test: table check, code review, etc.
3 Software Test Tools: including static analysis tools, dynamic test tools, test data automation generation tools, module test bars, test synthesis environments
3.1 Static Analysis Tools: Preprocessors, Database Tools, Error Analyzers, and Report Builders of Language Programs. Directly scan the testing body, analyze the data flow and control flow of the program, and then send a test report.
3.2 Dynamic Test Tool: By selecting the appropriate test case, actually run the measured program, more actual operation results and expected results, and find errors.
3.3 Test Data Automation Build Tools: Includes Path Test Data Generating Programs, Random Test Data Generating Programs, and Generate Test Data Based on Data Specifications
3.4 Module Test Desk is a special test case description language, which is responsible for transmitting input data to the test module, and then compares the actual output result with the desired results expressed in the language of the description test case. In addition, other functions: statement tracking, dynamic sentence, overlay metric, user-defined symbol table, content table, and output format.
3.5 Test Synthesis Environment: Includes environmental simulation programs, code checkpoints, test document generating programs, test execution strict procedures, output comparison procedures, program correctness certification procedures, etc., and various debugging tools. Moreover, there is an integrated system, integrating a variety of tools, such as Sadat, Microsoft Test for Windows and Pureartria, and more.
*********************************************************** **********
Test management
As an essential component of project or product development, it takes good organization and management. Using software quality specification, writing and implementing test cases and models, can be effectively organized.
The general test work process can also be: Plan-> Configuration (necessary Software Software) -> Development (Constructive or Configuring Test Tools, create test kits and test solution libraries, prepare appropriate reporting tools and record test systems How to run) -> Test (test, record test conditions, question, report results).
Test management can also be seen from the test manager and test team:
The test manager should manage the team. Many people think that the test is a boring thing, and it seems to be low-level things, so the test manager should constantly motivate the team members to fight for them. Sustained steadily in time progress. Just like running, overtime plus point at the beginning, will only lead to premature arrivals. As a test manager, there should be sufficient quality awareness. The method of evaluating quality risk is "Failure Mode and Effect Analysis, FMEA). This approach allows you to map the demand, specification, and project team assumptions at specific quality risks and results. Then, classify according to the risk level and arrange it in order. In fact, if it is very difficult to get sufficient resources, it is not bad to use a good tester. The supervisor and technical manager of the general enterprise do not really pay attention to the meaning and value of the test work. Perhaps they believe that the temporary investment of one-time strong test is enough to find that most of the problems, and actually this is the long-term development of the product, and the quality improvement is not too good. During the test process, the software function may be adjusted and changed, and the test discovery problem will also result in changes and need to be tested. Management also needs to be managed. In addition, due to the undiperics of the upper management department, it is necessary to communicate with it, and it is necessary to communicate with it; it is also very important to communicate with the development department, because development and testing are in nature, it is easy to produce each other. Some unnecessary contradictions. Different from the development department, the general quality or testing department and market or sales department is consistent. If both parties believe that high quality products are important brand strategies in the market strategy, thorough testing is to achieve such goals Said significance. Therefore, it is necessary to maintain collaboration and communication with the market sector.
Test managers can often ask themselves:
What tests do you plan? What tests did actually have? How many cases have been used? How old is it? Does the management department have enough support? Do they have to test the test report? Whether the contact department is timely contact? and many more. If you are test managers, you should be able to think of more questions.
Test team:
How much is the scale of the test team, generally depends on the scale of the project, the proportion of testers and developers, the project manager's understanding and expectation of quality assurance, etc., also depends on your accurate test plan. For some projects, it is best to have testers to intervene in the beginning.
As mentioned in this article, the qualities that testers must have in the test team include: effective frank and sincere communication skills, clear and concise expression skills, must be curious (but not too strong, Too much effort to explore a tiny problem), should not be afraid to make a hassle, a certain sense of responsibility, and the attention can be highly concentrated, and it is an occupational pessimist (but not complaining and disgust).
Here are some methods and basic tools:
Test schemes, test models and test cases are like experimenting, the experiment is really familiar for the science and engineering graduates like me. There will be experimentation programs, content and steps before experimenting, and the test seems to be the same. In addition, testing and common randomness based on test cases is also completely different, although people accustomed to random testing, if they are concentrated, there are some test cases in his mind.
About the test laboratory, testing the test work first to win as good environment. If possible, test lab should be established. The laboratory includes the necessary equipment, tool software (including test tools), and various operating system platforms, maintaining the practicality, tidy of the laboratory, avoiding others to disturb the test environment.
About test tracking software, making a simple test problem tracking software, record the results of the test, classify the problem of the test discovery, and associate the issues and modules, developers, which help analyze the problem, and can be effectively recorded The results of the test form a test report, and found some regular things. Therefore, test problems tracking software still has a certain value. About testing automation, there is a certain risk. For a stable system, you can even develop automation software yourself, and for software development processes, interfaces, main functions, and support environments that are in rapid deformation in development. Pay a lot of time for the test configuration environment.
The following is some tips and experiences:
When developing a test plan, take into account the risk of testing, and choose which tests to do, and give it to the testing; the test plan should be involved; the production of the test model should be as close as possible to the user, or stand in The user's use position is observed, and more problems should be found at this time.
Due to testing problems, you must retest after solving the problem, so the test time may be longer than the actual
Identify and pay attention to a small number of important aspects, and ignore most of the number of times, sometimes a few problems are fatal, these issues will be the most important mistake in software test results. The wrong positioning is sometimes difficult, to identify the cause of the necessary cause, not because the developer is misleaded because of the description error. Sometimes there is a problem that the error cannot be rebuilt. One of the solutions is to give a description in the error report.
For the description of the error, it should be accurate and complete and concise. Because the description or incomplete description can cause the developer's misunderstanding, the consequences are conceivable.
Sometimes experienced testers can find some problems with intuition, which can be called "error guess".
Test staff is easy to commit two wrong: First, the tester has a judgment error, and the system behavior report that does not have erroneous is incorrectly reported, or the error specifies too high severity, or too high estimated the seriousness of the problem, this will It caused the untrust of the developers, producing a "wolf coming" as the effect; second, the tester has lowed the seriousness or priority of the mistake, resulting in "test escape", which will cause product quality risk. The above two errors should be avoided as much as possible.
Finally, I suddenly thought that the test can actually cover the test of hardware, and even non-computer products, may be able to learn from each other.
There is also a very strange thinking, this kind of feelings make me somewhat confusing. I found that the distance between theory and practice is very far away. I first read a book of software project, then wrote half of the content, and then I rushed over a US book. , Called "Test Process Management", then finishing the contents of this article, there is more practical experience than many of this article. Goethe said that theory is pale, and the trees of life are often green. I changed slightly, it became it: theory is pale, practice tree evergreen. Perhaps testing is a very practical job, and university professors are generally impossible to pay attention to test work.
Posted @ 2004-07-07 00:35 Netbee Reading (93) | Comments (0) | Edit Collection
Is the test a fun thing? really?
Is the test a fun thing? really?
test. hate! I have always hate to do test. Test (unit testing and function test) is a matter of attacking "truly" work. Everyone is convinced that their code is perfect, isn't it? In the very few events that need to change the code, the comment is written so good, so that everyone can understand the meaning. I need to improve (I may also need some consultation). In the past few years, the unit test has become the core link of the software, thanks to a simple programming method called Extreme Programming (XP) (see Reference Resources). This method requires me to write unit testing for each function added, and maintain these tests. If the unit test fails, I can't integrate any code. As the code base is increasing, these tests will enable developers to complete changes.
At first, I think there is a unit test, there is no need to perform functional test. Oh, it's wrong. Functional testing is far from the unit test. I spent a long time to understand the difference between the two, and how to use both to improve the development process.
This article explores the difference between unit testing and functional testing. And outlines the methods of using these two tests in daily development.
Testing and development process testing is extremely important to developers, you must continue to test during the development process. Test should not only belong to a particular phase of the development cycle. It should never be the last task you want to complete before you give the system to your customers. How can you know when you finish all tasks? How can I know if the correction of a small error destroys the main function of the system? How can the system in the current imagination can evolve into a real system? Both unit testing and functional tests should be unsearched during the development process.
Unit tests should be the core link you write code when you do is tight and you want to control development schedule. Since the unit test is so important, you should write a test before writing the code.
A suitable unit test has the following functions:
Explain that the best design of the most practical design provides the best format of the class document to determine when the class completes the development of the developer's confidence of code as a fast reconstruction basis.
Unit test creates design documents with the natural development of the system. Read the previous sentence again. The document will develop naturally, this is the "Holy Cup" developed by software. What is the way to record a class effect than by providing a use case coding set? That is the unit test: a series of documentary code for work, providing output control. Thus, since the unit test must pass, the design document is always the latest.
You should first write tests, then write code. This provides a design for the class to be tested, this design allows you to concentrate on a small piece of code at every moment. This approach also makes the design no longer complicated. You have not tried to achieve some unnecessary functions for future. Write tests first and make you know when this class is complete. Once all tests are passed, the task is also completed.
Finally, unit testing allows you to be highly confident, which will turn to developer satisfaction. If you change the code, you can immediately discover if you make changes to the system.
Functional test is more important than unit testing, because the function test will verify that the system can be released. Functional Tests illustrate your working system in a useful way. A suitable function test has the following functions:
Capture user needs enhancement group (users and developers) in the system to meet the confidence in users' needs
Functional test captures user needs in effectively. Traditionally develops to capture demands through use. Typically, people discuss use cases to refine them for a long time. The last thing they got is only a paper empty text. Functional test is like self-verification cases. Extreme programming methods can explain this concept. XP Stories will become an agreement to communicate with developers in future users. Functional test is the result of this communication. The Stories that have not been tested cannot be perfect.
Function test fills the blank left by the unit test and enhances the confidence of the group to code. The unit test misses a lot of errors. Although it provides all the code you need, it may not provide all of the system features you need. Functional testing will expose the problem of missing unit testing. A suitable automation function test is also impossible to capture each error, but it can capture more errors than the best single unit test. The unit test and function test unit test indicates the correct execution of the code correctly to the developer; and the function test indicates that the code performs the correct operation.
The unit test unit test is written from the perspective of the programmer. It ensures a particular way to successfully perform a range of specific tasks. Each test ensures that as long as a given input, the method will output the expected result.
If there is no test framework, write a sustainable automation unit test is almost impossible. Select a team recognized framework before starting the test. You will always use this framework, so you'd better have a bit good to it. Extreme programming sites offer several unit test frameworks (see Reference Resources). The framework I am most familiar is JUnit, which is specifically used to test Java code.
Functional test function test is written from the user's perspective. This test ensures that the system executes the user expects it to perform.
Many times, the system has developed better than building houses. Although this type is not very appropriate, we can expand this kind of ratio in order to understand the difference between unit test and functional testing. The unit test is better than the building supervisor of the house building site. He cares about the various internal systems of the house, such as foundations, architecture, power supply systems, and pipelines. He ensures that the work of the (test) every part of the house is safe, normal, that is, the architectural instructions. In this case, the functional test is similar to the homeowner inspected the same building site. He assumes that the internal system will work properly and assume that the building supervisor is executing its task. What will happen to stay in this house? He cares about the appearance of the house, whether the size of each room is suitable, whether the house meets the needs of the family, and whether the location of the window is conducive to picking. The homeowner performs functional tests on the house. He considers problems from the perspective of users. Construction supervisors test the house execution unit. He considered questions from the perspective of construction workers.
Like a unit test, if there is no test framework, write a sustainable automation function test is actually impossible. JUnit is ideal for writing unit testing; however, when trying to write function tests, it is not a heart. For functional testing, there is no framework with JUnit. There are several products for functional testing, but I have never seen them applied to the production environment. If you can't find the framework that meets your needs, you must create one.
No matter how good we are building a project, there is no matter how flexible system we are creating, if our products are not suitable, then we are in vitness time. Therefore, functional testing is the most important part of development.
Because two tests are essential, you need to understand the principles that write them should follow.
How to write a unit test When you start writing a unit test, it is easy to be restored. The best way to get a unit is created for the new code. (Although it is more difficult to create unit testing for existing code, it is not unable to implement). First, start from the new code, wait for your entire process, create a test program for existing code.
As mentioned above, the unit test should be first written, and then write these units to test the code to be tested. How to write tests for code that is not there? Asked very well. Mastering this method requires 90% thinking to add 10% technology. I mean, you only need to assume that you have existed for classes you have written for it. The next task is to write a test. It will make a lot of grammar errors, but you should take it first. This step you have to do is to define the interface you want to implement. The next step is to run your unit test, correct the grammatical error (ie, write a class, so that it implements the interface that you just defined) and run the test again. Repeat this process, and write only the code that is written only. Run the test until the test is all passed. Once all units are tested, the code is completed. In general, each public method of the class should have a unit test. However, a functionally simple method (for example, getter method and setter method) does not require unit testing unless they acquire and set in some particular way. It should be followed by the following principle: ie, as long as you think there is a need to pay a behavior in the code, you will write a unit test. If you don't like many other programmers, the unit test is a method of recording code behavior.
Place the unit test with the relevant class of the tested in the same package. This organization approach enables each unit test to access methods and reference variables with package or protected access modifiers in the test class.
Avoid using domain objects in unit tests. The domain object is an object specific to an application. For example, an spreadsheet application may contain a registration object; this registration object is a domain object. If you have a class known to these domain objects, you can use these objects in the test. But if you have a class that does not use these domain objects, you don't contact these objects on this class in your test. This situation should be avoided because the code is reused. Classs created for a project are often used for other projects. Reuse these classes may be simple. However, if you use the domain object of another item in the test of the reuse class, it will be quite time consuming to work properly. Normally, this test will be deleted or override.
These mechanisms provide you with a good help, but if you don't run these tests, a comprehensive unit test becomes worthless. Early run tests usually make you confidence in the code at any time. You will continue to add functions as project progress. Running these tests will inform you that the new feature that has just been implemented is destroying the system.
After you have the skill of writing a unit test, let's take a look at the existing code. Writing tests for existing code may be a challenge. Don't test for testing. When you find that it is necessary to modify a class that has not been tested (or there is no test at all), please write a test. It is time to add a test now. As usual, the unit test of this class should capture the functions of each of its methods. One of the easiest ways to find what tests should be: View the comments in the existing code. Any comments should be captured within the unit test. The end of the method will be described in the beginning, indicating that the annotation block acting as a unit is tested.
How to write functional tests Although functional test is important, it is not attached to sufficient attention. Most projects have a separate group to do functional testing. Usually a large group of people constantly interact with the system to determine if the system works correctly. This concept and setup special function test team is very unwise.
The processing of functional testing and processing for unit test should not have a difference. As long as the code you have written is used to generate components that require users with interaction (such as dialog), you must write tests, but actually write tests to do before writing code. Please write with the user to obtain the function test of the user needs. Whenever starting a new task, you must describe this task in the Function Test Framework. Your development work will continue to develop forward. When adding a new code, perform unit testing. When all unit tests are completed, run the original function test to see if it can pass, or if you need to modify it. In theory, the concept of functional test team will disappear. Developers should write functional tests with users. After the end of a series of functional tests made to the system, members responsible for functional testing in the development group should bombardize the system with various changes in the initial test.
The boundaries of unit testing and functional tests typically have no clear boundaries between unit tests and functional tests. Honestly, sometimes I don't know where this limit is. When writing a unit test, I determine whether the currently written unit test is actually a function test based on the following principles:
If the unit tests across the class boundary, it may be a functional test. If unit tests become complicated, it may be functional tests. If the unit test is very fragile (that is, although it is an effective test, it must constantly change to handle different user combinations), it may be a functional test. If the write unit test is more difficult than the code to which it is tested, it may be a functional test.
Please note that "it may be a functional test". This article cannot provide hard and fast rules. There is a limit between unit testing and functional tests, but the specific location of the boundary is determined by you. You use the unit test to use the more skilled, and a specific test is the difference in unit test or the boundary of the function test.
Summary unit testing is written from the perspective of the developer and is concerned with a particular method of the class tested. When writing a unit test, use the following principles:
First write unit tests, then write the class code to be tested to capture the code annotation in unit test. Test all the public methods of performing "exciting" features (ie, not getter and setter unless they perform acquisition and setting operations in a unique manner). Place each test instance with the class to be tested in the same package to obtain access to the package member and the protection member. Avoid using the domain-specific objects in unit tests.
Functional test is written from the user's perspective and pays attention to system behavior of user interest. Find an excellent function test framework or develop a test framework and use these function test identify the true needs of the user. In this way, functional testers can obtain an automation tool and the use of this tool.
Make unit testing and function testing into central links during your development process. If you do this, you will be full of confidence in the operation and expansion of the system. If you don't do this, you don't have enough to grasp the system. The test may be less interesting, but unit testing and function testing during the development process makes it quite interesting.
