Minimum Software Testing Method

Preface

1.1. Introduction

For mostSoftwareSystem, howTestAnd effective testing is a headache. In software engineering, testing is an extremely important part of software engineering. However, in actual conditions, whether it is time, manpower, and resource allocation, so that most software companies in China have not conducted a complete theoretical test.

What we want to describe in this article is a simple and feasible method that can minimize the number of software systems.QualityRequired GroupTest Method.

1.2. Purpose

For any software, its value lies in the correctImplementationThe user'sRequirementThe final purpose of the test is to test whether the software is actually implementing the user's needs and enabling the system to reach the user's acceptable level.

1.3. Test Method

The user's final acceptance and acceptance of the software is the final acceptance of the software, and then the right investment can be invested.Use. SoDevelopmentIn the end, the system must have a complete set of scientific internal testing methods before being delivered to users. During Internal testing, the developers unanimously asked the testers to use them from the user's perspective and perform tests one by one. Only after the tests are passed can the system be submitted to the users.

That is to say, at least the system validation and system testing are required for internal testing.

2. Internal test process

2.1. Test preparation

Before testing, you must first prepare the relevant machines and equipment according to the system conditions, and build a testing environment with corresponding testers.

The corresponding testers must perform tests from the customer's perspective. That is to say, before the test, the system should be very clear about the functional objectives to be achieved and the professional appreciation ability of the testers, emphasis and non-emphasis should be understood.

The tester's requirement is the minimum requirement for internal testing.

2.2.WriteTest Plan

The test plan must include the following content:

1. Determine the testing personnel and conduct the division of labor, and clarify their respective responsibilities.

2. Clearly define the test functions and prioritize the functions.

Generally, the test work schedule is as follows:

? System Installation

? System parameter settings

? Traverse all business functions and determine whether all requirements are met

? Pass test

? Accuracy Test (includingDataTest)

? Failed test

? Status Test

? Query and report functions of business processing functions

? SystemPerformance

3. Test DataDesignDescription.

4. Training and other support conditions

2.3. TestUse CasesDesign

2.3.1. Writing Test Cases

Key Points

1. The functional points of test cases must be clearly written and parsed by SA. A large number of test cases should be compiled by the test team. The final test cases should be signed and confirmed by SA.

2. Of course, if SA is not encoded, it is most suitable for the test team lead.

3. the tracking and change of function points must be updated in real time, generally by SA or PM, and the test cases must also be updated accordingly.

ActualProcessYou need to use a small amount of test cases based on available resources (manpower, material resources, and time) to find more errors. It provides end users with quality evaluations with certain credibility. If you want to write and test all the use cases, the following is a specific example.ProgramYou can only list more than half of the test cases actually needed below.

2.3.2. A typical test case

Program: A Program receives three integer input values. The three integer values represent three edges of a table triangle. Based on these three values, the program will determine whether the triangle is an unequal side triangle, an isosceles triangle, or an equedan triangle.

Complete test cases:

Purpose comment of the test case

Test cases such as 1, 2, 3, 2, 5, and 10 with valid unequal edges cannot guarantee "yes" because such triangles do not exist.

Valid equilateral triangle

Effective equi triangle 1, 1, and 2 test cases cannot be included, because such a triangle does not exist

The test case is a valid isosceles triangle, which includes three replacements of two equal edges, for example, 3, 3, 4, 3, 4, 3, and 4, 3.

One side is 0

An edge is a negative value.

Three integers greater than 0, and two numbers are equal to 3rd. If the program considers 1, 2, and 3 as non-Equilateral triangles, This is a bug.

There are at least three test cases in the test above, so you can try three types of arrangement. The length of one side is equal to the length of the other two sides.

Three integers greater than 0, and the sum of the two numbers is less than 3rd, for example, 1, 2, 4, 12, 15, 30.

There are at least three test cases in the test above, so that you can try three types of arrangement: 1, 2, 4; 1, 4, 2, 4, 1, 2

All edges are 0.

Non-integer value

