Software Engineering Studio
Software Engineering Studio CSE 784
Popular in Course
Popular in Computer Engineering
This 36 page Class Notes was uploaded by Amelie Murphy on Wednesday October 21, 2015. The Class Notes belongs to CSE 784 at Syracuse University taught by Staff in Fall. Since its upload, it has received 53 views. For similar materials see /class/225563/cse-784-syracuse-university in Computer Engineering at Syracuse University.
Reviews for Software Engineering Studio
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/21/15
NetTestUnitv B Level Specificatiens CSE 784 Fail 2003 NetTestUnitv An automated testinci framework B Level Specifications BY Mithun Shanbhag 09152003 For CSE 784 Fall 2003 NetTestUnity B Level Speci catiuns CSE 784 Fall 2003 Table of Contents 1 INTRODUCTION 3 2 REFERENCE DOCUMENTS 4 21 Customer ASpecification 4 3 ARCHITECTURE 5 4 REQUIREMENTS 7 41 Functional Requirements 8 411 Harnessing 8 4111 Inputs 8 4112 Processing 8 4113 Output 8 412 TestExecut39 9 4121 Inputs 9 4122 Processing 9 4123 Output 10 413 Resource Allocation Tracking 11 4131 Inputs 11 4132 Processing 11 4133 Output 12 414 Result Logging 13 4141 Inputs 13 4142 Processing 13 4143 Output 14 42 Process Requirements 15 421 Physical Structure 15 422 Development Environment 15 43 External Interface Requirements 16 431 Hardware Interfaces 16 432 Software Interfaces API 16 5 DATA DICTIONARY 17 6 REQUIREMENTS TRACEABILITY MATRIX 18 7 NOTES 19 NetTestUnity B Level Speci catiuns CSE 784 Fall 2003 1 Introduction Automated testing Frameworks provide the software developer with a facility to construct multiple test cases aggregate them and monitor their automated execution Thus this saves the developer considerable time during code development and provides him with an indispensable tool If the automated testing framework also provides facilities for result logging and checks for memory leaks it is an added bonus Such a tool can be termed as a Test Harness Several test harnesses are commercially available for different platforms The most famous is JUnit a testing framework for java For the Net platform several programs like CSUnit DotUnit HarnessIt NUnit etc are available today Such tools are indispensable during construction based tests and also for unit tests to some extent In this document we are providing the Software Requirements Specifications for our Test Harness NetTestUnity This tool will operate under the Net platform only c specific The tool provides a facility to construct aggregate execute and monitor test objects It is also possible to log all the execution results and track all resource IO and memory allocations NetTestUnity B Level Specifications CSE 784 Fall 2003 2 REFERENCE DOCUMENTS JUnit Links 0 htt www39unitor indexhtm o htt 39unitsourcefor enet o htt 39unitsourcefor enet doc cookstour cookstourhtm Kent Beck39s paper on Testing Frameworks o httpwwwxproqramminqcomtestframhtm More links on Testing Frameworks o htt c2com c iwikiTestin Framework o httpwwwxoroqramminqcomsoftwarehtm NET testing frameworks CSUnit o htt wwwcsunitor index h Dot Net Unit 0 htt sourcefor enet ro39ects dotnetunit Dot Unit 0 httpdotunitsourceforgenet HarnessIt o htt wwwunittestin com NUnit o htt sourcefor enet ro39ects nunit XUnity o htt xunit miikcomua 21 Customer ASpecification Project 1 Test Harness 08252003 NetTestUnity Level Specifications CSE 784 FEB 2003 3 ARCHITECTURE Our goal is to create an Automated Testing Framework for the Net platform NetTestUnity will provide various facilities like construction aggregation and execution of test cases A Test driver must be able to interact with our NetTestUnity tool through interfaces NetTestUnity must also provide facilities for logging test results either to a file or to the console Also there must be a facility to monitor resource allocation to the test code NetTestUnity is called from a defined entry point which supplies it with suite of aggregated tests NetTestUnity then executes each of those tests and if required performs resource allocation tracking and logs the test result by binding it to a console stream a memory stream or a file stream NetTestUnity makes calls into the Test Driver to call the registered tests It also utilizes the File Services to access the test definition file Test Log lTrack Command Command LineGUI Suite of aggregated tests Test ommand Test Log File Stream Console Stream Memory Stream Request for Test De nition File File Services Handle to Test De nition Test Log Test Log Test result Resource Tracking M59 Resource Tracking Result Code being tested Function call to test code Context Diagram Test Harness NetTestUnity H Now referring to the Module diagram for out NetTestUnity program we see that all processing is split amongst the following modules NetTestUnity B Level Speci catiuns CSE 784 Fall 2003 Aggregator Executive Harness Test Driver Module Diagram Test Harness NetTestUnity o Aggregator This module is actually a top level executive Its responsibility includes aggregating test objects and executing them by use of the Harness module It sends the reference of the test objects to the Harness The program entry point is defined inside this executive o Harness This module is simply consists of interfaces through which test drivers can form test objects and execute them Its responsibilities include storing of test objects their execution logging their results and tracking allocations made to them It does this by interacting with the Test Driver module 0 Test Driver This module is responsible for constructing test objects Also it is responsible for overriding and implementing virtual functions provided by the Harness s tracking and logging interfaces This is a required activity for monitoring resource allocation and for logging test results NetTestUnity Level Speci catiuns CSE 784 Fall 2003 4 REQUIREMENTS Here we identify all of the processes that are collectively responsible for satisfying all of the software s requirements The processes are Harnessing TestExecution Result Logging and Resource Allocation Tracking Each of these processes is responsible for a set of requirements that we will describe in detail below TestExecuti on 2 Tu cunsuie memury hie stream Data Flow Diagram Test Harness NetTestUniy H NetTestUnity Level Specifications 41 CSE 7841 Fal 2003 Functional Requirements The following sections describe in some detail the activities performed by the NetTestUnity program 411 Harnessing The Harnessing Process is responsible for collecting references to individual tests or a suite of tests The Harness is simply composed of interfaces for facilitating test aggregation logging test results and FGSOU rce allocation tracking It is also responsible for calling each of the registered tests in the order specified 411 411 411 1 inputs The Harness is called from a defined entry point usually in the Test Driver module and supplied with references of either individual tests or aggregated test suites The Test Log Track command notifies the harness to start executing logging the tests the reference of which was given in the previous message 2 processing The Harness shall provide interfaces for aggregating and executing tests constructing The Harness shall store all of these test references in a container store and execute these test in the same order in which they were stored The Harness shall provide interfaces for tracking resource allocation deallocation and for logging test results 3 outputs The Test Reference is passed on by the Harness to the Test Execution process The Test Reference message is actually the reference of the individual tests registered with the harness The Test command sent to the TestExecution process contains a request for individual test execution or execution of an aggregated test suite Of course this request will probably be encapsulated in a function call NetTestUnit y Level Specifications CSE 784 Fat 2003 412 TestExecution The TestExecution process collects references to aggregated tests and executes each of them by making calls into the testing code The outputs to the testing code will be requests to execute the aggregated individual tests in the same order in which they were registered This will probably in the form of function calls and not explicit messages 4121 Inputs The Test Reference is passed by the Harness The Test command which contains a request for individual test execution or execution of an aggregated test suite The Handle to the Test De nition le is given to TestExecution file upon request by the File Services The Code under test returns the Test Result ie the function call when test execution has completed 4122 Processing All test drivers communicating with the test harness for test aggregation execution logging and allocation tracking shall interact through these interfaces only The process shall provide at least one class derived from the test interface for each module under test The process shall make use of a test definition files to supply test values to the source under test The test definition file can be a simple text file or it can be an XML file The process will interact with the Logging process The TestExecution process shall send a reference of a stream console memory or file to the Result Logging process Then it shall send a Test Result summary for each test executed passed and failed to the Logging process 0 All test results shall be classified as passed failed or error in execution o For test logging purposes the process shall also provide a class derived from the tracking interface NetTestUnity B Level Speci catiuns 3 CSE 784 Fall 2003 The process shall notify the Logging process of any errors Errors will likely be of the following nature exception during test execution or missing test definition file Outputs The TestExecution process sends the Test Reference message ie reference of the test executed to the Result Logging process and the Allocation Tracking process This reference enables these processes to extract type details through Reflections The TestExecution process sends the reference of the userspeci ed stream console memory or file stream to the Logging process This enables the Logging process to bind the test log to the stream After each test execution the TestExecution process sends the Result summary to the Logging process The TestExecution process also initiates the tracking process by sending an Allocation tracking command to the Tracking process The TestExecution process also sends an error message to the Logging process to notify it of any errors Eg An untrapped exception or missing test definition file NetTestUnit y Level Specifications CSE 784 FEB 2003 413 Resource Allocation Tracking This process is responsible for tracking all allocation and deallocation of resources for the source code under test Every time any source code under test dynamically allocates memory the allocation is tracked and recorded Similarly tracking is done while garbage collection or destruction of the dynamically memoryallocated objects This Allocation tracking feature helps us to detect memory leaks if any in the source All disk file and IO access are also tracked 4131 inputs 0 The Test Reference message which is actually the reference of the registered testing function 0 The Allocation Tracking Command which indicates to the tracking process to start tracking all resource 0 The Resource Tracking Result message is a log of the allocation summary made to the source code under test 4132 processing 0 The Tracker shall include classes derived from the tracking interface provided by the Harness for the purpose of tracking resource allocation to the source under test 0 The Tracker should list out in detail in its Tracking Summary message all the IO and Memory accesses preformed by the source code under test The tracker shall classify all allocation and accesses made by the source into the following categories File IO device and Memory 0 The process must test for memory leaks The process shall log the total number of bytes allocated and the total number of bytes remaining on program termination This information must be included with the Tracking Summary message 0 After each test is tracked the Tracker shall send a Tracking Summary message to the Result Logging Process 4133 outputs o The Resource Tracking Message is sent out by the tracking process to monitor the source code under test for disk file IO and memory allocations and deallocations NetTestUnity B Level Specifications CSE 784 Fail 2003 o The Tracking Summary message sent to the Result Logging Process indicates the net summary of all the Disk File IO and Memory allocation made to the executed test NetTestUnit y Level Specifications 414 The Result Logging process CSE 7841 Fal 2003 Result Logging is primarily responsible for receiving the summary of all test results from the TestExecution process and logging these results by binding them to a console memory or a file stream Thus the user can direct the summary of all tests performed either to the console or to a text file 4 142 141 inputs The Stream Reference message gives the reference of a user specified stream to the Result Logging process This stream can be a console memory or a file stream The Test Result Summary message indicates the execution details for each of the test passed or failed The Tracking Summary message indicates the resource allocation details for each test executed The Reference to the executed test is also handed to the Result Logger processing The Result Logger shall include classes derived from the logging interface provided by the Harness for each of the userspecified stream console memory or file stream The Result Logger can use the Reflection API to extract certain details from the test since it has a reference to it The Result Logger shall list out the referenced test s type as header for the Test Log output The Result Logging process shall combine all the Test Result and Tracking Summaries for individual tests and generate a Test Log for the entire test suite The program shall in this manner demonstrate all the test constructing executing logging and allocation tracking features The Result Logging process shall bind the generated Test Log to the userspecified console memory or file stream NetTestUnity B Level Specifications CSE 7841 Fail 2003 4141 outputs The Result Logging process outputs a Test Log message which is actually the test execution details for the entire suite of aggregated tests This log is bound to the referenced stream NetTestUnity Level Specifications CSE 784 FEB 2003 42 Process Requirements The process requirements specify the physical structure of the code developed and the environment where it must operate 421 Physical Structure The NetTestUnity program shall consist of more than one module A module is either an executive there is only one per program or a server There may be as many server modules as deemed appropriate by the development team Since all implementation will be done entirely in C all modules shall consist of a single file cs that contains the implementation The module shall contain the following elements 1 a manual page containing a prologue a paragraph describing module operations and a list of the public interface with interpretations to help a designer to use the module 2 a maintenance page describing the build process specifically naming the required files and compilation commands o The main function in each server module shall be enclosed by preprocessor statements preventing compilation unless the preprocessor detects a directive of the form TESTMODULENAME where MODULENAME is the name of the module with no extension 0 All modules shall begin with a prologue that contains descriptions of the following elements 1 file name with a few word summary version number language of implementation platform eg computer and operating system application author with address and email id OIU39IkWN 422 Development Environment The Test Harness program shall compile and link from the command line using Visual Studio NET version 7 and shall operate under the Windows NT operating system version 40 service pack 3 NetTestUnity Level Speci catiuns CSE 784 Fall 2003 43 External Interface Requirements This section of the specification will document all of the software and hardware interface requirements at a level of detail sufficient to allow the design of a system that will satisfy these requirements 431 Hardware Interfaces 0 No external hardware interface requirements 432 Software Interfaces API The program makes use of the Net Framework SDK 10 In particular the Test Harness uses the SystemCoIection library to utilize containers for aggregating test results Also for File and other IO accesses the program will make use of the SystemIO library And finally for dynamically loading type information during the logging and tracking processes the program will use the SystemType and SystemRefection namespaces NetTestUnity Level Specifications CSE 7841 FEB 2003 5 DATA DICTIONARY a Name Interpretation DFD Test Log Track Notifies NetTestUnity to start DFD1 command executing the tests with allocation tracking and logg g Test Reference The reference of the individual tests DFD 1 registered with NetTestUnity Test Command Informs the TestExecution unit to DFD1 execute the test ResourceTracking Message Function call to test source code DFD1 under test for resource allocation deallocation ResourceTracking Result Resource allocation deallocation DFD1 done for the source code under current test Function call to test code The TestExecution unit invokes a test DFD 1 function Test Result Result of test execution DFD 1 Test Result Summary The execution details for each of the DFD 1 test gassed or failed Tracking Summary The resource allocation details for DFD1 each test layeruteri Test Log The test execution details for the DFD1 entire suite of aggregated tests Ne iTestUnity Level Specifications CSE 7841 FEB 2003 6 REQUIREMENTS TRACEABILITY MATRIX NetTestUnity B Level Specifications CSE 784 Fall 2003 7 NOTES BSpecifications for NetTestUnity released on 09152003 CSE784 Software Studio Fall 2001 Duplicates Program B Level Specification for Software Developm ent version 12 09 September 2001 CSE 784 Software Studio james Fawcett PhD Duplicates Program B Specification 1 Table of Contents 1 ARCHITEC TURF 2 REFERENCE DOCUNIEN T 21 CUSTOMER ASPECIFICATION 22 REUSABLE SOFTWARE 3 REQUIREMENT 31 FUNCTIONAL REQUIREMENT 311 COMJVIAND LINE PROCE INC 3111 INPUT 3112 PROCF IN 3113 OUTPUT 312 DIRECTORY SEARCHING 3121 INPUT 3122 PROCF IN 3123 OUTPUT 313 DATA COLLECTION 3131 INPUT 3132 PROCF IN 3133 OUTPUT 314 DISPLAY 3141 SEARCHING DISPLAY 31411 INPUT 31412 PROCF INC 31413 OUTPUT 3142 DUPLICATES DISPLAY 31421 INPUT 31422 PROCF INC 31423 OUTPUT CSE784 Software Studio Fall 2001 3143 LOGGING FII E 13 31431 INPUT 13 31432 PROCE INC 13 31433 OUTPUT 13 32 PROCESS REQUIREMENT 14 321 PHYSICAL STRUCTURE 14 322 DEVELOPMENT ENVIRONMENT 14 4 DATA DICTIONARY 15 5 REQUIREMENTS TRACEABILITY MATRIX 16 6 NOTE 17 Duplicates Program B Specification 3 CSE784 Software Studio Fall 2001 1 Architecture The Duplicates program accepts a path specification on the command line which is used to start a search over the directory subtree rooted at that path Each duplicate file name found during that search is sent to standard output before the program s execution terminates Two file names are considered to be duplicates if they contain the same sequence of characters for both the primary name and extension The comparisons are to be made in a case insensitive manner Directory Services path lename paths path spec Duplicates duplicates Standard Output errors Figure 1 Duplicates Context Diagram path duplicates log If the path specification is not valid or no path specification is provided the Duplicates program will send an error message to standard output Processing is divided into the three major components shown in Figure 2 eg command line processing in DupsExec directory navigation in Nav and file and path storage in FileStore Command line processing accepts a path specification from the command line saves the current working directory name and sets the current working directory to match the input path specification If this fails an error message is sent to standard output Directory navigation examines all the file names in each directory found in the directory tree rooted at the specified path It sends each name and corresponding path to FileStore FileStore saves each encountered file name only once in its storage mechanism It associates with that name each path in which the name is found Each path is only stored once Duplicates Program B Specification 4 CSE784 Software Studio Fall 2001 Du psExec Nav FileStore Figure 2 Duplicates Module Diagram The Nav module is existing software and is to be reused Without modification Note that Nav contains a navig class that owns a dProc base class The dProc class contains virtual functions dirsProc and fileProc which may be over ridden by a derived class in the DupsExec module The overridden virtual functions provide the facilities to save file names and path names by accepting them from Nav and passing them on to the FileStore module Duplicates Program B Specification 5 CSE784 Software Studio Fall 2001 2 Reference Documents 2 l Customer A Specification Project 2 Duplicates Tuesday 27 July 1999 2 2 Reusable Software navh ver 12 62099 navcpp ver 12 42799 Duplicates Program B Specification 6 CSE784 Software Studio Fall 2001 3 Requirements Processing for the DUPLICATES program is divided here into four major processes command line processing directory searching data collection and display Each of these processes is responsible for a set of requirements described in this section currPamName 9 o 9amp5 299 t Display 4 Figure 3 Data Flow Diagram 1 Duplicates Program B Specification CSE784 Software Studio Fall 2001 3 l Functional Requirements These sections describe the activities required of the DUPLICATES program 311 Command Line Processing The Command Line process is responsible for initiating execution saving the path to the original current working directory reading the command line and sending the result to Directory Searching process 3lll inputs The path spec message contains a user supplied speci cation of the desired starting path 3112 processing The command line process shall accept from the command line a Win32 path descriptor and extract and save the current working directory name defined by the descriptor If no Win32 descriptor exists on the command line it shall send an error message to standard output When the Directory Searching process has concluded its activities and before the program terminates this process shall restore the current working directory to its value at the start ofthe program 3113 outputs The start path message contains the name of the root of the directory search The errors message indicates the nature of the error eg missing path descriptor Duplicates Program B Specification 8 CSE784 Software Studio Fall 2001 312 Directory Searching The Directory Searching process starts at the path specified by the starting path message and visits each subdirectory in the tree rooted at that path Order oftraversal is not significant 312 1 inputs The start path message Path is the name of a subdirectory returned by the Win32 API Filename is the name of a file returned by the Win32 API 3122 processing The Directory Searching process shall attempt to set the current working directory to match that path described by the starting path message If the attempt fails it shall send an error message to standard output and terminate If path setting is successful the process shall visit each sub directory rooted at the starting path For each subdirectory it shall send the name of each file in the directory along with its path out in the lename and pathname messages 3123 outputs Filename and pathname messages hold name and path of each file encountered in every subdirectory visited by the process The errors message contains a description of the nature of the error eg invalid start path The path message contains the name of a subdirectory used to change the current working directory The currPathName is sent each time a new directory is entered Duplicates Program B Specification 9 CSE784 Software Studio Fall 2001 3 13 Data Collection The Data Collection process is responsible for storing each lename and path sent in filename and path messages once and only once Each file is associated with a sequence of path names one for each path containing the file 3131 inputs The filename and pathname messages sent at the same time describe the name of each file name encountered and the path were it was found 3132 processing The Data Collection process shall save the name of each file encountered only once It shall associate with that file name the name of every path on which it is found The process shall save each path name once and only once 3133 outputs The FileStore Data Structure message contains a reference to the containers used by the Data Collection process to save files and their associated paths This makes the container contents available to processes receiving the message Duplicates Program B Specification 10 CSE784 Software Studio Fall 2001 314 Display The Display process is responsible for presenting to the user all of the duplicated file names found in the FileStore Data Structure message It does this by sending the duplicate information to the user s console Searching currpathname 41 FiIeStore Dup39mtes Data Structure Figure 4 Data Flow Diagram 14 screen and by building a logging file with the same information The display process also sends a sequence of path names to the user s console during the search process to occupy the user s attention during this rather lengthy process These activities are carried out in the three subprocesses shown in DFD 14 Duplicates Program B Specification 1 1 CSE784 Software Studio Fall 2001 3141 Searching Display This process writes to the standard output names of each directory visited during the searching process We do this to show the user that lengthy processing entailed by DUPLICATES program is indeed continuing and the program remains in a functional state 31411 inputs The currpathname message contains the name of the directory currently being searched 31412 processing The Searching Display process shall send each directory name encountered to standard output Each path name shall over write its predecessor eg this display will not scroll 31413 outputs This process sends all its outputs to the standard output in the paths message 3142 Duplicates Display 31421 inputs The FileStore Data Structure message contains a reference to the containers holding all file names and path names encountered during the directory searching process 31422 processing The Display process shall extract all of the duplicate filenames and their associated paths from the file and path storage and present them to the user via standard output The format used shall list each duplicated file name followed by a list of all the paths where it is found Each path name shall be preceded by the size and time and date of last modification for the file on that path 31423 outputs The duplicates and duplicates log messages contain the information specified in the processing section above They do not have the same formats so are given different message names Duplicates Program B Specification 12 CSE784 Software Studio Fall 2001 3143 Logging Display 31431 inputs The duplicates message contains a list of all the duplicated filenames each with a list of the paths on which they are found 31432 processing The Logging process shall write the contents of the duplicates message to a logging file The logging formats are not specified but should be in a form useful for users of the program eg readable and neat 31433 outputs The logging process creates a file called duplicatesdat If the file already exists in the current working directory it will be overwritten This file contains the contents of the duplicates log message Duplicates Program B Specification 13 CSE784 Software Studio Fall 2001 32 Process Requirements These requirements specify physical structure of the code developed and the environment where it must operate 321 Physical Structure The DUPLICATES program shall consist of more than one module A module is either an executive of which there is only one per program or a server There may be as many server modules as deemed appropriate by the development team An executive module shall consist on either a single implementation le c or cpp or both a header le h and corresponding implementation file A server module shall consist of both a header file and implementation le When both header and implementation file are present they shall have the same identifier differing only in extension The module shall contain the following elements preprocessor statements preventing multiple compilations embed ded around each header file a manual page containing a prologue a paragraph describing module operations and a list of the public interface with inter pretations to help a designer to use the module a maintenance page describing the build process specifically naming the required les and compilation commands a main function The main function in each server module shall be enclosed by preprocessor statements preventing compilation unless the preprocessor detects a directive of the form TESTMODULENAME where MODULENAME is the name ofthe module with no extension Both the header file and implementation le shall begin with a pro logue that contains descriptions ofthe following elements file name with a few word summary version number language of implementation platform eg computer and operating system application author with address telephone number and email account 322 Development Environment The DUPLICATES program shall compile and link from the command line using Visual C version 60 and shall operate under the Windows NT operating system version 40 service pack 3 Duplicates Program B Specification l4 CSE784 Software Studio Fall 2001 4 Data Dictionary Figure 5 Data Dictionary Duplicates Program B Specification 15 CSE784 Software Studio Fall 2001 5 Requirements Traceability Matrix Figure 6 Requirements Traceability Matrix Duplicates Program B Specification 16 CSE784 Software Studio Fall 2001 6 Notes Revisions 31422 original The Display process shall extract all of the duplicate filenames and their associated paths from the FileStore Data Structure and present them to the user via standard output 31422 revised The Display process shall extract all of the duplicate filenames and their associated paths from the file and path storage and present them to the user via standard output Duplicates Program B Specification 17