17602 Abdul Wadood Authif

Email: athiff.43@gmail.com 2020-05-09

Class: Software Testing
Teacher: Mr.Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17602 Abdul Wadood Authif

1/47
17604 Aiman Tabreez P
Email: aymantabrez@gmail.com 2020-05-09
Class: Cse A
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17604 Aiman Tabreez P

2/47
17607 Asfa Nazneen
Email: asfaabyan23@gmail.com 2020-05-09
Class: 3rd year CSE
Teacher: Kishore Verma

Software Testing Online Revision Test 3

Word count: 1130

1.Requirements based testing :

*Requirements based testing is a testing approach in which test cases, conditions and data are
derived from requirements. It also includes functional and non-functional attributes such as
reliability, usability or performance.
*Stages in requirements based testing,
Testing completion criteria
Testing is completed only when all the functional and non functional testing is complete.
Design test cases
A test case has five parameters namely initial state or preconditions, the inputs, data setup, expected
outcomes and actual outcomes.
Execute tests
Execute the test cases against the system under the test and document the results.
Verify test results - verify if the test cases match the expected and actual outcomes.
Verify test coverage
To verify if the test results satisfy the both functional and non-functional aspects
Track and manage defects
Any defects detected goes through detect life cycle and resolution occurs.
Positive and negative testing
It is a testing approach where the system validated the valid inputs.
Trster always checks for valid set of values
and check if a application behaves as expected with its inputs
Positive testing always tries to prove that a given product and project always meets the requirements
and specifications.
Eg
CConsider a scenario where you want to test an application which contains a simple text box to enter
age and requirements say that it should take only integers value
Negative testing
It is a testing where the system validated against the invalid input data. A negative test checks if a
application behavesas expected with its negative inputs.
Eg
CConsider a same age tectbox example which should accept only integer values. So here we provide
the characters like abcd in the age tectbox and check the behavior of the application.
State based testing
State transition testing is useful for both procedural and object oriented development. It is based on
the concepts of states and state machines
*A state is an internal configuration of a system or component. It is defined in terms of the values
assjmed at a particular time for the variable that characterize the system or component
*State charts are useful models of software.
*state charts are commonly depicted by a set of nodes
*A set of arrows between nodes indicate what inputs or transitions will cause change.

3/47
*The arrows display inputs or actions that cause the state transformation
User documentation and software compatibility testing
It is a type of non functional testing
*Any written or pictorial representation, defining, specifying or reporting or certifying activities
*documentation is important to a product's success as the product itself
*If the documentation is poor, non existent, or wrong, it reflects on the quality of the product and the
vendor
*compatibility is a non functional testing to ensure customers satisfaction
*It is to determine whether your software application or product is proficient enough to run in
different browsers, database, hardware, OS, mobile devices and networks.
2. Equivalence class partition
* Equivalence class partitioning results in a partitioning of the input domain of the software under
test.
* The finite number of partitions or equi
valence classes that result allow the tester to select a given member of an equivalence class as a
representative of that class.
* All members of an equivalence class are processed in an equivalent way by the target software.
*Therefore, if one test case in a particular equivalence class reveals a defect, all the other test cases
based on that class would be expected to reveal the same defect.
Cont’d
Boundary value analysis
*The test cases developed based on equivalence class partitioning can be strengthened by use of an
technique called boundary value analysis.
*Test cases that consider these boundaries on both the input and output spaces
Module tested on a payroll system
1) Description:
These test case scenarios test the Maintain timecard function of the Run Payroll System. The
requirements are that the user should be able to select a period, choose a project charge number and
enter how many hours he has worked on that project.
2) Procedure specifications
Change password
1) Description:
These test case scenarios test the Change password function of the Run Payroll System. The
requirements are the user should be able to change their needs.
Maintain employee information
1) Description:
These test case scenarios test the Maintain employee function of the Run Payroll System. The
requirements are the System administrator should be able to add/delete employees and change
employee information
Create administrative report
1.)Description:
These test case scenarios test the Create administrative report function of the Run Payroll System.
The requirements are that the System administrator should be able to create and save administrative
reports of all/or specified employees.
Change payment method
1) Description:
These test case scenarios test the Change payment method function of the Run Payroll System. The
requirements are that the user should be able to change his payment method to either pickup or direct

4/47
deposit.
3.White box testing
A program prime is an atomic programming unit. All structured programs can be built from
three basic primes
*sequential (e.g., assignment statements),
* decision (e.g., if/then/else statements), and
* iterative (e.g., while, for loops).
In white box testing,
The nodes represent sequential statements, as well as decision and looping predicates.
* For simplicity, sequential statements are often omitted or combined as a block that indicates that if
the first statement in the block is executed, so are all the following statements in the block.
*Edges in the graph represent transfer of control.
*The direction of the transfer depends on the outcome of the condition in the predicate (true or
false).
* each decision element (if-then, case, loop) executes with all possible outcomes at least once.
* In control flow model, all the edges in flow graph must be exercised at least once.
*If the defect is a missing statement it may remain undetected by tests satisfying complete statement
coverage.
* Input values must ensure execution the true/false possibilities for the decisions in (while loop) and
(if statement).
* Note that the if statement has a full else component, that is, there is no else part. However, we
include a test that covers both the true and false conditions for the statement.
*A path is a sequence of control flow nodes usually beginning from the entry node of a graph
through to the exit node.
*A path may go through a given segment of the control flow graph one or more times. We usually
designate a path by the sequence of nodes it encompasses.
Cont’d
•*A set of independent paths for a graph is sometimes called a basis set.
*For most software modules it may be possible to derive a number of basis sets.
*set of independent paths starting with the first path identified . (i) 1-2-3-4-8 (ii) 1-2-3-4-5-6-7-4-8
(iii)1-2-3-4-5-7-4-8

17607 Asfa Nazneen

5/47
17610 Charumathi S
Email: charumathi1603@gmail.com 2020-05-09
Class: Cse-A
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17610 Charumathi S

6/47
17614 Dhanupriya B
Email: dhanupriya873@gmail.com 2020-05-09
Class: 3rd Cse A
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17614 Dhanupriya B

7/47
17621 Hina Kausar.A
Email: kausarfathima1102@gmail.com 2020-05-09
Class: CSE-A
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17621 Hina Kausar.A

8/47
17622 A Janani
Email: Janani1067@gmail.com 2020-05-09
Class: IIIyr cse "A"
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17622 A Janani

9/47
17623 Janani D
Email: jananimadhu1906@gmail.com 2020-05-09
Class: 3 year CSE
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 1208

1.Payroll system :
EQUALANCE CLASS PARTITIONING :
*Equivalence class partitioning results in a partitioning of the input domain of the software under
test.
*The finite number of partitions or equivalence classes that result allow the tester to select a given
member of an equivalence class as a representative of that class.
*All members of an equivalence class are processed in an equivalent way by the target software.
*Therefore, if one test case in a particular equivalence class reveals a defect, all the other test cases
based on that class would be expected to reveal the same defect.
BOUNDARY VALUE ANALYSIS :
*The test cases developed based on equivalence class partitioning can be strengthened by use of an
technique called boundary value analysis.
*Test cases that consider these boundaries on both the input and output spaces.
TEST CASE ANALYSIS AND RESULTS :
A.LOGIN :
DESCRIPTION :
1.These test case scenarios test the login function of the Run Payroll System. The requirements are
that if the user specifies a valid user ID and password he will be logged in to the system. Otherwise
he will be refused access to the system. The test result is presented below.
2.Procedure specifications: In order for the Test Cases to be initialized, the tester must have installed
the Run Payroll System on his personal Computer, executed the Run Payroll system by clicking on
the run payroll icon and be logged in to the Payroll system with username/password.
B.LOGOUT :
DESCRIPTION :
1.These test case scenarios test the logout function of the Run Payroll System. The requirements are
that that if the User logs out and his timecard has been changed it will be saved. If the user has
created a report he will be asked to save it. The test result is presented below.
2.Procedure specifications.
C.MAINTAIN TIMECARD :
DESCRIPTION :
1.These test case scenarios test the Maintain timecard function of the Run Payroll System. The
requirements are that the user should be able to select a period, choose a project charge number and
enter how many hours he has worked on that project. The test result is presented below.
2.Procedure specifications.
D.CHANGE PASSWORD :
DESCRIPTION :
1.These test case scenarios test the Change password function of the Run Payroll System. The
requirements are the user should be able to change password to another than the default. The test
result is presented below.
2.Procedure specifications.

10/47
E.CREATE EMPLOYEE REPORT :
DESCRIPTION :
1.These test case scenarios test the Create employee report function of the Run Payroll System. The
requirements are the employee should be able to generate different kinds of reports and be able to
save them. The test result is presented below.
2.Procedure specifications.
F.MAINTAIN EMPLOYEE INFORMATION :
DESCRIPTION :
1.These test case scenarios test the Maintain employee function of the Run Payroll System. The
requirements are the System administrator should be able to add/delete employees and change
employee information. The test result is presented below.
2.Procedure specifications.
G.CREATE ADMINISTRATIVE REPORT :
DESCRIPTION :
1.These test case scenarios test the Create administrative report function of the Run Payroll System.
The
requirements are that the System administrator should be able to create and save administrative
reports of all/or specified employees. The test result is presented below.
2.Procedure specifications.
H.CHANGE PAYMENT METHOD :
1.These test case scenarios test the Change payment method function of the Run Payroll System. The
requirements are that the user should be able to change his payment method to either pickup or direct
deposit.
The test result is presented below.
2.Procedure specifications.

2.WHITE BOX TESTING :

*The white box approach focuses on the inner structure of the software to be tested. To design test
cases using this strategy the tester must have knowledge of that structure.
*The code, or a suitable pseudo code like representation must be available.
1.White box testing methods are especially useful for
2.revealing
3.design and code-based control
4.ogic and sequence defects
5.initialization defects
6.data flow defects.
COVERAGE AND CONTROL FLOW GRAPHS. :
*Coverage analysis is typically associated with the use of control and data flow models.
*The logic elements most commonly considered for coverage are based on the flow of control in a
unit of code.
For example,
1.program statements;
2.decisions/branches;
3.conditions;
4.combinations of decisions and conditions;
5.paths;
*A program prime is an atomic programming unit. All structured programs can be built from three
basic primes :

11/47
• sequential.
• decision.
• iterative.
SUM OF POSITIVE INTEGERS :
The input parameters are num_of_entries, an integer and an array of integers with number_of_entry
elements. The output parameter is integer sum.
1.pos_sum(a, num_of_entries, sum)
2.sum = 0
3.int i = 1
4.while (i <= num_of_entries)
5.if a[i] >
6.sum = sum + a[i]
end if
7.i = i + 1
end while
8.end pos_sum
COVERING CODE LOGIC :
*Two major payoffs for the tester:
1.quantitative coverage goals can be proposed, and
2.commercial tool support is readily available to facilitate the tester‘s work .
*The tester selects the logic element program statements to design tests that focus on the execution
of program statements.
*If the goal is to satisfy the statement adequacy/ coverage criterion, then the tester should develop a
set of test cases so that when the module is executed, all (100%) of the statements are executed at
least once.
*In control flow model, all the edges in flow graph must be exercised at least once.
*If the defect is a missing statement it may remain undetected by tests satisfying complete statement
coverage.
*Input values must ensure execution the true/false possibilities for the decisions in line 4 (while
loop) and line 5 (if statement).
*Note that the if statement has a full else component, that is, there is no else part. However, we
include a test that covers both the true and false conditions for the statement.
*Test satisfies both the branch adequacy criterion and the statement adequacy criterion.
PATHS : THEIR ROLE IN WHITE BOX TEST :
These tools typically calculate a value for a software attribute called McCabe‘s Cyclomatic
Complexity V(G) from a flow graph.
*The cyclomatic complexity attribute is very useful to a tester.
*The complexity value is usually calculated from the control flow graph (G) by the formula
V(G)=E-N+2
*The value E is the number of edges in the control flow graph and N is the number of nodes.
*cyclomatic complexity provides an approximation of the effort of testability of a module.
*The value of V(G) is used to approximate the testing time and resources required to test a software
module.
*The cyclomatic complexity value and the control flow graph give the tool for developing test cases
using the concept of a path.
*A path is a sequence of control flow nodes usually
beginning from the entry node of a graph through to the exit node.

