0% found this document useful (0 votes)
22 views10 pages

CHAPTER V House Rental Application Chapter 5

The chapter outlines a comprehensive system testing strategy, covering functional, integration, performance, security testing and more. It discusses creating test cases, executing tests, and documenting results. Black box and white box testing techniques are used, with black box focusing on inputs/outputs and white box on internal logic. Various system interfaces are tested.

Uploaded by

kaaha nura
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views10 pages

CHAPTER V House Rental Application Chapter 5

The chapter outlines a comprehensive system testing strategy, covering functional, integration, performance, security testing and more. It discusses creating test cases, executing tests, and documenting results. Black box and white box testing techniques are used, with black box focusing on inputs/outputs and white box on internal logic. Various system interfaces are tested.

Uploaded by

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

CHAPTER V:

SYSTEM TESTING
5. Introduction
This chapter outlines a comprehensive testing strategy, detailing the various types of system
testing that will be undertaken. It will cover functional testing to ensure that each feature
operates as intended, integration testing to validate the interaction between different modules,
performance testing to assess the app's responsiveness and stability under load, and security
testing to safeguard user data and protect against potential breaches. Additionally, the chapter
will delve into the process of creating test cases, executing tests, and meticulously
documenting results.

5.1 Testing of the system


Testing of the system, often referred to as system testing, is a comprehensive and structured
process in software development that focuses on evaluating the integrated components of a
software application as a whole. The primary goal of system testing is to ensure that the entire
system meets its specified requirements, functions correctly, and performs effectively in real-
world scenarios. This phase of testing occurs after individual components have been tested
and integrated into the larger software ecosystem.

5.2.1 Testing methods and comparison


5.2.1.1 Black box testing
Black box testing is a software testing method that focuses on evaluating the functionality of
a software application without requiring knowledge of its internal code, structure, or
implementation details. Testers approach the software as a "black box," meaning they only
interact with the inputs and outputs of the system, observing how it responds to different
inputs and assessing whether it produces the expected outputs. The primary objective of black
box testing is to validate the software's behavior and functionality from a user's perspective.
This method of test design is applicable to all levels of software testing: unit, integration,
functional testing, system and acceptance.

5.2.1.2 White box testing


White box testing, also known as structural testing or clear box testing, is a software testing
method that involves examining the internal code, logic, and structure of a software
1
application. Unlike black box testing, where testers focus solely on the external behavior,
white box testing allows testers to have detailed knowledge of the application's codebase and
use this knowledge to design test cases. The primary goal of white box testing is to ensure
the correctness of the software's internal logic and code execution.

Types of White Box Testing:

1. Code Coverage Testing (creating tests to satisfy some criteria of code coverage).
2. Mutation Testing
3. Fault Injection Methods
4. Static Testing

5.2.1.3 Comparison -black box testing and white box testing


Table Difference between black box testing and white box testing have been listed in below
table 5.1 based on below listed differences appreciate testing methods were used for testing.
Aspects Black box testing White box testing
Perspective Testing without knowledge Testing with knowledge of
of internal code, focusing on internal code, focusing on
inputs and outputs logic and code structure
Knowledge Testers do not require Testers have access to the
source code and understand
knowledge of the software's
the software's internal
internal implementation. workings.
Test Design Approach Uses functional Designs test cases based on
specifications to design test internal code paths and
cases. logic flow.
Design Based on requirements, user Derived from code analysis,
scenarios, and functional focusing on specific code
specifications. paths, conditions, and logic.
Focus Evaluates functionality, Verifies internal logic, code
external behavior, and user paths, and adherence to
experience. coding standards.
User Interaction Simulates user interactions Focuses on code execution
and external usage paths, internal algorithms,
scenarios. and control structures.

2
Table 5.1 Black box and White box testing

5.2.2 Performance Testing


Performance testing checks to see if the software can handle large quantities of data or
users. This generally referred to as software scalability.

5.2.3 Boundary Testing


