Canada Corner, Sharanpur Road, Nashik-422 002.

Computer Engineering Department

Year: 2016-17 Sem: 7th

Class: BE Subject: Project work

Assignment Title: Testing of project problem statement using generated test data (using mathematical
models, GUI, Function testing principles, if any) selection and appropriate use of testing tools, testing of
UML diagram’s reliability.

Assignment No: 07

Due Date: 10/09/2016 Date Submitted: 23/09/2016

Student Name: Rachana Sonawane Seat No: P10

Student Name: Priyanka Tate Seat No: P11

Student Name: Raj Bhole Seat No: P5

Student Name: Sagar Shinde Seat No: P9

Guide Name: Prof. N.V.Kapade

[Late submission of assignments may incur a penalty]

Guide Remark:……………………………………………………………………………………………………………………………

Project Coordinator: Prof. N. V. Kapade

Head of Department: Prof. K. V. Ugale
 Functional Testing Principles:

1. Automated Testing

Automation Testing, which is also known as test automation, is when tester writes sripts
and uses other software to test product. This process involves automation of a manual
process. Automation testing is used to re-run the test scenario that were perform
manually, quickly, and repeatedly. Apart from regression testing, automation testing is also
used to test coverage, improves accuracy, and saves time and memory in comparison to
manual testing.

2. Functional Testing

Functional testing is a software testing process used within software development in which
software is tested to ensure that it conforms with all requirements. Functional testing is a way
of checking software to ensure that it has all the required functionality that's specified within
its functional requirements.

3. Combinatorial Testing

Combination testing refers to tests that involve more than one variable.

A critical problem for multi-variable testing is called combinatorial explosion. The more
variables you combine, the higher the number of possible tests. Combination testing is about
picking a few tests that can teach us what we need to know about the space of combinations of
these variables.

4. Structural Testing

Structural testing, also known as glass box testing or white box testing is an approach where the
tests are derived from the knowledge of the software's structure or internal implementation.
The other names of structural testing includes clear box testing, open box testing, logic driven
testing or path driven testing.

Structural Testing Techniques:

 Statement Coverage - This technique is aimed at exercising all programming statements

with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure that all branches
are tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths which means
that each statement and branch are covered.
5. Data Flow Testing

Data flow testing is a family of test strategies based on selecting paths through the program's
control flow in order to explore sequences of events related to the status of variables or data
objects. Dataflow Testing focuses on the points at which variables receive values and the points
at which these values are used.

Data Flow testing helps us to pinpoint any of the following issues:

 A variable that is declared but never used within the program.

 A variable that is used but never declared.
 A variable that is defined multiple times before it is used.
 Deallocating a variable before it is used.

6. Model-Based Testing

Model-based testing is an application of model-based design for designing and optionally also
executing artifacts to perform software testing or system testing. Models can be used to
represent the desired behavior of a System Under Test (SUT), or to represent testing strategies
and a test environment.

7. Testing Object-Oriented Software

Software testing is an investigation conducted to provide stakeholders with information about

the quality of the product or service under test. Software testing can also provide an objective,
independent view of the software to allow the business to appreciate and understand the risks
of software implementation. Test techniques include the process of executing a program or
application with the intent of finding software bugs (errors or other defects).

Software testing involves the execution of a software component or system component to

evaluate one or more properties of interest. In general, these properties indicate the extent to
which the component or system under test:

8. Fault-Based Testing

A theory of fault-based program testing is defined and explained. Testing is fault-based when it
seeks to demonstrate that prescribed faults are not in a program. It is assumed that a program
can only be incorrect in a limited fashion specified by associating alternate expressions with
program expressions. Classes of alternate expressions can be infinite. Substituting an alternate
expression for a program expression yields an alternate program that is potentially correct. The
goal of fault-based testing is to produce a test set that differentiates the program from each of
its alternates. A particular form of fault-based testing based on symbolic execution is presented.
9. Test Execution

