UNIT- 4

SOFTWARE ANALYSIS & TESTING

STATIC AND DYNAMIC ANALYSIS
Static and Dynamic analysis

 Dynamic technique – it is performed by executing some test data and the outputs
of the program are monitored to find errors in the software code.
 Static technique – it is performed by executing the program conceptually and
without any data. Code reading, static analysis, symbolic execution, code
inspection, and reviews, etc. Are some of the commonly used static techniques

CODE INSPECTION
Code inspection is a type of static testing which aims in reviewing the software Code and
examining for any errors in that.

• It helps in reducing the ratio of defect multiplication and avoids later-stage error detection by
simplifying all the initial error detection processes.
• Actually, this code inspection comes under the review process of any application.

PURPOSE OF CODE INSPECTION

It checks for any error that is present in the software code.
• It identifies any required process improvement.
• It checks whether the coding standard is followed or not.
• It involves peer examination of codes.
• It documents the defects in the software code.

ADVANTAGES OF CODE INSPECTION :

• Improves overall product quality.
• Discovers the bugs/defects in software code.
• Marks any process enhancement in any case.
• Finds and removes defective efficiently and quickly.
• Helps to learn from previous defeats.

DISADVANTAGES OF CODE INSPECTION :

• Requires extra time and planning.
• The process is a little slower.
 SOFTWARE TESTING
Software testing is a process where we validate that the product developed is as per the
requirement of the client.
Software is ensured that it is defect free, safe to use, and validated against different metrics.
Software is tested for security, user experience, speed, performance, load capacity, and many
other parameters.

Software development and software testing both are ongoing processes as every time a new
functionality gets added, it is tested for its accuracy
Software testing is done to evaluate a software application or system to identify defects, errors,
or potential issues before it is released to the end-users. The primary goal of software testing is to
ensure that the software meets the specified requirements, is functional, reliable, and performs as
expected.
Software testing helps improve the overall quality of the software product, reduce development
costs, and prevent potential issues that could arise after the software is released to users.

PRINCIPLES OF SOFTWARE TESTING

The principles of testing are a set of guidelines that help testers to plan, design, and execute
effective software testing. These principles are essential in guiding testers to design and execute
effective software testing that will identify defects and improve the overall quality of the
software application being tested.

Identifying the presence of defects: Testing is not about proving that software is error-free but
about finding defects that need to be fixed. Defects can include code bugs, missing requirements,
incorrect functionality, and other issues.

Exhaustive testing is time consuming: It is impossible to test all possible combinations and
scenarios in software applications, so testers must focus on the most critical and high-risk areas.

Early testing saves time and money: It is more cost-effective to identify and fix defects early in
the software development life cycle than later in the process.
Defect clustering: In software development, defects often occur in clusters, meaning that a small
number of modules or components are responsible for the majority of defects. Testers should
focus on these high-risk areas.
Pesticide paradox: Repeating the same tests with the same inputs can result in the same defects
being identified repeatedly. Testers must continually update and modify their test cases to find
new defects.

Testing is context-dependent: The testing process should be tailored to the specific context and
requirements of the software application being tested.

Absence-of-errors fallacy: Finding no defects in the software application does not mean that it is
error-free. Testers must be aware of potential risks and unknown issues.
BLACK BOX TESTING

Black box testing involves testing a system with no prior knowledge of its internal workings. A
tester provides an input, and observes the output generated by the system under test. This makes
it possible to identify how the system responds to expected and unexpected user actions, its
response time, usability issues and reliability issues.

Black box testing is a powerful testing technique because it exercises a system end-to-end. Just
like end-users “don’t care” how a system is coded or architected, and expect to receive an
appropriate response to their requests, a tester can simulate user activity and see if the system
delivers on its promises. Along the way, a black box test evaluates all relevant subsystems,
including UI/UX, web server or application server, database, dependencies, and integrated
systems.

An example of a security technology that performs black box testing is Dynamic Application
Security Testing (DAST), which tests products in staging or production and provides feedback
on compliance and security issues.
Black Box Testing Techniques

With no internal knowledge of an application, structure is important to ensure that the test covers
all necessary cases. Some common techniques for performing a black box evaluation include:

● Equivalence Class Testing: An application may follow the same control flow for certain
types of inputs. For example, an application that should only be accessible to adults may
terminate if a user enters an age under 18 or a tool with a limited service area may
terminate for country or postal codes outside of that area. With equivalence class testing,
testers identify these classes that produce the same results and only test for one value
within that class.
● Boundary Value Evaluation: Boundary values are inputs where an application’s
changes from one control flow to another. For example, the ages 17 and 18 are boundary
values for adulthood since a 17 year old may be rejected by an application, while an 18
year old would be accepted. Boundary value evaluation tests these inputs to ensure that
the system is properly handling these edge cases.
● Decision Table Testing: An application may be designed to make decisions based on a
combination of inputs. For example, users over the age of 18 and living within a
particular area may be able to access an application. Decision table testing involves
enumerating each combination of inputs and its expected outcomes and developing a test
case to validate each combination.
● State Transition Evaluation: An application may be designed to change state under
certain conditions, such as locking a user’s account after a certain number of failed
authentication attempts. State transition evaluation involves identifying these situations
and developing test cases to validate them.
● Error Checking: This form of evaluation tests for common errors that a developer may
have made when creating an application. This often revolves around input sanitization
and ensuring that assumptions about an input are enforced. For example, testers may
check to see if developers properly handled an input of zero in a numeric field or
restricted the character set for a name to the letters and symbols that can appear in a
name.
Example of Black Box Testing
A simple black box testing example for a login functionality of a web application. In this
scenario, we will test the login page without having access to the internal code or implementation
details.
Test Case Name: Verify successful login with valid credentials.
Test Steps:

Open the web browser.

Enter the URL of the application’s login page.
Enter a valid username in the username field.
Enter a valid password in the password field.
Click on the “Login” button.

Wait for the application to process the login request.

Expected Result: The user should be successfully logged into the application’s
dashboard/homepage.
Test Case Status: PASS (if the user is redirected to the dashboard/homepage)
Test Case Name: Verify unsuccessful login with invalid credentials.

Test Steps:

Open the web browser.

Enter the URL of the application’s login page.
Enter an invalid username (e.g., “invaliduser”) in the username field.
Enter an invalid password (e.g., “wrongpassword”) in the password field.

Click on the “Login” button.

Wait for the application to process the login request.
Expected Result: The login attempt should fail, and an appropriate error message (e.g., “Invalid
username or password”) should be displayed on the login page.
Test Case Status: PASS (if the error message is displayed)

Features of Black Box Testing

Black box testing, as a software testing approach, offers several features and benefits that make it
an essential part of the software development process. Some key features of black box testing
include:

Focus on External Behavior: Black box testing emphasises evaluating the software’s
functionality from an end-user perspective, focusing on how the system behaves with
different inputs and usage scenarios.
Independence from Internal Code: Testers conducting black box testing do not require
knowledge of the internal code or implementation details, making it suitable for testers
who may not have programming expertise.
Requirement-Based Testing: Test cases in black box testing are designed based on the
software’s requirements and specifications. This ensures that the application meets the
intended functionality and business objectives.
 Real-World Scenario Testing: Black box testing helps simulate real-user conditions,
allowing testers to identify defects that might arise during actual usage of the software.
Validation of Interfaces: It is effective in verifying the accuracy of the software’s
interfaces, ensuring that inputs and outputs are correctly handled.
Identification of Interface-Level Bugs: Black box testing is particularly useful for
detecting interface-level bugs, such as incorrect error messages, incorrect data handling,
or missing functionality.
User-Centric Testing: By focusing on the end-user perspective, black box testing
ensures that the application meets user expectations and delivers a satisfactory user
experience.
Test Case Design Techniques: Black box testing employs various test case design
techniques, such as equivalence partitioning, boundary value analysis, decision table
testing, and state transition testing, to ensure comprehensive test coverage.
Compatibility Testing: It helps assess the software’s compatibility with different
environments, browsers, operating systems, and devices.

Test Automation Support: Many black box testing tools support test automation,
enabling the execution of repetitive test cases efficiently and reducing the testing cycle
time.
By leveraging these features, black box testing helps organizations deliver high-quality software
that meets user expectations and complies with the specified requirements. When combined with
other testing approaches, such as white box testing and gray box testing, it provides a
comprehensive testing strategy for software development projects.

ADVANTAGES OF BLACK BOX TESTING

Independence from Internal Implementation: Testers do not need to have access to the
source code or knowledge of the internal implementation, making it suitable for non-
technical team members.
User-Centric Testing: Black box testing focuses on the software’s external behavior,
ensuring that it meets user requirements and expectations.
Testing from End-User Perspective: It simulates real user scenarios, helping to identify
usability issues and ensuring the software meets user needs.
Early Detection of Interface Issues: Black box testing can uncover interface-related
defects, such as input validation errors and output discrepancies.
Effective at Integration Testing: It verifies the interactions between different system
components, making it valuable for integration testing.
Test Case Design Flexibility: Various test case design techniques, such as equivalence
partitioning and boundary value analysis, allow for effective test coverage.
Effective for Requirement Validation: Black box testing helps validate that the
software meets the specified requirements.

