CHAPTER 1 PLANNING PHASE

1.1 PROBLEM STATEMENT 1.1.1 Description of the present situation: At present, the GUI designing of the software web application, Online College Magazine, has been completed. Designing of the database is also over. The coding phase of the GUI is in progress and, is expected to be over soon. After that, the testing and validation phase will be approached. 1.1.2 Problem constraints : There is a constraint of manpower, as only three people are working on this project. If there were more, then the project would have been completed earlier, as well as, the work could have been divided between each person in the group. At present, there are no hardware or software constraints. Creating and managing an Online College Magazine where college students and faculties can post and read various articles, thus promoting literary insight. Articles can be searched by anybody in the world. Factors behind the motivation of this system are: a) Not all students make it to the printed magazine. b) Creativity of the students needs to be nurtured. c) Creating a user friendly interactive place where students/faculties can share their ideas. 1.1.3 Statement and brief description of goals: Functional Requirements: a) Students and faculty of the college can register as users and contribute to the magazine. b) Readers can download the magazine in PDF format. c) Alumni registration is supported. d) Registered members, moderators and administrator are allowed to post articles. e) The home page consists of attractive features like: editors choice, picture of the day, latest college news, recent articles, poems and photography contributions, article of the month, etc. f) Archives are to be maintained. g) Guests may read articles but are not allowed to post articles or comment on them, as this is strictly a college magazine. h) Search engine for all contributions made till date. Accessible by anybody. Non-functional Requirements: a) 247 availability to users. b) Better component design to get better performance at peak time. c) Flexible service based architecture will be highly desirable for future extension. d) Picture of the day. 2

e) Best articles, poetry, etc. Software Requirements: a) Web Browser like Google Chrome, Internet Explorer, Mozilla Firefox, Safari, et al. b) Net beans 6.7 or higher versions c) SQLyog d) Windows XP or Windows7 Hardware Requirements: a) 500Mb (or more) RAM b) 5GB (or more) free Hard Disk space c) Pentium IV with 2.8 GHz processors or higher versions. In our case, we have used both Pentium IV as well as Intel i3 processors. User Interface: a) Login page b) Comment box c) JSP, HTML pages d) Registration forms

1.1.4 List and description of users and their roles :

a) Registered Members (Students/Faculty/Alumni): Are free to access all contributions to the magazine, can comment on all contributions, ar free to make their own contribution in any field like articles, poetry, photography, experiences, art, research, etc. b) Administrator: Administrator has the privilege to access all contributions, to read them, and to delete them when necessary. He can post articles, news items, notices, etc. c) Guests/Anonymous: Can access all contents of the magazine and download magazine, but cannot comment or post any contributions.

1.2 SOLUTION STRATEGY a) List and brief description of all possible solutions : As there is a problem of less amount of manpower and a constraint of time, a possible solution would be to increase no. of developers and extending the time period. b) List and brief description of all accepted solutions : The problem of manpower has been dealt by dividing the modules among the current developers. c) List and brief description of all rejected solutions : The problem of time constraint cannot be solved as the time period cannot be extended, thus, that solution has been rejected. 3

1.3 DEVELOPMENT PROCESS 1.3.1 Life cycle model for the project: Online College Magazine is based on the Prototyping Life Cycle Model. This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The quick design focuses on a representation of those aspects of the software that will be visible to the user. The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and used to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done. 1.3.2 Team Structure: The team consists of three members: Catherine Nipps: Her role in the development of the web application is the complete designing of the GUI part. This includes making JavaServer Pages (JSP), CSS, and HTML pages. R. Yuvashree: Her role in the development of the web application includes the designing of the database, as well as, the coding of the GUI part. This includes working on SQLyog and using Servlets for coding of the GUI. Ankit Agrawal: His role in the development of the web application includes the validation and testing of the codes. This includes working on Java Scripts (JS). 1.3.3 Software Configuration Management :
a) List and brief description of non-changeable objects that would contribute to the software phase wise:

CSS: The Cascading Style Sheets remain the same throughout the development and use of the product. Servlets: The coding of registration pages, login pages, administrator privileges, remains unchanged throughout the development and use of the product. Java Scripts: The Java Scripting for login and registration modules remains unchanged throughout the development and use of the product.
b) List and brief description of changeable objects that would contribute to the software phase wise:

JSP: The contents of the JavaServer Pages have to be changed regularly according to the current contents of the magazine. Database: The database is the most frequently changed object of the project. It has to be updated according to the no. of new users, deleted users, content, etc.

Contents: The contents of the magazine, its cover, articles, new competitions, design, etc., will be changed from time to time. 1.3.4 Risk Management :
a) List and brief description of any kinds of risks that may occur phase wise:

All specifications may have not been mentioned and implemented. Spam and threatening contents may be posted by some spammers. The database may malfunction. The project may not be completed on time.
b) List and brief descriptions of any possible solutions for the above mentioned risks:

Interact with the users to understand each requirement correctly. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Avoid spammers by only allowing registered users to post anything after verification. Increase manpower.

1.4 SOFTWARE METRICS 1.4.1 Deciding the complexity category of the project under development: As the total number of Kilo lines of codes in our project is 20, it comes under the category of medium-sized projects. Medium-sized projects are used under semi-detached projects, thus well be using semi-detached project. We will use this model for estimation of cost of our project in terms of effort applied in person month, Development time in chronological order, required to complete the project.Well use organic COCOMO model to do the same. 1.4.2 Estimating Lines of Code needed for the complete development of the product: The estimated lines of code are 20,000. The construction cost model is unempirical estimation model i.e. model uses theoretically derived formula to predict cost related factors. 1.4.3 Calculating Programmer months for the project: E=a*(KLOC)^b D=c*(E)^d

Where, E=Effort, D=Duration in Person Month a,b,c,d are constants Given, KLOC=20 As it is Semidetached project: Now, a = 3.0, b =1.12, c =2.5, d = 0.3 5

Substituting in the formula E = a * (KLOC) ^ b E = 3.0 * (20) ^ 1.12 E = 85.95 in programmer month. (Due to enormous amount of coding of JSP and templates) 1.4.4 Calculating the development time for the project: D=2.5 * (85.95) ^.35 D=11.88 in month. 1.4.5 Using COCOMO model for cost estimation for the product: It computes the effort and related cost applied on the software development process as a function of program size expressed in terms of estimated lines of code (LOC or KLOC). Intermediate COCOMO model: It computes the software development effort as a function of Program size Set of cost drivers that includes subjective assessment of product , hardware, etc. Advanced COCOMO model: It incorporates all the characteristics of the intermediate version along with an assessment of cost drivers impact on each step of software engineering process. Three classes of software projects: Organic projects: These are relatively small and simple projects. Semidetached projects: These are medium size projects. Embedded projects: These are very large projects that have a very rigid requirements level.

1.5 Review and Planning Phase : Points and brief description of the reviews conducted and report of the results obtained : The planning decisions that we have made regarding which databases and applications we will migrate, and how we will migrate them, will help us define the environments that we require to develop the solutions. The incomplete, ambiguous, or even contradictory requirements have been recognized.

CHAPTER 2 ANALYSIS AND DESIGN PHASE

2.1 Analysis document for the product : 2.1.1 Data Dictionary : In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. 2.1.2 Entity Relationship Diagram : An E-R diagram can express the overall logical structure of a database graphically. E-R diagrams are simple and clear qualities that may well account in large part for the widespread use of the E-R model. Such a diagram consists of the following major components: Rectangles, which represent entity sets. Ellipses, which represent attributes. Diamonds, which represent relationship sets. Lines, which link attributes to entity sets and entity sets to relationship sets. Double ellipses, which represent multi-valued attributes. Dashed ellipses, which denote derived attributes. Double lines, which indicate total participation of an entity in a relationship set. Double rectangles, which represent weak entity sets.

2.1.3 Data Flow Diagram (DFD) DFD is an important technique for modeling a systems high-level detail by showing how input data is transformed to output results through a sequence of functional transformations. DFDs reveal relationships among and between the various components in a program or system. DFDs consist of four major components: A data flow diagram represents the following: External devices sending and receiving data Processes that change that data Data flows themselves Data storage locations

Data flow diagrams have replaced flowcharts and pseudo code as the tool of choice for showing program design. A DFD illustrates those functions that must be performed in a program as well as the data that the function will need. In spite of its strength, the beauty of DFD lies on its dependence upon just four symbols to express program design. Symbols of Data Flow Diagram: There only four symbols used to write Data Flow Diagram as follows: External Entities > Rectangular box 8

