preface

This paper summarizes some pre-test self-check cases from my daily development experience to help reduce the number of low-quality bugs and improve the test efficiency.

Style class Case

1. Handle overflow elements

Front-end development pages are based on UI diagram for style restoration and widescreen adaptation, generally there will not be too big a problem here, so here only one of the most easy to ignore is also very necessary to check the point: overflow element style

Let’s imagine a scenario where we don’t test for too many text/images/loops while we’re testing, and the QA student enters too many characters while testing, resulting in something like but not limited to the following:

  • Text exceeds element capacity, truncated portion is not visible/multiple lines are displayed but cannot scroll (element width is fixed /overflow is not handled properly)
  • Text beyond the content is displayed, but the newline is misplaced/shows scrollbar results affecting other elements in the line…
  • Loop through an element and break a line or flex layout without squeezing too many line breaks…

Similar situations I believe we have experienced, obviously these can be avoided in the stage of self-testing, but it is unavoidable to be too lazy to do the test or test is not fully tested after being tested.

Tip: For any elements that might overflow the container, use as many text/image/loop elements as possible at development time to test that the style holds, so that the content page style can be restored after self-testing.

2. Typesetting of form content

Table processing is usually based on the length of the content. Consider the following points:

  1. Whether the content displays only one line of text. When only one row is displayed, the display policy should be set for the column when the content exceeds the column width, for example, when the mouse moves in to display the complete content prompt.
  2. If the content is displayed on only one line, consider whether the content of a column needs to be allocated more width. For example, if a column is to display an article overview, you can set the minimum width for the column. In widescreen, the remaining width for the column can be automatically set.
  3. Fixed data, such as time stamps, mobile phone numbers, dates, etc., have a fixed width.
  4. If there are too many columns in the table, the processing method should be considered, such as displaying all contents in one row/sliding the middle contents in fixed first and last columns/clicking to expand all contents

Tip: For tables, make sure that the data is fully displayed. When testing, make sure that there is always a way to see all the data in each column. As for handling methods, you can communicate with design, product and testing students

Functional class Case

1. Search/query

For the search query function, the main self-test points are as follows:

  • Verify the validity of the query condition, and give the correct prompt when the query condition is invalid
  • Test the query criteria separately
  • Combine test query conditions
  • Clear the search criteria and perform the query

A more common scenario is that the page contains a query area (keyword input box, time selection box, condition selection, query button) and a result display area, the results are presented in a table, at the bottom of the page (optional pageSize and page). Here are some additional considerations:

  • After entering the query conditions, click query, and then select paging, whether the query results after paging are displayed correctly;
  • If the number of pages is not on the home page, change the search criteria to check whether the search criteria are correct and jump back to the home page
  • Change the query condition, do not click query, directly jump to another page, whether the results are normally displayed

You may be confused about the last point, but this is a real Case that happened. When a certain requirements development, project use vue, I in the form of query conditions with v – model the value of the binding the query conditions, click the query button directly with the value of the binding to the query, and when paging is the same as the incoming values, the result is even if the query conditions changed but did not click the query button is still using the updated values…

So it’s really important to pay attention to this, and make sure that the query criteria are stored in separate data from the current binding criteria

2. Delete the

The deletion operation is generally simple. It is necessary to pay attention to whether the data on the page is refreshed or jumped after the deletion operation.

3. The form

The reason why the Case of addition and modification is not written is that I want to say it together in the form.

Forms are more complicated. Consider the following:

1) Type of binding data

First consider the type of each piece of data bound in the form, such as String or Number. In particular, if the data required by the interface is Number, it is necessary to pay special attention to whether the data in the following form is String and whether type conversion is required.

2) Validity check

Validation of forms is probably one of the most annoying things to do. But in order not to be mentioned bugs, it is worth testing yourself a lot.

For a general input field, consider the following:

  • If required
  • Handling of whitespace (pre-whitespace/post-whitespace/middle whitespace/no whitespace allowed)
  • Ultra long character processing
  • Is it legal to enter letters, Chinese characters, punctuation marks, or other symbols

For special fields, there are special rules for checking the number field, password field, email field, phone number field, and so on. In these cases, you need to check whether your re is correct.

3) Create, view and edit

These three are grouped together because the create, view, and edit functions are likely to share the same form component.

There are two kinds of situations THAT I encounter at present:

  1. The three functions are split into three pages (but they all use the same component)
  2. All three functions are shown in the same popover (referencing the same component).

Whether it’s a page or a popover, it’s important to determine the state correctly when you’re using the same component. View generally no problem, simple display is good. The most problematic areas are creation and editing.

In general, bugs mostly appear in the editing page, because the operation is the most, the general process is:

Get detailed data -> initialize form data -> Modify data => Submit updated data.

According to the design of the back-end interface, the data is generally saved with a unique ID, which is needed for editing and saving, but not for creation. So be aware of what can go wrong in each section:

  • Did you get the data correctly when editing it (also make sure you don’t do extra fetching when creating it)
  • Whether the interface data is correctly converted to the data in the form (data processing is prone to bugs)
  • Edit whether to pass in when savingunique id(Do not pass when creating)

In addition, if the popover is used for increment and change check operation, also need to pay attention to:

  • Close the popover after saving successfully
  • The save button binds the disabled state, disables the button in the save, and should be made available again with or without success.
  • Whether the form data is reset when switching between the three states. Example: Create a form after editing it, leaving the form blank (and showing that the last edited data is about to be bugged)

4) Upload files

Uploading files is also a bug-prone feature. The main self-test points are as follows:

  • The file type is correct
  • File size limit
  • File limit
  • Upload an empty file/folder to see if it works
  • If the upload fails, upload again. The test can continue uploading normally

Interactive class Case

Finally, there are some self-test points for interaction classes. This category belongs to encountered may be tested to raise the bug, but the bug grade is generally low. But that’s also a bug, and our goal is to eliminate as many low-quality bugs as possible, so pay attention to those details.

1. The loading condition

It takes a certain amount of time for the interface to return data, and we do not want users to repeat operations for many times, so we need to add a loading state to the page/button and prohibit clicking the submit button.

2. Delete the vm

The user should be prompted for any deletion until the user confirms the deletion twice, unless the interaction design specifies that the deletion is not needed. Remember that deleting is always a risky operation.

3. Empty data

When a certain data displayed on the page is empty, compatibility policies need to be considered. The common methods are as follows:

  • Use placeholders such as “Gender: –“, “Description: Not yet available”
  • Do not display this item directly

As long as empty data is not displayed blank, this is not a problem. It’s a good idea to write a placeholder.

The last

Our goal is to eliminate low quality bugs, improve the test must pass! Ollie give!