Test execution are done by comparing the previous system of it so that the test executions of
our current system can
be over it. And the disadvantages can also be covered with our proposed model. By taking a
survey of every
message sending algorithms an methods our approach gives a robust protection from brute
force attack. Statistical
code table here helps in encoding the data. Test execution in the runtime environment of our
software will result a
success as it will be developed.

10. Inspection

An inspection is, most generally, an organized examination or formal evaluation exercise. In

engineering activities inspection involves the measurements, tests, and gauges applied to
certain characteristics in regard to an object or activity. The results are usually compared to
specified requirements and standards for determining whether the item or activity is in line
with these targets, often with a Standard Inspection Procedure in place to ensure consistent
checking. Inspections are usually non-destructive.

11. Program Analysis

program analysis is the process of automatically analyzing the behavior of computer programs
regarding a property such as correctness, robustness, safety and liveness. Program analysis
focuses on two major areas: program optimization and program correctness. The first focuses o
i pro i g the progra ’s perfor a e hile redu i g the resour e usage hile the latter
focuses on ensuring that the program does what It is supposed to do.
 DFD & UML Diagrams and Test Cases:
1. DFD Level 0

Fig 7.1: DFD Level 0

Test Case:

N/W Status(Complete/Inco
A User Validation(Yes/No) Valid user(Yes/No)
Connectivity(Yes/No) mplete)
B Static Analysis Atomicity(Yes/No) Consistency(Yes/No) Integrity(Yes/No) Durability(Yes/No)
Dynamic
C Atomicity(Yes/No) Consistency(Yes/No) Integrity(Yes/No) Durability(Yes/No)
Analysis
D DBN Atomicity(Yes/No) Consistency(Yes/No) Integrity(Yes/No) Durability(Yes/No)
2. DFD Level 1

Fig 7.2: DFD Level 1

Test Case:

N/W Status(Complete/Inco
A User Validation(Yes/No) Valid user(Yes/No)
Connectivity(Yes/No) mplete)
Static Analysis Atomicity
B Permissions(Yes/No) Validation(Yes/No) Access (Yes/No)
1 (Yes/No)
changing users
Static Analysis Atomicity
C SensitiveAPI(Yes/No) permissions Validation (Yes/No)
2 (Yes/No)
(Yes/No)
Dynamic Atomicity Dynamic
D Execution(Yes/No) Send Data (Yes/No)
Analysis (Yes/No) behaviour(Yes/No)
N/W
characterize Android
E DBN Connectivity Malware(Yes/No) Validation (Yes/No)
apps.
(Yes/No)
3. DFD Level 2

Fig 7.3: DFD Level 2

Test Case:

Validation(Yes/N N/W Status(Complete/Inco

A User Valid user(Yes/No)
o) Connectivity(Yes/No) mplete)
Atomicity
B Static Analysis 1 Permissions(Yes/No) Validation(Yes/No) Access (Yes/No)
(Yes/No)
changing users
Atomicity
C Static Analysis 2 SensitiveAPI(Yes/No) permissions Validation (Yes/No)
(Yes/No)
(Yes/No)
Dynamic Atomicity Dynamic
D Execution(Yes/No) Send Data (Yes/No)
Analysis (Yes/No) behaviour(Yes/No)
Construct
Atomicity
E Deep Learning change situation(Yes/No) architecture(Yes/N Validation (Yes/No)
(Yes/No)
o)
N/W
characterize Android
F DBN Connectivity Malware(Yes/No) Validation (Yes/No)
apps.
(Yes/No)
N/W
Google play evolution of
G Crawler 1 Connectivity Validation (Yes/No)
store(Yes/No) Android malware.
(Yes/No)
N/W
Newly crawled evolution of
H Crawler 2 Connectivity Validation (Yes/No)
malware(Yes/No) Android malware.
(Yes/No)
4. Test Cases for Sequence Diagram:

Fig 7.4: Sequence Diagram

Test Case:

Initial Conditions Condition 1

Steps Expected Results

A Online Submitted App
B App Integrity Checking done
Loop : loop Condition
A B
Loop end
Steps Expected Results

C Automatic Static Analysis

By parsing the Androidmanifest.xml permissions we can obtain the
D
required by the app
E Read permissions by Readable file.
F Required permissions.
By parsing the classes.dex permissions we can obtain the required by the
G
app
By parsing disassemble file we can know which API functions are
H called.
I Sensitive API
J Google Play Store.
K Newly crawled malware
Loop : loop Condition
C K
Loop end
L Automatic Dynamic Analysis
M Android APK executes Dynamic Analysis
N Droidbox sandbox obtain the executed app actions
O Dynamic behavior Monitor the App actions.
P Positive feature Set.
Q Negative Feature set.
 Loop : loop Condition
L Q
Loop end
R Deep Learning Model.
S Pre-trained Deep Belief Networks (DBN)
T RBM Initialization

U CD-K Sampling.

V For each parameter update

W The RBM Communications Assessment
X In the back-propagation phase
The pre- trained DBN is fine-tuned with labeled samples in a
Y supervised manner.

User testing and can automatically detect whether a submitted app

is a
Z
malware or not.
Loop : loop Condition
R Z
Loop end
5. Test Cases for Class Diagram:

Fig 7.5: Class Diagram

Test Case:

No.of
No.of Inward
Class Connectivity Association Collaboration Mapping Outward
Class
Class
Online submitted
app()
User Login Login Login - 4
App integrity
checking()
Required
-User -User permission()
Static -User -
-Static Readable file() 1
Analysis 1
Analysis 2 AndroidManifest
.xml()
Static -User -User -User Sensitive API()
Analysis 2 -Static Disasse led files 1 -
Analysis 1 classes.dex()
Android APK()
Dynamic
-User -User -User DroidBox sandbox() 1 -
Analysis
Dynamic behavior().
-User -User -User Pre-trained()
Deep 1
-DBN -DBN -DBN Back propagation 2
Learning
for fi e-tuning()
RBM initialization()
-Deep -User -User CD-k Sampling()
DBN -Deep -Deep Updating 1 1
Learning
Learning Learning parameter()
RBM Assessment()
6. Test case for Use-Case diagram:

Fig 7.6: Use-Case Diagram

 Alternate Special Pre- Post- Extension
Entity Basic flow
flow requirement condition condition point
User App submitted Login Login ID PlayStore Created Validation
Login ID
App integrity - Account Download Authentication
Password
Required
Static 1 permission Malware permissions PlayStore Created Validation

Readable file .apk file Account Download Authentication

AndroidManifest
.xml
Static 2 Sensitive API Malware permissions PlayStore Created Validation
Disasse led files .apk file Account Download Authentication
classes.dex
Dynamic Android APK Malware Monitor PlayStore Created Validation
Droid Box
Actions Account Download Authentication
sandbox
Dynamic behavior
Deep
Pre-trained DBN Samples PlayStore Created Validation
Learning
Back propagation
App set Account Download Authentication
for fi e-tuning
DBN RBM initialization Static App PlayStore Created Validation
CD-k Sampling Dynamic Permissions Account Download Authentication
Updating Deep
parameter Learning
RBM Assessment
Test Case:
7. Test Cases for Component Diagram:

Fig 7.7: Component Diagram

Test Case:

N/W Status(Complete/Inco
A User Validation(Yes/No) Valid user(Yes/No)
Connectivity(Yes/No) mplete)
Static Analysis Atomicity
B Permissions(Yes/No) Validation(Yes/No) Access (Yes/No)
1 (Yes/No)
changing users
Static Analysis Atomicity
C SensitiveAPI(Yes/No) permissions Validation (Yes/No)
2 (Yes/No)
(Yes/No)
Dynamic Atomicity Dynamic
D Execution(Yes/No) Send Data (Yes/No)
Analysis (Yes/No) behaviour(Yes/No)
N/W
characterize Android
E DBN Connectivity Malware(Yes/No) Validation (Yes/No)
apps.
(Yes/No)

Conclusion:
Hence we studies using generated test data (using mathematical models, GUI, Function testing
principles, if any) selection and appropriate use of testing tools, testing of
UML diagram’s reliability.