12/47
*A path may go through a given segment of the control flow graph one or more times. We usually
designate a path by the sequence of nodes it encompasses.
*A set of independent paths for a graph is sometimes called a basis set.
*For most software modules it may be possible to derive a number of basis sets.
*The number of independent paths in a basis set is equal to the cyclomatic complexity of the graph.
17623 Janani D

13/47
17624 Jeniper V
Email: jeniper113@gmail.com 2020-05-09
Class: 3rd year
Teacher: Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17624 Jeniper V

14/47
17625 Kalaiyarasi N
Email: arasikalai2400@gmail.com 2020-05-09
Class: 3rd year CSE-A
Teacher: Mr. Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17625 Kalaiyarasi N

15/47
17627 Keerthana R
Email: keerthanr3107@gmail.com 2020-05-09
Class: 3rd year CSE-A
Teacher: Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17627 Keerthana R

16/47
17631 Madhumitha K
Email: madhumithamadhumitha475@gmail.com 2020-05-09
Class: CSE A
Teacher: Kishore

Software Testing Online Revision Test 3

Word count: 1629

2. Black box testing:

Equivalence Class Partitioning
• Equivalence class partitioning results in a partitioning of the input
domain of the software under test.
• The finite number of partitions or equivalence classes that result
allow the tester to select a given member of an equivalence class as a
representative of that class.
• All members of an equivalence class are processed in an equivalent
way by the target software.
• Therefore, if one test case in a particular equivalence class reveals a
defect, all the other test cases based on that class would be expected
to reveal the same defect.
BOUNDARY VALUE ANALYSIS
• The test cases developed based on equivalence class partitioning can
be strengthened by use of an technique called boundary value
analysis.
• Test cases that consider these boundaries on both the input and
output spaces
TEST CASES ANALYSIS AND RESULTS
A. Login:
1) Description:
These test case scenarios test the login function of the Run Payroll System. The
requirements are that if the user specifies a valid user ID and password he will be logged in
to the system. Otherwise he will be refused access to the system. The test result is presented
below
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
B. Logout:
1) Description:
These test case scenarios test the logout function of the Run Payroll System. The
requirements are that that if the User logs out and his timecard has been changed it will be
saved. If the user has created a report he will be asked to save it. The test result is presented
below
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
C. Maintain Timecard

17/47
1) Description:
These test case scenarios test the Maintain timecard function of the Run Payroll System. The
requirements are that the user
should be able to select a period, choose a project charge number and enter how many hours he has
worked on that project.
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
D. Change Password
1) Description:
These test case scenarios test the Change password function of the Run Payroll System. The
requirements are the user should
be able to change password to another than the default. The test result is presented below
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
E. Create Employee Report
1) Description:
These test case scenarios test the Create employee report function of the Run Payroll System. The
requirements are the
employee should be able to generate different kinds of reports and be able to save them. The test
result is presented below
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
F. Maintain Employee Information
1) Description:
These test case scenarios test the Maintain employee function of the Run Payroll System. The
requirements are
the System administrator should be able to add/delete employees and change employee information.
The test
result is presented below (see Table VI).
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
G. Create Administrative Report
1) Description:
These test case scenarios test the Create administrative report function of the Run Payroll System.
The
requirements are that the System administrator should be able to create and save administrative
reports of all/or
specified employees. The test result is presented below.
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll

18/47
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
H. Change Payment Method
1) Description:
These test case scenarios test the Change payment method function of the Run Payroll System. The
requirements are that the user should be able to change his payment method to either pickup or direct
deposit.
2) Procedure specifications: In order for the Test Cases to be initialized, the tester must have
installed the Run Payroll System on his personal Computer, executed the Run Payroll
system by clicking on the run payroll icon and be logged in to the Payroll system with
username/password .
2. White box testing:
WHITE BOX TESTING
The white box approach focuses on the inner structure of the
software to be tested. To design test cases using this strategy the
tester must have knowledge of that structure.
The code, or a suitable pseudo code like representation must be
available.
• White box testing methods are especially useful for
• revealing
• •design and code-based control
• •logic and sequence defects
• •initialization defects, and
• •data flow defects.
Coverage and Control Flow Graphs
• Coverage analysis is typically associated with the use of control and data
flow models
• The logic elements most commonly considered for coverage are based on
the flow of control in a unit of code. For example,
(i) program statements;
(ii) decisions/branches (these influence the program flow of control);
(iii) conditions (expressions that evaluate to true/false, and do not
contain any other true/false-valued expressions);
(iv)combinations of decisions and conditions;
(v)paths (node sequences in flow graphs).
A program prime is an atomic programming unit. All structured
programs can be built from three basic primes-
• sequential (e.g., assignment statements),
• decision (e.g., if/then/else statements), and
• iterative (e.g., while, for loops).A program prime is an atomic programming unit. All structured
programs can be built from three basic primes-
• sequential (e.g., assignment statements),
• decision (e.g., if/then/else statements), and
• iterative (e.g., while, for loops).
The nodes represent sequential statements, as well as decision and
looping predicates.
• For simplicity, sequential statements are often omitted or combined
as a block that indicates that if the first statement in the block is

19/47
executed, so are all the following statements in the block.
• Edges in the graph represent transfer of control.
• The direction of the transfer depends on the outcome of the
condition in the predicate (true or false).
Covering Code Logic
Two major payoffs for the tester:
(i) quantitative coverage goals can be proposed, and
(ii) commercial tool support is readily available to facilitate the tester‘s
work .
The tester selects the logic element program statements to design
tests that focus on the execution of program statements.
If the goal is to satisfy the statement adequacy/ coverage criterion,
then the tester should develop a set of test cases so that when the
module is executed, all (100%) of the statements are executed at least
onc
each decision element (if-then, case, loop) executes with all possible
outcomes at least once.
• In control flow model, all the edges in flow graph must be exercised at
least once.
• If the defect is a missing statement it may remain undetected by tests
satisfying complete statement coverage.
• Input values must ensure execution the true/false possibilities for the
decisions in line 4 (while loop) and line 5 (if statement).
• Note that the if statement has a full else component, that is, there is
no else part. However, we include a test that covers both the true and
false conditions for the statement
Paths: Their Role in White Box-Based Test
Design
These tools typically calculate a value for a software attribute called
McCabe‘s Cyclomatic Complexity V(G) from a flow graph.
• The cyclomatic complexity attribute is very useful to a tester.
• The complexity value is usually calculated from the control flow graph
(G) by the formula
V(G)=E-N+2
The value E is the number of edges in the control flow graph and
N is the number of nodes.
Uses - to provide an approximation of the number of test cases
needed for branch coverage in a module of structured code.
• cyclomatic complexity provides an approximation of the effort of
testability of a module.
• the value of V(G) is used to approximate the testing time and
resources required to test a software module.
• The cyclomatic complexity value and the control flow graph give the
tool for developing test cases using the concept of a path.
• A path is a sequence of control flow nodes usually
beginning from
the entry node of a graph through to the exit node.
• A path may go through a given segment of the control flow graph one

20/47
or more times. We usually designate a path by the sequence of nodes
it encompasses.

17631 Madhumitha K

21/47
 17644 monisha j
Email: monijagan2599@gmail.com 2020-05-09
Class: cse a 3rd year
Teacher: kishore verma

Software Testing Online Revision Test 3

Word count: 447

1)i)Requirememt based testing:

Requirement based testing is a testing approach in ehich test cases, conditions and data are derived
from requirements. It includes functional attributes and also non functional attributes such as
performance, reliability and usability.

