Integration Test Plan

Size: px

Start display at page:

Download "Integration Test Plan"

Ashlee Morris
5 years ago
Views:

1 Integration Test Plan Team B.E.E.F.E.A.T.E.R. Nick Canzoneri Adam Hamilton Georgi Simeonov Nick Wolfgang Matt Wozniski

2 Date: May 1, 2009 Date Description Revision February 17, 2009 Initial revision 1 April 07, 2009 First revision 2 i

3 Contents 1 Introduction Purpose Scope Definitions, Acronyms, and Abbreviations Modules Introduction Project Structure Assumptions and Exclusions Introduction Assumptions Exclusions Testing Procedure Introduction Entry Criteria Exit Criteria Participants Introduction Roles and Responsibilities Reporting References 5 ii

4 1 Introduction 1.1 Purpose This document describes the integration test plan for the Brilliantly Engineered Extensible Framework Enabling AJAX Transaction-based Exchanges Reliably (B.E.E.F.E.A.T.E.R.). B.E.E.F.E.A.T.E.R. is a development scaffold to be used by developers when creating dynamic web-based applications. The B.E.E.F.E.A.T.E.R. project is described in detail in the B.E.E.F.E.A.T.E.R.Requirements Document[1] and B.E.E.F.E.A.T.E.R. Design Document[2]. 1.2 Scope This document describes the integration test procedure and the roles of B.E.E.F.E.A.T.E.R team members and stakeholders. This document is intended for the developers and project stakeholders who will be participants in the test or who will receive test reports. 1.3 Definitions, Acronyms, and Abbreviations Agile A software development methodology that encourages frequent inspection and adaptation of the design and a set of engineering best practices that allow for rapid delivery of high-quality software. AJAX Asynchronous JavaScript and XML. Using AJAX as a technique is the action of using a XML- HttpRequest to get information from the server asynchronously, meaning that the browser engine does not wait for the response from the server. Note that AJAX by design has a same-domain policy, which means that you can only send an XMLHttpRequest to the same domain that the JavaScript code is called from. API Application Programming Interface. An API is composed of the set of functions exported by a library, meant to be called by applications using that library. Client A computer or browser that requests objects from another computer (the server) over the Internet. CSRF Cross-Site Request Forgery, a type of security vulnerability that is exploited when a malicious web site causes a user s browser to perform an unwanted action on a trusted web site. CSS Cascading Style Sheets. It is a language that specifies the presentation of items. Framework A basic conceptual structure used to solve or address complex issues. The framework presented will abstract away the complex implementation details of writing web-based applications, allowing developers to quickly surmount formerly difficult problems. HTML Hypertext Markup Language. It is the primary language used for creating pages on the World Wide Web; other languages like CSS and JavaScript are meant to extend HTML. HTTP Hypertext Transfer Protocol. It is the primary protocol used for requesting web pages from a web server. JavaScript A scripting language that runs on the client. It is used to perform actions on the client and help perform requests to a server. JSON JavaScript Object Notation. It is a data format whose main goal is data interoperability. Modal Dialog A type of dialog that must be dismissed before that dialog s parent window can be interacted with again. Modern browser In this document, the phrase modern browser is used to describe web browsers that support JavaScript version 1.7 or higher and CSS version 2 or higher. This list includes Internet 1

5 Explorer from version 7 on, Firefox from version 2 on, Opera from version 9 on, Safari from version 3 on, and all versions of Google Chrome. Multi-threading The ability to run code with two paths of execution s instructions interlaced, rather than finishing one path before beginning the next sequentially. Mutex A form of execution control that prevents multiple simultaneous threads of execution over a section of code. Polling Requesting a status update. Since HTTP is a pull protocol, the applications will need to request status updates from the server by polling; the server cannot push those status updates. Polling interval The rate at which polling is done. A shorter polling interval means more poll requests per unit time, resulting in greater responsiveness for the application but more strain for the server. POSIX The Portable Operating System Interface. This is the common name for the collection of standards falling under IEEE 1003, which specify the operating system API and interfaces for what are loosely called the UNIX-like Operating Systems. Pull protocol A protocol in which the client-server query is initiated by the client. Push protocol A protocol in which the client-server query is initiated by the server. Round Trip Time A quantifier of network reliability. It measures the average time from the sending of the request to the server until a response from the server is received. Round Trip Timeout A quantifier of network reliability. It is the statistical maximum amount of time a request should take before it is considered to be a timeout. It is calculated from the Round Trip Time plus four standard deviations. Scaffold A programming framework that runs alongside application code to assist the developer by providing functionality. Server A computer or computing system that provides services across a network. SGML Standardized Generalized Markup Language, a metalanguage in which one can develop markup languages. XML, HTML, and XHTML are examples of markup languages that are defined by SGML. State Persistent information stored across a network connection. HTTP is a stateless protocol, meaning that no persistent information is maintained between multiple requests by a user. This poses a design problem for AJAX developers, who need stateful connections. Unit Test Unit tests are highly granular tests that attempt to test all possible paths through a software system and observe that the expected behavior occurs for each case. UNIX A multi-user operating system initially developed by AT&T Bell labs, upon which many of the POSIX standards are based. UNIX-like Unix-like operating systems conform to the POSIX specifications. URL Uniform Resource Locators. These are the addresses by which web pages are located. W3C The World Wide Web Consortium is the international standards organization that governs the standards used on the World Wide Web. W3C compliance means that an application complies to all relevant W3C standards. XHTML Extensible Hypertext Markup Language. XHTML is simply HTML that is written to be XML compliant. XML Extensible Markup Language, a strict subset of SGML meant to be easily machine parsed, human readable, and unambiguous. XSS Cross-Site Scripting, a security vulnerability allowing code injection using a specially formatted URL. 2

