Focus in software GUI testing (2)

5. command structure and Input

Here, only defects in implementation are processed. (Assuming that the programmer's choice of style is reasonable)

Inconsistency

Increasing the number of permanent truth rules can shorten the learning time, reduce documents, and make the program look more professional. Inconsistency is so common that it needs to plan and fight to choose the operating rules that can always be followed. Every tiny inconsistency is unimportant, but once a certain amount of data is reached, a well-conceived product may become difficult to use or even become a waste product. From the perspective of developers, it also shows the rigor of their development. A good test practice should mark the inconsistency of all findings, no matter how insignificant.

"Optimization"

Programmers sometimes intentionally introduce inconsistencies to optimize the program. It is really attractive, but you should also pay attention to the risks brought about by optimization and the necessity of Some Optimization: is the value of saving one or two key operations equal to the increase in learning time or the decrease in trust? Not necessarily.

-Inconsistent abbreviations

Without explicit abbreviations, abbreviations cannot be easily remembered. It makes no sense to abbreviated Delete as del and grep as grep.

-Inconsistent Termination Rules

The program should require a terminator for multi-key input.

-Inconsistent Command Options

If an option is meaningful to two or more commands, it should be available (unavailable) for these commands, and it should have the same name, in addition, it should be called in the same order in two cases.

-Commands with similar names

If the two commands have similar names, it is easy to confuse them. Do not use similar naming commands. This problem is particularly prominent in the Chinese interface software.

-Inconsistent uppercase letters

If the command input is case-sensitive, the first character of all commands should be in upper case (lower case ). The first character of the words embedded in the command should always be in upper case (lower case ). In addition, do not use multiple languages in a command unless necessary.

-Inconsistent menu locations

If the same command appears in different sub-menus, it is very difficult to keep the same command in the same position of different menus. This sentence is not very easy to understand, but it is much easier to understand it when we put it in the same sub-menu, rather than letting it move east to west to stay in other sub-menus.

-- Usage and description of inconsistent function keys

The significance of the function key should always be consistent in the Program (reversing or functional conflicts are unacceptable ).

-Inconsistent error handling rules

After the program detects an error, it may publish the error or try to correct the error. The behavior of any program should be predictable. If you do not receive any prompts or try to correct the error when submitting the error data, you cannot confirm whether the data is clean.

-Inconsistent editing rules

When you enter or check any data later, the same key and command should be used to modify it.

-Inconsistent data storage rules

Data should be stored in the same way in the same time and range. It should not save data when entering data in each region, while data is stored at the end of a record or a group of records at other times, or data is saved just before exiting.

-A waste of time

It seems that the design to waste time will irritate everyone and the time should be spent on more meaningful things.

-Twists and turns

To get to the desired command, you must select one by one. The result is that the command does not exist, cannot be implemented, or requires you to complete something or even a few things before you can use it-obvious fraud! I believe that the customer's dissatisfaction is almost the same as your (tester) dissatisfaction. For example, when a user fills up a full page of data and finally submits the data, he finds that one of the pages has been used.

-Optional

In fact, no interface contains a selection item in a menu that cannot be created. If no data exists, how do you review, save, and erase the data? How can I print documents without a printer? Some commands are not suitable for certain conditions (although they have no impact on usage), but developers may reserve such commands for the convenience of diagrams (unfortunately: this is too unprofessional); sometimes, the program will prompt for help, and when you actually use it, the program tells you that "you do not have the permission to use help"-many people would rather choose not to see what is beyond reach. This situation is common and is often ignored by developers and testers-but this is an error that should not exist.

-Are you sure you want?

Commands that seriously destroy data require repeated confirmation. Yes, this is required. For example, formatting a hard disk with full data does need to be confirmed multiple times. However, there is no need to perform complex validation operations on each small delete operation, and the user will become impatient. The result may be: when the user really performs a severe damage command, ignore the screen prompt, unpredictable consequences.

-Vague or personal-style commands

The command name should clearly indicate the role of the command. Do not ask the user to query the explanation of the command in the user manual while using the software. The survey shows that most users only have a rough understanding of the software manual when using software products, or even do not read it at all. Don't expect users to fully read the manual. It's our job. There is no reason to generate commands with obvious personal styles such as finger in a published program. Of course, if there is a foul language in the program, I hope (just hope) the customer was not so angry.

Menu

The menu should be as concise as possible. When there are too many icons or command names with different styles, lengthy and poor, and when you select Sub-items hidden under an obscure topic, understanding them will become very complicated. The more commands a menu overwrites, the more complicated it is to be planned. Without good planning, this will be a major obstacle for users to use.

-Menu layers that are too complex

If you have to go through one menu after another before reaching the command you want, I think I will choose to use another program with similar functions. The design rules referenced by programmers who create a deep menu tree indicate that no menu should have more than seven options, which is probably the best for beginners. Experienced users prefer to have more options at each menu level, make fewer mistakes, and respond more quickly and effectively, as long as the options can be organized and neatly formatted, and there is no ridiculous congestion or spelling mistake.

-Inappropriate menu navigation system

Even in the most appropriate deep menu system, you must be able to return to the previous menu, or move to the top menu structure, and exit the program at any time.

-Too many paths reach the same location

If many commands are repeated in the menu, the program needs to be reorganized. It may be convenient to repeat a command in different locations, but there are some restrictions. If you feel that you can reach another location from anywhere in the program-you have to rethink the internal structure and reliability of the program.

-Related commands are assigned to irrelevant menus.

Grouping commands or topics in a complex menu is not easy. People can easily ignore the obvious relationship between the two items and allocate them to separate menus. What we need to do when we need to adjust this: describe the relationship between the two items, and the menu that the two items should belong.

-Unrelated commands are placed under the same menu

Some commands are thrown into completely unrelated menus, which is not good, rather than re-selecting a higher-level title and reorganizing these commands-otherwise, the chaos would be serious.

-Incorrect keyboard usage

Improper use of the keyboard is always a problem.

-The edit key or function key cannot be used.

It doesn't matter if a program is transplanted from a machine without these keys. On the contrary, it may not work. Make sure that the program can use the existing edit key and function key.

-Non-standard usage of the cursor and edit key

These keys should work as they normally work on the machine, rather than as they normally work on another machine.

-- Non-standard use of function keys

If most programs use F1 as the help key, it would be inappropriate to define it as another feature in the program.

-Invalid keys cannot be filtered.

The program should be able to block and discard invalid characters, such as the letters entered when numbers are added. It should not respond. This is faster and more effective than error messages.

-The keyboard status cannot be changed.

The lights or screen information on the keyboard should tell you when your Num Lock key and other similar state conversion features are on.

-Failed to scan function keys or shortcut keys

You should be able to tell the computer to quit from its ongoing work; the program should always be able to identify any key specified by other systems-that is, keys that programs on the local machine can quickly recognize.

6. Missing commands

1) status conversion