Stages of requirement based testing:

*defining test completion criteria: Testing is completed only when all the functional and non
functional testing is completed.
*Design test cases: A test has five parameters namely, initial state, data setup, the inputs, expected
outcome and actual outcome.
*Excecute result: Excecute the test against the system under test and document the results.
*Verify test results: verify if the actual results and the expected results match each other.
*Verify test coverage: Verify if the test covers both the functional and non functional aspects of the
requirements.
*Track and manage defects: any defects occured goes through the defect life cycle and tracked to
resolution.

ii)POSITIVE AND NEGATIVE TESTING:

POSITIVE TESTING:
It is used to process where the system validated against the given input data.
Tester always checks that the systems behaves accordingly to the given inputs.
Positive testing tries to prove that a given product meets the requirements and specification.
EXAMPLE:
Consider a scenario where the there is a test application to enter your age in the given box. the input
should only be given in integers.

NEGATIVE TESTING:
A negative testing is used to validate the application against the given inputs. It is used to check
whether the system performs accordingly to the given negative input.
The main reason behind this testing is to ensure the stability of the software application against the
variety of negative inputs.
EXAMPLE: Consider the same textbox to give your age in the required field. It should accept only
integers. So when we provide characters as the input in the text box it should give the error message
as the expected output.

iii)STATE BASED TESTING:

state transition testing is useful for both procedural and object oriented development. It is based on te concepts of states and finite-state
machines, and allows the tester to view the developing software in terms of its states, and the inputs and events that trigger state
changes.

22/47
A state is a internal configuration of a system or component. It is defined in terms of assumed at a
particular time for the variables that characerize the system or component.
A finite state machine is an abstract machine that can be represented by a state grapg having a finite
numbers of states and a finite number of transitions between the states.

iv)USER DOCUMENTATION TESTING:

It is a type of non functional testing.
Any written or pictorial information describing,

17644 monisha j

23/47
17648 Nandhini K
Email: nandhinibe10299@gmail.com 2020-05-09
Class: Cse B
Teacher: Mr Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17648 Nandhini K

24/47
17650 Nithya K
Email: nithyabe10299@gmail.com 2020-05-09
Class: 3rd year CSE-B
Teacher: Mr Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17650 Nithya K

25/47
17651 S Pavithra
Email: ranisaravananamul@gmail.com 2020-05-09
Class: 3rd year Cse B
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17651 S Pavithra

26/47
17652 Pooja Baskar
Email: Poojainvlr@gmail.com 2020-05-09
Class: ST
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17652 Pooja Baskar

27/47
17654 Prasanth R
Email: rprasanthvijay512000@gmail.com 2020-05-09
Class: Cse b 3rd year
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17654 Prasanth R

28/47
17657 Preethi C
Email: preethiroopchandran@gmail.com 2020-05-09
Class: Software testing
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17657 Preethi C

29/47
17658 Priya Dharshini
Email: priyavinayagm2599@gmail.com 2020-05-09
Class: BE cse b-sec 3rd year 6 sem
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17658 Priya Dharshini

30/47
17659 Priyanka K
Email: priyankapriya9910@gmail.com 2020-05-09
Class: Be(cse)
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17659 Priyanka K

31/47
17662 Ramya M
Email: 2000rmya@gmail.com 2020-05-09
Class: BE CSE
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17662 Ramya M

32/47
17665 Sameer D
Email: dssameer2000@gmail.com 2020-05-09
Class: 3rd b
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17665 Sameer D

33/47
17672 Sreemathi Venkatesan
Email: sreemathi.vd@gmail.com 2020-05-09
Class: 3cseb
Teacher: Prof Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17672 Sreemathi Venkatesan

34/47
17673 Sridevi S
Email: srideviselvaraj79@gmail.com 2020-05-09
Class: 3rd year -"B"sec
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17673 Sridevi S

35/47
17674 Srividhya .m
Email: srividhyamanogaran2000@gmail.com 2020-05-09
Class: 3
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17674 Srividhya .m