The number of input data is incorrect. For example, 2 or more data is input.

Specifies the expected output of each test case

(Excerpted from the best software verification and validationManagementMethod)

2.4. Test Procedure

There are two test procedures for the actual situation:

2.4.1. Joint debugging between developers

The joint debugging between programmers usually occurs when a large system composed of multiple subsystems or a system is compiled by multiple persons according to the division of functions.

Generally, the test process is initiated by the functional creator of the business starting point. The end point of the test is the end point.

The specific form is as follows:

After the developer initiates the business at the starting point, the developer adds a paper joint debugging test book, clarifies the content to be initiated, and sends it to the programmer at the next processing stage.

Programmers in the next step should handle the problem accordingly. After the processing is completed, add the corresponding part in the joint debugging test book or sign the form in the joint debugging test book to indicate that the corresponding processing has been completed, and then send it to the programmer at the next processing stage, the internal joint debugging process is completed through the approval method similar to the approval method.

Internal joint debugging is a test of the program compiled by each programmer. Due to the division of labor andTechnologyDifferent levels are generally prone to situations where the workload and progress of each programmer are difficult to grasp. Therefore, the division of labor for joint debugging testing should be flexibly mobilized.

2.4.2. Work form of test team and program development team

1. after self-testing, the program personnel should submit the project manager for test acceptance. The project manager should notify the Test director in text or other ways to prepare for the test. The test director should go to the programmer's office to perform the preliminary test (the programmer will present the test on the spot ), record the number of bugs found on the spot (it is recommended that each programmer have a preliminary bug number table in front of his desk, each time the number of preliminary bugs is recorded in the file, the highest and lowest number of people and bugs per week are reported in the weekly report. In the final test phase, the preliminary test of the Bug data affects the assessment of the program personnel, which is used to strengthen the degree of self-inspection prior to the preliminary test by the program personnel)

2. the programmer packages the project file (source package) and EXE file (or installation package) in a zip file after passing the preliminary acceptance. Send it to the internal file administrator or the test file storage directory specified by the project. Otherwise, the programmer modifies the file and repeats step 1.

3. After the file administrator archives the version files for this test, the file administrator notifies the test owner of the location where the files to be tested are stored.

4. The test owner takes the corresponding system for testing, records the testing process, and finally submits the testing results to form a bug list, which is sent to the project manager. The project manager reviews the results and then sends them to the programmer.

5. the programmer modifies the program based on the bug list, updates the bug list file, and sends it to the project manager. The project manager reviews the file and sends it to the Test director.

6. Repeat Step 1. In later testing, the tester will track and review the original test errors.

The test owner and file administrator can be a dedicated person, Project Manager, or system administrator.AnalysisMember.

If end users are used as testers, too many bugs (especially the amount error) may cause users to fear the system, I think the program that will be given to them in the future will be a big bomb. Therefore, strict self-verification is required before submission. The bug must be taken seriously. Otherwise, users' confidence in the system will be affected. Critical criticism (weekly meeting or group meeting) must be carried out for serious bugs due to being not rigorous, so that programmers can strengthen their own checks.

2.4.3. testing team work requirements

1. Submit the bug list and Data

A) All bugs must be recorded.

B) major bugs can be promptly submitted to the project team for resolution. However, you must keep a bug record and continue other tests (except for not performing tests ).

C) if some testers believe that the tests are to be carried out and cannot be carried out, they should submit bugs.

D) data records should be detailed and key data for all operations should be recorded.

　

 

2. BUG Tracking

A) Track bugs that have been resolved and unsolved.

B) other bugs should be recorded for issues not resolved in the new version, and "legacy issues" may be noted ".

3. test task division

Specify the testing focus of each person, the storage location of files, and the method for submitting bugs. All bugs are summarized by the test team lead and submitted to the project team.

2.4.4. Test Group Workflow

1. Submit the test program to the PM of the project team;

Requirement: contains all engineering and execution files (the first requirement is the runable program pre-tested by the project team)

2. acceptance by testers;

3. The tester puts all files into one package;