Most programs go from one State to another. Before you select a menu item or submit a command, the program is in a certain state. In response to your selection, the program returns to another State. Programmers usually perform sufficient tests on their code to ensure that you can achieve any state you should be able to achieve.

-- Exit when nothing is done (status is returned)

You should be able to tell the application that the last choice you made is incorrect and return to the previous status.

-You cannot exit the program.

You should be able to exit when using a program that does not adversely affect the stored data. If the file you are editing has unexpected errors, after the suspension, it should be able to return to the previously saved status.

-- Cannot be stopped in the middle of the command

It is easy to tell the program to stop a command, and it is not difficult to return to the start point or select another command. If any problem occurs, you need to reconsider whether the previous design is true or not.

-- Cannot be paused

If the program limits the time you enter and the status changes as soon as the time reaches, You need to pause it for a while when you leave. This type of situation is often seen in game software, such as suspending the game.

2) crisis prevention

If system faults or user errors occur, the program should be able to minimize the consequences.

-No backup tools

It is not difficult for developers to back up an extra file. If you are modifying a file, the computer should keep a copy of the original version, so if your change has an error, you can still return a known version.

-- Cannot be undone

Undo an edited command that you have issued, at least one step. Restoring deleted files is a type of restricted revocation that allows you to recover data that is incorrectly deleted. Revocation is desirable, and recovery of deleted files should also be necessary.

-No, are you sure you want? "Prompt

To submit a job that clears a large amount of data or a command that clears a small amount of data but affects other jobs, or that is easy to submit incorrectly, the program needs to confirm during user operations, otherwise, security risks may occur (especially in case of background operations ).

-No incremental Storage

When inputting a large amount of text or data, you should be able to tell the program to save your work for a certain period of time, at least provide such user options. This will be very beneficial for sudden power loss and hardware damage.

3) handle user errors

People can capture their own mistakes, and experience tells us that they are easy to make other mistakes. They should be able to fix errors on their own and establish their own error checking mechanisms.

-No filters can be specified by the user.

When designing data entry tables and spreadsheet templates, you should be able to specify the data types valid for each region, and what programs should ignore or reject. For example, you can ask the program to reject numbers, letters, numbers not in a specific range, a valid date, or a date that matches the disk.

-Difficult Error Correction