Suitable for Large Projects: It can be applied at different testing levels, from unit
testing to acceptance testing, making it scalable for large projects.

LIMITATIONS OF BLACK BOX TESTING

Limited Code Coverage: Black box testing may not explore all possible code paths or internal
logic, potentially leaving certain defects undetected.

Inability to Test Complex Algorithms: It may not be effective at validating complex

algorithms or intricate business logic that requires knowledge of the internal code.

Redundant Testing: Some test cases may overlap, leading to redundant testing efforts and less
optimal test coverage.

Dependency on Requirements: Test cases are heavily dependent on the accuracy and
completeness of the provided requirements. Incomplete or ambiguous requirements can result in
incomplete testing.

Inefficiency with Repetitive Tasks: Manual black box testing can be time-consuming and
inefficient for repetitive tasks, making test automation essential for large-scale projects.

Inability to Assess Performance and Scalability: Performance-related issues and scalability

problems may not be effectively identified through black box testing alone.

Difficulty in Error Localization: Identifying the root cause of defects detected in black box
testing can be challenging, as testers lack access to internal code.

Limited Security Testing: While black box testing can identify certain security vulnerabilities,
it may not comprehensively address all potential security issues.
To overcome some of these limitations, organisations often use a combination of black box
testing with other testing approaches like white box testing (to assess internal code and logic)
and gray box testing (to combine elements of both black and white box testing).
This mixed approach allows for better test coverage and increased software quality assurance.

WHITE BOX TESTING

White box testing is an approach that allows testers to inspect and verify the inner workings of a
software system—its code, infrastructure, and integrations with external systems. White box
testing is an essential part of automated build processes in a modern Continuous
Integration/Continuous Delivery (CI/CD) development pipeline.

White box testing is often referenced in the context of Static Application Security Testing
(SAST), an approach that checks source code or binaries automatically and provides feedback on
bugs and possible vulnerabilities.
WHITE BOX TESTING TECHNIQUES

One of the main advantages of white box testing is that it makes it possible to ensure that every
aspect of an application is tested. To achieve full code coverage, white box testing can use the
following techniques:

● Statement Coverage: Statement coverage testing ensures that every line of code within
an application is tested by at least one test case. Statement coverage testing can help to
identify if portions of the code are unused or unreachable, which can be caused by
programming errors, updates, etc. Identifying this dead code enables developers to fix
incorrect conditional statements or remove redundant code to improve application
performance and security.
● Branch Coverage: Conditional statements create branches within an application’s
execution code as different inputs can follow different execution paths. Branch coverage
testing ensures that every branch within an application is covered by unit testing. This
ensures that even little-used code paths are properly validated.
● Path Coverage: An execution path describes the sequence of instructions that can be
executed from when an application starts to where it terminates. Path coverage testing
ensures that every execution path through an application is covered by use cases. This
can help to ensure that all execution paths are functional, efficient, and necessary.

White Box Testing Example

def Printme(a, b):

result = a + b
if result > 0:
print(“Positive”, result)
 else:
print(“Negative”, result)

In this code, Printme is a function that takes two inputs, adds them, and checks whether the result
is positive or negative. If the result is positive, it prints “Positive”. If the result is not positive
(i.e., zero or negative), it prints “Negative” along with it.
The goal of White Box Testing here is to verify all the decision branches (the if-else
condition) in the code.
To exercise the statements in this code, we would create the following test cases:

Test Case 1: a = 1, b = 1

This would test the “Positive” branch of the if-else condition.

Test Case 2: a = -1, b = -3
This would test the “Negative” branch of the if-else condition.

By running these test cases, we can ensure that both branches of the if-else condition in the code
are tested, which is the goal of White Box Testing.
Illustaration: Imagine this code as a road with a fork, where you can either go left or right. The
decision to go left or right is based on whether the result is positive.
The result is positive in the first test case, so we go left (the “Positive” branch). The result is not
positive in the second test case, so we go right (the “Negative” branch). By running both test
cases, we ensure that we have traveled both possible paths at the fork in the road, which is the
goal of White Box Testing.
What to Verify in White Box Testing?
In White Box Testing, you’re like a book reviewer who must check every chapter.

Here’s what you need to verify in white box testing:

