Turn: Exploratory testing

Some meaningful entries:　

1, consider whether the automation can find a valuable defect, whether to stand the test of time, whether it is worth paying maintenance costs

2. Decide what to test and when to test

* for each flaw found, a clear discussion of when it should be found

3. Decide how to test

* Is there a special path to guide people to find this flaw

* This function or concession is best used in the given method to test

* Know what tests are currently in place, and how our current and upcoming tests can increase overall test results

* Find software problems, need real users in the actual environment, with actual data, to do the actual work

* Simple repetitive work to achieve test automation

4, the most difficult part of the test is: decide what to test, determine the integrity of testing, confirm user scenarios, etc.

5, which are good tests, which are bad tests; What did the team learn after the test was completed?

Test Practice: (Very important)

　　1, the test is divided into two parts, namely "Test today's project, prepare tomorrow's project"

* Ensure the success of the current test project

* Learn what to do so that the next test project is tighter and easier

　　2, be vigilant to do one thing repeatedly, try to be able to automate

　　3, thinking:

* What technology did we use to find the flaw?

* Can we create a way to find more of these kinds of defects?

* Can you remember some practical test experiences and apply them continuously to improve test efficiency?

* What symptoms of the software can remind us that it is defective?

* Can we get more warnings from those symptoms in the future?

* What does this flaw teach us?

Thus summarizing a series of testing techniques, recommendations and tools

　　4. Reflection :

* Is there a problem with your own test process?

* Are there any defects in the testing process?

* Is there any impediment to my efficiency?

For example

1) Collect all defects (especially security breaches or data defects) that we release to the user:

Reflect on whether we have a process problem, whether the idea has a directional error, or whether it made a mistake

2) analyze each defect to achieve:

Stop writing similar flaws, be more adept at finding similar flaws, and how to identify them when similar defects occur

3) Enable team developers, testers, or planners to know and understand every flaw they have written

4) Organize the learned content into documents that form the basis of a known defect knowledge system, and try to prevent errors by new methods or automated means

　　5. When publishing each defect, ask yourself a few why and how:

* What was wrong in the beginning that caused the flaw? Can you help the development team build a system of knowledge to reduce errors?

* What are the symptoms of failure that can tell us now that this flaw is present? How can flawed behavior be separated from the correct behavior?

* What testing techniques can find this defect

　　6, learn how to use tools, and grasp information to understand how information impact testing

* Information from the application, including: requirements, architecture, code structure, source code, what to do when the program executes information

* When verifying code updates or bug fixes, which tests are affected

Training for yourself:

1, understand the software:

* What can the software do? What is the intention?

* What external resources does it use to complete the task?

* What is the main act of it?

* How does it interact with the environment?

2, understand the software failure:

* There are certain programming habits or program languages that are particularly prone to causing this type of failure

* Whether these specific failures may occur in certain types of software behavior

* How do these specific faults show themselves as invalid

3, understand the software failure:

* Why software fails

* How the software fails

* Any symptoms of software failure can reveal the health of our application

* Some features have a system problem

* How we force specific functions to fail

Self-Summary:

　　1. Recording part of Test integrity

* Execution of test Cases

* Coverage of test Cases

* Version update vs. use case maintenance

* Version complexity and importance, versus use case coverage

2. Consider what can be represented by graphs:

* Test which and which are not tested

* The complexity of the function modules tested

* Dependencies within the function module and external dependencies

* Which need to focus on testing

* The degree of completion of the tested part, especially for the focus module