It should be easy to modify an error. The entire system should not be restarted because of wrong data input. When inputting a string of data, you should be able to correct the error data without entering the remaining part again.

-- Annotations cannot be included.

When designing data input tables, electronic templates, and expert systems, you should be able to input comments for future reference and debugging. This is necessary.

-The relationship between variables cannot be displayed.

Some variables in input tables and templates are correlated, so it is easy to check the dependency of any variables on other variables. This should be carefully considered during design. In most financial management systems, such applications are common.

4) Other problems

-Privacy and security

For certain specific procedures, full data security needs to be taken into account to protect the confidentiality and privacy of companies, groups or individuals. In a multi-user system, you should be able to properly hide your files (usually implemented through encryption) and lock your files without tampering or reading them.

-Security concerns

The security control of a program should be considered and implemented with caution as much as possible.

-Hide menus

Many programs display a menu at the top, bottom, or at the edge of the screen (including most of the applications I previously tested ). They use the rest of the screen as the area for data entry and processing. The menu is just an aid for memory. Once the user understands all the commands he needs, he should be given full freedom to choose whether to retain the menu.

-Standard O/S features are not supported

For example, if the system uses sub-directories, the program should be able to reference other sub-directories. If the operating system provides wildcards (for example, *), the program should also be able to use.

-- Long names are not allowed

Long names should be allowed (as long as they are not too outrageous). After all, the era of insufficient memory and slow compiler response has passed. Do not turn your programs into cultural relics.

7. rigid procedures

Programs are flexible and fixed. Flexible programs are more personalized, while fixed and rigid programs are generally forced to do so due to the relationship between business processes. For example, you must borrow a book before returning it. Do not give too much freedom to users. Otherwise, the program may seem loose and should not be set to dead. It seems to put too much pressure on people.

1) user adjustable

-Noise cannot be switched off.

When a mistake occurs, many programs give warnings of "warning. However, if the keyboard is exposed every time, this is intolerable-especially in public places. Unnecessary noise must be disabled, at least the program must provide such control options.

-- Case sensitivity cannot be disabled.

A case-sensitive system should allow you to tell it to ignore the case.

-Hardware at hand cannot be used together

Some programs are locked for specific input/output programs. Users who have upgraded or changed the device may not be able to use these features. This is a pity. At the same time, it will also make users feel that it is a commercial bundle model and refuse to use this product. Developers should try to write common hardware interface code to adapt to most common hardware devices.

-Device initialization cannot be changed.

An application should be able to send user-defined initial states, or at least keep it as it is. It will be annoying to reconfigure each startup. Suppose you want to send control code to a printer to convert to compressed characters. If the program that prints data does not allow you to initialize the printer, you have to change the printer mode and status from the device, then run the program again. If the program blocks your printer settings, it is a design error.

-- Automatic saving cannot be disabled.

Automatic Storage is a good thing, but nothing is worse. Too frequent automatic saving may make users feel that the program is unreliable. So we should add the option of disabling auto save.

-The scroll speed cannot be changed.

Strictly speaking, this is not a serious problem. Many device drivers currently provide this option.

-The last operation cannot be repeated.

Such an example is redo in wordsoftware.

-The content you completed last time cannot be found.

This type of problem is common for data editing, especially text editing programs. A list of saved files should be provided unless it is disabled by the user.

-A custom command cannot be executed.

In the program option, once changed, it should take effect immediately and do not need to restart the program for loading again-except in special cases (if you cannot avoid it ).

-The Custom commands cannot be saved.

You should not just tell the program to close this operation, but should let the program always close this-as long as the settings do not change.

-Side Effects of feature changes

This situation is common. When a feature is modified, the relevant features are also changed. If side effects do exist, detailed document proofs and prompts should be provided in the manual and on-screen.

-Unlimited scalability

Developers can change all aspects of some programs. But as I said at the beginning, it is not always a good thing to provide programs with too much flexibility. Making a decision at your discretion is better than making a hasty modification.

2) Control Mode

Some programs are "overbearing ". Their error messages and help messages are superior to others, and their style cannot be forgiven-you cannot even give up the command or make changes after entering the data. The program should make it easier and more comfortable for you to complete a task. At least, it should not waste your time.

-Unnecessary and unreasonable requirements for a conceptual style

Some programs require you to input data in some order, or require you to complete a task before proceeding to the next step, or you need to make a decision before you consider the potential consequences of them. For example:

When designing a data entry format, why do you have to determine the name, type, width, or computing order of a data entry field before it is displayed on the screen? When you notice that there seems to be something wrong with putting different domains together, will you change some domains, change their positions, or even remove the least number fields? You may have to enter the field specification before using this format, but under this constraint, you should decide when to fill the details.

