Final Review of Software Quality Assurance and Testing (2)

Table of contents

Introducing local data structure testing

Example:

Introduce the stub module and driver module

Introduce a one-shot method build test

 Introduce system integration testing

Introduce top-up and top-down integration methods respectively

Example:

Tell an example of using top-down integration and using a depth-first strategy

 Introduce the big stick integration method

---

Introducing local data structure testing

Local data structure testing is a software testing method used to verify and evaluate the correctness and effectiveness of data structures in programs. It focuses on testing independent data structures in the program without considering the interaction with other modules or components.

In the local data structure test, focus on the following aspects:

1. Creation of data structures: Test the creation of data structures, including correct initialization, memory allocation, and initialization values.

2. Operations on data structures: Test operations on data structures, such as insert, delete, update, and search. By verifying that these operations modify the data structure as expected, and how the data structure behaves under various operational situations.

3. Boundary conditions of the data structure: test the behavior of the data structure under boundary conditions, including special cases such as the minimum value, maximum value, and null value of the test data structure.

4. Consistency and integrity of the data structure: Test the consistency and integrity of the data structure to ensure that the data in the data structure remains correct and complete. This includes testing associations and constraints between data structures.

5. Error Handling and Exceptions: Test the behavior of data structures in the face of errors and exceptions. For example, test how well a data structure handles invalid input, out-of-bounds operations, or other unusual conditions.

Local data structure testing usually requires designing a set of test cases for a specific data structure, covering different scenarios and operations, to ensure the correctness and stability of the data structure. The design of test cases should consider various possible input and operation sequences, including normal cases, edge cases and abnormal cases.

By performing partial data structure testing, errors in data structure implementation, boundary conditions, and exception handling problems can be found and corrected, and the quality and reliability of the data structure can be improved, thereby improving the stability and performance of the overall software system.

Example:

When it comes to local data structure testing, we can use a linked list as an example.

Consider a simple linked list data structure where each node contains a value and a pointer to the next node. We can design the following test cases to test the local data structure of the linked list:

1. Create a linked list: Test the creation process of the linked list to ensure that the head node and pointer of the linked list are initialized correctly.
2. Insert operation: Test inserting new nodes at different positions in the linked list, including inserting nodes at the head, middle and tail of the linked list. Verify that the structure and pointers of the linked list are updated correctly after the node is inserted.
3. Delete operation: test to delete nodes in the linked list, including deleting the nodes at the head, middle and tail of the linked list. Verify that the structure and pointers of the linked list are updated correctly after node deletion.
4. Lookup operation: The test looks up the nodes in the linked list by value, including existence and non-existence. Verify that lookup operations return correct nodes or incorrect results.
5. Boundary conditions: Test the boundary conditions of the linked list, such as an empty linked list, a linked list with only one node, etc. Make sure the behavior of the linked list and the correctness of the pointers in these special cases.
6. Abnormal conditions: Test the behavior of the linked list in the face of abnormal conditions, such as deleting or finding an empty linked list, or inserting invalid nodes, etc. Verify that the linked list can handle these exceptions correctly and perform error handling.

Through these test cases, we can verify the correctness and stability of operations such as creation, insertion, deletion, and lookup of the linked list data structure. This helps to spot potential problems and bugs in the linked list implementation, ensures that the linked list functions and behaves as expected, and thus improves the quality and reliability of the overall software system.

Introduce the stub module and driver module

Stub Module and Driver Module are two commonly used test assisting technologies in software testing, which are used to test the interaction and integration between modules or components.

1. Stub Module:

   • A stub module is a mock implementation used to replace a dependent module or component in the module under test .
   • Stub modules are usually designed to have the same interface as the module being replaced so that they can be replaced seamlessly during testing.
   • The stub module is mainly used to simulate the behavior of the dependent module to provide the input required by the tested module and return the predetermined output.
   • The goal of the stub module is to isolate the module under test so that the module under test can be tested independently without being affected by dependent modules.
   • Stub modules are typically used in the unit test and integration test phases of a test module.

