Skip to content

Commit 377bed4

Browse files
committed
ADD: software testing topic
1 parent c17c52c commit 377bed4

File tree

1 file changed

+278
-0
lines changed

1 file changed

+278
-0
lines changed

README.md

+278
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,7 @@ If you're interested in contributing to this project, please take a moment to re
5656
- [DBMS(Database Management System)](#dbms)
5757
- [Cryptography](#cryptography)
5858
- [Theory of Computation](#theory-of-computation)
59+
- [Software Testing](#software-testing)
5960

6061

6162
## Introduction
@@ -1072,6 +1073,282 @@ A problem is regarded as inherently difficult if its solution requires significa
10721073

10731074
Closely related fields in theoretical computer science are the analysis of algorithms and computability theory. A key distinction between the analysis of algorithms and computational complexity theory is that the former is devoted to analyzing the number of resources needed by a particular algorithm to solve a problem, whereas the latter asks a more general question about all possible algorithms that could be used to solve the same problem. More precisely, computational complexity theory tries to classify problems that can or cannot be solved with appropriately restricted resources. In turn, imposing restrictions on the available resources is what distinguishes computational complexity from computability theory: the latter theory asks what kinds of problems can, in principle, be solved algorithmically.
10741075

1076+
## Software Testing
1077+
1078+
Software testing is a critical process in software development that ensures the quality and functionality of software applications. It involves evaluating and verifying that a software program or application does what it is supposed to do. The goal is to identify any bugs or issues so they can be fixed before the software is released to users.
1079+
1080+
## What is Software Testing?
1081+
1082+
Software testing is the process of executing a program or application with the intent of finding software bugs. It can also be defined as the process of validating and verifying that a software program or application:
1083+
1084+
- Meets the requirements that guided its design and development
1085+
- Works as expected
1086+
- Can be implemented with the same characteristics
1087+
- Satisfies the needs of stakeholders
1088+
1089+
## Importance of Software Testing
1090+
1091+
1. **Quality Assurance**: Ensures that the software is of high quality.
1092+
2. **Security**: Identifies vulnerabilities and ensures that data is protected.
1093+
3. **Cost-Effective**: Detecting and fixing issues early in the development cycle is cheaper than doing so after release.
1094+
4. **Customer Satisfaction**: Delivers a product that meets user expectations and needs.
1095+
5. **Performance**: Ensures that the software performs well under various conditions.
1096+
1097+
## Types of Software Testing
1098+
1099+
### 1. Manual Testing
1100+
1101+
Manual testing involves manually executing test cases without using any automation tools. Testers play the role of end-users and use most of the application's features to ensure correct behavior.
1102+
1103+
### 2. Automated Testing
1104+
1105+
Automated testing uses specialized tools to execute test cases automatically. This is useful for large projects where manual testing would be time-consuming and less efficient.
1106+
1107+
## Common Testing Techniques
1108+
1109+
### 1. Unit Testing
1110+
1111+
- **Definition**: Tests individual units or components of the software.
1112+
- **Purpose**: Ensures that each part of the software performs as expected.
1113+
- **Tools**: JUnit, NUnit, TestNG.
1114+
1115+
### 2. Integration Testing
1116+
1117+
- **Definition**: Tests the integration of different modules or components of the software.
1118+
- **Purpose**: Ensures that integrated modules work together correctly.
1119+
- **Tools**: JUnit, NUnit, TestNG.
1120+
1121+
### 3. System Testing
1122+
1123+
- **Definition**: Tests the complete and fully integrated software product.
1124+
- **Purpose**: Ensures the system meets the specified requirements.
1125+
- **Tools**: Selenium, QTP.
1126+
1127+
### 4. Acceptance Testing
1128+
1129+
- **Definition**: Conducted to determine if the system satisfies the business requirements.
1130+
- **Purpose**: Validates the end-to-end business flow.
1131+
- **Tools**: Cucumber, FitNesse.
1132+
1133+
## Software Testing Life Cycle (STLC)
1134+
1135+
1. **Requirement Analysis**: Understanding the requirements and identifying the testable aspects.
1136+
2. **Test Planning**: Defining the strategy and planning resources.
1137+
3. **Test Case Development**: Writing detailed test cases.
1138+
4. **Test Environment Setup**: Preparing the environment in which tests will be executed.
1139+
5. **Test Execution**: Running the tests.
1140+
6. **Test Cycle Closure**: Closing the test cycle and evaluating the results.
1141+
1142+
## There Are Two Types of Testing That are
1143+
1. **WhiteBox Testing**
1144+
2. **BlackBox Testing**
1145+
1146+
## 1.White Box Testing
1147+
1148+
White box testing, also known as clear box testing, glass box testing, transparent box testing, or code-based testing, is a method of testing software that involves looking into the internal structures or workings of an application. Unlike black box testing, which focuses on the outputs generated in response to selected inputs and execution conditions, white box testing is performed by examining the code and the internal logic of the software.
1149+
1150+
### Key Concepts of White Box Testing
1151+
1152+
1. **Code Coverage**:
1153+
- White box testing aims to cover as much of the code as possible. This includes paths, branches, statements, and conditions within the code.
1154+
- Types of code coverage include:
1155+
- **Statement Coverage**: Ensures that each line of source code has been executed and tested.
1156+
- **Branch Coverage**: Ensures that every branch (i.e., each possible path) from each decision point is executed.
1157+
- **Path Coverage**: Ensures that every possible path through a given part of the code is executed.
1158+
1159+
2. **Internal Workings**:
1160+
- The tester needs to understand the internal implementation of the code, including the control flow, data flow, and how the different parts of the code interact with each other.
1161+
- Knowledge of programming languages, code structure, and the application's architecture is essential.
1162+
1163+
### Techniques of White Box Testing
1164+
1165+
1. **Unit Testing**:
1166+
- Focuses on testing individual functions or methods within the code.
1167+
- Usually performed by developers during the development phase.
1168+
1169+
2. **Integration Testing**:
1170+
- Tests the interaction between integrated units or components.
1171+
- Ensures that the units or components work together as intended.
1172+
1173+
3. **Static Analysis**:
1174+
- Involves examining the code without executing it.
1175+
- Tools can be used to analyze the code for potential errors or code quality issues.
1176+
1177+
4. **Dynamic Analysis**:
1178+
- Involves executing the code and examining its behavior.
1179+
- Helps in identifying runtime errors and performance issues.
1180+
1181+
### Advantages of White Box Testing
1182+
1183+
1. **Thorough Testing**:
1184+
- Since the tester has knowledge of the internal workings, more comprehensive testing is possible, covering more scenarios and edge cases.
1185+
1186+
2. **Early Bug Detection**:
1187+
- Issues can be detected and resolved early in the development cycle, reducing the cost of fixing bugs later.
1188+
1189+
3. **Optimization**:
1190+
- Helps in optimizing the code by identifying inefficient or unnecessary parts of the code.
1191+
1192+
4. **Security**:
1193+
- Allows for thorough security testing by examining the code for vulnerabilities.
1194+
1195+
### Disadvantages of White Box Testing
1196+
1197+
1. **Complexity**:
1198+
- Requires a deep understanding of the code and the technology stack, which can be complex and time-consuming.
1199+
1200+
2. **Limited Scope**:
1201+
- Focuses on the internal code structure, potentially missing issues related to the overall system behavior and user experience.
1202+
1203+
3. **Maintenance**:
1204+
- Test cases need to be updated with changes in the code, which can add to the maintenance overhead.
1205+
1206+
### When to Use White Box Testing
1207+
1208+
- **During Development**:
1209+
- White box testing is most effective during the development phase when the internal code structure is accessible and changes can be easily made.
1210+
1211+
- **For Critical Systems**:
1212+
- Systems that require a high level of reliability and security benefit greatly from white box testing.
1213+
1214+
- **Performance Optimization**:
1215+
- When performance is a key requirement, white box testing helps identify and optimize inefficient code.
1216+
1217+
## 2.Black Box Testing
1218+
1219+
Black box testing, also known as behavioral testing, is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This type of testing focuses on the input and output of the software system, ensuring that it behaves as expected according to the requirements.
1220+
1221+
### Key Concepts of Black Box Testing
1222+
1223+
1. **Functional Testing**:
1224+
- Focuses on testing the functional requirements of the software.
1225+
- Verifies that the application performs all intended functions correctly.
1226+
1227+
2. **Non-Functional Testing**:
1228+
- Focuses on testing non-functional aspects such as performance, usability, and reliability.
1229+
- Ensures that the application meets specific non-functional criteria.
1230+
1231+
3. **User Perspective**:
1232+
- Black box testing is performed from the user's perspective.
1233+
- The tester does not need knowledge of the internal code structure or implementation.
1234+
1235+
### Techniques of Black Box Testing
1236+
1237+
1. **Equivalence Partitioning**:
1238+
- Divides input data into equivalent partitions that can be tested.
1239+
- Assumes that all values within a partition behave similarly.
1240+
1241+
2. **Boundary Value Analysis**:
1242+
- Focuses on testing the boundaries between partitions.
1243+
- Identifies edge cases where bugs are more likely to occur.
1244+
1245+
3. **Decision Table Testing**:
1246+
- Uses decision tables to represent and analyze combinations of inputs and their corresponding outputs.
1247+
- Helps in testing complex business logic and rules.
1248+
1249+
4. **State Transition Testing**:
1250+
- Tests the software's behavior under various states and transitions between states.
1251+
- Useful for applications with a finite number of states and transitions.
1252+
1253+
5. **Use Case Testing**:
1254+
- Based on use cases that describe interactions between users and the software.
1255+
- Ensures that the software fulfills its intended use cases.
1256+
1257+
### Advantages of Black Box Testing
1258+
1259+
1. **User-Focused**:
1260+
- Ensures that the software meets user expectations and requirements.
1261+
- Tests the application from the end user's perspective.
1262+
1263+
2. **No Need for Internal Knowledge**:
1264+
- Testers do not need to understand the internal code or logic.
1265+
- Allows for independent testing by separate QA teams.
1266+
1267+
3. **Effective for Large Systems**:
1268+
- Suitable for large and complex systems where understanding the internal workings is impractical.
1269+
1270+
4. **Unbiased Testing**:
1271+
- Testers can identify issues without being influenced by the internal implementation.
1272+
- Encourages unbiased and objective testing.
1273+
1274+
### Disadvantages of Black Box Testing
1275+
1276+
1. **Limited Coverage**:
1277+
- May miss internal errors or issues that are not apparent from the external behavior.
1278+
- Focuses only on input and output, potentially overlooking underlying problems.
1279+
1280+
2. **Inefficiency in Identifying Certain Bugs**:
1281+
- Less effective in identifying hidden errors or performance issues within the code.
1282+
- Requires a large number of test cases to cover all possible scenarios.
1283+
1284+
3. **Test Case Creation**:
1285+
- Creating comprehensive test cases can be challenging without knowledge of the internal code.
1286+
- Relies heavily on requirements and specifications, which must be thorough and accurate.
1287+
1288+
### When to Use Black Box Testing
1289+
1290+
- **During Acceptance Testing**:
1291+
- Ensures that the software meets the specified requirements and is ready for deployment.
1292+
1293+
- **For User Interface Testing**:
1294+
- Validates that the user interface behaves as expected and is user-friendly.
1295+
1296+
- **For Functional Testing**:
1297+
- Verifies that the application performs its intended functions correctly.
1298+
1299+
## Failures, Errors, and Faults
1300+
1301+
In software testing, understanding the distinctions between failures, errors, and faults is crucial for identifying and addressing issues effectively. These terms, although often used interchangeably, have specific meanings in the context of software quality and testing.
1302+
1303+
### Faults (Bugs or Defects)
1304+
1305+
- **Definition**: A fault, also known as a bug or defect, is an incorrect step, process, or data definition in a software program. It is a flaw in the code or logic that can cause the software to behave unexpectedly or produce incorrect results.
1306+
- **Causes**: Faults can arise from various sources, including:
1307+
- Mistakes made by developers during coding or design.
1308+
- Incomplete or incorrect requirements.
1309+
- Miscommunication among team members.
1310+
- Lack of understanding of the system's intended functionality.
1311+
1312+
- **Example**: A developer might write an incorrect formula to calculate the total price, such as using addition instead of multiplication.
1313+
1314+
### Errors
1315+
1316+
- **Definition**: An error is a human action or omission that produces an incorrect result. In the context of software, an error typically refers to a discrepancy between the expected and actual behavior of the software during execution.
1317+
- **Causes**: Errors can be introduced by:
1318+
- Incorrect logic or algorithms.
1319+
- Typographical mistakes in the code.
1320+
- Incorrect assumptions about how the software should operate.
1321+
- Misinterpretation of requirements.
1322+
1323+
- **Example**: An error occurs when a user inputs invalid data, causing the software to perform an incorrect calculation or crash.
1324+
1325+
### Failures
1326+
1327+
- **Definition**: A failure is the manifestation of a fault during the execution of the software. It occurs when the software does not perform as expected or produces incorrect results due to the presence of one or more faults.
1328+
- **Causes**: Failures are caused by underlying faults in the software and can be triggered by:
1329+
- Specific conditions or inputs that expose the fault.
1330+
- Interactions between different parts of the software.
1331+
- Changes in the operating environment.
1332+
1333+
- **Example**: A failure happens when a shopping cart application incorrectly calculates the total price for items due to a fault in the pricing algorithm.
1334+
1335+
### Relationships Between Faults, Errors, and Failures
1336+
1337+
1. **Faults Lead to Errors**: Faults in the software code or design cause errors during the execution of the software.
1338+
2. **Errors Lead to Failures**: When an error occurs during execution, it can result in a failure if the software does not handle the error properly.
1339+
3. **Failures Indicate Faults**: The occurrence of a failure indicates that there is an underlying fault in the software that needs to be identified and corrected.
1340+
1341+
### Example Scenario
1342+
1343+
Consider an online banking application:
1344+
1345+
- **Fault**: A developer accidentally uses the wrong interest rate formula in the code.
1346+
- **Error**: When a user requests an interest calculation, the software calculates the interest incorrectly due to the faulty formula.
1347+
- **Failure**: The user receives an incorrect interest amount, leading to a failure in the application's functionality.
1348+
1349+
1350+
1351+
10751352

10761353

10771354
## Contributors
@@ -1285,6 +1562,7 @@ Closely related fields in theoretical computer science are the analysis of algor
12851562
<td align="center" valign="top" width="16.66%"><a href="http://namberino.github.io"><img src="https://avatars.githubusercontent.com/u/70761157?v=4?s=50" width="50px;" alt="nam"/><br /><sub><b>nam</b></sub></a><br /><a href="https://github.com/shhossain/computer_science/commits?author=namberino" title="Documentation">📖</a></td>
12861563
<td align="center" valign="top" width="16.66%"><a href="https://github.com/shaanrxx"><img src="https://avatars.githubusercontent.com/u/62669918?v=4?s=50" width="50px;" alt="Shaan Rehsi"/><br /><sub><b>Shaan Rehsi</b></sub></a><br /><a href="#content-shaanrxx" title="Content">🖋</a></td>
12871564
<td align="center" valign="top" width="16.66%"><a href="https://github.com/mjung1"><img src="https://avatars.githubusercontent.com/u/86390269?v=4?s=50" width="50px;" alt="mjung1"/><br /><sub><b>mjung1</b></sub></a><br /><a href="https://github.com/shhossain/computer_science/commits?author=mjung1" title="Documentation">📖</a></td>
1565+
<td align="center" valign="top" width="16.66%"><a href="https://github.com/karthi9772"><img src="https://avatars.githubusercontent.com/u/122985751?v=4" width="50px;" alt="karthi G"/><br /><sub><b>karthi9772</b></sub></a><br /><a href="https://github.com/shhossain/computer_science/commits?author=karthi9772" title="Documentation">📖</a></td>
12881566
</tr>
12891567
</tbody>
12901568
</table>

0 commit comments

Comments
 (0)