Testing


The internal testing sets the foundation for the final test plan phase. The test plan is the measurement of a successful system. The test plan had been derived from the requirements, and for the system to be satisfactory, the test plan must be acceptable.

The Test Plan

TSC wanted to make sure the chat application was deemed acceptable in the developers' opinion before presenting the system to the client. The client expected that the system would pass the test plan defined after the requirements were finalized and signed. This test plan had six major testing objectives and consisted of 13 testing conditions.

The user-account administration portion of the system required the testing of five conditions:

  • The first three conditions related to the adding, editing, and deleting of a user account that uses the chat system. These criteria are easily quantified by confirming if the required action was successful on the data stored. The results of these actions can easily be determined by viewing the affected data.

  • The fourth condition was to disallow an unauthorized log-in attempt when logging in to the user-account UI. The result of this test is either a correct log-in or a rejection. The developers were satisfied and used an in-house hacking competition to see if the system could be compromised. The development environment on which the system was currently hosted was very secure, and the user-account-administration user interface appeared to be secure. It was, however, noted that the production system must also be on a secure environment that will complement the code that implements the security.

  • The final condition in the user-account-administration section of the test plan was the displaying of online users. This is managed by the Flash Communication Server (FCS) as well as a table within the database. The development team was also comfortable in knowing that both these system could determine, and display, the current users online.

The second major objective was logging in. This logging in had to be recorded in the database as well as the FCS. The test plan's condition was to return a session ID on a correct log-in. This condition had to be extended internally to verify that the data was entered into the database as well as that a shared object was created under the chat/general instance. TSC tries to extend the test plan to also test the coding requirements that exist when the test-plan condition is reached.

The third objective was the notification of the user that a chat invitation has been sent. This can be confirmed in the intended user's UI, and it's also recorded in the server-side shared object. The test plan requires that the user be notified, which was confirmed by the developer team.

The fourth objective was the response to the request. This condition can be viewed easily if it has been successful. The developers were confident that this condition would also pass the test.

The fifth objective had four conditions:

  • The first condition was viewing the chat dialog screen. This condition is verified by the ability to view the message history displayed within an area of the individual chat UI.

  • The second and third conditions of the chat process were sending and receiving messages. This condition(the receiving of messages) needed the preceding condition (the sending of messages) to be successful for this condition's success to be viewed.

  • The last condition was the termination of the chat session. This can be viewed as the closing of the UI as well as the removal of the shared object from the chat/individual instance.

Performance Testing

One of the most challenging aspects of the system was to seamlessly provide an efficient interaction between the chat center and individual chat. This was the role of the invitation. The individual-chat UI was constructed to stand alone as well as be part of this system. TSC concentrated on testing this aspect before continuing on to present the application to the client. The interaction of smaller components to produce a larger functional unit must be the focus of attention. This is where challenges may arise.

The system's performance was addressed, and the development team attempted to stress-test the application. A number of testing scripts were developed to put the server under load and determine the time it took for the data to respond to assorted server requests and responses. This testing is used to identify any bottlenecks due to poorly performing code or components. The getTickcount function was used to output data to a file using the<cffile> tag.

Once the code was tested, there were no optimization recommendations that would need to be implemented. There were considerations, but nothing that would have an affect on the system.

Hardware considerations were noted. It appeared that a dual processor delivered considerably greater message processing than a single-processor system. These results were identified when the server was under the stress of a large number of concurrent active chat sessions that were involved in a simulated dialog.

The findings of the performance testing were negligible at this time. However, effective testing and tuning needs to be performed in an environment that imitates the production environment as closely as possible. TSC has developed the application on its internal-development system. This is obviously different from the production environment on which it will be deployed.

Once the development team is satisfied with its testing, the system needs to be accepted by the end user. If there had been modifications, then TSC might have had to go back and redesign or re-implement the portions that were incorrect.

End-user acceptance is the final stage and most important aspect that can determine whether or not the project is a success. A system can be functionally perfect, but if the end user doesn't use the system, then it cannot be deemed a success. TSC realizes that solving a problem does not necessarily mean it is the right solution for the client.

Presenting the chat system and its deployment will be discussed in the next chapter.



Reality Macromedia ColdFusion MX. Macromedia Flash MX Integration
Reality Macromedia ColdFusion MX: Macromedia Flash MX Integration
ISBN: 0321125150
EAN: 2147483647
Year: 2002
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net