As a tester, even if we can test and write all kinds of code, we should not forget that our technology is not as good as our professional development colleagues, so we should use our advantages to make up for it. It’s self-testing.

Therefore, every time we finish writing a complex business logic and functional function, we should fully consider all kinds of exceptions, and then capture and deal with them, commonly known as test and bug repair time. So we

    

Question 1:

I sincerely thank a little sister for her bug feedback. I did neglect this before and did not leave it on purpose.

It’s still on the third party table plugin, and the bug reappears by switching to the debug layer’s form-data or X-www… first On, and then click the cancel button, and then open it will appear display disorder and other conditions.

This problem will cause a lot of bugs, considering the cost of repairing third-party plug-ins is relatively high, so we adopt the simplest and crude way to bypass all of them.

Is to click the cancel button, a page refresh, so that all controls are in an initialized state.

Open P_apis. HTML and find the js function that undisabled the debugging layer:

What we used to do was hide the debugger layer

Instead, refresh the current page directly

The problem was solved.

        

Question 2:

The newly created interface opens the debugger shell layer for the first time and finds that the request mode is blank.

As you can see from console, the request mode in this interface’s data is null:

And our goal is to position it to None

So we can fix it on the back end as well as on the front end.

A simple back-end fix is to set the initial request mode of the interface to None instead of not writing.

Delete the old interface, and the new interface can be displayed normally.

Question 3:

When the new interface is opened for the first time, the top interface name input box should have a prompt, otherwise the user will not know what the input box is for:

So let’s go to this input box in P_apis. HTML and add the default text:

The effect is as follows:

Question 4:

When there are too many parameters, the screen can not fit, but there is no scrollbar:

The problem is that our debug shell is displayed out of the document stream, so it is very long and the browser does not know about it. The solution is as simple as either changing its position fixation or using a JS function to extend the height of the browser.

We see the previous position fixed mode code as follows:

Try the following:

And look at the effect:

Question 5:

Some students feedback that the 5 buttons of the interface have different styles and are very ugly.

So I’ll optimize it:

I’m going to go to the beginning of the HTML, and I’m going to go to this style, which controls the style of these three little buttons in the middle, but we’re going to make all five of them look the same, so this.wqrf_button{} is useless, I’m going to delete it.

Then find the HTML code for these five buttons, which we wrote in bootstrap3 as a button group:

Look at the results:

Question 6:

Some people respond to the button of the new project, looking very awkward, hope it can be changed.

Ok, let’s look at the original:

It doesn’t look good, so let’s change it to the following for now:

Removed the original New item button. Changed to be similar to a lot of foreign technology website way, using the keyword hyperlink writing method.

<h3 style="padding-left: 10px; < p style=" max-width: 100%; box-sizing: border-box! Important; color: grey;" > click < a href = "#" onclick = "javascript: the document. The getElementById (' add_project_div) style. The display = 'block'" > < / a > new project Create your own new project! </span> </h3>Copy the code

The effect is as follows:

As for the optimization of display effect, we will carry out various major changes in the future.

So small partner temporarily do not ridicule ugly….