Table of Contents Executive Summary 2
Download 471.88 Kb.
|
- Navigate this page:
- 4.2.2 Coach Application
- 4.2.3 Fan Application
- 4.2.4 Database
4.2 Testing Strategy4.2.1 Umpire Indicator:When designing the Umpire Indicator for this project the group found that certain systems of its design could be tested independently of the whole device. These parts that can be tested alone will be the first ones to test. The first part that can be tested in this manner is the 7-segment displays. From the display drivers the group will test each screen for the needed digits on that screen. Upon seeing all the appropriate digits on the three different screens with no flickering or fluctuation of brightness the screen assemblies will be deemed working and fully functional. The next part that can be tested independently is the microcontroller. The microcontroller after being fully programmed will be tested to see if the program properly changes the necessary outputs when certain actions have been triggered. After the program has been deemed stable on the microcontroller the pushbuttons and screens along with the LEDs can be added to the microcontroller. The green LED should light upon powering on the microcontroller, if this happens then testing is complete for the power LED. To test the ball, strike and out process the proper cycles need to be seen on the displays. The number of balls needs to progress as expected from “0” to “1” and so on to “4”. Upon seeing four the device should wait for the umpire to press the next batter button. All of the screen segments should behave in such a fashion. Strikes will progress from “0” to “3” and outs will progress also from “0” to “3”. Both of these after hitting three will wait for the umpire to hit the next batter button. After each press of the balls, strikes and outs buttons the tester will look for accidental hops of numbers from the bouncing of a switch. If the numbers appear stable and progress in the expected manner the buttons will be considered fully functional. The next thing to test is the reset and next batter buttons. With information stored as far as balls, strikes and outs in the device the reset button can be pressed to test it. The device should clear all of the displays and ready the device for further ball, strike and out inputs. After this process is deemed working the next batter button can be tested. The next batter button as explained earlier in this paper lets the device know that a new batter has come up to bat and that the device needs to be reset. With numbers of balls, strikes and outs stored in the device the next button needs to be pressed and test to see if the device attempts to send the appropriate data to the database even though wireless is not hooked up yet. The next step of the next batter process is to clear the numbers displayed on the device. After this has been properly seen on the device the next batter button can be deemed working. The last and potentially most tedious aspect to test in this design is the Bluetooth chip. The mode that the group is using the LinkMatik 2.0 in for this project is not a standard mode for this chip. The Bluetooth module will have to be programmed using a USB to TTL controller like the one from sparkfunelectronics.com part number DEV-09717 for $17.95. This cord will allow the group to HyperTerminal from a windows machine through a serial port to the device and instruct it to get into the needed modes for the design of this project. After it has been installed on the PCB the device needs to be tested to see that it is attempting to send the appropriate data. After every increment of the balls, strikes and outs screens by the pushbuttons the device should update the database with the new information just logged on the device. That registry call should be seen logged in the transmit pin on the Bluetooth device. After each of the balls, strike and outs are tested that the increment is properly transmitted from the LinkMatik 2.0 the special function buttons can be tested for their respected transmissions. The reset button should not send any response when pressed to the LinkMatik. If only the values on the device reset then the reset button function can be deemed fully functional. The last step to test with the LinkMatik is to see if when the next batter button is pressed that the current values of the ball, strike and out counts are sent to the LinkMatik transmit pin and then that the ball and strike count is reset while the out count stays the same. Also several special commands should be sent to the transmit pin on the LinkMatik when the next batter button is pressed. The next batter command needs to be sent to the LinkMatik output pin for the database to see. The last thing to test on the device by itself is the low battery indicator. If the red LED lights upon seeing a low voltage then the low battery circuit is fully functional. The hardest part of the testing procedure is the testing of the handheld umpire indicator to both of the coaching tablets. All of the ball, out and strike count increments need to be seen by both devices. These counts need to be continually updated by the umpire indicator until the next increment or special function is triggered on the umpire device. The next tested step is to test the next batter button. This button upon being pressed should not only send the ending ball and strike count for that batter but also signify to the coaching tablets that a new batter is up. This information can all then be uploaded to the database from the coaching tablets. 4.2.2 Coach Application:At any point in the coding process, a portion of code can be tested in eclipse simply by using either the run or debug command. Running these commands will either launch the Android software emulator that was included with the Android Development Kit or if you have a physical device connected, it will attempt to run the code on the connected device. Although the run command will launch any code onto the device, it will not give any information as to any errors or exceptions that occur within the running of the code. For that reason, any questionable code will be run through the debug command, which allows for the inclusion of breakpoints, and the ability to step through code line by line to determine with high precision where exactly a portion of code may be failing. Even with the exclusion of breakpoints while debugging, the logcat can be checked through the debug interface. The logcat displays detailed information, as shown in 4.2.2 Figure 1 below, of all the processes and inputs into a physical device. Any exception or error encountered will print a stack trace to the logcat to provide in depth information on what type of problem occurred and where exactly within the code it occurred at. 
4.2.2 Figure 1: The logcat showing a description of what is currently running on an android handset. All of the user interfaces can be tested easily without the inclusion of any of the other portions of the system. However, only the portions that are not generated programmatically at run time can be tested simply by looking at the XML file’s projected layout (which is also provided by the ADT plugin for Eclipse). Since most of the lists and views are created programmatically within the body of the code, only the frameworks can be seen in the above method. To extensively test whether or not the programmatically generated lists are correct, one of two courses of action can be taken. Either a roster an lineup can be created once the two portions of code that generate them have been proven working, or sample roster and lineup files can be loaded into the device to see if they load correctly and are displayed correctly from those files. Beyond the initial UI and pre-game functions, both the online database and umpire indicator must be proven working before the interactions between them can be tested from the coach application, otherwise there would be no indication as to what a failure in communication could be attributed to. Once the other two portions have been determined working their interaction can be tested as follows. To ensure that the umpire indicator and the coach application are interacting correctly, a new game should be started within the In-Game Manager interface. In order for this to occur, the two devices must first be paired via a Bluetooth connection. Once connected and the game has begun, the umpire device should just cycle through its possible inputs and ensure that the changes are being made in the on screen scoreboard. I.e. an increment in strikes on the umpire device instigates an increment in strikes on the coach application’s field view. Additionally, it should be tested where the umpire device cycles from 2 outs back to 0, which is the indication in the change of a half-inning. When this input occurs on the umpire indicator, the coach application should similarly switch between the at-bat and fielding interfaces of the In-Game Manager as shown in section 3.3.1 user Interface. Testing the interactions with the online database will be a bit more extensive than with the umpire indicator, the application will need to test that both the uploading of information and the downloading of information between the two is functioning correctly. The easier way check that plays are properly being uploaded to the data base is to begin a new game in the In-Game Manger interface and begin entering in plays at random (assumes that the umpire indicator is functioning as intended). A group member will be logged into the database monitoring anything that has most recently been uploaded. If the plays populating the database (if any) match what was input by the user on the coaching tablet, then the two systems can be assumed to be interacting correctly. To test that the coach application is properly pulling information on the database, a sample dataset must first be uploaded as described in section 4.2.3 Database. This sample data should be loaded into all of the sections of the coach up which external data is used: the Detailed Player View, the Post-Game Player Search, and the two Post-Game Team info tabs. If the data being shown on the coach application matches that of the predetermined data set, then it can be assumed that the data is being loaded from the database correctly. 4.2.3 Fan ApplicationTesting of the fan application will be done on as many separate phones running the most recent android OS as possible. This will be done to insure that the app runs on as many phones without issues as possible. Testing will be done on the menus, connectivity to the database, user friendliness, and general GUI effectiveness. On all pages, the league, current game, and player buttons should bring the user to their respective pages and show the last game, player and their selected league’s page. From the top menu, the three buttons; find a game, find a team, and find a player should bring the user to their respective pages; the current games screen, the team search screen, and the player search screen. The current games screen should obtain the current and recent games data from the database and display them to the user. The user should then be able to scroll through the games and select one, taking them to that games screen. The team search page should allow the user to search a team, making a call to the database to display possible matches. It should also display the team’s record and allow the user to scroll through and select one to take them to that team’s page. The player search page should work just like the team search page. The search function will be tested to display the possible matches for that player and allow the user to scroll through and select a player, taking them to that player’s page. The game screen should display both teams and the score board for the game. It should show a list of plays and update regularly with score, balls, strikes, outs, and plays. Clicking on a play should take the user to the play screen which should display detailed information on that play and allow the user to jump to other pages such as player and team pages. The team page should also allow the user to select a team to go to their team page. The team page should show the team name, league, coach, record and their logo. It should also display a list of the games they’ve played and games they’re going to play. There should also be a list of the players on the team. The user should be able to select a game or player and it should take them to their respective game or player page. The player page should show the players name, age, team, position, stats and picture. The user should be able to click the team to bring them to the team’s page. The last page to test is the league page. This page should allow the user to select from a drop down menu the league they are looking for and display the teams in that league with their record. The user should also be able to select a team and have them taken to the team’s page. Testing should be conducted to insure all links go to their corresponding page, the app is fast and displays the correct data, and has no graphical hiccups like drawing images over things.
Once the device applications can effectively communicate with the database server, the next step is to test baseball-related data and requirements. 4.2.4 Figure 2 traces the access route for the process of adding new records to the database, as well as updating variable-dependant statistics, such as batting averages. This procedure also includes things like player profile updates, creating/deleting players, and other statistic calculations. These types of functionalities are server-side dependant; they must be executed and managed by the database system. The following testing phase includes additional security features which dictate how spectators and coaches will interact with the database. 4.2.4 Figure 3 demonstrates the unique identifier differences between the coach and fan applications. Implementing a device-side identifier within the application will allow the database to easily differentiate between client types. From there, limiting each identifier to certain value types (specifically, disallowing spectators from writing values) requires basic identifier matching. Testing these features involves simulating some spectator and coach identifiers, and observing the database’s response to each client. 
4.2.4 Figure 2: Addition and Modification of Tables and Variables 
4.2.4 Figure 3: Database Privilege Testing Since the database is required to automatically manage backups for individual game data, as well as general purpose redundancy backups (to prevent data loss), the automated backup function must be tested to ensure it operates in the indicated ways. 4.2.4 Figure 4 outlines the response to a new game request, indicating how the data backups should occur. The database must detect when a new game has started, and backup (export data) the previous game data before overwriting the active game data. This can be tested by imitating the start of a new game to the database and observing the results. 
4.2.4 Figure 4: Database Export Testing Directory: seniordesign -> fa2010sp2011 seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr seniordesign -> Group 5 Spr-Sum 2011 seniordesign -> Senior Design II paper seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11 seniordesign -> Flight Performance Data Logging System seniordesign -> Amphibious vehicle seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle) seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler Download 471.88 Kb. Share with your friends:
|
