Software testing is a crucial part of any software development to ensure that the software is bug-free, user-friendly, fulfills all the customer’s requirements. Although testing plays a significant role in ensuring the product’s reliability, it’s not given much importance in the majority of the cases because it incurs a cost that feels extra to the majority of the stakeholders. The process of testing full software and reverting it to the development team for bug fixing is hugely time-consuming. Things get worse, then the retesting procedure comes into play, and the whole cycle continues until the product is bug-free.
Ideally, in project management, the cushion is always added for the development process, whereas the testing phase is under stress with short deadlines. There is also an observation that the majority of the issues found at debugging time are related to design flaws that cause exceptions in the final product. If proper design patters are taken into consideration during the development cycle, fewer chances are there for a big scale application failure during testing. Software testing models address two significant problems.
- Testing cannot wait till the end
- The end-product may be too complicated to under quality assurance due to the inter dependability of the modules
A model is an abstraction of a problem to solve it by identifying crucial aspects, and focusing only on those and pretending that other details don’t exist. This simplification serves to be extremely helpful in performing robust analysis, for instance, memory leaks identification, security analysis, proof of correctness, etc. The concept of using an abstracted model is like solving a computational or any real-life problem by simplifying it and solving small modules and use their solutions to get the answer to the bigger question.
There are generally two types of model-based testing:
- Source-code based
- Behavior-based
Source-code based model
Source code based models are designed to visualize the execution path of the code. This model makes it easy to create tests using graphs like Control Flow Graphs (CFGs). A control flow graph is a directed graph that represents the flow of control through the program code. The graph nodes represent basic blocks of program statements that always execute in a specific sequence, and the edges connect nodes in the pattern in which they get completed. Additionally, multiple edges indicate conditional statements (if statements, switches, loop).
Conditional statements are explained below with the simple code snippets and their Control Flow Graphs (CFGs).
If else statements
The code below checks that if ‘x’ is even, it prints “even” and otherwise prints “odd.” In the end, the value of x is 8.
if (x%2 == 0) {
cout << “even”;
}
else {
cout << “odd”;
}
x = 8;
The control flow graph of the above code will be as follow. Conditional statements are depicted in rhombus, whereas the unconditional is shown in a rectangular box.
Switch Statements
The code below prints “case1” if the value of x is one, and prints “case 2” if the value of x is ‘2’. In the end, it adds two variables and stores their result in variable y.
Switch (x) {
case 1:
cout << “case 1”;
case 2:
cout << “case 2”;
}
int y = x + z;
The CFG of the code is:
Loop
In the code below, the initial value of x is set to 10. Then, the while loop runs until the values of x becomes 0 and then prints “x is equal to 0”.
x = 10;
while (x >10){
x--;
}
cout << “x is equal to 0”;
The CFG of the code is:
Advantages of CFGs
With the CFGs of the codes to show the execution paths of the code, it is easier to test the working of the code without getting into the unnecessary code details. Furthermore, it can easily indicate the entry and exit points of the code and the unreachable blocks of the codes, which can’t be executed in any way. Moreover, the test cases can be designed to check the boundaries values of the conditional blocks to ensure the correct working of the blocks.
Behavioral Model
The behavioral model is based on the mapping of the system’s functionality to a series of abstract program states. Unlike a code-based model where a standard method of modeling the behavior of any system is a directed graph.
The simple state machine diagram of a digital watch is used to prescribe the behavioral model of the system. The circles represent the current state of the system, and arrows represent events. Whenever an event occurs, the system changes its state depending on the direction of the arrow.
The diagram explains the general working of the digital watch.
- Whenever a mode button is pressed once, the watch goes into the hour mode. As many times as the advance button is pressed, the hour is incremented by 1.
- If the mode is pressed the second time, the watch goes into the minute mode. The minute is incremented by one whenever the advance button is pressed.
- When the mode button is pressed the third time, the second is incremented by 1 with every pressing of the advance button.
- Pressing the mode button again sends the watch back into the hour mode.
As per the diagram, the user can’t directly go into the incrementing state, and if the advance button of the watch will is pressed directly, the watch will keep showing the current time.
Advantages of the state machine diagrams
Ideally, it is recommended to model the complex behavior of the system in its life cycle without any code that helps in the appropriate design later on. However, modeling a state diagram is not a substitute for a program, but only a way to explore and understand the working of a program.
Lastly, the testing models are designed on the basis of the system specification. The well-formed, accurate, and consistent model always reflects the actual program. Hence, these abstract models can be tested against the software’s requirements to ensure the software’s correctness, security, and usability before its complete development and dispatching.