36/47
17674 Srividya .m
Email: srividhyamanogaran2000@gmail.com 2020-05-09
Class: 3
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

17674 Srividya .m

37/47
17675 Suva Lakshmi
Email: rsuva2000@gmail.com 2020-05-09
Class: 3 cse b
Teacher: Kishore verma

Software Testing Online Revision Test 3

Word count: 0

17675 Suva Lakshmi

38/47
17679 Vignesh P
Email: vghfriends@gmail.com 2020-05-09
Class: CSE-B
Teacher: Kishoreveruma

Software Testing Online Revision Test 3

Word count: 0

17679 Vignesh P

39/47
17682 Yamini S
Email: yamini.s2802@gmail.com 2020-05-09
Class: CSE B
Teacher: Kishore Verma sir

Software Testing Online Revision Test 3

Word count: 0

17682 Yamini S

40/47
17683 Zubaida Afreen
Email: afreenaffy2000@gmail.com 2020-05-09
Class: 3
Teacher: Kishore Verma

Software Testing Online Revision Test 3

Word count: 0

17683 Zubaida Afreen

41/47
 510617104018 harinandhan v
Email: harinandhan15@gmail.com 2020-05-09
Class: cse a
Teacher: kishore varma

Software Testing Online Revision Test 3

Word count: 388

1.i.Requirement based testing:

Requirement based testing is done based on the requirements derived like test case,conditon
and data.In requirement based testing the functional and non functional aspects like perfomance ,
usability and etc are tested

Stages in requirement testing:

•defining test completion - test the functional and non functional aspects completely
•design test case - deside what are all to be tested
•execute test case - perform the test case
•verify result - verify the result is succuss as expected or failed
•track defects - if there is any defects find and fix it

ii)Positive testing:

• positive testing is a process of testing the software with only the vaild set of inputs
• it checks the software to run as expected
• it checks that for given valid inputs the software is performing correctly
• the intension of positive testing is to prove that the software as no defects

Ex:

consider the application containg the age column.the age should be always integer. testing with only
integer value is called as positive testing

age 21

Negative testing:

• negative testing is a process of testing the software with only the invalid set of inputs
• the intension of negative testing is to prove that the software as some defects
• it checks the softwate with invalid input and expect for the error

Ex:

consider the same application containing the age column . the age should be entered in integer if
any char is entered then is a defect

age aaadfv

42/47
iii)State based testing:

• state based testing is also called as state transition testing

• state transition testing is usefull for both procedural and object oriented development
• it is based on states and final state machine
• it tests the states, transition between the states, events and input

Ex:

an atm machine is in idle state before inserting the atm card. when the atm card is inserted then it
should change to other state.
state based testing test this transition between the states when the event is occured.

iv)User documentaion testing:

• user documentational testing is a type of non functional testing

• document testing is perfomed on the reports,requirements , procedures and etc
• if the document is not right there will be major and costly problem
• documents are checked for spelling and grammer mistakes

510617104018 harinandhan v

43/47
510617104063 Sameer D
Email: dssameer2000@gmail.com 2020-05-09
Class: 3rd b
Teacher: Kishore varma

Software Testing Online Revision Test 3

Word count: 0

510617104063 Sameer D

44/47
iWGXbx BRAHADEESWAR K
Email: eswar.blaze@gmail.com 2020-05-09
Class: CSE A
Teacher: Kishore Varma

Software Testing Online Revision Test 3

Word count: 0

iWGXbx BRAHADEESWAR K

45/47
soundariya soundariya b
Email: soundariyab2000@gmail.com 2020-05-09
Class: cse-b
Teacher: kishore varama

Software Testing Online Revision Test 3

Word count: 0

soundariya soundariya b

46/47
soundaryavkn@gmail.con Soundarya
Soundarya
Email: soundaryavkn@gmail.con 2020-05-09
Class: 3yr b
Teacher: Kishore

Software Testing Online Revision Test 3

Word count: 0

soundaryavkn@gmail.con Soundarya Soundarya

47/47