6 2 Modules 2.1 Introduction This section describes the modules to be integrated in the B.E.E.F.E.A.T.E.R. project. 2.2 Project Structure The development scaffold exists on the client and server, separated by an HTTP connection. Both the client and server portions of the software are divided into layers. Together, the client and server layers form the scaffold core. On the client side, the scaffold core is comprised of the messaging layer, which reads and writes protocol messages, and the connection management layer, which controls access to and actions upon the HTTP client/server connection. On the server side, the scaffold core is comprised of the messaging layer, which complements the clientside messaging layer, and the authentication / session layer, which verifies and attaches state to incoming HTTP requests. In addition to the scaffold core layers, a development library exists on the client-side of the application, providing extensions to the JavaScript language capabilities. Because our project forms a development scaffold, each individual module operates independently and can be combined in different ways as needed by the applications created with the scaffold. Therefore, our integration testing needs to show that each module can be combined with different combinations of other modules. 3 Assumptions and Exclusions 3.1 Introduction This section describes the assumptions and exclusions present in the integration test procedure. 3.2 Assumptions Each module is assumed to have passed unit tests displaying that its internal logic is working correctly. Integration testing will only test the interaction between modules and will not test the inner workings of each module. 3.3 Exclusions Since the number of ways that modules can be combined is too large to test exhaustively, we will test a carefully selected subset of combinations to build assurance that the modules interact correctly. 3

7 4 Testing Procedure 4.1 Introduction As part of our project, we are creating several demo applications that demonstrate diverse uses of our development scaffold. These demo applications are specifically chosen because they demonstrate different ways to combine the various features of our framework. As a result, these applications provide an implicit integration test of the framework, as each combines a different subset of our scaffold s modules and allows them to work together to accomplish a set task. Thus, our scaffold s modules successfully integrate when our demo applications work correctly and can utilize their selected subset of modules together. 4.2 Entry Criteria Integration testing may begin when: all modules have successfully undergone unit testing the sample integration applications have been completed consent of the project leader and test leader is obtained 4.3 Exit Criteria Integration testing ends successfully when: no defects or deficiencies are observed after all testing is completed Integration testing ends unsuccessfully when: a defect or deficiency is observed during testing the testing team must end testing before all tests can be completed 5 Participants 5.1 Introduction This section describes the roles and responsibilities of team members during integration testing. 5.2 Roles and Responsibilities For the integration tests, the following roles will be assumed by B.E.E.F.E.A.T.E.R. team members: Project Lead Matthew Wozniski Test Lead Nick Canzoneri Testers Adam Hamilton, Nick Wolfgang, Georgi Simeonov 5.3 Reporting If any defects are discovered during integration testing, they must be reported to the Test Lead, who will report the problem to the Project Lead to be addressed during the next meeting. 4

8 6 References 1. Nick Canzoneri, Adam Hamilton, Georgi Simeonov, Nick Wolfgang, Matthew Wozniski. Requirements Document for Team B.E.E.F.E.A.T.E.R., Nick Canzoneri, Adam Hamilton, Georgi Simeonov, Nick Wolfgang, Matthew Wozniski. Design Document for Team B.E.E.F.E.A.T.E.R.,

Requirements Document

Requirements Document Team B.E.E.F.E.A.T.E.R. Nick Canzoneri Adam Hamilton Georgi Simeonov Nick Wolfgang Matt Wozniski Date: May 1, 2009 Date Description Revision November 25, 2008 Initial version 1 February