3, the ability to identify software defects, need to consider how to reduce the software errors in the combination of such ability is really meaningful. (It's also a very bad thing I've done in the past, "he recalled.)

* Think of an interesting point of view that I've seen before:

"The true value of software testing does not reflect how many flaws are found in the code, but rather the limitations of the design and programmer's approach to problem solving, the narrowness of ideas, and the lack of skills." ”

PS: I am not a fans of automated testing, nor is it an artificial test of the fans, do not believe that there is a silver bullet, but if there is only one hammer, then all the nails will be seen as the same nail! It's a tragedy, not a gospel!

Exploratory testing, note two

Test Ten Commandments:

1, you should use a lot of input, to repeatedly temper the application of the test

* Large-scale random testing (automation), and helps to understand the relationship between input and output

2. You should covet your neighbor's app

3. You should seek the wise prophet yourself.

* Whether the corresponding input has a corresponding output, that is, whether the test datum clearly understand the specific input and environmental conditions combination of circumstances;

* Try to automate the test benchmark, maybe not, but think of it so you can choose to do more efficient work

4. You should not worship the failure that cannot be reproduced

* Make the best effort to note and remember (or record) the sequence of actions taken on the software, while remembering the application's response

* Consider using a debugger to track actions and software status tools

* Beware of the time spent in vain for it all day

5. You should respect your model and automated testing

* The test model is the crystallization of the wisdom of what the application does (i.e. the model) and how to do it (i.e., automated testing)

* Even if you do not automate, you should try

6. You should use the fault of the developers to oppose them

* Summarize the developer's error types, understand their own error patterns, and then apply that type of error test to each module that the developer writes

7, you should be addicted to the application of the murder (such as to make your machine blue screen bar ^_^)

* For any defect should be investigated in depth, rather than easily let go

* Confirm whether you really understand the extent and destructive effects of defects

8, you should keep the product release time of holiness

* Do not complain about the release date, when the time is not enough before the consequences should be warned beforehand

9, you should covet the source code of the developer

* Understand error handling code, and which inputs can trigger them

10. You can't assume anything.

* Before we verify that a flaw is true, don't believe it's true

* When testing, should not expect anything, neither expect him to happen, nor expect that he should not happen

Personal Summary:

1. Focus On Error handling code

* Input filter: Used to prevent wrong input into the tested software

* Input check: To ensure that the software does not use the wrong input

* Exception Handling

* input type, input length, and boundary value

2, should have the characteristics:

* Constantly surpass ourselves, quality first, continuing education

* Don't be annoyed by the pitfalls of escaping, think of them as a learning opportunity

Training for yourself:

Interesting point of view:

1, software testing is a discipline, not skill, nor art, it is necessary to pass training, training means to understand every detail of the subject!

2, in the absence of a prior understanding of how to properly compile the software, there is no way to establish a software development, so that the quality of better possible!

3. Evaluate testers, not to use the number of software defects, the severity of software defects, the number of test cases, the amount of code for automated tests, the numbers of regression test suites, and any specific metrics to measure. Testers are responsible for educating people who undermine quality, what behavior is wrong, and how to improve it.

Exploratory testing, note three

* Prioritize all the things you want to do and start with the most important things

5 Elements of decision making for local exploratory testing: input, status, code path, user data, execution Environment

Input:

1. Identify which input values are associated with other inputs and use them in the same test case

2. Identify and consider the sequencing of inputs

3, pay attention to distinguish the illegal input is input filter, or input check, or use exception

* Note If you can bypass input filter

* Note the Ctrl,alt,shift key combination of characters, find special characters

4, note that the test does not enter any value of the case, the default value of the situation

* Note that the default value can be modified, deleted

5, according to the output results to select input

* You can sometimes observe the output and then select the new input

* Note that the initial state affects the output and whether you want to run the test several times repeatedly

* Can I save the output results? Try changing the saved output values to see if the values are changed, regenerated, or have a new problem

State:

1, confirm the software status is temporary, or long-term preservation

2. Use status information to help find relevant inputs

3. Use status information to identify important input sequences

* For example, if a state change is added in some way, it must be considered whether an overflow will occur.

Code path:

1. Understand the branch that the input will cause the software to go

User data:

1, use the user's real data (you may not know all the data of the relationship and structure, with real data can compensate this)

Exploratory testing, note four

* After setting up a global target, start testing

Several objectives of exploratory testing:

1. Understand how the application works, how its interfaces look, what functions it implements

2, force the software to display all the ability:

* The goal is to make the software work hard to prove that the software does realize the functions required to achieve the design

3, to find defects, and purposeful to reduce the number of defects to zero

The software features are divided into several overlapping "regions", specific areas and test methods are as follows:

Downtown:

* Meaning: The features and features of the software that the user wants to use, the characteristics and the masking features and codes described on your software box

Test method:

1, the Guide test method: According to the user manual to test

2, Selling point test method: to observe which sales demonstrations, test the demonstration process, and can add the challenge test method

3, Landmark test method: Determine the key software features in advance, determine their pre-and post-order

4, Limit test method: to the software to ask the most difficult questions

5, Express test method: Focus on the data, find each and the data have contact software features

6. Traverse test: By selecting a target (for example, all menu items, all error messages, or all dialog boxes), and then using the shortest path that can be found to access all objects contained by the target

Historical District:

* Meaning: Legacy code from previous versions, and features and features that have been more flawed

Test method:

1, bad neighbor test method: Repeated testing of the shortcomings of a particularly many places

2. Museum testing: Focus on old code that is accepted for re-editing, or old code that runs in a new environment without being altered

3, the previous version of the test method: Regression testing, focus on the new version of the test cases can no longer run

Entertainment area:

* Meaning: The auxiliary features of the software, not the main line features

Test method:

1, supporting the test method: concern and the main characteristics of very neighboring characteristics, such as with the main features appear on the monitor, easy to be noticed by users

2, Shenxiang test method: The most unlikely to be used in the software or the least attractive features, to help improve code coverage

* Note: When multiple features are mixed together during testing, such as important and unimportant mixing, you can consider:

* * Questions about Input: whether these two features will handle the same input

* * Questions about output: Do the two feature functions operate the same area on the visible user interface? Will they produce the same output?

* * Questions about data: These two features manipulate some of the internal data that they share? Whether to read shared data or modify shared data

3, Overnight testing method: Performance testing and stress testing, never close the program, continuous use of certain characteristics to test the software

Tourism:

* Meaning: only attractive features and functions for new users, it is concerned with the various functions of fast access to the software, rather than concerned about whether the software is working

Test method:

1, collector test method: Collect the output of the software, collect more the better

* The idea behind it is that testers reach all the places they can reach and record the observed output.

2. Long path test method: Test the feature that is as far away from the application start point as possible, for example: Which feature needs to be clicked N times to be used, select the feature, click the past, and then test it

* Guideline: Try to navigate the application as much as possible before you reach your destination, so choose the features buried in the deepest application

* Can be combined with collector test method

3, Supermodel test method: Only care about the surface of things

4, test one to send a testing method: Test run an application, and then run another copy of the application, and then run a copy, focus on the network transmission data, file operation and other aspects

Hotel Area:

* Meaning: Refer to minor and ancillary functions that are often overlooked or are less described in the test plan

Test method:

1. Cancellation test method:

* Start the operation and stop it and take some time to check around the application

* Find the most time-consuming operations in your application to fully implement this approach

* You can try to start an action, do not stop it, and then start another operation at the same time

* It is also important to change the state of the object under test before canceling the object being tested.

2, lazy test method: To do as little practical work,

* You can try to accept all default values and test the program's handling of default values

Dilapidated area:

* Meaning: Refer to minor and ancillary functions that are often overlooked or are less described in the test plan

Test method:

1, pay attention to the input restrictions, which are illegal input; Be careful not to do things in the order specified

2, repeat the same operation, repeated input of the same data

Summarize:

1, tracking which test method found the most defects, which kind of execution time is the least, which code, interface, function coverage, etc.

Exploratory testing, note five: hybrid exploratory testing

Test scenarios by introducing changes to scene operations, including: insert steps, delete steps, replace steps, replace data, replace environment

Insert Step:

* Inserting one or more steps into a scene can increase the chance of software failure

1. Insert more data:

* Ask yourself: "What data does this scenario use?" How to make meaningful additions to the data used by the test "

* Provide more information than required by the scene, or exceed the required number of scenarios

2. Using additional input

* Learn what additional features are associated with the features mentioned in the scenario

* Learn what other inputs are related to the input used by the scene

3. Access the New interface:

* Learn which interfaces are relevant to the interface used by existing scenarios

To remove a step:

* Remove redundant and optional steps to make the scene as few steps as possible

Replacement steps:

* Explore alternative methods to perform each step and action in the scene

Repeat steps:

* Repeat some specific actions, or repeat multiple actions

To replace the environment:

1. Replacing hardware

2, replace the container: For example, the program is running in a so-called container application (such as a browser)

3. Replace the container version

4. Modify Local Settings

* Note whether the program uses some local settings, and assumptions about these local settings

It mentions a method called mixed-vote testing, in short, a test of common data or common scenarios.

Turn: Exploratory testing