Software Testing considerations

1. Considerations when looking for bugs

(1) The process of software system implementation is a set of controls to implement their own functional logic process. We use a few common Web controls to illustrate where we need to be aware.

text Box (textbox)

Text boxes are used to enter information in more cases. Text boxes are the same, but different places of text boxes need to enter the information will not be the same, for example, some are used to enter the time and date, and some are used to input text. First of all, we want to combine the needs, to determine the specific role of text box, if used to enter the date time, you can enter a number of formats of the date and time, is read-only, or can be manually modified, whether the Chinese characters, special symbols and other input restrictions (many times, input mismatch information, the system will appear wrong). If you enter text, verify that the length of the text entered is limited (if the maximum value of the database setting is exceeded, error) also pay attention to the visual length of the text box settings, and the input information and the overall style of the page is harmonious.

Tag (label)

tags, basically do not implement what logic function, just play the role of the display tag. For the label, we note that there is no typos (of course, no place can have typos such a low-level error), when the label and other controls used together, we want to combine the overall style of the page, to verify that its settings are appropriate, such as the distance between the label and other controls, The font style and color of the label are appropriate.

radio button (RadioButton)

Radio buttons, as the name implies, can only select one. In general, radio buttons appear as groups. If you enter the gender information, there are "male" and "female" two options, we want to confirm that only one of them, do not allow two items can be selected, and submitted is the selected information.

check box (checkbox)

As you can say, the action of the check box and radio button is relative. When using checkboxes, it is necessary to ask for multiple selections, and it is natural to verify that multiple options are implemented. Here I give an example: there are

A, B, c three query conditions, is the form of a check box to achieve. When you have verified each of the query criteria, it is best to perform a combination of validation, that is, when you select only A and C or B and C to query. Perhaps sometimes the bug is caused by a background query statement error, not the check box itself error. What I'm trying to say is don't forget to do this test verification.

Drop-down list (DropDownList)

The function of the drop-down list is somewhat similar to that of a radio button, select a message from the list that you want. Most of the time, the list of options are the most frequently used, even if the user does not make special requirements, the system is best to use the most frequently used to set the default option, which saves the user one operation step (not only here, to pay attention to the default options in the entire system settings, Software should be the most user-friendly). Also pay attention to whether the drop-down list is the right width and whether the list information is completely displayed.

button (Button/submit)

We should note the difference between the button and the submit two buttons, which is mainly used to implement the corresponding method function, which is used to submit the corresponding form to the corresponding action. One thing here is that when you click the button that executes a delete class, be sure to add a hint, and that you have the OK and cancel function on the message to prevent the user from accidentally deleting the wrong message.

(2) Now the software system is no longer as monotonous as before, the software has implemented a lot of special effects. To give a simple example

Boy explain, for example, to a button, when the cursor is placed above it is an effect, when the cursor left, it is another effect. Also pay attention to the cursor changes, when the cursor is in the text box can be entered on the "I" shape, on the general button is curved three fingers of the small hand shape. We should pay attention to the unity of special effects, and the effect is not the more the better. The effect of the implementation of the system becomes more colorful, users will be more enjoyable to use the software.

(3) Every system that is slightly more complex is usually made up of multiple pages, rather than using only a single monotonous

Page, we should pay attention to the interface display tonal style is unified, font size from the title to the specific content whether the level, similar, the same level of style set is unified. Although the system can be composed of multiple interfaces, we do not want to see redundant interfaces. There may not be a specific requirement for the interface, but I think the high-quality interface is an integral part of a high-quality piece of software.

(4) When testing the software, it must not be measured without any purpose. This will not only increase the workload, but also does not

Able to thoroughly test the system. We need to have a plan to carry out the testing work. If you're worried about forgetting some feature points, the "carpet" test can work, from the first function point of the page to the last one for a carpet-based search test.

(5) Attention to the interface page and scroll bar and other small problems, some local information is very little, a page can be displayed,

There is no need to paging function, some windows will see the scroll bar, if you set the window larger, you can display all, it is best to remove the scroll bar, I think each user wants to see all the information at a glance, and do not want to pull to pull. There is a place to have time, be sure to have time information, especially when it comes to printing the report place.

(6) The general system needs to login with the user name and password, and will assign different permissions to different users.

Do not always use the correct user and password within the appropriate scope of the test work, from the moment you open the landing window to realize that the test has begun. In the testing process, do not step in the procedures, you do not know how users will operate the process, and sometimes the opposite, to know that testing is destructive.

(7) The environment of the user's use of the software and the development of software may not be exactly the same. We can consider and verify

Here are a few questions:

Does the other browser have the same problem?

Do the other hardware and software configurations have the same problem?

Do you have the same problem with different scheduling settings?

Did the previous version have the same problem?

2. Considerations when submitting a bug

(1) When you find a problem, you do not have to hurry to submit, you can do validation (including recurrence, contrast testing, etc.) to confirm,

