DOC PREVIEW
UConn CSE 4904 - My Beats Implementation and Test Plans

This preview shows page 1-2-3-4-5 out of 16 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

My BeatsImplementation and Test PlansCSE 4904: Design LabMilestone IIIReport by Dylan Barrett1Table of ContentsObjectives ------------------------------------------------------- 3Background Information -------------------------------------- 4Project Structure Overview ----------------------------------- 5MyBeats Module ----------------------------------------------- 6Implementation --------------------------------------------- 6Testing ------------------------------------------------------- 6AnalyzeInteraction Module ----------------------------------- 7Implementation --------------------------------------------- 7Testing ------------------------------------------------------- 7TrackGenerator Module ---------------------------------------- 8Implementation --------------------------------------------- 8Testing ------------------------------------------------------- 8MidiGenerator Module ----------------------------------------- 9Implementation ---------------------------------------------- 9Testing -------------------------------------------------------- 9OggGenerator Module ------------------------------------------ 10Implementation ---------------------------------------------- 10Testing -------------------------------------------------------- 10DataStructures Module ----------------------------------------- 11Implementation --------------------------------------------- 11Testing ------------------------------------------------------- 11Schedules --------------------------------------------------------- 12Responsibilities -------------------------------------------------- 12Tools -------------------------------------------------------------- 12Appendix A: File Formats ------------------------------------- 14References -------------------------------------------------------- 162ObjectivesThe objective of this Implementation and Test Plan is to describe how the project as specified in the Specification Document is to be implemented in code as well as how the code is to be tested. While the project's Specification document detailed the requirements of the final product, this document will provide the concrete design and implementation information that lays out how the final product will be achieved. More specifically, this document will describe the breakdown of the project into discrete modules, how each of these modules will be tested separately, and also a little about how the modules will be tested once integrated. The following phases of testing will occur: Unit Testing Integration Testing Systems Testing Beta TestingUnit Testing will be done on each of the individual modules. It tests each module to ensure that it works as expected when provided sample input. Once the sample input is provided to the module, the output's module can be compared to the expected output. This phase of testing will help ensure that most of the problems are caught early, when the complexity of the code is not too great. Additionally, the tests created for Unit Testing can be saved as a test suite and can be rerun continuously throughout the development cycle. This will result in bugs created by new or changing code to be caught immediately and also pinpoint exactly where the problem occurs. Ideally, the Unit Tests should be created before the implementation coding of the module begins. Because of time constraints, though, the implementation and Unit Testing will likely occur simultaneously.Once each of the modules implementation has been completed and passed all Unit Tests it will be time to begin integration. During the process of integration each of the modules will be put together to make a complete product. It is at this time that Integration Testing will occur. The purpose of Integration Testing is to ensure that all of the modules perform as expected when interacting with other modules. Specifically, the focus will be put on the interfaces each module abides to. This helps to catch problems that can occur when the output of one module becomes the input of another.Once the integration tested has completed, Systems Testing can begin. This is the phase of testing 3that is the most tied to the Specification Document that was created earlier. Now that the product has been integrated and seems to be working properly it is important to go back and check that each of the project's requirements are satisfied. This is an important stage of testing because no matter how well a piece of software seems to be working, if it does not do exactly what it has been specified to do, then it is incorrect. This phase can be completed by simply making a checklist of each of the requirements from the specification. Next, each of the requirements is looked at and if the software correctly implements that requirement then the corresponding check box can be checked.Finally, now that the product has completed coding and testing it can enter the Beta Testing phase. Beta Testing is the phase where the product is released to a small group of people who are not involved with the creation of the product. These people then use the product and report back any problems or feedback that they have to the development team. For this project, the Beta Testing phase will have two purposes. First, because the nature of this project includes a set of heuristics that will have to be constantly adjusted, the Beta Testing will allow end users to give feedback about the performance of the product. This feedback can then be used in the tweaking of the set of heuristics until they reach an acceptable level. Another benefit of Beta Testing is that any bugs that were not caught in previous phases may be caught. This is because the people testing the product will be looking at it with fresh eyes. The developers are often so closely tied to the code that they will not be able to find simple bugs that an end user can find pretty quickly. After this final phase of testing, the product should be ready for a final release.Background InformationThe purpose of this section of the document is to summarize the background information of the project. My Beats is a product that will be able to dynamically generate game tracks which can played on games similar to the popular game Guitar Hero1. In these games, players can “play along” on instrument-like controllers to a song the is played within the game. The game displays a set of “buttons” on the


View Full Document

UConn CSE 4904 - My Beats Implementation and Test Plans

Download My Beats Implementation and Test Plans
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view My Beats Implementation and Test Plans and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view My Beats Implementation and Test Plans 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?