Practical--functional test method and actual test content

1. Data input test:

When entering data into the system or entering database operations commands, it is generally the process of testing the system's data operations on the database.

Data type testing: Because different database systems have different requirements for data types, the data types of data fields are defined when you define a database table. Test steps and methods: in the System Data maintenance function interface, input or modify data, deliberately enter non-system design data type, check whether the system is acceptable, if not acceptable, check whether to meet the system in this aspect of the design requirements, such as immediate removal of illegal content, input focus can not be to the next input location, The system customized prompt information, not allow the development tool error messages, etc. If the system can be accepted and saved, it depends on whether the field type design of the database table is inconsistent with the user or the custom, and note whether the other modules have specific requirements when the data is transferred.

Boundary value test: Enter data that conforms to the range of values, the upper and lower bounds of the range of values, and the data that exceeds the range of values, based on the requirements of the range of data values. Note that in addition to testing the database system itself data type value range, but also according to the software system design some specific requirements, design test cases to test.

Data legitimacy testing: In addition to testing whether the input data satisfies the data type and scope of the database system used, the tester should check the legitimacy of the input data based on experience and the specific requirements of the software system and requirements. For example: Date legitimacy (date of birth, duration of insurance, time of occurrence, requirements based on custom and business logic), and date rationality. Pay, proportion, rate, etc., should pay attention to the reasonable and legitimate input.

Single and double quotes: do not ignore errors and data problems that can be caused by entering single and double quotes. In the function entry interface, the input box in a field enters data that includes both single and double quotes, which can be problematic later when queried through the SELECT statement. Especially in the Web-based system, input single quotation marks, when querying data records, there will be a page link error (page cannot be linked or cannot find or link object error).

NULL test: When testing data entry or modification of the functional interface, if you do not enter anything, the system is not designed to not NULL, then, pay great attention to its impact. Because the data can be saved normally, but the data table is a null value, then all operations related to that field, such as query (and), calculation (summation, multiplication), and so on, can have data problems (evaluates to 0, no records returned). For testers, the first thing to check is whether the system is empty or empty or empty. Also for fields that allow no values to be entered, during testing, check whether the report is displayed or printed in the interface as a key feature or title.

Space: In the Data maintenance function interface, when entering data, you should pay attention to whether there are spaces in the input location, first look at the system design, how to consider, if the system allows the input of spaces, check the condition query or as the parameters when the data return, and check whether the program used to remove the space function.

Inconsistencies in data validation: When testing, for some primary keys, such as numbers, encodings, code, or fields that serve as queries or call conditions, be aware that the system checks for their input legality and whether the requirements of the query or invocation criteria are consistent. In particular, there are no specific constraints in the design of data structures, and the procedures for verifying the control of the situation.

Analysis: The main purpose of data input test is to ensure the legitimacy and rationality of data input into the system. I think that the data input process is very important to check, if in the programming process, do not pay attention to the data verification function, although it seems to speed up the development progress, but will bring some unpredictable programming or maintenance work.

2. Directory path Test:

Test the path requirements specified in the system, change the path, check whether the system can operate correctly and the system's error-troubleshooting function. When testing, according to the system Design Manual (detailed design) or through the program source code familiarity, to find out the path specified during the operation of the system or in the course of operation, users need to select the path of the place. Deliberately change the path (choose the correct path, select a different path, enter a path that does not exist). Check if the system has fault tolerance and flexibility on the path. For example, in principle in the program, it is best not to write absolute path, in addition to provide a Configuration Path dialog box, if you enter an illegal path, the system has no prompts and so on.

3. Data Operation Test:

Tests that include data manipulation tests and user interface actions.

Modify and add data: for new and modified data, pay attention to the following aspects of testing. interface, whether the data list is refreshed immediately after the new data has been added successfully, whether the wrong data is emptied when the input error is entered, and whether the input focus is controlled. On the prompt message, whether there is a prompt to save the success, input errors, the prompt error message is accurate, readable. In terms of data, it is appropriate to check the data submitted via SQL.

Delete data: Test Delete record, whether the system has a confirmation prompt, can be deleted in bulk, according to the detailed design of the system, check the deletion of the main table records, on the business, the other related tables are changed accordingly.

The submission and rollback of things: familiar with the development of C/S mode or database application system, people know the concept of database things. When a complex business logic or business has data consistency and integrity requirements, try to use things to commit to the data so that it can be rolled back in the event of a system or hardware failure caused by an unexpected cause. According to the design requirements of the system, the data integrity and fault tolerance of the system can be tested by artificially simulating the unexpected fault during testing.

4, toolbar and shortcut key test:

In the functional interface test, the shortcut keys defined in the System menu and the tool buttons in the menu toolbar are tested. It is mainly about validity and conformance testing. Validity: Check if it is valid and the interface is unresponsive. Consistency: The information that is defined or prompted is consistent with the functionality that is actually completed.

5. Operation Sequence Test

Button Order Test: In the functional interface, do not follow the design or the habit of the sequence of operations to click on the function button to see what the system reaction; repeatedly, repeatedly click on a button to see how the system reacts. Mainly is the test system's control, the calibration and the fault tolerance ability;

Business logic Order: not according to the normal business logic of the system, process operation; 6, Button Effectiveness Control test: Mainly testing when there is no condition or; 7, the same time operation test: For delete, modify, add data and one, 8, attachment pressure test: For the transmission, upload, download, mail, etc. 9, data output test: ; Data processing output test: The main test of the data sorting, condition query; printout: Test printing function can print out the report, hit; 10. Web test: Stress based on Web mode.

Business logic Order: test whether the system controls the order of business processes without following the normal business logic and process operations of the system.

6. Button Effectiveness Control test:

The main test is the "Enabled" property of the button when there is no condition or practical significance. For example: A business is not processed, the next part of the function button is strain gray (not available). When the cursor has pointed to the last bar, the "Next" and "Last Record" buttons are grayed out and so on.

7, the same time operation test:

For deleting, modifying, adding data and some business functions, perform multi-client same-time operation test to see how the system reacts.

8, the attachment pressure test:

For sending, uploading, downloading, mail and other functions of the system, select large files, test, to check the system's interface effect and stability, see if it will crash or long time without any response.

9. Data Output test:

Data processing output test: The main test is the sorting of the information, whether the conditional query output the correct data according to the conditions or requirements of the input.

Print output:

Test whether the print function can print out the report correctly, after printing the settings, whether it can be printed according to the requirements set.

10. Web testing:

Web-based application, for some of the page submitted form, by multiple click "Back" key, to test the system processing situation. For the page with the function of saving data, click "Save" multiple times to test the system's processing situation.

Additional Testing considerations:

1. What are the strategies for testing?
Answer: Black box/White box, static/dynamic, manual/Automatic, smoke test, regression test, beta test strategy

2. What do you think is the key to good test case work?
Understanding of requirements and design documentation, familiarity with the system

3. What was the test process you used to work in?
Requirements Review (developer, product Manager, tester, project manager)

Requirements determination (out of a defined requirements document)

Develop design documentation (developers can output design documents before they start writing code)

To test your strategy, write test cases,

Send to developer and test Manager (informal review case)

Execute test case (may be supplemental use case in intermediate), test version

Submit a bug (some bugs need to be identified by the developer (critical level, or suddenly found outside the scope of the test case, difficult to reproduce), and some can be recorded directly into TD)

Developer modifications (can be quickly modified during testing)

Regression testing (you may find new problems and start running by the process)

Practical--functional test method and actual test content