Data Flow > Arrow headed lines Process > Bubble (Circle or round corner square) Data Store > Narrow opened rectangle

2.1.4 State Transition Diagrams (STDs) State transition diagram are used along with specifications to define the functional detail for a system. Unlike data processes, control processes have a specialized role: enforcing sequencing over environmental control stimuli to the system, and the internal operation of the system. A control process is defined on an STD that represents the definition of the control process as a finite-state-machine. The number of the STD is the same as the number of the control process it defines. The finite-state-machine enters an initial state when activated, either notionally at system startup or when the control process is activated by an enable or trigger prompt. 2.1.5 Data Object Description document : 2.1.4.1 Entity Relationship Diagram (ERD)

Fig. 2.1

Fig. 2.2

Fig. 2.3

10

2.1.6 Process Specification document : 2.1.6.1 Data Flow Diagram (DFD)

Fig. 2.4

11

2.2 Creating Designs document : 2.2.1 Interface Design :

Fig. 2.5

12

Fig. 2.6

13

Fig. 2.7

14

Fig. 2.8

15

Fig. 2.9

16

Fig. 2.10

17

Fig. 2.11

18

Fig. 2.12

19

2.3 Milestones, Walkthroughs and Inspection document : a) Setting up Milestones for the implementation and testing phases. A milestone is a point some way through a project plan that indicates how far the project has progressed. A milestone deliverable refers to a tangible product that is produced signifying the reaching of the milestone.

Fig. 2.13 1. 2. 3. 4. 5. Specification Design Database Design GUI part Code GUI part Integration and Testing

In a Walkthrough, the producer describes the product and asks for comments from the participants. These gatherings generally serve to inform participants about the product rather than correct it. Software Inspections are a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into field operations. Walkthrough is an informal meeting for evaluation, usually no preparation is required for this. Inspection is a method that deserves careful consideration by any organization concerned with the quality of the product they ship. It is a formalized method of improving a work product by continually measuring it against standards and requirements.

20

CHAPTER 3 Implementation Phase

21

3.1 Coding : Java Platform, Enterprise Edition or Java EE is a widely used platform for server programming in the Java programming language. The Java platform (Enterprise Edition) differs from the Java Standard Edition Platform (Java SE) in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server. Java EE is defined by its specification. As with other Java Community Process specifications, providers must meet certain conformance requirements in order to declare their products as Java EE compliant. Java EE includes several API specifications, such as JDBC, RMI, e-mail, JMS, web services, XML, etc., and defines how to coordinate them. Java EE also features some specifications unique to Java EE for components. These include Enterprise JavaBeans, Connectors, servlets, portlets (following the Java Portlet specification), JavaServer Pages and several web service technologies. This allows developers to create enterprise applications that are portable and scalable, and that integrate with legacy technologies. A Java EE application server can handle transactions, security, scalability, concurrency and management of the components that are deployed to it, in order to enable developers to concentrate more on the business logic of the components rather than on infrastructure and integration tasks. Java Servlets A servlet is a Java programming language class used to extend the capabilities of servers that host applications accessed via a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers. Thus, it can be thought of as a Java Applet that runs on a server instead of a browser. A Servlet is a Java class in Java EE that conforms to the Java Servlet API, a protocol by which a Java class may respond to requests. They are not tied to a specific client-server protocol, but are most often used with the HTTP protocol. Therefore, the word "Servlet" is often used in the meaning of "HTTP Servlet". Thus, a software developer may use a servlet to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as CGI and ASP.NET. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL rewriting. To deploy and run, the Apache Tomcat Server may be used. It is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run. Life cycle of a servlet The container calls the no-arg constructor. The Web container calls the init() method. This method initializes the servlet and must be called before life of a servlet, the init() method is called only once. 22

