Introduction to Software Engineering (4) Software Coding Testing and Maintenance

1. Software programming

1.1 Good programming habits

Variable names are meaningful and use uniform naming rules.
Write self-documenting code (prologue comments or inline comments) and
consider maintainability in advance (values ​​that can exist in the form of constants are better in the form of variables).
Good visual arrangements can Improve code readability (indentation/blank lines)

1.2 Code Integration

1.2.1 One-time integration

Driver Modules and Stub Modules

question:

1. Extra driver stub writing
2. fault isolation

1.2.2 System Integration (SQA Team)

top-down integration

The processes of bfs and dfs are both possible.
bfs is more convenient to control the logical structure of the system.
dfs can realize the function of a certain branch as soon as possible.

Breadth first: control the logical consequences of the entire system

Depth first: implement a function as early as possible

advantage:

• fault isolation
• Stub modules are not wasted
• logically correct
• Ability to detect design (top-level) errors early
• Logical components are more fully tested

shortcoming:

• Lower-level software is tested late and insufficiently

bottom up

The processes of bfs and dfs are both possible

advantage:

• Fully tested low-level reusable components Very large operational components
• The driver module does not need to be written
• fault isolation

shortcoming:

• Design errors may be discovered later

sandwich integration

Logical components are integrated top-down,
operational components are integrated bottom-up,
and finally the two are integrated at the interface

In the object-oriented process, objects are bottom-up, and others are top-down

2. Software testing

The software testing process follows the " bottom-up, step-by-step integration " approach, that is, starting from small-scale testing and proceeding to large-scale testing step by step.

2.1 Software testing classification

• black box testing

Test according to specification (data-driven, functional or I/O-driven), ignore code - use specification to select test cases

• white box testing

Test to code (logic-driven, structured or path-oriented testing) - ignore specification - use code to select test cases

Each path through the artifact must be executed at least once

Detecting all paths does not prove that the program is correct

in conclusion

Specification testing, code testing, random testing are not reliable

2.2 Black box testing (user)

Avoid the huge amount of testing caused by data coverage (unit testing)

• equivalence test
• Boundary value analysis test

Functional testing based on black box testing

2.3 White Box Testing (Developers)

• statement coverage

Select enough test data that each statement in the program under test is executed at least once

• branch coverage

Not only should every statement be executed at least once, but every possible outcome of every predicate should be executed at least once

• condition coverage

Not only execute each statement at least once, but also make every condition in the decision expression take various possible results

• branch + condition override

Select enough test data so that each condition in the decision expression can obtain various possible results, and each decision expression can also obtain various possible results . It satisfies both judgment coverage and condition coverage

• Condition combination coverage

Select enough test data so that every possible combination of conditions in each decision expression occurs at least once . Satisfies the combined coverage of the conditions, and must also satisfy the judgment coverage, condition coverage and judgment/condition coverage

• path coverage

Select enough test data so that each possible path of the program is executed at least once , and if there are loops in the program diagram, each loop is required to go through at least once

Summarize

In principle, statement coverage is performed, that is, each statement that processes data is covered once

Neither statement coverage nor branch coverage can detect problems in logical judgments

The use case satisfies conditional coverage and branch coverage, but it still cannot check out the problem of logical judgment

2.4 Unit testing

 2.5 Integration testing

2.6 Confirmation test

2.7 Test Management

SQA Software Quality Assurance Group

• GUI integration testing: mouse clicks, keyboard input
• Product testing: testing the entire product from the user's point of view, based on simulated data
• Acceptance testing: based on real user data (correctness, robustness, performance, documentation) ( validity )

3. Software maintenance

3.1 Maintenance after handover

In a broad sense: the maintenance process during the entire software life cycle;
in a narrow sense: the software maintenance process that occurs after the software is delivered

• Corrective maintenance: Some errors were not found during acceptance and testing, but were discovered by users or maintainers
• Perfection maintenance: maintenance caused by further improving quality (adding functions, running speed, optimizing cohesive coupling of modules, optimizing documents, optimizing code)
• Adaptive maintenance: due to changes in the external environment (new compilers, new operating systems, new platforms)

Maintenance work is the most difficult, requiring practitioners to understand the entire life cycle of the software

• bug: small defect, undesired deviation
• defect: the software cannot fulfill the requirements correctly
• error & fault: fault, abnormal situation in the component, error is easy to solve
• failuer: failure, the software does not have the functions required at the time of design
• vulnerability: flaws, present in software architecture and design

Defect report: users or maintenance personnel need to fill in the error performance and specific operation process and other information in the defect report

3.2 Features of software maintenance

(1) There is a huge difference between structured maintenance and unstructured maintenance

• Unstructured maintenance : the only component is program code, and maintenance activities start with painstakingly evaluating program code , which is very expensive
• Structured maintenance : There is a complete software configuration, and the maintenance work starts from the evaluation of the design document

(2) Costly to maintain (understand)

(3) There are many problems in maintenance (understanding)

3.3 Maintenance and management work

bug report

Due to human and material resources, each defect sometimes cannot be fixed immediately, and requires an investigation management process

• Submit a bug report
• Check the previous defect report, if there is one before, give feedback directly, if not, fix it and find a solution, and then file the defect report, modification list, design document, and user manual
• Create a copy of the defect report and distribute it to all practitioners (repair time and other information) to facilitate the unified resolution of the same problem

  

Authorization for Changes to Software Products

Corrective maintenance:

• Assign maintainers to analyze and fix
• To test the modification, regression testing is required
• modify document
• Prologue comments for updated code

Perfect maintenance and perfect maintenance:

• Requirements change report (functional or performance changes to requirements)

The final product must be tested by the SQA team before distribution, and the baseline and private copy principles must be followed

Software reverse engineering is a process from concrete to abstract.