Scribd
Upload
16 views7 pages

Harare Institute of Technology School of Information Science and Technology Dept: Information Technology

Uploaded by

gracejamu4
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
16 views7 pages

Harare Institute of Technology School of Information Science and Technology Dept: Information Technology

Uploaded by

gracejamu4
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

HARARE INSTITUTE OF TECHNOLOGY

SCHOOL OF INFORMATION SCIENCE AND TECHNOLOGY


DEPT: INFORMATION TECHNOLOGY

NAME: EMMANUEL LEON ISHEANESU CHINJEKURE

REG NUM: H230393F

PART: 2.1

COURSE NAME: SOFTWARE TESTING

COURSE CODE: IIT2106

ASSIGNMENT 2
1. A bank has developed a new mobile banking application. The application allows users
to check account balances, transfer money, pay bills, and manage account settings.
Design a test plan to assess the security of the login and money transfer features,
Include the types of tests you would perform and the tools you would use. (13)

Test Plan for Mobile Banking Application Security

1. Introduction

This test plan focuses on assessing the security of the login and money transfer features of the
new mobile banking application. The objective is to ensure these features are secure from
unauthorized access and potential vulnerabilities.

2.Scope:
This test plan will focus on:

i. Login Security – Assessing the authentication mechanisms and session management.


ii. Money Transfer Security – Verifying secure transaction handling and preventing
unauthorized transfers.

3.Objectives

 Identify potential vulnerabilities in the login and money transfer features.

 Ensure compliance with industry security standards (e.g., OWASP, PCI-DSS).

 Verify secure data transmission and storage.

 Protect users’ sensitive information and funds.

4. Types of Tests

A. Authentication Tests

 Brute Force Attack: Attempt multiple logins using common passwords and analyze
account lockout mechanisms.

 Password Complexity: Test for enforcement of strong password policies (length,


characters, etc.).
 Multi-Factor Authentication (MFA): Check that the application requires and
securely implements MFA, such as SMS OTP or biometric authentication.

 Session Management: Test session expiration and invalidation upon logout and
inactivity.

 Replay Attack Prevention: Ensure tokens are one-time use and cannot be reused by
intercepting login attempts.

B. Authorization Tests

 Privilege Escalation: Ensure users with different privilege levels (e.g., standard user
vs. admin) cannot access restricted features.

 Cross-Account Access: Verify that users cannot access other users' accounts or
transfer money on their behalf by altering request parameters.

C. Data Transmission Security Tests

 Man-in-the-Middle (MITM) Attack: Simulate attacks using tools like Burp Suite or
OWASP ZAP to intercept data in transit, verifying it is encrypted.

 SSL/TLS Verification: Confirm that all data transmitted between the mobile app and
server is encrypted using HTTPS with up-to-date SSL/TLS configurations.

 Certificate Pinning: Verify the app implements certificate pinning to prevent


compromised or rogue certificates.

D. Input Validation and Injection Tests

 SQL Injection: Attempt to input SQL injection strings into login and money transfer
fields to check for proper sanitization.

 Cross-Site Scripting (XSS): Ensure input fields sanitize user inputs to prevent XSS
attacks, especially in user account management.

 Command Injection: Check if it’s possible to inject malicious code into fields used
in the backend (e.g., account or transfer information).

E. API Security Tests

 API Endpoint Authorization: Test that the API endpoints related to login and
money transfer are restricted to authorized users.
 Rate Limiting and Throttling: Test the app's resilience against abuse by simulating
high volumes of login and transfer requests.

 Error Messaging: Verify error messages do not reveal sensitive information, which
could aid attackers in exploiting vulnerabilities.

F. Data Storage Security Tests

 Sensitive Data Storage: Confirm that sensitive data (e.g., login tokens) is not stored
in plaintext in local storage.

 Encryption at Rest: Check that sensitive data, such as user credentials, are stored
securely on the server with encryption.

5. Testing Tools

 Burp Suite - for testing authentication, API security, and data transmission security
(MITM attacks).

 OWASP ZAP - for web application security testing, especially for session and input
validation tests.

 JMeter - for simulating load on login and money transfer requests and testing rate
limiting.

 Postman - for testing API authorization, parameter tampering, and response


validation.

 SQLmap - for detecting SQL injection vulnerabilities in login and transfer requests.

 Appium - for automating functional and security tests on the mobile application.

6. Test Execution

Each test will be executed in a staging environment using test accounts. Results, including
logs, screenshots, and error messages, will be recorded for analysis.

7. Reporting

Upon completion of the test plan, a detailed report will be created, documenting identified
vulnerabilities, severity levels, recommendations, and remediation actions.
2. Describe three challenges associated with Regression Testing in Agile environments.
[7]