When describing a task to a project management system, why do you first need to list all the tasks and then list people that are available, then, before entering any data for the next job, will the job assigned to someone be exactly the same? Since you may try to decide what jobs are assigned to, don't you want to change the data after seeing the results?

There are so many restrictions because some developers believe that people should organize their work in some way. But the best way they think is not always the best. We should be more aware that, in addition to service flow bans, there is no need to add any restrictions on the user's style-of course, if the user needs it.

-Friendly to new users, but not necessarily friendly to veterans

The optimization process designed for beginners may be helpful for them to master the system, but it will also bring troubles to some experienced veterans. They prefer to use the software freely. One solution is to provide more than two paths to meet the needs of users at different levels.

-AI and automation

Some smarter and more convenient programs will guess your next action, and do not want to execute these guesses; the automatic correction program is indeed good unless it "corrects" the correct data. Sometimes, users do not necessarily want to do this. The available options can buffer conflicts in this regard.

-Excessive or redundant necessary information

Excess and redundant necessary information is as annoying as we are. Some programs will request information that they never use or only display on the screen once, or require you to re-enter the data you have already entered-not for verification, just re-obtain the data once, which is an amazing waste of time.

-Unnecessary steps are repeated.

If you make a mistake when entering a long command step or data, some programs will allow you to re-input them indiscriminately; some programs force you to re-enter or confirm any commands that may be wrong. For some tasks, you may even need to confirm each step. Believe me: unnecessary repetition or validation is a waste of time.

-Unnecessary restrictions

Why is it necessary to limit a database to so many fields or records, or restrict a spreadsheet to only numbers, and restrict a project manager to so many tasks, what if a word processing program is limited to so many characters? Non-essential constraints on performance or reliability should not be constraints.

8. Performance

Many experienced users think that performance is the most important availability factor: using a FAST program, they feel more focused, and more things are under control. In the case of rare exceptions, the faster the program, the better.

There are many definitions of performance, generally including the following perceptual knowledge:

Program speed: How fast is the standard task executed?

User throughput: How fast can you use a program to Execute standard tasks?

Perceived performance: in the user's opinion, how fast is the program? Is it satisfactory to you?

Regardless of the definition, program speed is always a key factor. However, a poorly designed quick program is much slower than its actual running and processing speed.

1) program speed reduction

Many Design and code errors may reduce the execution errors of a program. The program may execute a lot of unnecessary work, such as initializing a memory area that will be overwritten before reading, or making unnecessary repetition of work, for example, a task executed in a loop can be completed out of the loop; design decisions also affect the speed of the program, and are generally more serious than the slow speed caused by obvious errors.

2) slow response

The program should immediately respond to the input. If there is a delay between the time you enter a letter and the time you see the letter, it is obviously too slow. Quick feedback must be effective and necessary for any input event, including the mouse, keyboard, trackball, and keyboard.

3) How to Reduce user Throughput

A lightning-fast program may be slower to execute tasks than a snail bait. This includes:

Anything that may make user errors more likely. (Poor training, user habits, program style, etc)

Slow error recovery. For example, if an error is found after a long string of characters is entered, it must be re-entered.

Anything that puzzles you, but does not provide help documentation or manual materials.

A program that has a lot of input but has little to do-this is not a good program. For example, dividing a simple task into a small subtask requires confirmation of all the tasks.

When testing, using comparative testing is an effective method: Compare the products in development with those of competitors. If people spend longer time using your products, it makes sense to discover this problem.

4) poor response

I once tested a product and it took nearly one minute to retrieve the data from the database after I input the first data. This is a slow response program. It takes at least half a day to complete the input of nearly 300 pieces of data in a form. This is not allowed. Responding quickly to input is the most basic function of a program. A fast-acting program will not force you to wait until you submit the next command, but will let you continue to do other things.

5) No advance Input

A program that allows you to input data in advance will enable you to type the data when it is engaged in other jobs. It will remember the input content, display it, and process it later. You should not wait for the next command.

6) No warning is given that an operation will take a long time

If it takes more than a few seconds to do something, the program should inform the user. For a long task, it should give you a rough impression of time rather than let you wait for it to end. The general method of solving such problems is to give the approximate time or progress bar to be completed.

7) Too many program prompts and inquiries

Prompts, warnings, and inquiries may be useful, but if they appear too frequently, they will make people very angry.

8) Try to use simple commands and prompts

On a slow terminal, text, long menus, and beautiful images are often impatient. You should replace it with a brief language. Do not use statements such as "you really want to send this email to a mailbox at a speed of 500 k/s.