2. Driver Module:

   • A driver module is a module used to trigger the execution of a module or component under test.
   • The driver module is usually designed to have the same interface as the tested module, so that the function of the tested module can be called correctly.
   • The goal of the driver module is to simulate calls to the module under test and provide appropriate input data to verify the behavior and output of the module under test.
   • The driver module is usually used in the integration test and system test phase of the test module.

By using stub modules and driver modules, isolation and simulation between modules can be achieved, so that module testing and integration testing can be performed better. The stub module and the driver module can provide the required input and simulate the behavior of other modules, so that the tested module can be tested independently and ensure the correctness of its function and interaction.

Introduce a one-shot method build test

One-off method construction testing is a method used in software testing, which aims to quickly build a set of test cases in a limited time to find as many defects as possible in the software.

Here are the general steps and considerations for building a test for a one-off method:

1. Determine the test objectives: clarify the objectives and scope of the test, and understand the characteristics and requirements of the function, module or system to be tested.

2. Collect information: Collect relevant information about the system, including requirements documents, design documents, user manuals, etc. Understand the system's inputs, outputs, functions, and boundary conditions.

3. Formulate test strategy: According to the test objectives and the characteristics of the system, formulate an appropriate test strategy. Identify testing methods, techniques and tools.

4. Design test cases: Design test cases using appropriate test design techniques such as equivalence class partitioning, boundary value analysis, cause-and-effect diagrams, etc. Consider testing requirements in terms of functionality, performance, security, etc.

5. Prioritization: Prioritize the test cases according to the test objectives and the importance of the system. Prioritize important and critical test cases for execution.

6. Writing test cases: According to the designed test cases, write specific test scripts or test cases. Ensure the accuracy and completeness of test cases.

7. Execute Test: Execute the test cases according to the predetermined test strategy and sequence. Document test results and defects found.

8. Defect management: Record, track and repair the found defects in a timely manner. Ensure that defects are properly addressed.

9. Summary and Feedback: After the test is completed, conduct a test summary and evaluation. Feedback test results to the development team, and provide test reports and suggestions.

In one-off method construction testing, the focus is on constructing as valid test cases as possible within a limited time to uncover potential defects. Therefore, the choice of test design techniques and the prioritization of test cases are critical. At the same time, records and feedback during the testing process are also necessary in order to track and solve the problems found in time.

 

wrong notes here 

right idea here

 

 Introduce system integration testing

System integration testing is a stage of software testing, which aims to verify whether different software modules or subsystems can work together normally after integration, so as to ensure the function, performance and stability of the whole system.

The following are general steps and key considerations for system integration testing:

1. Requirements Analysis: Carefully review the system's requirements specification to ensure that you understand the system's functionality, performance, and interface requirements.

2. Design test strategy: Based on requirement analysis, develop strategy and plan for system integration test. Determine the scope, objectives, resources and time constraints of the test, etc.

3. Determine the integration order: Determine the integration order of the modules according to the module dependencies of the system. Usually, you start with the lowest-level modules and gradually integrate to the top-level modules.

4. Develop integration test cases: design and write integration test cases according to requirements specifications and design documents. Test cases should cover each function, interface and abnormal situation of the system.

5. Configure the test environment: establish an appropriate test environment, including hardware, operating system, network configuration, etc., to support the integration test.

6. Execute integration tests: Execute integration test cases according to the test strategy and integration sequence. During testing, test results, problems and defects are recorded.

7. Defect management: record, classify and track the found defects. Ensure that defects are properly addressed and validated.

8. Verify system functions: verify whether the system functions and business processes are integrated according to the requirements specifications. Ensure correct data transfer and processing between different modules.

9. Verify system performance: Evaluate system performance metrics such as response time, throughput, and resource utilization. Make sure your system performs well under load and stress.

10. Verify system stability: Conduct long-term running and stability tests to verify the reliability and stability of the system under continuous operation and abnormal conditions.

