1. Target
Develop complete and specific test routes and processes to provide a basic process framework for fast, efficient, and high-quality software testing.
The ultimate goal is to standardize and normalize software testing.
2. Test procedure Description
3. Test requirements Analysis
Test requirements are the basis of the entire testing process, determining the scope and role of test objects and test work. Used to determine the entire test work (such as scheduling schedules, test designs, etc.) and as a basis for testing coverage. And the identified test requirements must be verifiable. That is, they must have an observable, measurable result. A requirement that cannot be verified is not a test requirement. So my understanding now is that test requirements are a relatively large concept that is reflected in the entire test plan document, not a similar use case or other.
• Test requirements are the basis for the development of test plans, which determine the test requirements to provide an objective basis for the test plan;
• Test requirements are the guide to design test cases, determine what to test, and what to measure to be targeted design test cases;
• Test requirements are the denominator for the calculation of test coverage and cannot be effectively tested without testing requirements;
3.1. test methods and specifications
3.1.1, test methods
With the development of software technology, project types are becoming more diversified. According to the project type should choose the specific strong test method, the appropriate test method can let us do more with less. The following are the test methods that can be referenced for the current project engineering:
--β Test (beta test)-Non-programmers, testers
Beta test, English is betatesting. Also known as beta testing, user acceptance Testing (UAT).
Beta testing is a test performed by multiple users of the software in the context of the actual use of one or more users. Developers are usually not on the test site, and beta testing cannot be done by programmers or testers.
When development and testing are done at the root of the test, the final errors and problems need to be found before the final release. This test is typically done by an end user or other person and cannot be done by a programmer or a tester.
--α Test (alpha test)-Non-programmer, tester
Alpha Test, English is alphatesting. Also known as alpha testing.
Alpha testing is a test performed by a user in a development environment, or a controlled test performed by a user within the company in a simulated actual operating environment, and the alpha test cannot be done by the programmer or tester of the system.
Test the application system when the system development is nearing completion, and after testing, there will still be a small number of design changes. This test is typically done by an end user or other person, and cannot be done by a programmer or a tester.
--Compatibility test--Testers
The compatibility test refers to whether the test software can be successfully ported to the specified hardware or software environment, such as testing between different browsers in the B/S project.
--user interface Test-ui test--Testers
User interface testing, English is user interface testing. Also known as UI testing.
User interface, in English is user interface. Refers to the visible appearance of the software and the parts of its underlying interaction with the user (menus, dialogs, Windows, and other controls).
User interface testing refers to whether the style of testing user interface satisfies customer requirements, whether the text is correct, whether the page is beautiful, text, picture combination is perfect, whether the operation is friendly and so on. The goal of the UI test is to ensure that the user interface provides the user with the appropriate access or browsing capabilities by testing the functionality of the object. Ensure that the user interface complies with company or industry standards. Including user-friendly, humanized, easy to operate test.
The user interface tests the user interface of the analysis software to meet user expectations or requirements. It often includes tests on menus, dialogs, and dialog boxes for all buttons, text, error hints, Help information (menu and content), and more. For example, test the size of the dialog box used by the caret feature in Microsoft Excel, whether all buttons are aligned, string font size, error message content and font size, toolbar position/icon, and so on.
--Smoke test--version compiler
Smoke test, English is smoketesting.
The name of the smoke test is understood to be that the test takes a short time and is sufficient for just one sack of smoke. Some people think it is an image analogy of the new circuit board function basic Ability check. Any new circuit board after welding, first power check, if there is a design defect, the circuit board may be short-circuit, the board smoke.
The smoke test object is every newly compiled version of the software that needs to be formally tested to verify that the software is functioning properly and that it can perform the following formal testing work. The performer of the smoke test is the version compiler.
--random test--Test personnel
Random test, English is adhoctesting.
Random tests do not have written test cases, record expected results, check lists, scripts, or instructions for testing. It is mainly based on the experience of the testers of the software function and performance checks. Random testing is an important complementary means of performing use case testing according to the test specification, and is an effective way and process to ensure the completeness of testing coverage.
Stochastic testing is primarily a test of some of the important functions of the software being tested, and it also includes testing those parts of the current test sample (TestCase) that are not covered. In addition, focus on testing for software updates and newly added functionality. Focus on some special point situation, special use environment, concurrency, check. In particular, the major bugs found in previous tests are re-tested and can be combined with regression testing (regressivetesting).
--black box test (functional Test)--testers
Black box test, English is blackboxtesting. Also known as functional testing or data-driven testing.
Black-Box testing is a software test based on the specifications of the software, which does not take into account the workings of the software, so the software is like a black box for the user.
Software testers to the user's point of view, through a variety of input and observation software of various output results to discover the shortcomings of the software, and do not care about how the program implementation of a software testing method.
--Performance testing
Performance test, English is performancetesting.
Performance testing is the term commonly used in alternating load and forced tests. The ideal "performance test" (and other types of tests) should be defined in the requirements documentation or quality assurance, test plan. Performance tests typically include load tests and stress tests.
It is common to verify that the performance of the software is met by repeated use under normal conditions and system conditions. or perform the same task the new version is no slower than the old version. Generally also check the system memory capacity when running the program will not be lost (Memoryleak). For example, the validator saves a huge file with a new version that is no slower than the old version.
3.1.2, test specification
The test specification is a test standard developed according to the development specification, and the test specification is also an important basis for the post test case writing. Because the development specifications vary by company and vary by product, the standard level of the test specification is different for each company.
From the theory to the method to all kinds of process to all kinds of report template, all belong to the scope of test specification, when a set of norms formed, can make the test work more robust, all problems can be checked.
3.2, software Requirements Specification
Software Requirements Specification is the goal of the software to achieve the various functions. Is the basis of the work of the testers, there is no need to judge the test results are correct.
3.3. Software Design Description (summary and detailed design)
The design manual contains some framework, fields, database design, etc. of the software. Software design instructions have a great impact on the test work, no software design explained that many problems will not be traceable, the pre-test preparation work is based on software design instructions to develop.
3.4, page prototype (demo)
Page prototypes are the best path for project personnel to quickly familiarize themselves with the project. In the case that the requirement is not clear enough and the design specification is not comprehensive, the page prototype is also an important basis for the post test case writing idea.
4. Test process Design
Define the purpose of the test, finalize the goal, and verify that the result is what the test will do. Including:
1. Test scope: Describe the test scope of this test, such as: Test software function range, test type, etc.
2. A simple description of how to build a test platform and the potential risks of testing.
3. Project information: Description of the project to be tested related materials, such as: input and output documents, product description, the main software functions.
4. Distribution of human resources.
5. Test requirements: Generally speaking, it is all the design and requirement documents in the test. As the basis for this test
4.1. Test strategy development
This phase is based on requirements, detailed design, test plan completion, mainly is the strategy phase of this test. A lot of companies less this one stage, need to have a planned product function deduction test function point, most companies are directly take the document to start doing use case design.
Analyze the requirements and list the specific features. (generally according to the function of the interactive document can be clear out of the general function of this function, a layer of division down, until there is no functional form.) Then consider the use of those test methods? Once the work is done, we can better follow the 1.1-point coverage of these function tables. Also allows us in the use case review, fully confirm that our work is effective to ensure that the quality of the product. Generally before this, some business training and requirements reviews are necessary to listen to. This can be earlier and more proficient understanding of the requirements, but also to ensure that some of the mistakes in product design.
How do you test for each test? As follows:
A) Functional testing
---functional range (divided into the respective function modules)
---Using test methods (equivalence classes, boundary values, and other test method methods)
---test criteria (description of the feature in accordance with the design, requirements, and specification documentation)
b) Interface Testing
c) Compatibility test
4.2. Test Plan
1) Fully consider the practicality of the test plan, i.e. the proximity and operability between the test plan and the actual. The purpose of writing a test plan is to fully consider the various resources that are performed when testing, including test content, test criteria, time resources, human resources, and so on, to accurately analyze all the resources that can be invoked at execution time and the various effects that may be affected by various conditions.
A) test content: For a software test plan will be clear what tests to do this test?
Such as: System testing: Throughout the system testing will be (interface testing, functional testing, performance testing, and
Tests such as capacitive testing, load-loading testing, reliability testing, etc.).
b) testing purposes: generally more to ensure that the quality of products to achieve the expected target. This indicator is the end criterion defined in the test.
c) Test criteria: need to consider the need for this test to enter those documents, the project ends the definition of standard, test end standards? Bug level definition, priority definition, bug management process definition. This all needs to be clear in the execution of the test. These should be included in the plan.
d) Resource allocation: This is divided into human resources, software and hardware resources. The use of human resources is generally written into a Tester task assignment table, according to different stages, each stage to submit the corresponding results (very difficult). The hardware and software resources are mainly in the planning to take into account how many computers or other tools to list.
e) test risk: Most of the consideration is that the project development is postponed, the tester insufficient use cases can not fully cover the test point, the time is not enough use cases can not be fully executed, the bug can not be modified in a timely manner resulting in an inability to verify, the test staff skills to lengthen the test progress
f) Software testing strategies are generally separate to do the relevant test program.
4.3. Test Accessories
Use case templates, defect report templates
Setting up the test environment
Defect management process and defect level definition
Defect status is generally divided into: new, open, allocated, repaired, closed, reopened, in the middle there are: delay, repeat, reject, etc. status
Defect Management Process:
1. After the tester or developer discovers the bug, determines which module to enter the problem, after filling in the bug report, the system will automatically notify the development leader and the module developer by email.
2. The development leader, according to the specific situation, re-reassigned assigned to the bug belongs to the developer.
3. After receiving the email message, the developer will decide whether to change the scope.
If not, re-reassigned assigned to the development leader or should be assigned to the developer.
If so, handle it, resolved and give a solution. (Can create patch attachments and supplemental instructions)
4. The tester inquires the bug that the developer has modified, and carries on the regression test.
After verification is correct, the modified state is verified. After the entire product release, modified to closed.
Again, reopened, the status changes to "new" and sends an email notification.
5. If the bug has not been processed in a week. Bugzilla will always use email to harass its owner and take immediate action. The administrator can set the deadline for taking action at the latest, such as 3 days, and the system defaults to 7 days.
5. Test implementation
5.1. Implementation
Development will be transferred to our testing department for system testing. Get the version we first build the test environment
To make a predictive trial, the purpose is to judge whether this version is testable. If the forecast does not pass, call back to the development department rework, if passed, start our first round of system testing.
The first round of system testing we perform all of the test cases we write, record the results of the test, and find defects to submit the defect report. When the first round of testing is over, we submit all the bug lists to the developers for modification.
As they fix the bug, we do a test evaluation of the first-round system test and a test report. We also need to modify and increase the test cases we write according to the actual situation. Development bug end, submit a new version to us, we re-build the test environment to start the second round of system testing. The first is to return to the defect report we submitted, and then in the use case to select some high-priority use cases to test, found that the problem continues to submit defect reports, only to the defect rate is lower than the user requirements, we conducted the final round of regression testing, the end of system testing. The specific test rounds are determined based on the quality of the version and the complexity of the project.
6. Test evaluation
---The execution phase is over, we'll give you a general test report on the quality of the process and version of the test we tested.
1) need to review those requirements?
2) Use cases need to review those?
3) Should the plan be reviewed?
4) Defect review those?
5) Bug evaluation?
Output of the test summary report document:
1, can let the specific task in charge of the test of the individual responsible for the module quickly evaluation, put forward relevant recommendations. Give an overall assessment
2, the overall bug according to different levels of statistics, use case number, use case execution quantity
3, the test of human resources in the project statistics. (Unit: Person/day)
4, the project software and hardware Resources statistics.
5, put forward the overall evaluation of software.
6.1. Test report
The test report includes a conclusion on the functionality of the software, a description of the software capabilities designed to meet this functionality, and the proven capabilities of one or more tests.
Indicates whether the development of the project software has reached a predetermined target and whether it can be delivered.
Summarize the resource consumption data of the test work, such as the level level of the worker, the consumption of the machine.
Record the test results and findings and the test work of the project to obtain the output of the supporting carrier, according to the input and plan, the requirements of the comparison to summarize the experience of this project.
Basic procedures and requirements for software testing