Boundary testing is a software testing technique that focuses on testing the boundaries or
limits of input values to ensure that a software application handles them correctly. It aims to
identify defects that might occur at the edges of valid and invalid input ranges, where
software behavior can be unpredictable or erroneous.

5.2.4 Testing strategy and Testing plan


Black box testing and white box testing were used as the main testing techniques to test the
entire system for all the stages. Although both of these testing techniques have advantage and
disadvantage as discuss above, but when combined, they help to ensure through testing of
the services. All the functions, procedures are tested as single individual units first and after
integrating

individual units into one-unit, integrated units were tested as a whole. When the
function/procedure

is tested for the first time, black box testing methodology was used. It was tested for excepted
results on different user inputs. If the function did not deliver the excepted outcome white
box testing methodology was used. So, it was tested by going through each and every relevant
code. After testing for functionality of the functions/procedures, these functions/procedures
ware combined and testing using black box testing methodology. If the results show any
discrepancy than except output, the again they were tested for expected results using white
box testing methodology. Once the service was completed then it was tested using test data
by using black box and white box approach. All the interfaces were checked using black box
approach. Since 26 validation rules have been applied at all the possible areas of user
interfaces, testing of some areas were not required.

3
5.3 System interface
5.3.1 Interface testing
This is the login page which can user enters him email and password and this page has
validation.

Figure 1 login testing

4
Figure 2 login testing

Figure 5.3.1 dashboard using

This is the dashboard when admin enters the right password and right email it directed to this
page where he or she can manage and see the different sections of the application.

5
Figure 3 dashboard using

6
Figure 5.3.3 houses

It is stored in the list of houses of Kumis real state application and new houses are registered.

Figure 4 houses

7
Figure 5.3.4 User

The owner of the application has the ability to create a new user, every admin who has given
an email and password can login into the system, and every admin has full control of the system.

Figure 5 registration user

Figure 5 registration user


8
5.4.1 Table three test cases
User interface: login

Action Input Expected output status


Type Email and Admin@gmail.com Login to the application Pass
password and click Password 092672 with appropriate
log in button. Admin12@gmail.com permissions.
Password 64666
Type invalid Email Admin56@gmail.com I/flutter (4781): Pass
Password 7348535
and password then [firebase_auth/user-
click log in button. not-found] There is no
user record
corresponding to this
identifier. The user may
have been deleted.
Type valid Email Admin@gmail.com I/flutter (4781): Pass
and keep password [firebase_auth/channel-
empty then click error] Unable to
login button. establish connection on
channel.
Keep Email blank 123456 I/flutter (4781): Pass
and type [firebase_auth/channel-
correct password error] Unable to
and click login establish connection on
button. channel.

Table 5.4.1 Test case.

9
5.4.2 Table 4 Test report

Test Actual output Status


case
ID
1 • Login to the Application when Email and password is correct Pass
Pass
• Display error message “I/flutter (4781): [firebase_auth/user-
not-found] There is no user record corresponding to this
identifier. The user may have been deleted.” when the Email is
incorrect and password.
Pass
• Display error massage “I/flutter ( 4781):
[firebase_auth/channel-error] Unable to establish connection on
channel.” when the Email is correct and password is incorrect

• Display error massage “I/flutter ( 4781):


[firebase_auth/channel-error] Unable to establish connection on
Pass
channel.” when the Email is correct and password is blank or
incorrect.

Table 5.4.2: Test report.


5.5 Conclusion:
In this chapter, we delve into the realm of testing methods, testing strategies, and test plans
for the house rental application's solution and implementation. Alongside, we explore the
intricacies of the implementation strategy. Also, this chapter discusses about testing methods,
testing strategy, and test plans of the solutions and implementations methodologies with
implementations strategy. Further, problems faced in the application development process
also have been discussed in this chapter Once the software implementation was done, the
next main activity was to evaluate the implemented software. In other word it should be
evaluated whether the software meets all the requirements identified at the initial stage of
finalizing software requirement specification and the provided functionality works properly.

10

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy