Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Assignment#5 Clo1: Software Quality Engineering Wednesday, May 27, 2020

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 10

ASSIGNMENT#5

CLO1

Aymal Khalid khan


Software Quality Engineering BSE_VI  01-131172-005 Wednesday, May 27, 2020
Aymal khalid Khan BSE_VI SQE

Contents
Q.1. Answer the following questions, defining and highlighting difference
between:.....................................................................................................................2
a) White-box and black box testing?.........................................................................2
Test cases Generated for white box testing have three distinct advantages:..........2
 A set of Black Box test cases is relatively small with respect to the full set of
programmed behaviors...........................................................................................2
 Testing can be commenced at an earlier stage. One need not wait for the GUI
to be available.........................................................................................................2
b) Control-flow and dataflow-based testing..............................................................3
c) Quality control and Quality assurance..................................................................3
d) Top-down integration and bottom-up integration.................................................4
e) Fault and Error......................................................................................................5
Q.2. what is an MM-Path? What are the various observable behavior criteria that
can put endpoints on MM-Path?...............................................................................5
Q.3. Please use category-partitioning method considering function definition given
below and answer the following questions:..............................................................5
Input spaces and partitions/value classes:.......................................................6
Strong Robust Test case:.....................................................................................7
Q.4.............................................................................................................................8
Introduction.........................................................................................................8
Checklist:.............................................................................................................8
Cleared Checklist:...............................................................................................8
Resulting Faults:..................................................................................................9
Conclusion:...............................................................................................................9
References:...............................................................................................................9

01-131172-005 Assignment#5 1
Aymal khalid Khan BSE_VI SQE

Q.1. Answer the following questions, defining and highlighting


difference between:
a) White-box and black box testing?
The goal of both approaches is to identify test cases. Black Box based testing uses only the
specification to identify test cases, while White Box testing uses the program source code
(implementation) as the basis of test case identification.
White Box Testing Black Box Testing
White box testing in contrast with Black Box testing The reason that specification-based testing was originally
can be defined as If the implementation (of the black called “functional testing” is that any program can be
box) is known and is used to identify the test cases. considered to be a function that maps values from its input
The ability to “see inside” the black box allows the domain to values in its output range.
tester to identify test cases on the basis of how the This notion is commonly used in engineering, when systems
function is actually implemented. are considered to be black boxes. This led to another
synonymous term—black box testing, in which the content
Test cases Generated for white box testing have three (implementation) of the black box is not known, and the
distinct advantages: function of the black box is understood completely in terms
of its inputs and outputs
 A set of Black Box test cases is relatively Test cases Generated for black Box Testing have two distinct
small with respect to the full set of advantages:
programmed behaviors.
 They are independent of how the software is
 Testing can be commenced at an earlier stage.
implemented, so if the implementation changes, the test
One need not wait for the GUI to be available.
cases are still useful;
 Testing is more thorough, with the possibility
 Test case development can occur in parallel with the
of covering most paths.
implementation, thereby reducing the overall project
development interval.
Cons:
Cons:
 It is hard to imagine this method identifying Black Box based test cases frequently suffer from two
behaviors that are not programmed problems: significant redundancies may exist among test
 Since tests can be very complex, highly skilled cases, compounded by the possibility of gaps of untested
resources are required, with a thorough software
knowledge of programming and
implementation.
 Test script maintenance can be a burden if the
implementation changes too frequently.
 Since this method of testing is closely tied to
the application being tested, tools to cater to
every kind of implementation/platform may
not be readily available.

01-131172-005 Assignment#5 2
Aymal khalid Khan BSE_VI SQE

b) Control-flow and dataflow-based testing


Control-Flow Data-Flow
A control-flow test can be described as A data-flow testing is one in which a graph
graph that shows decisions actually taken while shows paths actually taken through testing.
testing. A data-flow testing can be described as a
A Control-Flow Testing can be outlined as directed graph in which assignments and
a directed graph in which executed statements references to variables are represented by the
(or procedures) are represented by the nodes, nodes, and information flow is represented by
and control flow is represented by the arcs. For the arcs. For the purpose of hypothesis
the purpose of hypothesis generation, limit your generation, limit the data-flow graph to
control-flow graph to statements or procedures assignments and references that were actually
that were actually executed. You can develop executed.
this information using a program trace or an
execution profile.

c) Quality control and Quality assurance


The Main difference between them is that Things QC assure things done before developing
software & related produces while QA reassure Things done after developing software & related
products.
Quality control Quality assurance
- Quality Control (QC) is fault/failure Quality Assurance (QA) is fault prevention
detection through static and/or dynamic through process design and auditing -
testing of artifacts - Examining the artifact Creating processes, procedures, tools, jigs,
against pre-determined criteria to measure etc. to prevent faults from occurring -
conformance Examples: Templates, checklists, guides
- Main goal - Main goal:
Stopping leakage of defects before Prevent as much as possible defect injection
deployment, find, fix, or containment. which be defined as (Deliberately
inserted defects, inserted at any phase, and
intended to determine the effectiveness of
quality assurance) .

01-131172-005 Assignment#5 3
Aymal khalid Khan BSE_VI SQE

d) Top-down integration and bottom-up integration


Integration Testing
 Decomposition-Based Integration:
The functional decomposition tree (directed tree) is the basis for integration testing because it is
the main representation, usually derived from final source code, which shows the structural
relationship of the system with respect to its units. All these integration orders presume that the
units have been separately tested; thus, the goal of decomposition-based integration is to test the
interfaces among separately tested units
Top–Down Integration Bottom-up integration
Top–down integration begins with the main Bottom–up integration is a “mirror image” to
program (the root of the tree). Any lower- the top–down order, with the difference that
level unit That is called by the main program stubs are replaced by driver modules that
appears as a “stub,” where stubs are pieces of emulate units at the next level up in the tree.
throwaway. Steps:
Steps For Top Down Integration: Bottom–up integration begins with the leaves
The Steps in top–down integration are as of the decomposition tree, and use a driver
follow: version of the unit that would normally call it
1. The goal of the first step is to check to provide it with test cases.
that the main program functionality is (Note the similarity to test driver units at the
correct. unit level. As units are tested, the drivers are
2. Once the main program has been gradually replaced, until the full
tested develop stubs for all the units decomposition tree has been traversed.
called by the main program. The bottom-up strategy begins with the
3. In a stub for any unit, the tester hard terminal modules in the program (the modules
codes in a correct response to the that do not call other modules). After these
request from the calling/invoking unit. modules have been tested, again there is no
4. Next steps are as follow each time best procedure for selecting the next module
replace one stub at a time, leaving the to be incrementally tested; the only rule is
others as Stubs. that, to be eligible to be the next module, all
The stub replacement process proceeds in a of the module’s subordinate modules (the
breadth-first traversal of the decomposition modules it calls) must have been tested
tree until all the stubs have been replaced. previously
The “theory” of top–down integration is that, Cons:
as stubs are replaced one at a time, if there is Less throwaway code exists in
a problem, it must be with the interface to the Bottom–up integration, but the problem of
most recently replaced stub. (Fault Isolation) impossible interfaces persists.
Cons:
This process generates impossible interfaces.
In practice, the effort to develop stubs is
usually quite significant.
Disadvantage:
The drawback to this is that when (not if!) a failure is observed, few clues are available to help
isolate the location(s) of the fault.

01-131172-005 Assignment#5 4
Aymal khalid Khan BSE_VI SQE

e) Fault and Error


Error:
An incorrect internal state that is the manifestation of some fault. Or a measure of the difference
between the actual and the ideal.
Fault:
A static defect in the software or a condition that causes a system to fail in performing its
required function.
Difference:
Faults are problems in the code, failures are incorrect external events. Testing is the process of
trying to cause failures or to show that they occur at an acceptable rate. In contrast, debugging is
a diagnostic process where, given a failure, an attempt is made to find the associated fault.

Q.2. what is an MM-Path? What are the various observable behavior


criteria that can put endpoints on MM-Path?
 An interleaved sequence of module execution paths and messages
 We can describe sequences of module execution paths that include transfers of control
among separate units.
 MM paths always represent feasible execution paths, and these paths cross unit
boundaries

There are three observable behavioral criteria that put endpoints on MM Paths:
Event quiescence:
Occurs when a system is nearly idle, waiting for a port input event to trigger further processing.
•This is a system level property with an analog at the integration level: message quiescence.
Message quiescence
Occurs when a unit that sends no messages is reached
Data quiescence
Occurs when a sequence of processing culminates in the creation of stored data that is not
immediately used
.

Q.3. Please use category-partitioning method considering function definition given


below and answer the following questions:

Function Definition:
In mathematics, the factorial of a non-negative integer n, denoted by n! Is the product of all
positive integers less than or equal to n. For example,

The value of 0! is 1, according to the convention for an empty product. The students of MS-SE
were we're asked to test a function which calculates the factorial (n!) of a number n, returning 0
for negative inputs and -1 when the result is out of range (with size of int as 16 bits):

01-131172-005 Assignment#5 5
Aymal khalid Khan BSE_VI SQE

1) Define input spaces and their partitions


2) Develop test case for strong robust case

1. This function does only one thing, so we identify one Independently Testable
Feature: that is that the method or factorial (INT n) correctly computes and returns the
factorial of its parameter, n, or returns an appropriate error code.
2. Parameters and environment: The parameters here are pretty obvious — there's only
one, n. the environment, which is that INT has a limited range:
1. On a 32-bit computer system, INT has a range from -231 to 231-1.
2. On 64-bit computers the range is from -263 to 263-1. Those are big numbers, but
factorials are big as well: 14! Is too big for a 32-bit INT, and 22! Too big for a 64-
bit INT.
3. Identify the capacity of the system's INT as an environment factor, and an INT
might be one of several different sizes depending on the platform.

Input spaces and partitions/value classes:


Three partitions:
Environments to test in: 16-bit, 32-bit and 64-bit;
For n we also have three partitions: negative, in range and out-of-range:

Value classes for environment — size of INT:

1. 16-bit
2. 32-bit
3. 64-bit

Value classes for parameters — n:

1. n < -1 (undefined: return 0)


2. n = -1 (undefined: return 0 — just below boundary)
3. n = 0 (just above boundary)
4. 0 < n < MAX (IN RANGE)
5. n = MAX (just below boundary)
6. n = MAX + 1 (out of range: return -1 — just above boundary)
7. n > MAX + 1 (out of range: return -1)

MAX is the largest factorial we can compute in the relevant environment:

Test Case:

We have three different environments and seven different value classes, so this means 3 × 7 = 21
tests.

01-131172-005 Assignment#5 6
Aymal khalid Khan BSE_VI SQE

Test case Size of INT Value class for n Expected result


1 any Value class n < -1 0 (undefined)
2 any n = -1 0 (undefined)
3 any n = 0 1
0 < n < MAX (for all
4 any varies (correct answer)
environments)
n > MAX + 1 (for all
5 any -1 (out of range)
environments)
6 16-bit n = MAX (correct answer)

7 16-bit n = MAX + 1 -1 (out of range)


8 32-bit n = MAX (correct answer)
9 32-bit n = MAX + 1 -1 (out of range)
10 64-bit n = MAX (correct answer)
11 64-bit n = MAX + 1 -1 (out of range)

General test Case For all the Environments:

Strong Robust Test case:


Test case Size of INT n Expected result Description
1 64-bit -100 0 Value class n < -1
2 32-bit -1 0 Value class n = -1
3 32-bit 0 1 Value class n = 0
4 16-bit 5 120 Value class 0 < n < MAX (for all
environments)
5 64-bit 99 -1 Value class n > MAX + 1 (for all
environments)
6 16-bit 7 5,040 MAX = 7
7 16-bit 8 -1 MAX = 7
8 32-bit 12 479,001,600 MAX = 12

9 32-bit 13 -1 MAX = 12

10 64-bit 20 2,432,902,008,176,640,000 MAX = 20

01-131172-005 Assignment#5 7
Aymal khalid Khan BSE_VI SQE

Q.4. Please make use of a good checklist for code review and please review the
following code, report issues and highlight how you have selected and
implemented a particular software verification technique such that you first share
the checklist and then the resulting faults.
Introduction

Competing tasks manipulating the same resource, we can easily get a race condition as the
resources are not in step-lock or utilizes a token based system such as semaphores. There many
problems which can arise:

Checklist:
Checklist For the Code Review
Threading  
1.
Interlocking
2.
Memory leak
3.
User and Kernel Mode Switching
4.
Multi-Tasking
5.
Multi-Threading
6.
Check Thread Pool
7.
List Reason
Thread Synchronization
8.
1. Threading   sem_init(for threads)  Initialization (Thread)

1. Interlocking sem_wait ,sem_post  Mutex Lock

2. Memory leak sem_destroy Memory Leak

3. User and Kernel Mode Switching #include <unistd.h>

Cleared Checklist:

Resulting Faults:

Resulting Faults
1. Multi-Tasking
2. Multi-Threading
3. Thread Pool
4. Thread Synchronization

01-131172-005 Assignment#5 8
Aymal khalid Khan BSE_VI SQE

Conclusion:

In this assignment we covered from basic of testing to an extent of practical in the first question
we covered the major and basic differences from glossary of basic testing then moved on mm
paths of a function did categorical partitioning based testing and final made a review code
checklist for a common operation in Operating System called semaphore.

References:

Introduction to Software Testing by Paul Amman, Jeff Offutt (z-lib.org)

Software Reading Techniques Twenty Techniques for More Effective Software Review and Inspection —
Yang-Ming Zhu

Software-testing-concepts-and-tools-oozy

Software-testing craftsman’s approach

01-131172-005 Assignment#5 9

You might also like