The project testing process mainly includes several stages: project establishment, requirements review, use case review, test execution, and test report documentation.
1. Documents required for testing after project establishment
1. Requirements specification
2. Prototype diagram (and UI diagram)
3. Interface documentation
4. Database dictionary (number of tables, caching mechanism)
2. Requirements review
Participants:Development, testing and demand personnel, the demand personnel will host the explanation.
In order for the meeting to be held effectively, testers and developers need to be familiar with the requirements documents and prototypes before the meeting begins, mark out any doubtful points and confirm them one by one during the meeting, and urge development and requirements to pay attention to unclear points. Points that cannot be answered immediately are recorded together. After the meeting, emails are organized and sent to all participants.
In the controllable progress of the project, requirements review is a necessary step. Of course, some smaller projects will ignore this stage. I personally think this is a very necessary link. This not only reduces the differences of opinions among later development, testing, and demand personnel, but is also a necessary means to ensure the progress of the project.
3. Use case writing (also write the test plan according to the development plan)
use case function type
The department where I work divides use cases into 7 categories:
1. Main process: the main functional process implemented by this module.
2. Alternative flow: It does not necessarily complete the execution of a function, but terminates the process.
3. Abnormal flow: Due to some abnormal reasons, the function of the process cannot be realized.
4. Business rules: required items, mandatory requirements.
5. Normal category: return function, required input range, page button switching, etc.
6. Exception types: network exceptions, return exceptions, etc.
7. Interface inspection: Check the style and content of each page.
Note: Among several major categories, the four major categories of main process, normal category, exception category, and interface check are more commonly used. A project does not need to cover all use case categories. It only needs to conduct test cases according to the actual situation of the project. can be classified.
Writing test cases can be done on TestLink and excel. Generally, it is done on TestLink. Small projects are more accustomed to using excel. The fields for excel to record test cases are:
Use case number, function module, function type, use case level, use case description, preconditions, data, test steps, expected results, client, execution results, remarks, designer, executor, etc.
Notes on writing use cases:
1. Design test cases using use case design methods as much as possible
2. Don’t just write use cases based on the requirements clearly marked in the requirements document, but also consider some derived scenarios;
3. Before writing the use case, first draw the decoction flow chart of the entire function;
4. Use case descriptions are concise and include results, do not repeat them;
5. The use case steps and expected results must be consistent, and one step corresponds to one expected result.
How to write test cases
1. Equivalence class division
2. Boundary value analysis method
3. Wrong inference method
4. Cause and Effect Analysis
5. Scenario method
4. Use case review
Participating personnel:Development, testing, requirements personnel, project managers, led by testers.
This link is carried out before the functions are developed. The use cases are improved based on the points raised during the review. After the improvements are completed, emails are sent to the participants.
In the project team, in most cases, testing will understand the requirements better than development. Professionalism determines that our understanding of the requirements is definitely closer to the customer. The output product after our understanding of the requirements is a test case, a certain In this sense, use cases are a kind of refinement of requirements. Development will be more biased towards functional implementation in terms of understanding requirements, and the product is the program. Therefore, there are often inconsistent understandings of requirements in development and testing, and developers do not understand the requirements in such detail. I believe that all project managers and requirements analysts can resonate with this:
We The role of test case review includes but is not limited to the following three points:
1. Unify the understanding of requirements among development, testing, and requirements
2. Help the team Develop a more detailed understanding of requirements and develop the habit of looking at requirements
3. Requirements analysts also have blind spots in their understanding of requirements to a certain extent, and these blind spots can be dug out through reviews ( The role of requirements review is the same)
4. Testers have different abilities and experiences, and all use cases will also be different. Through review, we can point out the scenarios we missed, so as to better guarantee The quality of our project
5. During the use case review, many interaction design problems, front-end and back-end interaction problems, etc. will be exposed
6. If the test case is Conduct a review before the development is completed. In many cases, even if the developer does not read the requirements specification, as long as he carefully participates in the use case review meeting, basically there will be no missed requirements or too large deviations in requirement implementation. Because you have to go to every It is impossible for a developer to look at the requirements so carefully in a short time. Use case reviews are the bridge to this transition period.
Generally, the use case writing can be completed according to the planned time, and 1 day will be reserved for them to review the requirements. Before reviewing the use cases of each module, these people will be clearly named. Please pay attention. During the review process, ask the developers some questions. They are not just talking about the use cases. They don't need to look at the requirements, but I will ask questions. We need to At the same time, it improves developers’ sense of participation.
5. Test execution
showcase test:
The test is carried out on the development computer, mainly executing key test cases and process use cases, which are operated by the development staff and reviewed by the testers. If the showcase does not pass, it will be returned and the email will be sent.
Smoke test:
After the showcase test passes, it is submitted to the test, and the tester starts running a large number of key test cases. If there are many problems when running a use case for a certain module, you can also call it back to development. The smoke test report email has the following fields: Whether the test module passed or not Reason for failure Test details Remarks
The description of the email is roughly as follows: The following are the submitted functional smoke test results as of a certain date, none of which passed. The details are as follows:
ps: The reasons why the smoke test fails are basically the same. . . . . , please cooperate with each other to fix and test as soon as possible, thank you~
Functional testing:
Functional testing is the main stage in manual testing. This stage mainly involves running test cases in full and submitting bugs to the defect management tool.
1. Form test:
a. Problems with the fields and completeness of form data and the length limit of the form input box
b. Some common sense logic verification, such as date of birth and occupation, whether the working years are appropriate, matching between provinces, cities and regions, etc. If the default value is set, it also needs to be tested.
2. Navigation test:
Navigation testing is to judge whether an application is easy to navigate by considering these factors between different page jumps, or buttons, dialog boxes, lists, windows, etc.: Is it intuitive? Are the main modules of the system accessible or reachable through the home page? Does the site need other help such as a site map or search engine? Another focus of web system navigation is whether the page structure, navigation, menu, style, etc. are consistent to ensure that users can find the content they want based on intuition or simple judgment. (Reference blog http://www.cnblogs.com/imyalost/p/5622867.html)
3. UI testing:
It can also be understood as UI testing, which includes pictures, animations, borders, colors, fonts, backgrounds, buttons, etc.
Note: I have made a rough summary of several key points to consider:
a. The picture must have a clear purpose, representative; the picture size should be as small as possible, generally using JPG or GIF compression (that is, the size limit)
b. Whether the overall style of the page is consistent with the purpose of the system
c. Are the background colors, fonts, and combinations reasonable?
4. Content test:
This is mainly used to detect the accuracy and relevance of the information provided by the web system.
For example: the price of the product, text description; the accuracy of the information, whether there are spelling errors; (this is easier to overlook, you need to pay more attention) the relevance of the information, such as the "related article list, video list, etc." of many websites
5. Overall interface test
a. This is what we often call user experience. Whether users feel comfortable when browsing, overall style, etc.
b. It is recommended to generally conduct a questionnaire-like survey to determine user feedback information. It is best to have the participation of end users. You can refer to similar notes. What are the common system styles? Consider this test system based on actual conditions. style
6. Link test (I usually don’t pay attention to it during the test process, but pay more attention to the security test of permission allocation, mainly whether the links shared by people with different permissions can be filtered correctly to ensure security)
7. Input box test (paste the blog http://www.cnblogs.com/imyalost/p/5622867.html)
In web testing, we often encounter this kind of input box test. The input box test seems simple, but in fact it contains many basic testing methods and thinking logic. Here are some points I have summarized:
1) Verify the consistency of input and output information
2) Is the text prompt in front of the input box correct?
3) Processing and recognition of special characters: single and double quotes, brackets, commas, semicolons, etc., as well as upper and lower case status, half-width and full-width status
4) The size, length, border, etc. of the input box
5) Input of different characters, and processing of character combinations (numbers + letters + characters, etc.)
6) Processing mechanism for spaces and tab line break keys
7) Conversion and encryption of asterisks or other asterisks in the password input box
8) Is there a limit to the length of characters entered in the input box?
9) The color, specifications, etc. displayed by the characters themselves
10) Some input boxes need to be restricted. Is there a prompt if I make a mistake? Are the tips simple and reasonable?
11) Input state. In some cases, the input box is uneditable. When it is in the editing state again, does the input state of the input box change?
12) Input type: whether to allow input operations such as copy, paste, and cut
13) Whether the keyword supports wildcards, as well as the search capabilities of the keyword, sensitive words, etc.
14) When entering spaces in the input box
15) For example, when logging in and registering, the judgment of various input conditions: whether to input, whether the input is correct, etc.
8. User permission test (paste the blog http://www.cnblogs.com/imyalost/p/5622867.html)
User permissions, as the name suggests, are the rights that the account has to perform operations.
1) After granting permissions to an account, log in to the account to check whether you have the granted permissions and whether the permissions are set correctly (whether the permissions are exceeded or insufficient)
2) Delete or modify the account permissions that have been logged in and are performing operations. Verify whether the program can handle it correctly.
3) Re-register the system and change the login identity before logging in again. Can the program be executed correctly? Can the previous permissions be continued to be used?
4) When using work assignment or role management, can the program handle it correctly if the workgroup or role containing the user is deleted?
5) When accounts with different permissions log in to the same system, are the permission ranges correct?
6) Can you add permissions to accounts with empty information and long user names?
7) Is it allowed to delete system administrators or modify administrator permissions? The actual situation after deletion or modification
8) Can logged in users modify or delete their own or others’ permissions and information?
9) When adding a user (with a number or identification), can the permissions be processed correctly under the combination of different user names and identifications?
10) After modifying user permissions or information, will it have any impact on other modules?
11) If the user information is modified to be the same as other existing user information, can the modification be successful? Are there any corresponding tips?
12) Will modifying certain settings affect the permissions of other accounts that have the same permissions as this account or are higher/lower than this account?
13) Can the same user belong to other groups at the same time? Can the permissions of each group overlap?
Regression Testing:
The regression test book should be based on the bugs recorded during the test execution process and the use cases that failed to execute. Verify whether it has been modified and updated based on the recorded bugs. If necessary, evaluate whether the system needs to be re-run based on the number of bugs. process.
Compatibility test: (refer to blog http://www.cnblogs.com/imyalost/p/5622867.html)
a. Platform compatible
There are many operating systems, such as Windows, Unix, Linux, Macintosh, etc.; which system the user uses depends on the user, therefore, system compatibility testing is necessary.
b. Browser compatible
The browser is the core component of the web client. Different browsers have different support for Java, JavaScript, CSS or HTML specifications;
In addition, the framework and structural style used are displayed differently or even not displayed in different browsers, and different browsers have different security settings.
One way to test browser compatibility is to create a compatibility matrix to test the compatibility of different versions of browsers from different manufacturers.
For example, when testing IE browser, you can use a tool called IEtester to test compatibility, or you can use the F12 console to switch browser versions to test compatibility with the display of some previous front-end elements, etc.
In view of the fact that there are many browsers in the domestic market, such as 360, Sogou, Sohu, QQ Browser, etc., these local browsers basically use the dual-core configuration of the IE browser core.
Safety test:
The main areas of security testing are as follows:
a. Many web application systems now adopt the method of registering first and then logging in. Therefore, test the validity of the user name and password, pay attention to case sensitivity, frequency limit, whether you can browse certain pages without logging in, etc.
b. Is there any timeout limit, link sharing, cookie hijacking?
c. Test whether relevant information is written to the log file during user operations and whether it can be traced, etc.
d. If a security set is used, it is necessary to test whether the encryption is correct, the integrity and correctness of the information before and after encryption.
e. The question of whether scripts can be placed and edited on the server or front-end without authorization
f. SQL injection verification of input box
6. Test report and operation manual
The test report templates used by each company may be different, but the focus is to reflect the test results and the bug allocation module that appeared in the test. It is also necessary to pay attention to the status of bug resolution. Just make statistics according to the needs in the template.
The operation manual is mainly written for those who use the system. The requirements are specific and detailed. The description of what roles and modules can perform what operations must be clear, with step-by-step screenshots and text.
Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends, and this warehouse also accompanies Thousands of test engineers have gone through the most difficult journey, and I hope it can help you!Friends in need can click on the small card below to receive it