4. submit it to the project configuration library;

5. test execution

Note: testers perform tests according to the division of test tasks, business dependencies, and related requirements documents.

6. Fill in the test record and bug list

Requirements: the test records should be filled in real time and in detail as required during the test process; the bug list should be filled in as required after the test is completed every day

7. Submit the test records and test bug list to the test team lead (no longer than two days );

Note: The tester completes a test within two days.

8. The test team lead collects test results and submits the bug list to the PM of the project team in a timely manner.

9. The project team should promptly change the program and track and record the bug resolution;

Requirement: the project team should submit a new software version (defined by date) to the test team for testing within two days. Submit the new software version to the configuration library and notify the test group in time

2.5. General Problems

2.5.1. LAX self-testing by programmers

When a tester is present, the programmer often fails to perform a full test on the encoded program, and then will be thrown to the test team for testing. The test team will assume excessive responsibilities. solution: programmers conduct unit tests, provide unit test records, and enhance program rigor. At a certain time (one or two days), the program temporarily freezes the code, and programmers perform mutual testing, let them understand how their programs are compiled or demonstrate to the project leader, undermining their sense of superiority.

2.5.2. The rationality of Data constraints is the first step in the pre-desktop check.

Whether the data is within the agreed condition range; whether the cross-border processing is normal; whether the processing is normal for default, blank, null, and zero values.

3. Software Testing Standards

Software testing involves the following aspects:

1. Integrity of user requirements:

Whether or not the specific system is implemented according to the business process required by the user.

2. document integrity:

Whether all the documents specified in the contract have been completed.

3. Pass the test (including accuracy test)

The first step of the test is to test what the system can do.

4. Conditional coverage test

The second step of the test is how the test system is considered. The test data is used to determine whether sufficient conditions are covered, so that the system can achieve sufficient quality.

5. Rationality of Data constraints:

Whether the data is within the agreed condition range; whether the cross-border processing is normal; whether the processing is normal for default, blank, null, and zero values.

6. Status Control

Processes systems and functions in different states, such as database shutdown and whether the client can be started properly.

7. General Software Performance and others:

Whether the operating environment and usability required by the software, portability, compatibility, error recovery capability, and maintainability are recognized by users.

There are two possibilities for the test results. One is that various aspects (mainly functional and performance indicators) meet the requirements described in the software requirements, and the user accepts the system; another possibility is that the software does not meet the requirements described in the software requirements, which is unacceptable to users. Serious errors found at this stage (generally important business logic) are difficult to be corrected at a scheduled time. Therefore, you must negotiate with the user to find a proper solution to the problem.

About Author:

Wang Hui, with eight years of programming and system management experience, uses C and Java programming languages. Currently, a company in Shenzhen is a project manager who uses C and Oracle databases to develop application systems. You can contact by ddxxkk@21cn.com.

4. Appendix

4.1. Test Plan outline

From guide to computer software product development documentation GB 8567-88

The testing mentioned here mainly refers to the Assembly testing and validation testing of the entire program system. This document is prepared to provide a testing plan for the software, including the content, schedule, design considerations, methods and evaluation criteria for testing data. The specific requirements are as follows:

17. 1 Introduction

17. 1. 1 Writing Purpose

17. 1. 2 Background

17.1. 3 Definition

References

17. 2 plan

Software Description

17. 2. 2 Test content

17. 2. 3 test 1 (identifier)

. Schedule

17. 2. 3. 2 Conditions

17.. 3. Test Materials

. Testing Training

17. 2. 4 test 2 (identifier)

......

17. 3 test design instructions

17. 3. 1 test L (identifier)

17. Control

17. 3. 1. 2 Input

17. 3. 1. 3 Output

17. 3. 1. 4 Process

17. 3. 2 test 2 (identifier)

.......

17. 4 Evaluation Criteria

17. Range

17. 4. 2 data sorting

17. 4. 3 scale

4.2. Necessary content of the Bug list

Including the name and version of the program with errors, error subject, error severity level, test process description, tester, test time, Modification result, modifier, and modification time.

