The art of software testing. Myers (2nd edition) (2004) (The art of software testing. Myers (2nd edition) (2004).pdf), страница 36

Without written specifications or goals, you do notknow whether your application performs acceptably. Operationalspecifications are often stated in terms of response times or throughput rates. For instance, a page should load in x seconds, or the application server will complete y credit card transactions per minute.Testing Internet Applications207A common approach you may use when conducting performancetests is stress testing. Often, system performance degrades to thepoint of being unusable when the system becomes overloaded withrequests.

This might cause time-sensitive transactional componentsto fail. If you perform financial transactions, then component failures could cause you or your customer to lose money. The conceptson stress testing presented in Chapter 6 apply to testing businesslayer performance.As a quick review, stress testing involves blasting the applicationwith multiple logins and simulating transactions to the point of failure so you can determine whether your application meets its performance objectives. Of course, you need to model a typical uservisit for valid results.

Just loading the homepage does not equate tothe overhead of filling a shopping cart and processing a transaction.You should fully tax the system to uncover processing errors.Stress-testing the application also allows you to investigate therobustness and scalability of your network infrastructure. You maythink that your application has bottlenecks that allow only x transactions per second.

But further investigation shows that a misconfigured router, server, or firewall is throttling bandwidth. Therefore, youshould ensure that your supporting infrastructure components are inorder before beginning stress testing. Not doing so may lead to erroneous results.Data ValidationAn important function of the business layer is to ensure that data youcollect from users are valid.

If your system operates with invalidinformation, such as erroneous credit card numbers or malformedaddresses, then significant errors may occur. If you are unlucky, theerrors could have financial implications to both you and your customers. You should test for data collection errors much like yousearch for user-input or parameter errors when testing stand-aloneapplications. Refer to Chapter 5 for more information on designingtests of this nature.208The Art of Software TestingTransactional TestingYour e-commerce site must process transactions correctly 100 percent of the time.

No exceptions. Customers will not tolerate failedtransactions. Besides a tarnished reputation and lost customers, youmay 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 writtendocument specifying exactly what constitutes a transaction. Does itinclude a user searching a site and filling a shopping cart, or does itonly consist of processing the purchase?For a typical Internet application, a transaction component is morethan completing a financial transaction (such as processing credit cards).Typical events that a customer performs in a transaction include thefollowing:• Searching inventory• Collecting items the user wants to purchase• Purchasing items, which may involve calculating sales tax andshipping costs as well as processing financial transactions• Notifying the user of the completed transaction, usually viae-mailIn addition to testing internal transaction processes, you must testthe external services, such as credit card validation, banking, andaddress verification.

You typically use third-party components andwell-defined interfaces to communicate with financial institutionswhen conducting financial transactions. Don’t assume these itemswork correctly. You must test and validate that you can communicate with the external services and that you receive correct data backfrom them.Data Layer TestingOnce your site is up and running, the data you collect become veryvaluable. Credit card numbers, payment information, and user pro-Testing Internet Applications209files are examples of the types of data you may collect while runningyour e-commerce site. Losing this information could prove disastrousand crippling to your business. Therefore, you should develop a set ofprocedures to protect your data storage systems.Testing of the data layer consists primarily of testing the databasemanagement system that your application uses to store and retrieveinformation.

Smaller sites may store data in text files, but larger, morecomplex sites use full-featured enterprise-level databases. Dependingupon your needs, you may use both approaches.One of the biggest challenges associated with testing this layer isduplicating the production environment. You must use equivalenthardware platforms and software versions to conduct valid tests. Inaddition, once you obtain the resources, both financial and labor, youmust develop a methodology for keeping production and test environments synchronized.As with the other tiers, you should search for errors in certain areaswhen testing the data layer. These include the following:• Response time. Quantifying completion times for DataManipulation Language (DML) (Structured Query Language[SQL] INSERTs, UPDATEs, and DELETEs), queries(SELECTs), and transactions.• Data integrity.

Verifying that the data are stored correctly andaccurately.• Fault tolerance and recoverability. Maximize the MTBF andminimize the MTTR.Response TimeSlow e-commerce applications cause unhappy customers. Thus, it is inyour interest to ensure that your Website responds in a timely mannerto user requests and actions. Response-time testing in this layer doesnot include timing page loads, but focuses on identifying databaseoperations that do not meet performance objectives. When testing thedata-tier response time, you want to ensure that individual databaseoperations occur quickly so as not to bottleneck other operations.210The Art of Software TestingHowever, before you can measure database operations, you shouldunderstand what constitutes one.

For this discussion, a database operation involves inserting, deleting, updating, or querying of data from theRDBMS. Measuring the response time simply consists of determininghow long each operation takes. You are not interested in measuringtransactional 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 donot want to measure the speed of a complete transaction when testing data layer response times. Too many factors may skew the testresults if you test the whole transaction.

For example, if it takes a longtime when users try to retrieve their profiles, you should determinewhere 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, ifthe SQL statement is poorly written, it will reveal itself when you testresponse time.Data layer response-time testing is plagued with challenges.

Youmust have a test environment that matches what you use in production; otherwise, you may get invalid test results. Also, you must havea thorough understanding of your database system to make certainthat it is set up correctly and operating efficiently. You may find thata database operation is performing poorly because the RDBMS isconfigured incorrectly.Generally speaking, though, you perform most response-time testing using black-box methods. All you are interested in is the elapsedtime for a database transaction(s).

Many tools exist to help with theseefforts, or you may write your own.Data IntegrityData-integrity testing is the process of finding inaccurate data in yourdatabase tables. This test differs from data validation, which you conduct while testing the business layer. Data validation testing tries toTesting Internet Applications211find errors in data collection.

Data integrity testing strives to finderrors in how you store data.Many factors can affect how the database stores data. The datatypeand length can cause data truncation or loss of precision. For date andtime fields, time zone issues come into play. For instance, do youstore time based on the location of the client, the Web server, theapplication server, or the RDBMS? Internationalization and character sets can also affect data integrity.

For example, multibyte character sets can double the amount of storage required, plus they cancause queries to return padded data.You should also investigate the accuracy of the lookup/referencetables used by your application, such as sales tax, zip codes, and timezone information. Not only must you ensure that this information isaccurate, you must keep it up to date.Fault Tolerance and RecoverabilityIf your e-commerce site relies on an RDBMS, then the system muststay up and running. There is very little, if any, time available fordowntime in this scenario. Thus, you must test the fault toleranceand recoverability of your database system.One goal of database operations, in general, is to maximize MTBFand minimize MTTR.

You should find these values specified in thesystem requirements documentation for your e-commerce site. Yourgoal when testing the database system robustness is to try to exceedthese numbers.Maximizing MTBF depends on the fault-tolerance level of yourdatabase system. You might have a failover architecture that allowsactive transactions to switch to a new database when the primary system fails. In this case, your customers might experience a small service disruption, but the system should remain usable. Another scenariois that you build fault tolerance into your application so that a downeddatabase affects the system very little.