An important function of the business layer is to ensure that data you collect from users are valid. If your system operates with invalid information, such as erroneous credit card numbers or malformed addresses, then significant errors may occur. If you are unlucky, the errors could have financial implications to both you and your customers. You should test for data collection errors much like you search for user-input or parameter errors when testing stand-alone
applications. Refer to Chapter 5 for more information on designing tests of this nature.
Transactional Testing
Your e-commerce site must process transactions correctly 100 percent of the time. No
exceptions. Customers will not tolerate failed transactions. Besides a tarnished reputation and lost customers, you may also incur legal liabilities associated with failed transactions.
You can consider transactional testing as system testing of the business layer. In other words, you test the business layer from start to finish, trying to uncover errors. Once again, you should have a written document specifying exactly what constitutes a transaction. Does it include a user searching a site and filling a shopping cart, or does it only consist of processing the purchase?
For a typical Internet application, a transaction component is more than completing a financial transaction (such as processing credit cards). Typical events that a customer performs in a transaction include the following:
• Searching inventory
• Collecting items the user wants to purchase
• Purchasing items, which may involve calculating sales tax and shipping costs as well as processing financial transactions
• Notifying the user of the completed transaction, usually via e-mail
In addition to testing internal transaction processes, you must test the external services, such as credit card validation, banking, and address verification. You typically use third-party
components and well-defined interfaces to communicate with financial institutions when conducting financial transactions. Don’t assume these items work correctly. You must test and validate that you can communicate with the external services and that you receive correct data back from them.
Data Layer Testing
Once your site is up and running, the data you collect become very valuable. Credit card numbers, payment information, and user profiles are examples of the types of data you may collect while running your e-commerce site. Losing this information could prove disastrous and crippling to your business. Therefore, you should develop a set of procedures to protect your data storage systems.
Testing of the data layer consists primarily of testing the database management system that your application uses to store and retrieve information. Smaller sites may store data in text files, but larger, more complex sites use full-featured enterprise-level databases. Depending upon your needs, you may use both approaches.
One of the biggest challenges associated with testing this layer is duplicating the production environment. You must use equivalent hardware platforms and software versions to conduct valid tests. In addition, once you obtain the resources, both financial and labor, you must develop a methodology for keeping production and test environments synchronized.
As with the other tiers, you should search for errors in certain areas when testing the data layer. These include the following:
• Response time. Quantifying completion times for Data Manipulation Language (DML) (Structured Query Language [SQL] INSERTs, UPDATEs, and DELETEs),
queries(SELECTs), and transactions.
• Data integrity. Verifying that the data are stored correctly and accurately.
• Fault tolerance and recoverability. Maximize the MTBF and minimize the MTTR.
Response Time
Slow e-commerce applications cause unhappy customers. Thus, it is in your interest to ensure that your Website responds in a timely manner to user requests and actions. Response-time testing in this layer does not include timing page loads, but focuses on identifying database operations that do not meet performance objectives. When testing the data-tier response time, you want to ensure that individual database operations occur quickly so as not to bottleneck other operations.
However, before you can measure database operations, you should understand what constitutes one. For this discussion, a database operation involves inserting, deleting, updating, or querying
long each operation takes. You are not interested in measuring transactional times, as that may involve multiple database operations. Profiling transaction speeds occurs while testing the business layer.
Because you want to isolate problem database operations, you do not want to measure the speed of a complete transaction when testing data layer response times. Too many factors may skew the test results if you test the whole transaction. For example, if it takes a long time when users try to retrieve their profiles, you should determine where the bottleneck for that operation resides. Is it the SQL statement, Web server, or firewall? Testing the database operation independently allows you to identify the problem. With this example, if the SQL statement is poorly written, it will reveal itself when you test response time.
Data layer response-time testing is plagued with challenges. You must have a test environment that matches what you use in production; otherwise, you may get invalid test results. Also, you must have a thorough understanding of your database system to make certain that it is set up correctly and operating efficiently. You may find that a database operation is performing poorly because the RDBMS is configured incorrectly.
Generally speaking, though, you perform most response-time testing using black-box methods. All you are interested in is the elapsed time for a database transaction(s). Many tools exist to help with these efforts, or you may write your own.