14th Week Software Engineering Course Summary

This week we learned software testing in this class, first we need to know the meaning of a few words.

BUG: Bugs in Software

Test Case: Testing cases

Test Suite: Testing case Set

Bugs can be broken down into: symptoms, program errors, root causes. The symptom is what is wrong with the software from the user's point of view. Program error is from the point of view of the code, the code of what error caused the software error. The root cause is the root of the error, the root cause of the code error.

This week we learned a variety of test methods: unit Testing and code coverage testing, building validation tests, acceptance tests, exploratory testing, regression testing, scenario Integration System testing, partner test effectiveness testing, stress testing, internal and external public testing usability testing, and in-combat testing.

We also need to practice and discuss the testing tools until we have a test experience. Here's a look at the design pattern:

Generally speaking, a pattern has four basic elements:

1. Pattern name (pattern names) a mnemonic that describes the problem, solution, and effect of a pattern in one or two words. Naming a new pattern adds to our design vocabulary. Design patterns allow us to design at a higher level of abstraction. Based on a pattern glossary, we can discuss patterns between ourselves and our colleagues and use them when writing documents. The pattern name helps us to think, so that we can communicate design ideas and design results to others. Finding the right model name is also one of the difficulties in cataloging our design patterns.

2. The problem (problem) describes when the pattern should be used. It explains design problems and the causes and consequences of problems, which may describe specific design problems, such as how to use object representation algorithms. It may also describe a class or object structure that results in an inflexible design. Sometimes the problem section includes a series of prerequisites that the usage pattern must meet.

3. The solution (solution) describes the components of the design, the interrelationships between them, and their respective responsibilities and collaborative approaches. Because the pattern is like a template that can be applied to many different situations, the solution does not describe a specific and specific design or implementation, but rather provides an abstract description of the design problem and how to solve the problem with a general-meaning combination of elements (class or object combination).

4. The effect (consequences) describes the effect of the pattern application and the problem that the usage pattern should weigh. Although we do not always refer to pattern effects when we describe design decisions, they are important for evaluating the costs and benefits of design selection and understanding usage patterns. Most software effects focus on measuring time and space, and they also express language and implementation issues. Because reuse is one of the elements of object-oriented design, pattern effects include its impact on system flexibility, extensibility, or portability, and explicitly listing these effects is useful for understanding and evaluating these patterns. The difference in starting point produces a different understanding of what a pattern is and what is not. A person's model may be a basic structural component for another person. In this book we will discuss patterns at a certain level of abstraction. Design mode does not describe the design of lists and h a s H tables, although they can be packaged in classes, reusable, or designed for the entire application or subsystem in a complex, specific domain. The design pattern in this book is a description of the classes that are used to solve general design problems in a given scenario and the objects that communicate with each other.

14th Week Software Engineering Course Summary