Code Paths: This is like checking every chapter in the book. You must ensure every part
of the code is visited and works correctly.
Loops: This is like checking if the book has any repeated chapters. In code, loops are
parts that can run multiple times. You must ensure these loops work correctly and don’t
repeat forever.
Conditions: This is like checking if the book has twists and turns. In code, conditions can
change what the software does. You need to ensure that every possible outcome of these
conditions is tested.
Inputs and Outputs: This is like checking the start and end of the book. You need to
ensure that for every input (start), the software produces the correct output (end).

Individual Parts: This is like checking every character in the book. In code, these are the
individual functions or objects. You need to make sure each one works correctly on its
own.
Remember, White Box Testing aims to ensure every part of the code works correctly, just like a
book reviewer wants to ensure every part of the book makes sense.

ADVANTAGES AND LIMITATIONS OF WHITE BOX TESTING

Just like a book review can help you decide whether to read a book, White Box Testing has
advantages and limitations that can help you decide when to use it.
Advantages Limitations

Thorough Testing: Like reading every Complexity: Just like a book can be hard
chapter of a book, White Box Testing to understand if it’s written in a difficult
checks every part of the code, making it language, White Box Testing can be
very thorough. complex because it requires
understanding the code.

Early Bug Detection: Like spotting a Time-Consuming: Just like reading a

typo in the first few pages of a book, long book can take a lot of time, White
White Box Testing can find bugs early in Box Testing can be time-consuming
the development process, which makes because it’s so thorough.
them cheaper and easier to fix.

Improves Security: Like a book review Requires Expertise: Just like

that warns about inappropriate content, understanding a book written in an old or
White Box Testing can find security foreign language requires special
issues in the code, helping to make the knowledge, White Box Testing requires a
software more secure. deep understanding of coding and
implementation.

Optimizes Code: Like a book review Bias: Just like a book reviewer might
that suggests removing unnecessary miss flaws in a book they love,
chapters, White Box Testing can find developers who test their own code might
unnecessary or redundant code, helping miss bugs because they’re too familiar
to make the software more efficient. with it.

DIFFERENCE BETWEEN BLACK BOX TESTING AND WHITE BOX TESTING

Parameters Black Box Testing White Box Testing

Black Box Testing is a way of White Box Testing is a way of

software testing in which the testing the software in which the
Definition internal structure or the program tester has knowledge about the
or the code is hidden and internal structure or the code or
nothing is known about it. the program of the software.

Black box testing is mainly

White box testing is mainly
focused on testing the
focused on ensuring that the
Testing objectives functionality of the software,
internal code of the software is
ensuring that it meets the
correct and efficient.
requirements and specifications.

Black box testing uses methods

White box testing uses methods
like equivalence partitioning,
like control flow testing, data
Testing methods boundary value analysis, and
flow testing and statement
error guessing to create test
coverage testing.
cases.

Black box testing does not

require any knowledge of the White box testing requires
Knowledge level internal workings of the knowledge of programming
software, and can be performed languages, software architecture
by testers who are not familiar and design patterns.
with programming languages.
 White box testing is used for
Black box testing is generally
testing the software at the unit
Scope used for testing the software at
level, integration level and
the functional level.
system level.

Implementation Implementation of code is not Code implementation is

needed for black box testing. necessary for white box testing.

Done By Black Box Testing is mostly White Box Testing is mostly

done by software testers. done by software developers.

Black Box Testing can be

Terminology White Box Testing is the inner
referred to as outer or external
or the internal software testing.
software testing.

Testing Level Black Box Testing is a White Box Testing is a structural

functional test of the software. test of the software.

Black Box testing can be

White Box testing of software is
Testing Initiation initiated based on the
started after a detail design
requirement specifications
document.
document.
Programming No knowledge of programming It is mandatory to have
is required. knowledge of programming.

Testing Focus Black Box Testing is the White Box Testing is the logic
behavior testing of the software. testing of the software.

Black Box Testing is applicable White Box Testing is generally

Applicability to the higher levels of testing of applicable to the lower levels of
software. software testing.

Alternative Names Black Box Testing is also called White Box Testing is also called
closed testing. as clear box testing.

Time Consumption Black Box Testing is least time White Box Testing is most time
consuming. consuming.

Suitable for Algorithm Black Box Testing is not

White Box Testing is suitable for
Testing suitable or preferred for
algorithm testing.
algorithm testing.
 Data domains along with inner
Approach Can be done by trial and error
or internal boundaries can be
ways and methods.
better tested.

Example Search something on google by By input to check and verify

using keywords loops

Types of Black Box Testing:

Types of White Box Testing:

● Functional Testing
Types ● Path Testing
● Non-functional
● Loop Testing
testing
● Condition testing
● Regression Testing

