VELLORE INSTITUTE OF TECHNOLOGY
Vellore
SCHOOL OF COMPUTER SCIENCE AND ENGINEERING
Winter Semester 2024 - 2025
BCSE301L -Software Engineering
Digital Assignment - II
Instructions:
• Assignments are not teamwork, it’s an individual work.
• Each student must answer 5 scenarios based on the question mapping done at the end
this document.
• Copying from Internet sources is strictly prohibited.
• Marking Scheme ( (5*2) – (1 if Plag% >25 ||2 if Plag% > 35 || 4 if plag%>45||6 if plag%
Reg. No: 21BCB0125
Name: Suryadevara Meghana Chakravarthi
White-box testing, also known as clear box testing, glass box testing, or structural tes
involves examining the internal structure of the software being tested. Here are some scenari
where white-box testing would be appropriate:
1. **Unit Testing for Code Coverage:**
- Scenario: A software development team is working on a new feature that involves complex
business logic.
White-box Testing Scenario:
White-box testing is crucial for ensuring the internal logic of a software system functions corre
In this scenario, an e-commerce platform is implementing a dynamic pricing feature that cons
user loyalty status, product demand, and active promotions. The testing process begins with
statement coverage to verify every line of code executes properly, using test cases like
Gold members purchasing high-demand items during promotions. Branch coverage then
examines all decision points, such as different discount tiers applied based on user status and
demand levels. Path coverage further tests all possible logical flows, while boundary value an
checks edge cases like minimum and maximum loyalty points. Error handling tests confirm th
system properly manages invalid inputs without crashing.
The testing leverages tools like JUnit/TestNG for execution, JaCoCo/Cobertura for coverage
analysis, and SonarQube for code quality checks. The goal is to achieve 100% statement and
branch coverage, ensuring the pricing algorithm works accurately under all conditions. T
his comprehensive white-box approach validates the feature's reliability before deployment,
minimizing risks in production. The tests focus not only on expected scenarios but also edge
cases and error conditions, guaranteeing robust performance. By examining the internal code
structure, developers can identify and fix logic errors that might otherwise go undetected in
black-box testing.
5. **Code Review and Static Analysis:**
- Scenario: A software company is about to release a new version of its flagship product.
White-box Testing Scenario:
As part of the final quality assurance process before launching a major product update,
our development team implements rigorous white-box testing methodologies. We conduct
thorough manual code inspections where senior developers examine critical modules
line-by-line, paying special attention to complex business logic and integration points.
These reviews focus on identifying logical errors, potential performance bottlenecks,
and areas where code could be optimized for better maintainability.
Complementing the manual reviews, we run advanced static code analysis using
multiple scanning tools configured with our organization's specific quality thresholds.
These automated checks flag security vulnerabilities like buffer overflow risks, identify
dead code segments, and verify compliance with our internal coding standards.
We particularly scrutinize authentication modules, data validation routines, and error
handling implementations. The testing process includes generating detailed reports of
code metrics (cyclomatic complexity, coupling, etc.) which help us pinpoint areas needing
refactoring before release.
10. **Compatibility Testing across Multiple Platforms:**
- Scenario: A mobile app development company is releasing a new version of its application.
Black-box Testing Scenario:
The mobile app development team is conducting comprehensive black-box compatibility
testing for their upcoming release across iOS and Android platforms. Testers will verify
core functionality including login authentication, payment processing, and data s
ynchronization on various device models, operating system versions, and screen
resolutions without accessing internal code. They'll simulate real user conditions by
testing under different network speeds, battery levels, and interruption scenarios to ensure
consistent performance and user experience across all supported devices and environments.
The testing matrix includes popular iOS devices (iPhone 12-15, various iPads) running
iOS 16-17 and Android devices (Samsung Galaxy S21-S23, Google Pixel 6-8) running
Android 12-14. Test cases will validate responsive UI adaptation, biometric authentication,
offline functionality, and cross-platform feature parity while maintaining strict focus on
observable behavior rather than internal implementation. Cloud-based device farms
will supplement physical device testing to maximize platform coverage before the
production release.
14. **Penetration Testing for Security Assessment:**
- Scenario: An e-commerce platform wants to assess its vulnerability to cyber-attacks.
Black-box Testing Scenario:
To evaluate its cyber defenses, the e-commerce platform has engaged ethical hackers
to conduct blind penetration testing without any system knowledge. The security team
will approach the platform as malicious actors would, probing for weaknesses in customer
accounts, payment systems, and administrative portals. They will systematically test for
vulnerabilities including insecure data transmissions, weak password policies, and
improper input validation that could enable attacks like credit card skimming or customer
data theft.
The assessment will simulate sophisticated attack chains combining technical exploits with
social engineering tactics. Testers will attempt to compromise user sessions, intercept u
nencrypted data, and bypass security controls while documenting each successful breach.
Special attention will be given to the checkout process, where they'll test for vulnerabilities
that could allow transaction manipulation. The final report will prioritize risks based on
exploit difficulty and potential business impact, providing actionable recommendations
to harden the platform before the next major sales event.
19. **Method Call Mutations:**
- Scenario: An application invokes methods/functions to perform tasks.
Mutation Testing Scenario:
To evaluate the robustness of an application's method invocation logic, mutation testing
will be applied to systematically alter method calls within the codebase. Testers will
create mutants by modifying method signatures, including changes to parameter orders,
data types, and return values. Specific mutations will involve removing method calls entirely,
duplicating invocations, or substituting them with different but compatible methods to
verify error handling and validation logic. The test suite must detect these artificial defects
by failing appropriately when encountering mutated versions, thereby proving the tests
can catch real-world method invocation errors.
The testing process will focus on critical execution paths where method calls interface with
external systems or process sensitive data. Mutations will simulate common development
mistakes like incorrect parameter passing, null reference issues, and improper exception
handling. Each mutant version will be executed against the full test suite, with surviving
mutants indicating gaps in test coverage. Special attention will be given to method
chains and callback functions where errors might propagate silently. The results will
quantify test effectiveness through mutation scores and identify areas needing additional
test cases to achieve reliable fault detection.