11. Generate test report: organize test results, problems and defects, and generate system integration test report. The report should contain information such as test coverage, defect statistics, and test evaluation.

System integration testing is a key step to ensure the functionality and performance of the entire software system. Through proper integration sequence and meticulous test design, interface problems between modules, data consistency problems and integration exceptions can be effectively discovered and resolved. This helps to ensure that the system, when integrated, will function as expected and meet the needs of the user and the system.

Introduce top-up and top-down integration methods respectively

Top-down and bottom-up are two common software system integration methods, which are used to gradually integrate the components of the system together to verify the correctness of their functions and interfaces.

1. Top-Down Integration (Top-Down Integration):

   • Top-down integration is a step-by-step integration method that starts from the highest-level components of the system and gradually integrates lower-level components downward.
   • In top-down integration, the top-level components of the system are implemented and integrated first, and then gradually drill down to the next level by using stub modules (stubs) to replace unfinished low-level components.
   • The integration of each top-level component depends on the components at the next level, and the stub modules are gradually replaced until all components are integrated to form a complete system.
   • The advantage of top-down integration is that it can verify the overall architecture and high-level functions of the system as early as possible, but it may take a long time to complete the integration and development of the underlying components.

2. Bottom-Up Integration:

   • Bottom-up integration is a step-by-step integration method that starts with the lowest level components of the system and gradually integrates higher level components upwards.
   • In bottom-up integration, the lowest-level components are implemented and integrated first, and then gradually upgraded to the next level by using the driver module (driver) to call the component.
   • The integration of each bottom-level component depends on the upper-level components, and the driver modules are gradually replaced until all components are integrated to form a complete system.
   • The advantage of bottom-up integration is that it can quickly complete the integration and development of the underlying components, but it takes a long time to verify the overall architecture and high-level functions of the system.

Top-down and bottom-up are two different integration approaches, each with advantages and disadvantages. Top-down integration can verify the high-level functions and architecture of the system earlier, but it takes a long time to complete the integration of the underlying components . Bottom-up integration can complete the integration of the underlying components faster, but it takes longer to verify the overall architecture of the system. In practical applications, you can choose a suitable integration method according to project requirements and time constraints, or combine the two methods for hybrid integration.

Example:

Suppose we are developing an e-commerce website, which contains the following main components: user management module, product management module, shopping cart module and order management module. We will use both top-down and bottom-up approaches for integration.

1. Top-down integration:

   • First, we start from the top level of the system and implement the user management module. This module is responsible for functions such as user registration, login and personal information management.
   • Use stub modules to replace the unfinished product management module, shopping cart module and order management module to simulate their behavior when testing the user management module.
   • Then, we integrated the product management module and tested its functions with real user management modules and stub modules. This validates the interface between the user management module and the product management module.
   • Next, we integrate the shopping cart module and the order management module in turn, and use the real user management module, commodity management module and stub module to test them.
   • Finally, all the modules are integrated to form a complete system, and the overall function and interface are verified.

2. Bottom-up integration:

   • First, we start with the lowest-level commodity management module, implement and integrate this module. This module is responsible for functions such as adding, editing and deleting products.
   • Use the driver module to call the commodity management module to test its functions. This allows verification of the behavior and interface of the commodity management module.
   • Next, we integrate the shopping cart module and test it with a real product management module and driver module. This validates the interface between the shopping cart module and the item management module.
   • Then, we integrated the order management module and user management module in turn, and tested them with the real shopping cart module, product management module and driver module.
   • Finally, all the modules are integrated to form a complete system, and the overall function and interface are verified.

Through the above examples, you can feel the difference between top-down and bottom-up integration methods. Top-down integration starts from the highest level of the system and gradually integrates downwards. First, the top-level modules are tested, and then the lower-level modules are tested layer by layer. Bottom-up integration starts from the bottom layer and gradually integrates upwards. First, the bottom-level modules are tested, and then the upper-layer modules are upgraded and tested layer by layer. The difference between the two approaches lies in the order of integration and the module substitution (stub or driver) used during integration, as well as when to verify the overall functionality and interfaces of the system.

