File Assay (A Program which predict and search the files from system)

(i)
A
MINOR PROJECT REPORT
ON
“FILE ASSAY”
Submitted to
JABALPUR ENGINEERING COLLEGE, JABALPUR (M.P.)
In partial fulfillment of the requirement for award of the degree of
(BACHELOR OF ENGINEERING)
INFORMATION TECHNOLOGY ENGINEERING
Under the Guidance Of
ASST. PROF AVITA FUSKELE
Submitted by-
Aditi Jha (0201IT121001)
Aditya Nair (0201IT121002)
Ajay Parmar (0201IT121004)
Akshat Sinha (0201IT121007)
SIXTH SEMESTER
DEPARTMENT OF INFORMATION TECHNOLOGY
JABALPUR ENGINEERING COLLEGE, JABALPUR
SESSION 2014-2015

(ii)
JABALPUR ENGINEERING COLLEGE,
JABALPUR
DECLARATION
We hereby declare that the project entitled –“File Assay” which is being submitted as
Minor Project of 6th semester in Information Technology Engineering Department to
JABALPUR ENGINEERING COLLEGE, JABALPUR (M.P) is an authentic record of our
genuine work done under the guidance of, Prof. Prashant Jain, Head of Department,
Information Technology Engineering, Jabalpur Engineering College, Jabalpur.
Date:
Place: Jabalpur Aditi Jha (0201IT121001)
Ajay Singh Parmar (0201IT121004)

(iii)
JABALPUR
CERTIFICATE
ACADEMIC YEAR: 2014-2015
This is to certify that the minor project report entitled “File Assay” submitted by Aditi Jha,
Aditya Nair, Ajay Parmar and Akshat Sinha has been carried out under my Guidance and
Supervision. The Minor project report is approved for submission requirement for minor project
in 6th semester in Information Technology Engineering from Jabalpur Engineering College,
Jabalpur (M.P).
Prof. Prashant Jain Prof Avita Fuskele
Head of Department, Supervision and Guide,
Information Technology, Information Technology,
Jabalpur Engineering Jabalpur Engineering
College College
Date: Date:

(iv)
JABALPUR
CERTIFICATE
ACADEMIC YEAR: 2014-2015
This Preliminary Dissertation Report entitled “File Assay” submitted by Aditi
Jha(0201IT121001), Aditya Nair(0201ITI121002), Ajay Singh Parmar(0201ITI121004) and
Akshat Sinha(0201ITI121007) is approved for the award of degree of Bachelor of
Engineering in Information Technology Engineering.
Internal Examiner External Examiner
Date: Date:

(v)
JABALPUR ENGINEERING COLLEGE, JABALPUR (M.P.)
ACKNOWLEDGEMENT
We express our sincere indebtedness towards our guide Prof. Avita Fuskele, Assistant
Professor, Information Technology Engineering, Jabalpur Engineering College, Jabalpur (M.P)
for her invaluable guidance, suggestions and supervision throughout the work. Without her kind
patronage and guidance the project would not have taken shape. We would also like to express our
gratitude and sincere regards to her for her kind approval of the project, time to time counselling
and advices.
We owe sincere thanks to all the faculty members in the department of information
technology for their kind guidance and encouragement from time to time.
Lastly, we would like to thank our parents who have supported us throughout this work.
Date: Aditi Jha (0201IT121001)
Ajay Singh Parmar (0201IT121004)

