The test process of the project mainly includes several stages: project approval, requirement review, use case review, test execution, test report document
1. Documents to be obtained after the project is tested
1. Requirements specification
2. Prototype diagram (and UI diagram)
3. Interface documentation
4. Database dictionary (number of tables, caching mechanism)
The needs assessment
Participants: development, testing and demand personnel, and the demand personnel will preside over the explanation.
In order to hold the meeting effectively, testers and developers need to be familiar with the requirements documents and prototypes before the meeting, mark out the questionable points and confirm them one by one in the meeting, and supervise the development and the requirements for the unclear points. Points that could not get a positive response immediately were recorded together. After the meeting, the emails were sorted out and sent to all participants.
In the controllable progress of the project, it is a necessary link in the requirement review. Of course, some relatively small projects will ignore this stage. Personally, I think this is a very necessary link, which not only reduces the disagreement between the later development, testing, and demand personnel, but also is a necessary means to ensure the progress of the project.
3. Use case writing (while writing a test plan according to the development plan )
Use Case Feature Type
The inaugural department divides use cases into seven 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. Exception flow: Due to some abnormal reasons, the function of the process cannot be realized.
4. Business rules: required items, mandatory requirements.
5. Normal class: return function, input range of required items, switching of page buttons, etc.
6. Exception class: network exception, return exception, etc.
7. Interface check: Check the style and content of each page.
Note: The four major categories of main process, normal category, exception category, and interface inspection are used more frequently. A project does not need to cover all use case categories, but only needs to test cases according to the actual situation of the project. can be classified.
Writing use cases can be done on TestLink and excel. Generally, it will be done on TestLink. Small projects are more accustomed to using excel. The fields of excel recording 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 use case writing:
1. Design test cases in combination with the use case design method as much as possible
2. Do not write use cases only according to the requirements clearly marked in the requirements document, but also need to consider some derived scenarios;
3. Before writing the use case, first draw the decoction flow chart of the entire function;
4. The use case description is concise and with results, do not repeat them;
5. Use case steps and expected results should 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. Scene method
4. Use case review
Participants: development, testing, requirements personnel, project managers, led by testers.
This link is carried out before the development of the function is completed, and the use case is improved according to the points mentioned in the review. After the improvement, the email is sent to the participants.
In the project team, in more cases, testing will understand the requirements better than the development. The professional determines that our understanding of the requirements is definitely closer to the customer. The output product of our understanding of the requirements is the test case. In a sense, the use case It is a kind of requirement refinement. The development's understanding of requirements will be more inclined to function realization, and the product is the program. Therefore, development and testing often have inconsistent understanding of requirements, and development will not understand requirements in such detail. I believe that all project managers and requirements analysis resonate:
we do test case review. It is limited to the following 3 points:
1. Unified development, testing, and demand to understand the requirements of the three parties.
2. Help the development team to understand the requirements in a more detailed way, and at the same time develop the habit of looking at
the requirements. There are also blind spots in understanding, and these blind spots can be dug out through reviews (the role of requirements review is the same)
4. The capabilities and experience of testers are different, and all use cases will also have differences. Through review, we can point out the scenarios we missed, so as to It can better guarantee the quality of our projects
. 5. During the use case review, many problems in interaction design, front-end and back-end interaction problems will be exposed
. Looking at the requirements specification, as long as he seriously participates in the use case review meeting, basically there will be no missing requirements, and there will be too much deviation in the implementation of requirements. Because you have to look at the requirements so carefully by each developer, in a short time is unlikely. Use case reviews are a bridge to this transition period.
Generally, the use case can be written according to the planned time, and 1 day will be reserved in the middle to show them the requirements. Before reviewing the use cases of each module, these people will be clearly named and pay attention. During the review process, ask the development questions, not just talk about the use cases. They can ignore the requirements, but I will ask them. At the same time increase the developer's sense of participation.
5. Test execution
Showcase test:
The test is carried out on the development computer, and the key test cases and process use cases are mainly executed, which are viewed by the development operation and the testers together. If the showcase does not pass, it will be called back and sent by mail.
Smoke test:
After the showcase test is passed, it is submitted to the test, and the testers start to run a large number of key test cases. If there are many problems when running the use case for a certain module, you can also call it back for development. The following fields in the smoke test report email: Test Module Pass or Fail Reason 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, and none of them passed. The details are as follows:
ps: The reasons for failing the smoke test are basically the same. . . . . , please cooperate with each other and fix the test as soon as possible, thank you~
Functional testing:
Functional testing is the main stage in manual testing. This stage is mainly to run test cases in full and submit bugs to defect management tools.
1. Form test:
a. The field, integrity of the form data and the length limit of the form input box
b. Some common sense logic verifications, such as: date of birth and occupation, whether the working years are appropriate, the matching between the provinces and urban areas, 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, and windows: Is it intuitive? Are the main modules of the system accessible or reachable from the home page? Does the site need additional help such as a sitemap or a search engine? Another key point of web system navigation is whether the page structure, navigation, menu, style, etc. are consistent, ensuring that users can find what they want by intuition or simple judgment. (Reference blog http://www.cnblogs.com/imyalost/p/5622867.html)
3. UI test:
It can also be understood as UI testing, which includes pictures, animations, borders, colors, fonts, backgrounds, buttons, and more.
Note: I have made a general summary of several key points to be considered:
a. The picture must have a clear purpose, representing; the size of the picture should be as small as possible, generally using JPG or GIF compression (that is, the size of the specification)
b. Whether the overall style of the page is consistent with the purpose of the system
c. Is the background color, font, and collocation 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, the text description; the accuracy of the information, whether there are spelling errors; (this is easy to ignore, need 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 the user experience. Does the user feel comfortable browsing, overall style, etc.
b. It is recommended to generally do a questionnaire-like survey to determine the feedback information of users. It is best to have the participation of end users. You can refer to similar notes. What is the general system style? Consider the actual test system. style
6. Link test (I don’t usually pay attention 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 properly filtered to ensure security)
7. Input box test (paste 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 to be simple, but it actually contains a lot of basic testing methods and thinking logic. The following 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 quotation marks, parentheses, commas, semicolons, etc., as well as 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 space and tab newline keys
7) The line transfer of the character asterisk or other asterisks in the password input box, encryption
8) Is there a limit to the length of the input characters in the input box?
9) The color, specification, etc. displayed by the character itself
10) Some input boxes need to be restricted, such as wrong input, is there a prompt? Is the prompt simple and reasonable?
11) In the 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 ability of the keyword, sensitive words, etc.
14) When entering a space in the input box
15) For example, login and registration, the determination 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 permission to an account, log in to the account to check whether it has the granted permission and whether the permission setting is correct (whether the permission is over or insufficient)
2) Delete or modify the account permissions that have been logged in and are performing operations, whether the program can be processed correctly, verify
3) Re-register the system to change the login identity and then log in, whether the program can be executed correctly, and whether the previous permissions can continue to be used
4) In the case of work assignment or role management, if the workgroup or role containing the user is deleted, can the program handle it correctly?
5) Accounts with different permissions log into the same system, whether the scope of permissions is correct
6) Can you add permissions to accounts with empty information and long usernames?
7) Is it allowed to delete the system administrator or modify the administrator authority? Actual situation after deletion or modification
8) Can logged in users modify or delete their own or others' permissions and information
9) Add users (with numbers or logos), whether the permissions can be handled correctly under the combination of different user names and logos
10) After modifying user permissions or information, will it affect 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) Modifying some settings will affect the permissions of other accounts with the same permissions as the account or higher/lower than the account
13) Can the same user belong to other groups at the same time, and can the permissions of each group overlap?
Regression Testing:
The regression test book is based on the bugs recorded during the test execution process and the use cases that fail to execute. Verify whether the bugs have been modified and updated according to the recorded bugs. If necessary, it is necessary to re-run the system according to the number of bugs. process.
Compatibility test: (refer to the blog http://www.cnblogs.com/imyalost/p/5622867.html)
a. Platform compatible
In many operating systems, such as Windows, Unix, Linux, macintosh, etc.; which system the user uses depends on the user, so a system compatibility test is necessary.
b. Browser compatibility
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 adopted frame and structural style 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, to test the IE browser, you can use a tool called IEtester to test compatibility, or you can switch browser versions through the F12 console to test compatibility with the display of some previous front-end elements, etc.
In view of the many browsers in the domestic market, such as 360, Sogou, Sohu, QQ browser, etc., these local browsers basically adopt the dual-core configuration of the IE browser kernel
Safety test:
The main areas of security testing are the following:
a. Many web application systems now use the method of first registering and then logging in. Therefore, test the validity of the user name and password, pay attention to case sensitivity, limit the number of times, whether you can browse some pages without logging in, etc.
b. Is there a timeout limit, link sharing, cookie hijacking
c. Test whether the relevant information is written to the log file when the user operates, whether it is traceable, etc.
d. If a secure word is used, it is necessary to test whether the encryption is correct, the integrity and correctness of the information before and after encryption
e. Is it possible to place and edit scripts on the server or front end without authorization?
f. SQL injection verification of the input box
6. Test report and operation manual
The test report template may be different for each company, but the focus is to reflect the test results and the bug allocation module that appeared in the test, and also pay attention to the status of bug resolution, as long as statistics are made according to the needs of the template.
The operation manual is mainly written for people who use the system. The requirements are specific and detailed. The description of what roles and modules can be performed and what operations can be performed should be clear, step by step with screenshots and text.