Docstoc

CMS6

Document Sample
CMS6 Powered By Docstoc
					CMS USING RFID                                                     SYSTEM TESTING


CHAPTER-6

                            SYSTEM TESTING


6.1 Introduction


Testing is one of the most important phases in the software development activity. In
software development life cycle (SDLC), the main aim of testing process is the
quality; the developed software is tested against attaining the required functionality
and performance.

During the testing process the software is worked with some particular test cases and
the output of the test cases are analyzed whether the software is working according to
the expectations or not.

The success of the testing process in determining the errors is mostly depends upon
the test case criteria, for testing any software we need to have a description of the
expected behavior of the system and method of determining whether the observed
behavior confirmed to the expected behavior.

6.2 Testing Fundamentals

      The process of executing a system with the intent of finding an error.

      Testing is defined as the process in which defects are identified, isolated,
       subjected for rectification and ensured that product is defect free in order to
       produce the quality product and hence customer satisfaction.

      Quality is defined as justification of the requirements

      Defect is nothing but deviation from the requirements

      Defect is nothing but bug.

      Testing can demonstrate the presence of bugs, but not their absence

      Debugging and Testing are not the same thing!


Dept of IT/KEC, 2010-11                                                            58
CMS USING RFID                                                          SYSTEM TESTING


          Testing is a systematic attempt to break a program or the AUT



   Testing Methodologies:

            Black box Testing: It is the testing process in which tester can perform
             testing on an application without having any internal structural knowledge
             of application. Usually Test Engineers are involved in the black box testing.

            White box Testing: It is the testing process in which tester can perform
             testing on an application with having internal structural knowledge.
             Usually The Developers are involved in white box testing.

            Gray Box Testing: It is the process in which the combination of black box
             and white box tonics’ are used.
   Types of Testing:

            Smoke Testing: It is the process of initial testing in which tester looks for
             the availability of all the functionality of the application in order to perform
             detailed testing on them.

            Regression Testing: It is one of the best and important testing. Regression
             testing is the process in which the functionality, which is already tested
             before, is once again tested whenever some new change is added.

            Re-Testing: It is the process in which testing is performed on some
             functionality which is already tested before to make sure that the defects are
             reproducible and to rule out the environments issues if at all any defects are
             there.

            Static Testing: It is the testing, which is performed on an application when
             it is not been executed.ex: GUI, Document Testing

            Dynamic Testing: Is the testing which is performed on an application when
             it is being executed. Ex: Functional testing.

            Alpha Testing: It is a type of user acceptance testing, which is conducted
             on an application when it is just before released to the customer.

Dept of IT/KEC, 2010-11                                                                   59
CMS USING RFID                                                              SYSTEM TESTING


         Beta-Testing: It is a type of UAT that is conducted on an application when
          it is released to the customer, when deployed in to the real time environment
          and being accessed by the real time users.

         Compatibility testing: It is the testing process in which usually the
          products are tested on the environments with different combinations of
          databases (application servers, browsers…etc)

         Installation Testing: It is the process of testing in which the tester try to
          install or try to deploy the module into the corresponding environment by
          following the guidelines produced in the deployment.

6.3. Testing Strategy


 Levels of Testing

Since the errors in the software can be injured at any stage. So, we have to carry out
the testing process at different levels during the development. The basic levels of
testing are Unit, Integration, System and Acceptance Testing.




                    Module1            Module2              Module3

                     Units                  Units                   Units




                              i/p   Integration o/p i/p   Integration o/p




             System Testing: Presentation + business +Databases

            UAT: user acceptance testing


Fig 6.1 levels of testing


Dept of IT/KEC, 2010-11                                                                 60
CMS USING RFID                                                       SYSTEM TESTING


(A) Unit Testing

Unit testing mainly focused first in the smallest and low-level modules, proceeding
one at a time. But for the purpose of testing, modules themselves were used as stubs,
to print verification of the actions performed. Each module was tested against
required functionally and test cases were developed to test the boundary values.

(B) Integration Testing

Is a systematic technique for constructing the program structure, while at the same
time conducting tests to uncover errors associated with interfacing as the system
consists of the number of modules the interface to be tested was between the edges of
the two modules.

(C) System Testing

Is a series of different tests whose primary purpose is to fully exercise the computer-
based system? It also tests to find discrepancies between the system and its original
objective, current specifications.

(D) Functional Testing