(vi)
Table of Contents
Chapter 1 BACKGROUND
1.1 Abstract ................................................................................................................................. 1
1.2 Problem Statement ............................................................................................................... 1
1.3 Algorithm And Ideas.............................................................................................................. 2
1.4 Scope Of The Project............................................................................................................. 2
1.5 Definition And Abbreviation.................................................................................................. 3
1.6 Team Architecture and Overview ......................................................................................... 5
1.7 Objective................................................................................................................................ 6
Chapter 2 General Description
2.1 Functionality Of Project ........................................................................................................ 7
2.1.1 Functional Requirement................................................................................................. 7
2.1.2.Modules Description ...................................................................................................... 7
2.1.3 Non Functional Requirement......................................................................................... 8
2.2 Modules................................................................................................................................. 9
2.3 Requirement Specification.................................................................................................. 10
Chapter 3 Design
3.1 High Level Design ................................................................................................................ 11
3.1.1 System Analysis ............................................................................................................ 11
3.1.2.Requirement Collection................................................................................................ 11
3.1.3 DFD`s............................................................................................................................. 11
1.4 Block Diagram.................................................................................................................. 14
3.1.3 Architectural Model...................................................................................................... 14
3.2 Low Level Design ................................................................................................................. 17
Chapter 4 Testing
4.1 Testing Overview................................................................................................................. 18
4.2 Testing Approach................................................................................................................. 20
4.3 Test cases ............................................................................................................................ 23
Chapter 5 Limitations .......................................................................................................... 24
Chapter 6 References .......................................................................................................... 25

1
CHAPTER 1
BACKGROUND
1.1 Abstract
File Assay is an Operating System based and independent program that is used to search a file on a
hard drive. The file could be anything from text based document to multimedia file, the size of the
file could be variable. File Assay provide the time efficient and extension based output with help of
proper indexing and popular data structure algorithms.
Our project deals with the creation of an interactive file indexing software that has access to all the
parts of the hard drive and make use of command prompt to perform following tasks-
1. The program starts searching for the file the moment the user enters the very first letter of the
filename.
2. The search won’t be shown to the user explicitly.
3. The program creates a database that stores the recent searches of any file by the user.
1.1.1 Programming Language Used:-
C programming language with the help of File Handling and Data Structure. Even though various
developers have included internet search for the file along with hard drive search, our program will
only be searching local hard drive for the file.
1.2 Problem Statement
Designing Desktop Search engine. Desktop search engine will searches for the given string in the
text files and pdf files of the desktop. Input given to search engine was search string and the output
will the list of files containing the text and their path. The ordering of the files done by the ranking
and the ranking has been retrieved by giving the priority in extension of each files which has been
derived after search.
Input: Search string
Output: List of files containing search string
Goals: Completion of search engine flow for searching text in the text and pdf files i.e. extension
based output.

2
1.2.1 Future Enhancement
Extending the search to other type format files and adding advanced search options.
Searching based on indexing is faster compared to non-index based search. So we want to design a
desktop application which will search file content based on indexing.
Providing different search criteria’s will give flexibility for users. In the current application scenario
we can index a particular folder and its subfolder which will make indexing time shorter. (Avoids
unnecessary indexing of all files when you want to search in particular folder and its subfolders).
1.3 ALGORITHMS AND IDEAS
Various algorithms such as Moore’s algorithm, sorting etc. will be used for the creation of desired
software. These algorithms will make easy for the user to search a particular file from the group of
files having same names.
When a user searches for a file, the program will search the hard drive for every file of that name
and the search list will first be saved to a temporary text file. After that sorting will be done on that
list based on the priority. For example .exe files will be shown at the top (depend upon the priority
table) and according to this priority based techniques, and the use of proper Indexing and data
structure,
The output which has been derived from the file assay after searching has been prioritize by their
file extension and this is the main keyword of the sorting method of our program. We will try to
build a program which work efficiently.
1.4 SCOPE OF THE PROJECT
The project, more precisely the program, can be used as an alternative over any other conventional
file searching programs when efficiency in terms of time is required.
The use of popular algorithm and technique make this program as a better approach to search any
file of the particular system in an optimum way and in a required time.
1.4.1 Future Scope:
There is lots of windows based file searcher which are good alternative of File Assay. But the main
thing which differentiate the File Assay from them is the time limit while searching any item that is
the motive of this program is to generate output within a time extend and the next thing is the
searching was so fast for the item which has been recently searched by the user. The second motive
is the key point of this program as the other alternative are not feasible to do so.

3
1.5 DEFINITIONS AND ABBREVIATIONS
1.5.1 FILE HANDLING:
File handling is the process of adding, removing and manipulating the files of all or any kinds of
extensions or size via executing some predefined commands.A file represents a sequence of bytes,
does not matter if it is a text file or binary file. C programming language provides access on high
level functions as well as low level (OS level) calls to handle file on your storage devices.
Here is the some points on file handling:-
1. New way of dealing with data is file handling.
2. Data is stored onto the disk and can be retrieve whenever require.
3. Output of the program may be stored onto the disk
4. In C we have many functions that deals with file handling
5. A file is a collection of bytes stored on a secondary storage device (generally a disk)
6. Collection of byte may be interpreted as –
1) Single character
2) Single Word
3) Single Line
4) Complete Structure.
1.5.2 MOORE’S ALGORITHM:
In computer science, the Boyer–Moore string search algorithm is an efficient string searching
algorithm that is the standard benchmark for practical string search literature. It was developed by
Robert S. Boyer and J Strother Moore in 1977. The algorithm pre-processes the string being searched
for (the pattern), but not the string being searched in (the text). It is thus well-suited for applications
in which the pattern is much shorter than the text or where it persists across multiple searches. The
Boyer-Moore algorithm uses information gathered during the pre-process step to skip sections of the
text, resulting in a lower constant factor than many other string algorithms. In general, the algorithm
runs faster as the pattern length increases. The key features of the algorithm are to match on the tail
of the pattern rather than the head, and to skip along the text in jumps of multiple characters rather
than searching every single character in the text. This algorithm is used to predict the full word when
a part of that word is written. The prediction can be done on referring to a file based on recent
searches. The Boyer-Moore algorithm searches for occurrences of P in T by performing explicit
character comparisons at different alignments. Instead of a brute-force search of all alignments (of
which there are m - n + 1), Boyer-Moore uses information gained by pre-processing P to skip as
many alignments as possible.

4
1.5.3 SORTING
The SORTING has 3 senses:
1. An operation that segregates items into groups according to a specified criterion.
2. The basic cognitive process of arranging into classes or categories.
3. Grouping by class or kind or size.
Sorting is any process of arranging items according to a certain sequence or in different sets, and
therefore, it has two common, yet distinct meanings:
Ordering: Arranging items of the same kind, class or nature, in some ordered sequence,
Categorizing: Grouping and labelling items with similar properties together (by sorts).
The main purpose of sorting information is to optimise its usefulness for specific tasks. In general,
there are two ways of grouping information: by category e.g. a shopping catalogue where items are
compiled together under headings such as 'home', 'sport & leisure', 'women's clothes' etc. (nominal
scale) and by the intensity of some property, such as price, e.g. from the cheapest to most expensive
(ordinal scale).
1.5.4 DATA STRUCTURE
In computer science, a data structure is a particular way of organizing data in a computer so that it
can be used efficiently. Data structures can implement one or more particular abstract data types.
Which are the means of specifying the contract of operations and their complexity. In comparison, a
data structure is a concrete implementation of the contract provided by an ADT.
Different kinds of data structures are suited to different kinds of applications, and some are highly
specialized to specific tasks. Data structures are generally based on the ability of a computer to fetch
and store data at any place in its memory, specified by a pointer – a bit string, representing a memory
address that can be itself stored in memory and manipulated by the program.
Types of Data Structures are:-
1.) Primitive types
E.g. Boolean, true or false, Character Floating-point, Double,
2.) Enumerated type, a small set of uniquely named values
3.) Composite types
(Sometimes also referred to as Plain old data structures.)
E.g. Array, Container, ListSet, Priority queue, Queue, Double-ended queue, Stack, Tree, Graph.
The implementation of a data structure usually requires writing a set of procedures that create and
manipulate instances of that structure. The efficiency of a data structure cannot be analysed
separately from those operations. This observation motivates the theoretical concept of an abstract
data type, a data structure that is defined indirectly by the operations that may be performed on it,
and the mathematical properties of those operations (including their space and time cost).

5
1.6 TEAM ARCHITECTURE
1.6.1 Aditi Jha (Group leader):
The member participate in the Documentation and testing part of the project. Member perform
different test strategies to identify bugs and error in the program. The member perform different level
testing to make program appropriately robust.
1.6.2 Akshat Sinha:
The member participate in the design part so that other one get prototype for their work. The main
role of member is the Designing of abstract model and gave a proper judgement on how to implement
the model suggesting different algorithms and implementation strategies.
1.6.3 Aditya Nair:
The team member is responsible for implementing different algorithm in the program and the use of
proper indexing tool to make program optimum and time efficient. The team member is also
responsible for implementation of modular level codes.
1.6.4 Ajay Singh Parmar:
The team member is responsible for implementation of code to integrate different modules and make
them feasible by implementing different algorithm`s like Moore`s algorithm, Tree traversing
algorithm etc.
1.7 OVERVIEW
Following points are the general Overview of the project.
1) The program starts searching for the file the moment the user enters the very first letter of
the filename.
2) The program creates a database that stores the recent Searches of any file by the user.
3) Indexing provide easy and time efficient level of search.
4) This database help system to research the same file in a less time.
5) Time limit prevent the system from moving towards deadlock condition.

6
1.8 OBJECTIVE
File Assay is a Operating System based program that is used to search a file on a hard drive. The file
could be anything from text based document to multimedia based file, the size of the file could be
variable.
Our project deals with the creation of an interactive file indexing program that has access to all the
parts of the hard drive and make use of command prompt to perform his defined tasks.
The main Objective of the File Assay is the followings:-
1) Lightning Fast Searching
2) Advanced Querying
3) Search Result Actions
1.9 FUTURE GOALS
As file Assay is the File searcher there is many program which compete with it. The key thing is that
the Moore’s algorithm is never used in any kind of file searching programs. We can expect that this
algorithm will be used to achieve higher efficiency in less time input. The efficiency may increase
by using indexing in a very good level and therefore the next some version of the program was based
on this goal i.e. use of proper level of indexing. And then after successful achievement of this goal
the next hopeful task is to prioritize the file according to extension as well as their use.

7
CHAPTER 2
GENERAL DESCRIPTION
2.1 FUNCTIONALITY OF THE PROJECT
2.1.1 Functional Requirement
1) Searching of the File from the system database.
2) Extended Searching by using Indexing and Moore`s Algorithm
3) Extension Wise Sorting by generalizing the priority using extension of the file.
4) Recent Search Log to research or view the last search data in a feasible manner.
2.1.2 Modules Description
2.1.2.1 SEARCHING
This module will provide searching of the file in whole hard drive.
INPUT: File name with extension. .
PROCESSING: Searching.
OUTPUT: Location of file.
2.1.2.2 EXTENDED SEARCHING
In this module user just have to type very few letters of file.
INPUT: Few letters of file name with extension.
PROCESS: Searching.
OUTPUT: All the matched files.

