6 to the notes of programming craftsman

Chapter 8 test age

• No matter how good a programmer you think you are, releasing untested software is tantamount to committing suicide.
• Too many software plants do not underestimate the importance of detailed testing, or try to squeeze the test to the last minute before the software is released.
• Testing is an important code building technology.

  In software development, the following terms are often confused:

• "Error": Something you do wrong. It is a specific kind of human behavior that can cause Software defects.
• "Defect": the consequence of an error in the software. The concealment of defects makes debugging extremely difficult.
• "Fault": When a defect is triggered, it may cause a fault, but it may not. Faults are the manifestations of defects and the problems we are truly worried about. It may be the only event we can notice.
• "Bug": usually used as a synonym for a defect.
• A good test is a skill. The most important principle of a test is to do it.
• Testing is a completely different and independent activity from debugging, although the boundaries between them are vague and often confused together, testing is a system process to check whether your software has any defects, while debugging is a process to track the causes of the defects.

  During the entire software development process, different objects need to be tested:

• A large number of documents will go through a testing phase, also known as "review".
• The code that implements the specification will naturally be tested on the developer's computer.
• Test the final product to check whether the system functions are as expected.
• Testing and QA are also different: the purpose of testing is to identify wrong behaviors, that is, where the software and its specifications are inconsistent; QA is prevention, it ensures that our development process generates high-quality software.
• During the development process, everyone will have an impact on the production of high-quality software. The quality of the software is not the quality you can add after the code is complete.
• Why do we need to perform software testing? 1. Help us locate defects and correct them; 2. Ensure that the same defects will not occur in future versions.
• The test cannot prove that there is no defect, but that there is a defect. Do not generate a false sense of security because the code passes an incomplete set of tests.
• Who will perform the test? A programmer has the responsibility to test the source code he has compiled.
• The QA department is responsible for testing, but should test the product, rather than testing the newly written code.
• What are the test content? Our main test strategy is to drill all the code and verify their behavior by writing more code. The other is to directly check the code to verify its correctness.
• When will the test be performed? Testing while writing code is the earliest opportunity to identify code errors. Early and detailed testing is the most effective way to ensure software quality.
• The bug cost increases with the development process, so it is important to start testing code as early as possible.
• Test-driven development advocates testing as a core constructor, that is, you can write the code to test the tested code before writing the tested code.
• This policy has a profound implication: when you begin to consider writing a piece of code, you must also consider how to test it, which will improve the way you design the code.
• Strategy of continuous integration: the more frequently we perform tests, the more likely we will find problems.

  To test whether a specific piece of code can run normally, you need a test case to verify the following two points:

• Correct output is generated for all valid inputs.
• All invalid inputs may cause proper failures.
• Most people can easily trust the code they read and believe it is correct. When you write some code, you will only read what you want to write, instead of what you actually write, you should learn to read it twice and read all the code from the perspective of criticism.

  Factors that make the test difficult include:

• Code scale.
• Dependency.
• External input.
• External incentives. Code can respond to incentives other than function calls. If the time and frequency of these incentives are unclear, it will be especially troublesome.
• Thread. Multiple Control threads make the test more complex.
• Evolution.
• Hardware defects.
• Difficult fault forms. Code may crash in several surprising and strange ways.
• Writing Test cases is not easy. When components are combined and dependent on each other, the complexity of the software increases exponentially in the city, it will make your life complex.
• No matter how hard you try to test, you still cannot create defect-free software. In the real world, tests rarely prove that the software is pervasive, but can only prove that it is usable.

  Software Test types can be divided:

• Unit test. It is usually used to represent a module for testing code. It actually describes testing an atomic unit.
• Component test. Used to verify the behavior of a complete component consisting of one or more units.
• Integration testing. Test the combination of components placed in a system to ensure that they are correctly connected.
• Regression testing. The software or its environment is revised or closed and then re-tested.
• Load Testing. Make sure that the code can process the expected amount of data that is thrown to it, and the load test can check whether the program is "scaled up" as expected.
• Stress testing. In a short period of time, the Code throws a large amount of data to observe what happens to the code. The purpose is to ensure that the Code is not in disorder when it is under real impact. This test is usually used in multithreading or real-time systems.
• Fatigue Test. Similar to stress testing, it focuses on code running for a long time under a high load to identify any performance problems that may occur after a large number of operations. It can detect some defects that cannot be detected by other tests.
• Availability test. It is usually carried out in an availability lab with high controllability.

  We have the following two ideas when conducting your software test design:

• Black box testing. Also called function testing.
• White box testing. Also called structure test. The cost is much higher than that of black box testing.
• Black box testing is concerned with the lack of code, and white box testing is concerned with the functional defects of the Code.
• Write a comprehensive test case. Each test is applicable to one aspect of the Code. 15 tests that repeatedly point out the same defect are far less useful than 15 tests that point out 15 different defects.
• You must choose the tests that are most likely to identify Software defects, rather than executing the tests that just repeatedly point out few identical problems. Testing that does not match the purpose may only make the wrong thing worse.

  You can use the following test cases to perform a black box test:

• Some good input.
• Some bad input.
• Boundary Value.
• Random data.
• Zero.
• The quality of the unit test you write depends largely on the quality of the Code interface you want to test.
• Write clear APIs to reduce dependencies on other code and disconnect any dead links to other components.
• Designed for testing, code is constructed in a reasonable, understandable, and maintainable manner. You will reduce the Coupling Degree of components and increase their degree of polymerization.

  The following principles are applied to help you compile code with excellent testability:

• Make each part of the code self-contained, rather than establishing unstated or lack of substantive dependencies with the external world.
• Do not rely on global variables. Set this state to a shared structure passed as an independent variable.
• Restrict the complexity of your code and divide the code into small, understandable, and individually tested code blocks.
• Keep the code observability.
• Make your code test run automatically as much as possible, which is faster, easier, and safer than manual testing, and can make the test run more regularly.
• Automate Unit tests as part of your build process.

  When a program fault occurs, follow these steps:

• Pay attention to what you did and what operations triggered this fault.
• Try again to check whether the problem is repeated, how often it occurs, and whether it is related to any other activities you have given your colleagues.
• A complete description of the fault should be very specific.
• Record these descriptions.
• Write the simplest test case that can detect this defect.
• Faults that are difficult to solve are irregular or even random, making it difficult to describe their characteristics.
• You must use systematic methods to find defects, and you must also use systematic methods to manage and handle defects.

  Defect tracking system is an important weapon for us to manage defects. This tool is a dedicated database and its interfaces are visible to everyone involved in the testing process. Common Operations include:

• Report fault.
• Assign responsibility.
• Determine the priority of the report.
• Marked as corrected.
• End report.
• Query the database.
• Modify entries.
• Any programmer who writes a test has a secret goal: to prove that his code is correct, rather than finding out where it is faulty.
• Excellent programmers: 1. write and test the code they have written; 2. perform tests at the micro level so that tests at the macro level are not blocked by silly coding errors. 3. focus on product quality and take responsibility for it, and play their role throughout the test.
• Bad programmers: 1. I do not think that testing is an important and necessary part of software development. I think it is the work of others. 2. submitting untested code to the QA Section is surprising when the test finds a defective behavior; 3. because the problem is found very late, it makes your life more complex-less than doing a full test early, it will be knocked down by many defects that are difficult to locate iede.