In Functional Testing test cases are decided solely on the basis of requirements of the
program or module and the internals of the program or modules are not considered for
selection of test cases. This is also called Black Box Testing.

(E) Structural Testing

In Structural Testing test cases are generated on actual code of the program or module
to be tested. This is called White Box Testing.

 Testing Process

A number of activities must be performed for testing software. Testing starts with test
plan. Test plan identifies all testing related activities that need to be performed along
with the schedule and guide lines for testing. The plan also specifies the levels of
testing that need to be done, by identifying the different testing units. For each unit
specified in the plan first the test cases and reports are produced. These reports are
analyzed.

Dept of IT/KEC, 2010-11                                                               61
CMS USING RFID                                                       SYSTEM TESTING


 Testing Terminology

               The following are the testing terminologies.

 Test Plan
               Test plan is a general document for entire project, which defines the
scope, approach to be taken and the personal responsible for different activities of
testing. The inputs for forming test plane are
                                Project plan

                                Requirements document

                                System design

 Test Case
               A document that defines a test item and specifies a set of test inputs or
data, execution conditions and expected results. The inputs / data used by a test case
should be both normal and intended to produce a “good” result and intentionally
erroneous and intended to produce an error. A test case is generally executed
manually but test cases can be combined for automated execution.

 Test Case Execution and Analysis
               The steps to be performed for executing the test cases are specified in
separate document called test procedure specification. This document specifies any
specify requirements that exist for setting the test environment and describes the
methods and formats for reporting the results of testing.

 Test Script
               Step by step procedures for using a test case to test a specific unit of
code, function, or capability.

 Test Scenario
               A chronological record of the details of the execution of a test script
captures the specifications, tester activities and outcomes used to identify defects.

 Test Run
               A series of logically related groups of test cases or conditions.




Dept of IT/KEC, 2010-11                                                                 62
CMS USING RFID                                                     SYSTEM TESTING


6.3.1. Maintenance of Testing

The system can be handling and maintained with few difficulties. This software can
adapt to any changes appear in the future. The system is ensuring problem free. If any
changes appear as time passes by, it can be cleared without many changes in the code.
Thus the problem of maintenance can be tackled.

Maintenance phase mainly focuses on the change that is associated with error
correction, adoptions required as the software’s environment evolves and changes due
to enhancements borough about by changing customer requirement. Software will
undoubtedly undergo change after it delivered to the customer.

Change will occur because error have been encounter because the software must be to
accommodate changes in its external environment because the customer requires
functional or performance enhancement. Software maintenance replies each of the
preceding phases to an existing program rather than new one.

                  Corrective Maintenance
                  Adaptive Maintenance
                  Perceptive Maintenance
                  Preventive Maintenance

 Corrective Maintenance

Even with the best quality assurance activities, it is likely that the customer will
uncover defects in the software. Corrective maintenance changes the software to
correct the defects.

After the customer uses the system, he can detect error in this system. These changes
can be easily accommodated in the system because it is well developed. Suppose after
user enters some invalid input or does not fill the required fields then he will get an
error message that the required fields are empty.

 Adaptive Maintenance

Overtime, the original environment for which the software was developed is likely to
change. Adaptive maintenance results in modification to the software was developed

Dept of IT/KEC, 2010-11                                                             63
CMS USING RFID                                                    SYSTEM TESTING


is likely to change. Adaptive maintenance results in modification to the software to
accommodate the changes to its external environment.

As the external changes are changed in the future, these changes also can
accommodate. This system can run under any platform. The changes in the rules in
the rules of the organization can also be easily accommodated.

 Perceptive Maintenance

As the software is used, the customer or the user will recognize additional functions
that will provide benefits. Perceptive maintenance extends the software beyond its
original functional requirements.   The required additional function can be easily
added to the system. These additional functions enhance system functionality and the
system becomes user friendly.

 Preventive Maintenance

Computer software deteriorates due to change and because of this preventive
maintenance, often called software re-engineering, must be conducted to enable the
software to serve the needs of its end users. In essence, preventive maintenance
makes changes to computer programs so that they can more easily corrected, adapted
and enhanced. As changes are made, it is likely that some new defects will be
introduced, causing the failure. Before the failure is corrected, another change is
requested, causing another failure. Slowly, the minimum failure are begins to rise and
the software is deteriorating due to change. Every software failure indicates that an
error in design or process, which the design was, translated into machine executable
code, software maintenance more complexity than hardware maintenance.

 Test Approach

Testing can be done in two ways:

              Bottom up approach

              Top down approach

 Bottom up Approach