Regression testing in Agile environments presents unique challenges due to the iterative,
rapid-paced nature of development cycles. Here are three key challenges:

i. Frequent Changes and Limited Time


Agile methodologies focus on delivering small, incremental changes in short sprints,
often two to four weeks long. With each iteration, new features, bug fixes, and code
updates are added, which can introduce unintended issues in previously working
functionalities. The limited sprint duration leaves minimal time for exhaustive
regression testing, making it difficult to maintain a comprehensive suite of tests while
also managing new development.
ii. Test Maintenance and Scalability
As the codebase evolves, the number of regression test cases grows. Tests need
frequent updates to align with changes in requirements, design, or code structure.
Maintaining and updating a large suite of tests within each sprint is time-consuming
and requires effort from the testing team. Additionally, scaling tests for continuous
integration (CI) environments adds complexity, as the tests must be reliable and
compatible with the CI pipeline for successful automation.
iii. Balancing Manual and Automated Testing
While automation can expedite regression testing, creating and maintaining automated
tests that cover all potential regressions is challenging. Some areas, like user
interfaces, may require manual testing due to the complexity of replicating human
interactions in automated scripts. Determining the right balance between manual and
automated regression testing is crucial, but it can be difficult to allocate resources
effectively while managing sprint deadlines.

3. Consider a program that takes three numbers as input and print the values of these
numbers in descending order. Its input is a triple of positive integers (say x, y and 2)
and values are from interval [300,7001]. Generate I. Worst case II. robust test cases.
I. Worst Case Scenarios

Worst-case scenarios test the limits of the input range and challenging cases for ordering:

1. All values are equal (same number):


o Input: 300,300,300300, 300, 300300,300,300
o Expected Output: 300,300,300300, 300, 300300,300,300
2. All values are at the lower boundary:
o Input: 300,300,300300, 300, 300300,300,300
o Expected Output: 300,300,300300, 300, 300300,300,300
3. All values are at the upper boundary:
o Input: 7001,7001,70017001, 7001, 70017001,7001,7001
o Expected Output: 7001,7001,70017001, 7001, 70017001,7001,7001
4. Values are in ascending order (lowest to highest):
o Input: 300,4000,7001300, 4000, 7001300,4000,7001
o Expected Output: 7001,4000,3007001, 4000, 3007001,4000,300
5. Values are in descending order (highest to lowest):
o Input: 7001,4000,3007001, 4000, 3007001,4000,300
o Expected Output: 7001,4000,3007001, 4000, 3007001,4000,300
6. One value at the lower boundary, one at the upper boundary, and one in
between:
o Input: 300,4500,7001300, 4500, 7001300,4500,7001
o Expected Output: 7001,4500,3007001, 4500, 3007001,4500,300
7. Two values are equal, and the third is different:
o Higher values equal:
 Input: 5000,5000,3005000, 5000, 3005000,5000,300
 Expected Output: 5000,5000,3005000, 5000, 3005000,5000,300
o Lower values equal:
 Input: 300,300,7001300, 300, 7001300,300,7001
 Expected Output: 7001,300,3007001, 300, 3007001,300,300

II. Robust Test Cases


Robust test cases include tests that go beyond normal expectations to check how the program
handles boundary and invalid inputs. Since robust cases may consider out-of-range or
unexpected values, this will test error handling, though some cases may be outside the
program’s usual operating conditions.

1. Values just outside the valid range (boundary tests):


o Input: 299,4000,7001299, 4000, 7001299,4000,7001
 Expected: Error or rejection (299 is out of range)
o Input: 300,4000,7002300, 4000, 7002300,4000,7002
 Expected: Error or rejection (7002 is out of range)
2. Negative numbers:
o Input: −1,400,500-1, 400, 500−1,400,500
o Expected: Error or rejection (negative values are invalid)
3. Non-integer values (if supported):
o Input: 400.5,500,600400.5, 500, 600400.5,500,600
o Expected: Error or rejection (assuming only integers are allowed)
4. Boundary at maximum values with large differences:
o Input: 300,7000,7001300, 7000, 7001300,7000,7001
o Expected Output: 7001,7000,3007001, 7000, 3007001,7000,300
5. Very close numbers within the range but unordered:
o Input: 500,501,499500, 501, 499500,501,499
o Expected Output: 501,500,499501, 500, 499501,500,499
6. Duplicate values at maximum and minimum limits:
o Input: 300,7001,7001300, 7001, 7001300,7001,7001
o Expected Output: 7001,7001,3007001, 7001, 3007001,7001,300
7. All middle-range numbers with different ordering:
o Input: 4500,3200,51004500, 3200, 51004500,3200,5100
o Expected Output: 5100,4500,32005100, 4500, 32005100,4500,3200

You might also like