Tell an example of using top-down integration and using a depth-first strategy

Suppose we are developing a social media application, which includes user management module, message management module and friend management module. We will use top-down integration with a depth-first strategy for integration.

1. User management module:

   • We start from the top layer of the system and implement the user management module, which is responsible for functions such as user registration, login and personal information management.
   • First, we run an integration test on the user registration functionality. We create a user registration test case to verify that the user can successfully register and the registered user information can be saved correctly.
   • Next, we test the user login functionality. We create a login test case to verify that the user can log in with the correct credentials and can enter the system after logging in.
   • Finally, we test personal information management features, such as users being able to edit their profile, change their password, etc. We create corresponding test cases to verify that these functions work correctly.

2. Message management module:

   • After the user management module passed the basic test, we started to integrate the message management module.
   • First, we test the send message functionality. We create a test case to verify that a user can successfully send a message to another user, and that the message is correctly delivered to the recipient.
   • Next, we test the function of receiving messages. We create corresponding test cases to verify that users can receive messages sent by other users, and the messages can be displayed correctly.
   • Finally, we test the message deletion functionality. We create a test case for deleting a message, verifying that a user can delete a message he or she has received and that the message can be removed from the system.

3. Friend management module:

   • After the message management module passes the basic test, we integrate the friend management module.
   • First, we test the add friend function. We create a test case to verify that users can successfully add other users as friends, and the friendship relationship can be established correctly.
   • Next, we test the delete friend function. We create a corresponding test case to verify that the user can delete the added friend, and the friend relationship can be removed correctly.
   • Finally, we test the find friends functionality. We create a test case for finding friends, verify that users can find other users according to conditions, and the search results can be displayed correctly.

Through the above examples, we used the top-down integration method and adopted the depth-first strategy, first completed the basic integration and testing of the user management module, and then gradually integrated other modules and tested them in the order of depth-first. This can ensure the correctness of the system's core functions and top-level modules, and gradually verify and integrate the lower-level modules to ensure the correctness of the overall system's functions and interfaces.

 

 

 

 Introduce the big stick integration method

Big Bang Integration Testing (Big Bang Integration Testing) is a software integration testing method that integrates all components together for testing at a later stage in the development process . Compared with other integration methods, the big stick integration method integrates the components of the whole system together instead of integrating them one by one or layer by layer.

The following are the characteristics and steps of the big stick ensemble method:

Features:

1. Rapid integration: The big stick integration approach allows all components to be integrated into the system in one go, allowing rapid holistic testing.
2. Highly parallel: Since all components are integrated at the same time, there is no need to rely on the completion of other components, so the testing process can be carried out in parallel.

step:

1. Development and testing are independent: In the big stick integration approach, development and testing are usually done in parallel. The development and unit testing of individual components can be carried out in an independent environment.
2. Component Integration: Once the development and unit testing of individual components is complete, they are integrated into the system in one go. At this point, all components are loaded and connected simultaneously.
3. Overall testing: After the integration is completed, conduct overall functional and interface testing. During this phase, testers test the entire system, verifying its functionality, performance, and stability.
4. Problem solving: If a problem or bug is found in the overall testing, the developer will debug and fix it based on the test results.
5. Repeat testing: After fixing a problem, retest to ensure the effectiveness of the fix and the correctness of the overall system.

The advantage of the stick ensemble approach is its speed and high parallelism. It is suitable for relatively simple systems, where there are few dependencies among the various components, and the integration of components has little impact on the system as a whole. However, because this method postpones the integration and testing of the entire system to the later stage of development, it may lead to a large number of problems and errors found in the integration stage, increasing the workload of repairing and debugging. Therefore, the big-stick integration approach requires developers and testing teams to work closely together to ensure that the integrated system works stably.