Dept of IT/KEC, 2010-11                                                            64
CMS USING RFID                                                     SYSTEM TESTING


Testing can be performed starting from smallest and lowest level modules and
proceeding one at a time. For each module in bottom up testing a short program
executes the module and provides the needed data so that the module is asked to
perform the way it will when embedded within the larger system. When bottom level
modules are tested attention turns to those on the next level that use the lower level
ones they are tested individually and then linked with the previously examined lower
level modules.


 Top down approach


This type of testing starts from upper level modules. Since the detailed activities
usually performed in the lower level routines are not provided stubs are written. A
stub is a module shell called by upper level module and that when reached properly
will return a message to the calling module indicating that proper interaction
occurred. No attempt is made to verify the correctness of the lower level module.
 Validation
The system has been tested and implemented successfully and thus ensured that all
the requirements as listed in the software requirements specification are completely
fulfilled. In case of erroneous input corresponding error messages are displayed




Dept of IT/KEC, 2010-11                                                             65
CMS USING RFID                                                                 SYSTEM TESTING


6.4 Test Cases for Each Form

Modules:

S.No.            Requirement     Requirement Name               Source                         Stable(Y/N)
                 ID
                                                                (Admin/user)

01               CMS01           Admin Login                    Admin                          Y

02               CMS02           Create user                    Admin                          Y

03               CMS03           Update user                    Admin                          Y

04               CMS04           Delete user                    Admin                          Y

05               CMS05           Card Process                   User                           Y



FIGURES 6.4 (a) USECASE OF Modules




Requirement ID                 CMS01

Title                          Admin Login

Description                    Admin can login for create user , update user, delete user .

Actor                          Admin

Input                          user name and password

Behavior                                 Comparison of inputs with the login table of adminlogin.
                                         Check whether it is equal to adminlogin table.


Output                         Message “Valid user/ Invalid user” will be shown to the govt.

Pre condition                  Admin should have an account

Post condition                 Admin will be logged in



FIGURE 6.4 (b): Testing of Admin Modules


Dept of IT/KEC, 2010-11                                                                              66
CMS USING RFID                                                               SYSTEM TESTING




Requirement ID         CMS02

Title                  Create user

Description            The admin will be creating the user info.

Actor                  Admin.

Input                  Username, department, designation, Permissions to department.

Behavior                   Accept the information entered by the admin.
                           Create a new entry for the new user info
Output                 Message display “user info store in database”.

Pre condition          Admin should receive the details from user.

Post condition         The user information will be added and will be displayed.

Use case Diagram



                         Admin.                                    Enter user info




Figure 6.4 (c): Testing of Create Modules




Dept of IT/KEC, 2010-11                                                                  67
CMS USING RFID                                                                SYSTEM TESTING




Requirement ID         CMS03

Title                  Update user

Description            The admin will be Changing details in the particular user.

Actor                  Admin

Input                  Username, department, designation, Permissions to department.

Behavior                   Accept the information entered by the admin.
                           Update the details of the user.
Output                 Message “a User detail has been updated” will be shown.

Pre condition          Admin should receive the details from user.

Post condition         Details will be added.

Use case Diagram



                          Admin                                      Update user




Figure 6.4 (d): Testing of Update Modules




Dept of IT/KEC, 2010-11                                                                   68
CMS USING RFID                                                                 SYSTEM TESTING

Requirement ID           CMS04

Title                    Delete user

Description              The admin will be delete the particular details of the user

Actor                    Admin

Input                    user id, name.

Behavior                     Accept the information entered by the admin.
                             The particular user will be deleted.
Output                   Message “user details have been deleted” will be shown.

Pre condition            Admin should receive the details from user.

Post condition           Details will be deleted



Figure 6.4 (e) : Testing of Delete Modules




Dept of IT/KEC, 2010-11                                                                    69
CMS USING RFID                                                           SYSTEM TESTING




Requirement ID          CMS05

Title                   Card process

Description             Check valid user or invalid user

Actor                   User

Input                   Card, department

Behavior                     User allowed the department or not

Output                  Message “Welcome to CSE department” will be shown.

Pre condition           User have the card

Post condition          User allowed the CSE department

Use case Diagram



                            User                                   Enter card




Figure 6.4 (f) : Testing of Card process Modules




Dept of IT/KEC, 2010-11                                                              70

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:24
posted:4/27/2012
language:English
pages:13
Description: Campus Management System Document