8
2.1.2.3 EXTENSION WISE SORTING
In this module priorities are given according to file type.
INPUT: File name.
PROCESSING: Search according to file type priorities.
OUTPUT: Results according to priorities (Sorted according to priorities)
2.1.2.4 RECENT SEARCH LOG
In this module all the recent searches are stored.
INPUT: File name.
PROCESSING: Storing of file in recent database.
OUTPUT: Results arranged according to recent searches.
2.1.2.5 TIME CONSTRAINT
In this module the searching should respond after a preset timing.
INPUT: File name.
PROCESSING: Searching in a bounded time.
OUTPUT: File Location.
2.1.3 Non-Functional requirements
1. User Interface:
This is a console application using C and provide options:
1) Search File of the system database of the custom or a predefined locations.
2) Show recent searches files sorted in terms of the time they were accessed
3) Open of the file from the respected directory.
2. Technology Used:
Language: C
Backend: File handling, data structure by using C language, File Directory in C
3. Performance Requirement:
Search must show result before the preset timer otherwise searching should be considered fail.

9
2.2 MODULES
2.2.1 MODULE 1
1) The program when started will just ask for filename. The search will start after the full name
of the file is entered.
2) The File could be anything form text based document to multimedia based file, the size of
the file could be variable.
3) User may enter entire filename with extension In the keyword for searching a respective file
and the program may search the entire file of the Hard disk.
4) There is a timer on a system, if the program was unable to find a file in a corresponding time
then user may have to search the file in a particular directory.
2.2.2 MODULE 2
1) There is a system which may sort the searched file.
2) The Sorting of the file was done by the respective extension they have.
3) The particular method out of many is used for sorting which yields the feasible result at a
least time.
2.2.3 MODULE 3
1) There is a system which may save the each log of the searched file, index them.
2) The log was saved onto a hard drive for future access.
3) These log will gave fastest access to the recent searched files.
4) The system was helpful for showing the “RECENT SEARCH” fuction which are showing
the file which was recently searched by the users
2.2.4 MODULE 4
1) System will gave the facility to user for opening the file he search.
2) He may have to select the file according to the respective option and there is a proper keyword
which is used to avail this facility.
3) After searching, a particular serial number has been allotted to the each searched file, which
may help the user for opening the corresponding file in a ease manner.

10
REQUIREMENT SPECIFICATION(RS)
S.NO. REQUIREMENT ESSENTIAL
OR
DESIRABLE
OR
OPTIONAL
DESCRIPTION
RS1 The system should
provide option for
searching a file.
Essential It will help user to
search a file.
RS2 Search by incomplete
name
Essential It will help user to
search a file without
knowing full name.
RS3 System should
provide files
according to priority
Essential It is for user
convenience.
RS4 Provide option for
opening file.
Desirable It will make system
more user friendly.
RS5 Provide option for
exit from program
Essential This feature is for
security purposes.
RS6 The program must
display proper error
message if any error
occurs
Essential Making program
more robust and user
friendly

11
CHAPTER 3
DESIGN
3.1 HIGH LEVEL DESIGN
3.1.1 System Analysis
Analyzing the system is very important process. For this purpose there are various tools available in
the market that can be used. The most popular and commonly used tools for data are Data Flow
Diagram (DFD), Entity Relationship Diagram, and System Flow Charts. The main points to be
discussed in system analysis are:
1. Specification of what the new system is to accomplish based on the user requirements.
2. Functional hierarchy is showing the functions to be performed by the new system and
their relationship with each other.
3.1.2 Requirement Collection
Requirements collection is a necessary part of our project. Understanding completely what a project
will transport is critical to its accomplishment. This may look very easy but common it is needed
attention to this area. Many projects start with the barest headline and list of requirements, only to
find later the problem not been properly understood. The contents of the statement of requirements
should be stable or change relatively slowly. Once we have created our statement of requirements,
ensure the user and all others understand that this and only this will be delivered.
3.1.3 DFDs
Through DFD, our project illustrates the flow of data elements from the data source external or
internal data store to store internal data or external data sink, through an internal process. A DFD
has no information about the timing of operations, or whether it will work in sequence or in parallel.
Therefore quite different from Flowchart, which shows the flow controls through an algorithm,
which allows the reader to determine what will be implemented processes, in what order, and under
any circumstances, but not any kind of data will be input if the output of the system, nor where the
data comes from and go to, nor where the data will be stored.
The Project is based upon the program which work as a systematic file and folder searcher.
The search process do the same for user and the resultant was the Searched File in Sorted Order.

12
Here the Project is based upon the program which work as a systematic file and folder searcher. The
search process do the same for user and the resultant was the Searched File in Sorted Order.

14
3.1.4 BLOCK DIAGRAM
3.1.5 ARCHITECTURAL MODEL
INCREMENTAL MODEL
3.1.5.1 Overview
In incremental model the whole requirement is divided into various builds. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed modules. Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced during the first
module, so you have working software early on during the software life cycle. Each subsequent release
of the module adds function to the previous release. The process continues till the complete system is
achieved.

15
INTRODUCTION
In incremental model the whole requirement is divided into various builds. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into
smaller, more easily managed modules. Each module passes through the requirements, design,
implementation and testing phases. A working version of software is produced during the first
module, so you have working software early on during the software life cycle. Each subsequent
release of the module adds function to the previous release. The process continues till the complete
system is achieved.
For example:
In the diagram above when we work incrementally we are adding piece by piece but expect that
each piece is fully finished. Thus keep on adding the pieces until it’s complete. As in the image
above a person has thought of the application. Then he started building it and in the first iteration the
first module of the application or product is totally ready and can be demoed to the customers.
Likewise in the second iteration the other module is ready and integrated with the first module.
Similarly, in the third iteration the whole product is ready and integrated. Hence, the product got
ready step by step.

16
Diagram of Incremental model:
Advantages of Incremental model:
1) Generates working software quickly and early during the software life cycle.
2) This model is more flexible – less costly to change scope and requirements.
3) It is easier to test and debug during a smaller iteration.
4) In this model customer can respond to each built.
5) Lowers initial delivery cost.
6) Easier to manage risk because risky pieces are identified and handled during it’d iteration.
Disadvantages of Incremental model:
1) Needs good planning and design.
2) Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
3) Total cost is higher than waterfall.

17
3.1.3.5 When to use the Incremental model:
1) This model can be used when the requirements of the complete system are clearly defined
and understood.
2) Major requirements must be defined; however, some details can evolve with time.
3) There is a need to get a product to the market early.
4) A new technology is being used
5) Resources with needed skill set are not available
6) There are some high risk features and goals.
3.2 LOW LEVEL DESIGN
3.2.1 PSEUDOCODE
a.)For Determining if a Filename Is in an Expression
Input for this algorithm are:
1. Filename: A Unicode string containing the file name string that is being matched. Filename may
not contain any wildcard characters.
2. Expression: A Unicode string containing the regular expression that's being matched with
Filename.
3. Ignore Case: A Boolean value indicating whether the match is case insensitive (TRUE) or case
sensitive (FALSE).
This algorithm returns TRUE if Filename matches Expression, and FALSE if it does not.
Pseudocode:
Part 1 -- Handle Special Case Optimizations
1. If Filename is empty and Expression is not, the routine returns FALSE.
2. If Expression is empty and Filename is not, the routine returns FALSE.
3. If both Expression and Filename are empty, the routine returns TRUE.
4. If the Expression is the wildcard "*" or "*.*", the Filename matches the Expression and
the routine returns TRUE.
5. If the first character in the Expression is wildcard "*" and the rest of the expression does
not contain any wildcard characters, then the remaining expression is compared against the
tail end of the Filename. If the comparison succeeds then the routine returns TRUE.

18
Part 2 -- Match Expression with Filename
1. The Filename is string compared with Expression using the following wildcard rules:
2. * (asterisk) matches zero or more characters.
3. ? (question mark) Matches a single character.
4. DOS_DOT (" quotation mark) matches either a period or zero characters beyond the name
string.
5. DOS_QM (> greater than) Matches any single character or, upon encountering a period or
end of name string, advances the expression to the end of the set of contiguous DOS_QMs.
6. DOS_STAR (< less than) Matches zero or more characters until encountering and matching
the final in the name.
b.)For Building the Relative Path Name for a Link
The inputs for this algorithm are:
1) Link: A Link whose relative path name we are building.
2) RootDirectory: A DirectoryFile indicating how far to walk up the directory hierarchy
when building the relative path name.
This algorithm returns a Unicode string representing the portion of a Link's path name from
RootDirectory to Link itself, inclusive. The returned string starts with a backslash and uses
backslashes as path separators. If Link is not a descendant of RootDirectory, the algorithm returns
an empty string to indicate this error.
Pseudocode:
1. If Link.File equals RootDirectory:
1. Return "".
2. Else If Link.File equals Link. File. Volume. RootDirectory:
1. Return an empty string.
3. Else If Link. ParentFile equals RootDirectory:
1. Return "" + Link.Name.
4. Else
1. Set ParentRelativeName to BuildRelativeName(Link.ParentFile, RootDirectory).
2. If ParentRelativeName is empty:

19
1. Return an empty string.
3. Else
1. Return ParentRelativeName + "" + Link.Name.
4. EndIf
5. EndIf
C.)For Finding All Files under a Directory
The inputs for this algorithm are:
1) RootDirectory: A DirectoryFile ADM element indicating the top-level directory for the
search.
This algorithm returns a list of files that are descendants of RootDirectory, including
RootDirectory itself.
The algorithm uses the following local variables:
2) Lists of Files (initialized to empty): FoundFiles, FilesToMerge
Pseudocode:
1. Insert RootDirectory into FoundFiles.
2. For each Link in RootDirectory.DirectoryList:
3. If Link.File.FileType is DirectoryFile:
1. Set FilesToMerge to FindAllFiles(Link.File).
4. Else:
1. Set FilesToMerge to a list containing the single entry Link.File.
5. EndIf
6. For each File in FilesToMerge:
1. If File is not an element of FoundFiles, insert File into FoundFiles.
7. EndFor
8. EndFor
9. Return FoundFiles.

20
CHAPTER 4
TESTING
4.1 Testing Overview
Software testing is an investigation conducted to provide stakeholders with information about the
quality of the product or service under test. Software testing can also provide an objective,
independent view of the software to allow the business to appreciate and understand the risks of
software implementation. Test techniques include the process of executing a program or application
with the intent of finding software bugs (errors or other defects).
It involves the execution of a software component or system component to evaluate one or more
properties of interest.
As the number of possible tests for even simple software components is practically infinite, all
software testing uses some strategy to select tests that are feasible for the available time and
resources. As a result, software testing typically (but not exclusively) attempts to execute a program
or application with the intent of finding software bugs (errors or other defects).
Software testing can provide objective, independent information about the quality of software and
risk of its failure to users and/or sponsors Software testing can be conducted as soon as executable
software (even if partially complete) exists. The overall approach to software development often
determines when and how testing is conducted. For example, in a phased process, most testing occurs
after system requirements have been defined and then implemented in testable programs. In contrast,
under an Agile approach, requirements, programming, and testing are often done concurrently.
Software Testing is evaluation of the software against requirements gathered from users and system
specifications. Testing is conducted at the phase level in software development life cycle or at
module level in program code. Software testing comprises of Validation and Verification.
4.1.1 Software Validation
Validation is process of examining whether or not the software satisfies the user requirements. It is
carried out at the end of the SDLC. If the software matches requirements for which it was made, it
is validated.
4.1.2 Errors - These are actual coding mistakes made by developers. In addition, there is a difference
in output of software and desired output, is considered as an error.
4.1.3 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error
which can cause system to fail.
4.1.4 Failure - failure is said to be the inability of the system to perform the desired task. Failure
occurs when fault exists in the system.

21
4.1.5 Manual Vs. Automated Testing
Testing can either be done manually or using an automated testing tool:
Manual - This testing is performed without taking help of automated testing tools. The software
tester prepares test cases for different sections and levels of the code, executes the tests and reports
the result to the manager.
Manual testing is time and resource consuming. The tester needs to confirm whether or not right test
cases are used. Major portion of testing involves manual testing. Automated this testing is a testing
procedure done with aid of automated testing tools. The limitations with manual testing can be
overcome using automated test tools.
A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done with
manual testing. But to check if the web-server can take the load of 1 million users, it is quite
impossible to test manually.
There are software and hardware tools which helps tester in conducting load testing, stress testing,
regression testing.
4.2 Testing Approaches
Tests can be conducted based on two approaches –
1) Functionality testing
2) Implementation testing
When functionality is being tested without taking the actual implementation in concern it is
known as black-box testing. The other side is known as white-box testing where not only
functionality is tested but the way it is implemented is also analyzed.
Exhaustive tests are the best-desired method for a perfect testing. Every single possible value in the
range of the input and output values is tested. It is not possible to test each and every value in real
world scenario if the range of values is large.
4.2.1 Black-box testing
It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester
in this case, has a set of input values and respective desired results. On providing input, if the output
matches with the desired results, the program is tested ‘ok’, and problematic otherwise.
In this testing method, the design and structure of the code are not known to the tester, and testing
engineers and end users conduct this test on the software.
4.2.2 Black-box testing techniques:
Equivalence class - The input is divided into similar classes. If one element of a class passes the
test, it is assumed that all the class is passed.
Boundary values - The input is divided into higher and lower end values. If these values pass the
test, it is assumed that all values in between may pass too.

22
Cause-effect graphing - In both previous methods, only one input value at a time is tested. Cause
(input) – Effect (output) is a testing technique where combinations of input values are tested in a
systematic way.
Pair-wise Testing - The behavior of software depends on multiple parameters. In pairwise testing,
the multiple parameters are tested pair-wise for their different values.
State-based testing - The system changes state on provision of input. These systems are tested based
on their states and input.
4.2.3 White-box testing
It is conducted to test program and its implementation, in order to improve code efficiency or
structure. It is also known as ‘Structural’ testing.
In this testing method, the design and structure of the code are known to the tester. Programmers of
the code conduct this test on the code.
4.2.4 White-box testing techniques:
The below are some White-box testing techniques:
Control-flow testing - The purpose of the control-flow testing to set up test cases which covers all
statements and branch conditions. The branch conditions are tested for both being true and false, so
that all statements can be covered.
Data-flow testing - This testing technique emphasis to cover all the data variables included in the
program. It tests where the variables were declared and defined and where they were used or
changed.
Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs parallel to software
development. Before jumping on the next stage, a stage is tested, validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or issues left in the
software. Software is tested on various levels -
4.2.5 Unit Testing
While coding, the programmer performs some tests on that unit of program to know if it is error free.
Testing is performed under white-box testing approach. Unit testing helps developers decide that
individual units of the program are working as per requirement and are error free.

23
4.2.6 Integration Testing
Even if the units of software are working fine individually, there is a need to find out if the units if
integrated together would also work without errors. For example, argument passing and data
updating etc.
4.2.7 System Testing
The software is compiled as product and then it is tested as a whole. This can be accomplished using
one or more of the following tests:
4.2.8 Functionality testing
Tests all functionalities of the software against the requirement.
4.2.9 Performance testing - This test proves how efficient the software is. It tests the
effectiveness and average time taken by the software to do desired task. Performance testing is done
by means of load testing and stress testing where the software is put under high user and data load
under various environment conditions.
4.2.10 Security & Portability - These tests are done when the software is meant to work on
various platforms and accessed by number of persons.
4.2.11 Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of testing
where it is tested for user-interaction and response. This is important because even if the software
matches all user requirements and if user does not like the way it appears or works, it may be rejected.
4.3 Alpha testing- The team of developer themselves perform alpha testing by using the
system as if it is being used in work environment. They try to find out how user would react to some
action in software and how the system should respond to inputs.
4.4 Beta testing- After the software is tested internally, it is handed over to the users to use it
under their production environment only for testing purpose. This is not as yet the delivered product.
Developers expect that users at this stage will bring minute problems, which were skipped to attend.
4.5 Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested
thoroughly to detect if there is any negative impact of the added code. This is known as regression
testing.