The classification of error severity levels is described as follows:

· Severe error: as a result, the system cannot achieve its functional objectives and the test cannot proceed. It mainly includes: The program cannot be started, the program is terminated abnormally, the program crashes, the key requirements are not fulfilled, serious numerical calculation errors, security errors, and serious discrepancies between the documents and the software.

· Moderate errors: the system cannot achieve its functional goals normally, but it knows how to avoid errors through other methods. It mainly includes: Abnormal Termination of the program but can be avoided, system boundary value errors, non-critical requirement understanding errors, and system document errors.

· Minor error: it makes the user/operator inconvenient to use, but does not affect the realization of system functions. It mainly includes: Incorrect query report format, unfriendly user interface, incorrect display format, slight numeric calculation errors, unoptimized system processing, and minor errors in system documents.

· Suggestion: make the system more comprehensive and constructive comments.

4.3. Definitions of common nouns

White-box testing: if the internal activity mode of the product is known, you can test whether all the internal activities of the product comply with the design requirements. This method is called White-box testing and checks the internal logic structure of the software, based on carefully checking the details of the process, the program status can be checked at different points by providing a set of test cases with specified conditions and loops to test the Logic Path passing through the software, to determine whether the actual status is consistent with the expected status.

Black box testing: focuses on the external characteristics of the software, without considering the internal logic structure of the software. Tests are performed on the software interface to check whether the software meets the functional requirements, whether the input can be correctly received, and the output results, and whether external information (such as data files) can be maintained) integrity.

Unit Test (module test): similar to debugging, that is, module-by-module test. It is based on detailed design description and tests important control paths to detect errors. Use white box testing.

Integration Test (assembly test or joint test): similar to joint debugging, it mainly refers to the interface between modules and the connection between modules.

Validation Test (effectiveness test): verifies the functionality and performance of the software and other features are consistent with the user's requirements. Whether the function is consistent with the user's requirements. Use black box testing.

System Testing (System Joint debugging): the software that passes the validation test, as an element of the entire computer-based system, it is combined with computer hardware, peripherals, some supporting software, data and personnel, and other system elements in the actual running (use) environment, perform a series of assembly and validation tests on computer systems.

Acceptance Test: Implemented by the user. The so-called black box test is used to confirm whether the software functions are consistent with the described requirements.

Regression testing: repeat some or all tests previously performed

Recovery test: A system test that forces the software to fail in different ways, so that the software can be properly restored.

Security Testing: attempts to verify the prevention mechanism established in the system to prevent abnormal intrusion.

Strength Testing: A system is required to run in a very large quantity, frequency, or capacity resource mode. It is actually a sensitive testing technology.

Performance testing: It is to test the performance of the software running in the environment that is assembled into the system. Performance testing should cover every step of the testing process

Test Cases: A group of test data that is most likely to discover an error or a certain type of error

4.4. alpha and beta testing

In fact, it is impossible for software developers to fully anticipate the actual use of programs by users. For example, users may mistakenly understand commands, or provide some strange data combinations, or may be confused about the output information recognized by designers. Therefore, whether the software truly meets the requirements of end users should be subject to a series of "acceptance tests ". The acceptance test can be informal or planned or systematic. Sometimes, the acceptance test lasts for weeks or even months, and errors are constantly exposed, resulting in development delays. A software product may have a large number of users and cannot be accepted by each user. At this time, a process called alpha and beta testing is adopted to discover problems that only end users can discover.

Alpha testing refers to a software development company's internal staff simulating various user lines to test the upcoming software products (called alpha version), trying to detect and correct errors. The key to Alpha testing is to simulate the actual operating environment and users' operations on software products as much as possible, and do their best to cover all possible user operations. The software products adjusted through Alpha testing are called Beta versions. Followed by beta testing, software development companies organize typical users to actually use beta versions in their daily work, and require users to report exceptions and provide comments. Then the software development company corrected and improved the beta version.

This article from: http://www.testage.net/html/91/n-141991-2.html