See is the probability of the problem or every time must be the problem, need to use different versions of different machines to do contrast verification, of course, if you are already very sure is a bug, it will not waste time to compare the verification.

(2) The description should be clear and accurate and do not use vague words (for example, as if it seems to be) to describe the phenomenon of discovery.

In this case, such as testing a software, submit a bug described as "Software help description seems to have a typo", and did not say which page which line and the specific word is wrong, should be modified to what. So it can't be said to be a good description.

(3) To consider the feelings of developers, some problems, especially some of the more subjective issues, in the problem description

Generally do not appear with strong emotional color punctuation, such as "Requirements", "must" and exclamation points (except for special cases). Some of the more tactful words such as "suggest ...", "Hope ...", "please ..." can be used when submitting such a question. "

(4) cannot confirm that a phenomenon is not a bug can be confirmed to other people or developers,

and then to submit.

(5) The problem of probability, the test process inevitably encountered some of the probability of problems, it is difficult to find out the law of its production,

Even if the problem occurs only once during the testing process, it must be submitted for such problems, supplemented by explanations that cannot be reproduced or irregular.

(6) When describing the problem, to be realistic, do not exaggerate, such as the probability of the problem, the probability of the occurrence of only 10%,

It's not supposed to be written in 50%.

(7) When submitting a bug, the correct expected output should be indicated when the problem is clearly described, i.e.

It is important that the outcome should be what it is. Now we submit a bug in some of the test and development of the two sides know what to look like, and in the bug description is not written to what kind of son, such as "when the call on the Hang machine key can not reject incoming calls" This describes a bug, and did not specify how to modify, generally this describes how to modify the look of people, So it is acceptable for us to write and not write the expected correct results. However, for some of the description of the bug must be expected to write the correct results, or developers will be at a loss, do not know what to change to what kind of son.

(8) Many times, the bugs that are submitted need to be reproduced, and some bugs are discovered by chance during the testing process.

A long time will blur the specific data or environment when the bug is found, causing the bug to not be reproduced. So the more detailed the description of the bug, the better. If the language is difficult to clearly describe the problem found, it is best to be attached to the picture or log records and other auxiliary instructions.

(9) When submitting a test bug, if the problem occurs in a specific environment, make sure that the problem

The resulting environment (hardware, software) is clearly described.

(10) Before submitting the problem, you should know clearly the software requirements, specification definition. I believe a lot of people have come across this embarrassment.

Situation, after submitting an important question, it was told that it was not a problem, and that the software was designed that way or needed to be treated like that.

(11) Some problems arise, not necessarily the problem of testing the software itself, it may be some other problems

Causes, such as "Auto-drop when mobile phone calls" problem, this may be caused by channel switching failure, is the problem of the network, not our mobile phone software itself problems. Similar situation will be many, which we have a wealth of product background knowledge.

(12) Write bug report There is no formula, no absolute template, the most basic is to enable customers or targets to repair

Change, browse bug report people understand, and in a short time, and do not need to think repeatedly. Others sometimes have to consider some of the likes of the target audience. For example, whether a similar bug is a merge or a separate commit, the steps of the bug are divided (whether each step is a point, or some points can be merged). At this point, I think "flexibility and adaptation" is very important.

(13) After discovering a bug and filling out the bug report, in the review, you need to pay special attention to a

The point is: this bug report will let other people still have the space of association or play. A good bug report is not broken down, in other words, the bug is not to let others think you have some places to test, and perhaps other problems. For example, one of the testers found that the system returned an error when entering 16 (within the allowable range) and submitting it: You cannot enter a number below 48. This is really a mistake, but if you just submit it as you do now, the other one might think: Is it a question of entering numbers below 48? So he might ask you to test other data. This prolongs the lifetime of the bug and wastes everyone's time.

After the bug has been submitted, it is not just the end of everything, follow-up verification and so on.

3. Things to note after a bug is submitted

(1) If the programmer needs to reproduce the problem, try to minimize the steps to reproduce it with minimal steps.

This is very helpful for programmers to find the root cause of the problem. Because the least steps can be developers quickly and accurately lock down the root cause of the problem.

(2) It is best to verify that the bug can be closed by the person who reported the bug. Anyone can fix the bug, but only the

The current bug can be confident that the bug has actually been fixed.

(3) When your bug report is called "not repro (non-reproducible)", check if a step is missing

Or clear, then look for programmers. Programmers typically choose this option when they cannot reproduce the bug by using the steps in the bug report.

(4) To keep track of the bugs submitted, to maintain communication with the programmer, is the bug in time to get

To avoid affecting the overall progress of the project.

I think, as a software tester, even if you are good and like this job, you will feel the tedious test process. Sometimes get rid of a bug, will lead to another or more bugs appear, in the face of this seemingly endless test work, the heart is inevitably a little irritable. But irritability to irritability, must not let their emotions too much influence to their own work, always have to be serious and responsible, down-to-earth, I hope I can do so diligently.

Software Testing considerations