After initialization, the servlet can service client requests. Each request is serviced in its own separate thread. The Web container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request for a method that is not implemented by the servlet is made, the method of the parent class is called, typically resulting in an error being returned to the requester. Finally, the Web container calls the destroy() method that takes the servlet out of service. The destroy() method, like init(), is called only once in the lifecycle of a servlet. JavaBeans Java Beans are reusable software components for Java that can be manipulated visually in a builder tool. Practically, they are classes written in the Java programming language conforming to a particular convention. They are used to encapsulate many objects into a single object (the bean), so that they can be passed around as a single bean object instead of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a nullary constructor, and allows access to properties using getter and setter methods. In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behaviour. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans. The required conventions are as follows: The class must have a public default constructor (no-argument). This allows easy instantiation within editing and activation frameworks. The class properties must be accessible using get, set, is (used for boolean properties instead of get) and other methods (so-called accessor methods and mutator methods), following a standard naming-convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. The class should be serializable. It allows applications and frameworks to reliably save, store, and restore the bean's state in a fashion independent of the VM and of the platform.

JavaBeans is a portable, platform-independent component model written in the Java programming language. The JavaBeans architecture was built through a collaborative industry effort and enables developers to write reusable components in the Java programming language. With the JavaBeans API you can create reuseable, platform-independent components. Using JavaBeans-compliant application builder tools, you can combine these components into applets, applications, or composite components. JavaBean components are known as beans. Beans are dynamic in that they can be changed or customized. A bean information class implements the BeanInfo interface. A BeanInfo class explicitly lists those bean features that are to be exposed to application builder tools.

23

Properties are the appearance and behavior characteristics of a bean that can be changed at design time. Builder tools introspect on a bean to discover its properties and expose those properties for manipulation. Beans expose properties so they can be customized at design time. Customization is supported in two ways: by using property editors, or by using more sophisticated bean customizers. Beans use events to communicate with other beans. A bean that is to receive events (a listener bean) registers with the bean that fires the event (a source bean). Builder tools can examine a bean and determine which events that bean can fire (send) and which it can handle (receive). Persistence enables beans to save and restore their state. After changing a bean's properties, you can save the state of the bean and restore that bean at a later time with the property changes intact. The JavaBeans architecture uses Java Object Serialization to support persistence. A bean's methods are no different from Java methods, and can be called from other beans or a scripting environment. By default all public methods are exported.

Java Server Pages (JSP) Java Server Page is a Java technology that helps software developers serve dynamically generated web pages based on HTML, XML, or other document types. Released in 1999 as Sun's answer to ASP and PHP, JSP was designed to address the perception that the Java programming environment didn't provide developers with enough support for the Web. To deploy and run, a compatible web server with servlet container is required. The Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems and the JCP must both be met by the container. Architecturally, JSP may be viewed as a high-level abstraction of Java servlets. JSP pages are loaded in the server and are operated from a structured special installed Java server packet called a Java EE Web Application, often packaged as a .war or .ear file archive. JSP allows Java code and certain pre-defined actions to be interleaved with static web markup content, with the resulting page being compiled and executed on the server to deliver an HTML or XML document. The compiled pages and any dependent Java libraries use Java bytecode rather than a native software format, and must therefore be executed within a Java virtual machine (JVM) that integrates with the host operating system to provide an abstract platform-neutral environment. JSP syntax is a fluid mix of two basic content forms: scriptlet elements and markup. Markup is typically standard HTML or XML, while scriptlet elements are delimited blocks of Java code which may be intermixed with the markup. When the page is requested the Java code is executed and its output is added, in situ, with the surrounding markup to create the final page. JSP pages must be compiled to Java bytecode classes before they can be executed, but such compilation is needed only when a change to the source JSP file has occurred. Java code is not required to be complete (self contained) within its scriptlet element block, but can straddle markup content providing the page as a whole is syntactically correct (for example, any Java if/for/while blocks opened in one scriptlet element must be correctly closed in a later element for the page to successfully compile). This system of split inline 24