It is comparatively more
Exhaustiveness It is less exhaustive as compared
exhaustive than black box
to white box testing.
testing.

LEVELS OF TESTING

Testing levels, also known as levels of testing, refer to the different phases or stages of testing
software during its development cycle. The main idea behind this concept is that each level of
testing targets specific aspects of the software’s functionality, which allows for better quality
assurance and fewer potential defects.
The most common types of testing levels include – unit testing, integration testing, system
testing, and acceptance testing. Unit tests focus on individual components, such as methods and
functions, while integration tests check if these components work together properly. System tests
verify that the entire system meets the functional requirements specified by stakeholders, while
acceptance tests validate the software against their criteria for acceptable behavior.

UNIT TESTING
Unit testing is the first level of testing. This testing is the most basic type of testing done by the
developers before handing the software/product to the testing team.

Unit Testing Definition: Unit testing is a type of software testing in which individual units
or components of the software are tested.
Primary Objective: The main objective of unit testing is to isolate each component of the
software and then perform tests to illustrate that every individual component is accurately
meeting the requirements and delivering the expected output.

ADVANTAGES OF UNIT TESTING

Here are some of the advantages of unit testing:
● Helps to catch bugs/defects earlier, which preserves both – time and money
● Detects regression bugs (It is a kind of bug that is not found until and unless the
software/product is released or is in production)
● Helps to understand the behavior of the code
● The cost of conducting unit testing is low.

Disadvantages of Unit Testing

Here are some of the disadvantages of unit testing, such as:
● Writing test cases takes time.
● Unit testing is incapable of detecting all errors.
● GUI code testing must be performed correctly, as it will be challenging to test the
software’s graphical user interface using unit testing.

INTEGRATION TESTING
Integration testing is the second level of testing. The testers, rather than the developers, mainly
conduct this testing. This testing can be performed manually or using integration testing tools,
such as Selenium.

Integration Testing Definition: Integration testing is a type of software testing in which

individual software components (modules) are logically integrated (combined) and tested as
a group.

Advantages of Integration Testing

Here are some of the advantages of integration testing:
● Increases test coverage
● Offers a higher level of reliability
● Aids in the identification of integration issues between modules
● Helps to ensure that the integrated components (modules) work properly before
proceeding to the next level of testing: system testing
● Bugs discovered at this level are more uncomplicated to resolve than those discovered
at later levels of testing.

Disadvantages of Integration Testing

Here are some of the disadvantages of integration testing, such as:
 ● It can be challenging to perform in comparison to system testing.
● Testing the integration between the various connected modules takes a long time and a
lot of resources.
● It necessitates the creation of stubs and drivers, which, if not done correctly, can result
in insufficient testing.
● Lower-level modules need to be adequately tested.
● The test output is difficult to observe.

SYSTEM TESTING
System testing is the third level of testing. This level of testing assists you in identifying bugs
and challenges while ensuring that the software will meet all specific requirements. A specialized
testing team is usually in charge of this type of testing.

System Testing Definition: System testing is software testing in which all components are
tested together (as a whole) to ensure that the final product meets the specified
requirements.

Primary Objective: The main objective of this level of testing is to make sure that the
software/product meets specified requirements and runs as smoothly as possible in its
operating environment.

Advantages of System Testing

Here are some of the advantages of system testing:
● Covers complete end-to-end software testing.
● Tests both: the system software architecture and business requirements
● Assists in resolving post-production issues and bugs

Disadvantages of System Testing

Here are some of the disadvantages of system testing, such as:
● Requires a lot of time as it needs to test the entire framework
● Increases the testing cost and the effort involved, as business requirements and
software architecture must be considered when conducting tests.

ACCEPTANCE TESTING
Acceptance testing is the last and final level of testing. This level of testing is broad in scope,
ranging from simply finding spelling and cosmetic errors to discovering bugs that might produce
a significant error in the software.

Acceptance Testing Definition: Acceptance testing is a type of software testing that

determines whether or not the software should be released to the public.
Primary Objective: The main objective of acceptance testing is to evaluate whether the
software complies with the end-user requirements and whether it is ready for deployment.

Advantages of Acceptance Testing

Here are some of the advantages of acceptance testing:
● Identifies problems with new products before they reach users
● Allows the clients to test the features of the software
● Increases satisfaction and reliability as client checks the software themself.
● Helps the client to understand the target audience in a better way after analyzing the
data gathered using acceptance testing

Disadvantages of Acceptance Testing

Here are some of the disadvantages of acceptance testing, such as:
● Significant resources and planning are required.
● You have no say in which test cases are used.
● It is challenging to assess test progress.