24
4.6 Testing Documentation
Testing documents are prepared at different stages -
4.6.1 Before Testing
Testing starts with test cases generation. Following documents are needed for reference –
SRS document - Functional Requirements document
Test Policy document - This describes how far testing should take place before releasing the
product.
Test Strategy document - This mentions detail aspects of test team, responsibility matrix and
rights/responsibility of test manager and test engineer.
Traceability Matrix document - This is SDLC document, which is related to requirement gathering
process. As new requirements come, they are added to this matrix. These matrices help testers know
the source of requirement. They can be traced forward and backward.
4.6.2 While Being Tested
The following documents may be required while testing is started and is being done:
Test Case document - This document contains list of tests required to be conducted. It includes Unit
test plan, Integration test plan, System test plan and Acceptance test plan.
Test description - This document is a detailed description of all test cases and procedures to execute
them.
Test case report - This document contains test case report as a result of the test.
Test logs - This document contains test logs for every test case report.
4.6.3 After Testing
The following documents may be generated after testing:
Test summary - This test summary is collective analysis of all test reports and logs. It summarizes
and concludes if the software is ready to be launched. The software is released under version control
system if it is ready to launch.
Testing vs. Quality Control, Quality Assurance and Audit
We need to understand that software testing is different from software quality assurance, software
quality control and software auditing.
Software quality assurance - These are software development process monitoring means, by which
it is assured that all the measures are taken as per the standards of organization. This monitoring is
done to make sure that proper software development methods were followed.
Software quality control - This is a system to maintain the quality of software product. It may
include functional and non-functional aspects of software product, which enhance the goodwill of
the organization. This system makes sure that the customer is receiving quality product for their
requirement and the product certified as ‘fit for use’.

25
TEST CASES
Test
case id
Test case
name
Test case
description Test steps
Test
status
pass /
fail
Test
priority
Step Expected Actual
1. Verify for
correct file
name.
Checking the
file which is
in the system.
Enter the file
name with
correct
extension.
File
successfully
searched by
the program.
File
searched.
Pass
2. Verify for
incorrect
file name.
Checking for
the file which
is not in the
hard disk.
Enter a
wrong file
name.
File should
not be found
by the
program.
Error
message.
Pass
3. Verify for
correct file
name with
wrong
extension.
Checking for
a file with
wrong
extension.
Enter a file
name which
is present in
the system
with wrong
extension
name.
File should
not be found
by the
program.
Error
message.
Pass

26
CHAPTER 5
LIMITATIONS
Implementation Details:
1. Index Module: We have implemented the code basing on the examples provided over internet for
reading the data from pdf files.
2. Input Module : We have written the actions for the fields and the UI is created using NetBeans.
3. Search Module : We have implemented the code.
4. Output Module : We have implemented the logic and UI for this module.
We assuming to have project writing for approximately 700 lines of code.

27
CHAPTER 6
REFERENCES
1. InforFilesonMicrosoftNetworks”. Microsoft Download Center. Microsoft Corporation.
2008-06-30. Retrieved 2007-07-14.
2. "AvailabilityoftheWindowsDesktopSearchadd-inforFilesonMicrosoftNetworks
3. (Revision:5.0)".MicrosoftSupport.MicrosoftCorporation.2008-12-10.Retrieved2012-01
4. "Technical FAQ: How long does it take for Windows Search to finish indexing a
computer?”. Microsoft Corporation. Archived from the originalon24September2011.
Retrieved28 May 2014.
5. "IFilterInterface" .MSDN. Microsoft Corporation. Retrieved2012-01-02.
6. "Listofsearchablefiletypes". www.Google.in
7. "Developing Property Handlers for Windows Search" .MSDN .Microsoft Corporation.
2011-09-07. Retrieved 2012-01-02.
8. "Using the search-MS Protocol". Retrieved 2007-09-24.
9. "Change Journals (Windows)". Retrieved 2007-07-14.
10. "Managing the Index”. MSDN. Retrieved 2007-10-12.
11. Lextrait, Vincent(July2010). "The Programming Languages Beacon ,v10.3".Retrieved
5Sep 2010.
12. "WindowsSearchasaDevelopmentPlatform".
13. "WDSrevisionupdate, expanded applicability rules, auto-approve
revisions". Retrieved 2010-02-01.
14. "Windows Search". Retrieved 2007-10-03.
15. "Natural Language Searching Windows Vista". Retrieved 2007-06-22.
16. "WindowsSearch3.x".MSDN. Retrieved 2007-10-12.
17. "OverviewoftheWindowsVistadesktopsearchchangesinWindowsVistaServicePack
18. 1". Retrieved2007-07-14.

File Assay (A Program which predict and search the files from system)

Recommended

Recommended

More Related Content

Similar to File Assay (A Program which predict and search the files from system)

Similar to File Assay (A Program which predict and search the files from system) (20)

Recently uploaded

Recently uploaded (20)

File Assay (A Program which predict and search the files from system)