coding sections is called step over scripting because it can wrap around the static markup by stepping over it. Markup which falls inside a split block of code is subject to that code, so markup inside an if block will only appear in the output when the if condition evaluates to true; likewise markup inside a loop construct may appear multiple times in the output depending upon how many times the loop body runs. The JSP syntax adds additional XML-like tags, called JSP actions, to invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag libraries that act as extensions to the standard HTML or XML tags. JVM operated tag libraries provide a platform independent way of extending the capabilities of a web server. Note that not all commercial Java servers are Java EE specification compliant. JavaServer Pages (JSP) is a technology based on the Java language and enables the development of dynamic web sites. JSP was developed by Sun Microsystems to allow server side development. JSP files are HTML files with special Tags containing Java source code that provide the dynamic content.The following shows the Typical Web server,different clients connecting via the Internet to a Web server. In this example,the Web server is running on Unix and is the very popular Apache Web server. JavaScript JavaScript, also known as ECMAScript, is a prototype-based, object-oriented scripting language that is dynamic, weakly typed and has first-class functions. It is also considered a functional programming. JavaScript is an implementation of the ECMAScript language standard and is primarily used in the form of client-side JavaScript, implemented as part of a web browser in order to provide enhanced user interfaces and dynamic websites. This enables programmatic access to computational objects within a host environment.JavaScript's use in applications outside web pagesfor example in PDF documents, site-specific browsers and desktop widgetsis also significant. Newer and faster JavaScript VMs and frameworks built upon them (notably Node.js) have also increased the popularity of JavaScript for server-side web apps.JavaScript uses syntax influenced by that of C. JavaScript copies many names and naming conventions from Java, but the two languages are otherwise unrelated and have very different semantics. Features- The following features are common to all conforming ECMAScript implementations, unless explicitly specified otherwise. Imperative and structured JavaScript supports structured programming syntax in C (e.g., if statements, while loops, switch statements, etc.). One partial exception is scoping: C-style block-level scoping is not supported (instead, JavaScript has function-level scoping). JavaScript 1.7, however, supports block-level scoping with the let keyword. Like C, JavaScript makes a distinction between expressions and statements. One syntactic difference from C is automatic semicolon insertion, in which the semicolons that terminate statements can be omitted. Dynamic Dynamic typing

25

As in most scripting languages, types are associated with values, not with variables. For example, a variable x could be bound to a number, then later rebound to a string. JavaScript supports various ways to test the type of an object, including duck typing. Object based JavaScript is almost entirely object-based. JavaScript objects are associative arrays, augmented with prototypes (see below). Object property names are string keys: obj.x = 10 and obj['x'] = 10 are equivalent, the dot notation being syntactic sugar. Properties and their values can be added, changed, or deleted at run-time. Most properties of an object (and those on its prototype inheritance chain) can be enumerated using a for...in loop. JavaScript has a small number of built-in objects such as Function and Date. Run-time evaluation JavaScript includes an eval function that can execute statements provided as strings at runtime. Functional First-class functions Functions are first-class; they are objects themselves. As such, they have properties and methods, such as length and call(); and they can be assigned to variables, passed as arguments, returned by other functions, and manipulated like any other object. Any reference to a function allows it to be invoked using the () operator. Nested functions 'Inner' or 'nested' functions are functions defined within another function. They are created each time the outer function is invoked. In addition to that, the scope of the outer function, including any constants, local variables and argument values, become part of the internal state of each inner function object, even after execution of the outer function concludes. Closures JavaScript allows nested functions to be created, with the lexical scope in force at their definition, and has a () operator to invoke them now or later. This combination of code that can be executed outside the scope in which it is defined, with its own scope to use during that execution, is called a closure in computer science. Prototype-based Prototypes JavaScript uses prototypes instead of classes for inheritance. It is possible to simulate many class-based features with prototypes in JavaScript. 26

Functions as object constructors Functions double as object constructors along with their typical role. Prefixing a function call with new creates a new object and calls that function with its local this keyword bound to that object for that invocation. The constructor's prototype property determines the object used for the new object's internal prototype. JavaScript's built-in constructors, such as Array, also have prototypes that can be modified. Functions as methods Unlike many object-oriented languages, there is no distinction between a function definition and a method definition. Rather, the distinction occurs during function calling; a function can be called as a method. When a function is called as a method of an object, the function's local this keyword is bound to that object for that invocation. Miscellaneous Run-time environment JavaScript typically relies on a run-time environment (e.g. in a web browser) to provide objects and methods by which scripts can interact with "the outside world". In fact, it relies on the environment to provide the ability to include/import scripts (e.g. HTML <script> elements). (This is not a language feature per se, but it is common in most JavaScript implementations.) Array and object literals Like many scripting languages, arrays and objects (associative arrays in other languages) can each be created with a succinct shortcut syntax. In fact, these literals form the basis of the JSON data format. Regular expressions JavaScript also supports regular expressions in a manner similar to Perl, which provide a concise and powerful syntax for text manipulation that is more sophisticated than the built-in string functions. Vendor-specific extensions JavaScript is officially managed by Mozilla Foundation, and new language features are added periodically. However, only some non-Mozilla JavaScript engines support these new features: property getter and setter functions (also supported by WebKit, Opera, ActionScript, and Rhino) conditional catch clauses iterator protocol adopted from Python shallow generators/coroutines also adopted from Python array comprehensions and generator expressions also adopted from Python 27

proper block scope via the new let keyword array and object destructuring (limited form of pattern matching) concise function expressions (function(args) expr) ECMAScript for XML (E4X), an extension that adds native XML support to ECMAScript.

28

CHAPTER 4 TESTING PHASE

29

What is Software Testing? Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software. The difficulty in software testing stems from the complexity of software: we cannot completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality. 4.1 TESTING STRATEGY Software testing strategy includes the following: Test activities are determined and test data selected. The test is conducted and test results are compared with the expected results

There are various types of testing Unit Testing Unit Testing is essential for the verification of the code produced during the coding phase and the goal is test for the internal logic of the module/program. In the generic code project, the unit testing is done during coding phase of data entry forms whether the functions are working properly or not. In this phase all the drivers are tested, they are rightly connected or not. Integration Testing All the tested modules are combined into subsystems which are then tested. The goal is to see if the modules are properly integrated, and the emphasis being on the testing interfaces between the modules. In the generic code integration testing is done mainly on table creation module and insertion module. System Testing It is mainly used if the software meets its requirements. The reference document for this process is the requirement document. Acceptance Testing It is performed with realistic data of the client to demonstrate that the software is working satisfactorily. In the generic code project testing is done to check whether the creation of tables and respected data entry is working successfully or not.

30

4.2 TEST PLAN Black-box testing The black-box approach is a testing method in which test data are derived from the specified functional requirements without regard to the final program structure. It is also termed datadriven, input/output driven or requirements-based testing. Because only the functionality of the software module is of concern, black-box testing also mainly refers to functional testing -a testing method emphasized on executing the functions and examination of their input and output data. The tester treats the software under test as a black box -- only the inputs, outputs and specification are visible, and the functionality is determined by observing the outputs to corresponding inputs. In testing, various inputs are exercised and the outputs are compared against specification to validate the correctness. All test cases are derived from the specification. No implementation details of the code are considered. It is obvious that the more we have covered in the input space, the more problems we will find and therefore we will be more confident about the quality of the software. Ideally we would be tempted to exhaustively test the input space. But as stated above, exhaustively testing the combinations of valid inputs will be impossible for most of the programs, let alone considering invalid inputs, timing, sequence, and resource variables. Combinatorial explosion is the major roadblock in functional testing. To make things worse, we can never be sure whether the specification is either correct or complete. Due to limitations of the language used in the specifications (usually natural language), ambiguity is often inevitable. Even if we use some type of formal or restricted language, we may still fail to write down all the possible cases in the specification. Sometimes, the specification itself becomes an intractable problem: it is not possible to specify precisely every situation that can be encountered using limited words. And people can seldom specify clearly what they want -- they usually can tell whether a prototype is, or is not, what they want after they have been finished. Specification problems contribute approximately 30 percent of all bugs in software. The research in black-box testing mainly focuses on how to maximize the effectiveness of testing with minimum cost, usually the number of test cases. It is not possible to exhaust the input space, but it is possible to exhaustively test a subset of the input space. Partitioning is one of the common techniques. If we have partitioned the input space and assume all the input values in a partition is equivalent, then we only need to test one representative value in each partition to sufficiently cover the whole input space. Domain testing partitions the input domain into regions, and considers the input values in each domain an equivalent class. Domains can be exhaustively tested and covered by selecting a representative value(s) in each domain. Boundary values are of special interest. Experience shows that test cases that explore boundary conditions have a higher payoff than test cases that do not. Boundary value analysis requires one or more boundary values selected as representative test cases. The difficulties with domain testing are that incorrect domain definitions in the specification cannot be efficiently discovered. Good partitioning requires knowledge of the software structure. A good testing plan will not only contain black-box testing, but also white-box approaches, and combinations of the two.

31