7.4. Breaking the Application
When testing ASP.NET web applications there are various common test cases you can attempt to ensure you haven't missed anything obvious. Based on these tips and together with the advice provided previously you should have a good initial base to start manually testing your application.
7.4.1. Session Timeouts
As discussed in the "Usability" section, session timeouts are a great way to test applications to see what breaks. The problem arises when, as the name implies, the session state has timeout. This occurs when a user has left a browser window open for a period of time. When they return they navigate to a section of the site which attempts to read the session information and fails because it has unexpectedly been recycled. One way to test this would be to leave a browser window open for 20 minutes until the timeout occurred. This would be a very lengthy process. A more productive approach is to override the default timeout for the test site. This is set in the web.config of the site. If you set the timeout to 1, then you will only have to wait one minute before navigating to see the effects:
<configuration> <sessionstate timeout="1" /> </configuration>
Remember to make sure that this setting is not deployed into production. Another way to identify potential problems is to code-review the pages to see which ones deal with the session. If the page doesn't deal with any session state, then there is not much point in testing it.
Another way is to force Internet Information Service (IIS) to restart the application pool. IIS is the web server used to host ASP.NET applications. There are two ways to restart the server: one is by simply stopping and starting the server which affects all sites hosted on that server. The other approach is to restart the application pool associated with the site you're testing. IIS automatically restarts the application pools after 1,740 minutes (29 hours) to help the server recover from memory leaks and other resources. By forcing a restart you can see how the application behaves in this situation and make sure that no undesired effects occur. Application pools can be restarted from within the IIS Manager.
7.4.2. External Services
Stopping external services is an excellent way to test how applications behave in certain situations. External systems include both third party APIs such as Flickr or PayPal but could also include your own services such as a database server. Although you would hope these external systems had 100 percent uptime, sadly this is not the case, and you need to test to see how the application copes when these services are not accessible. There are a couple of items to look out for. The most obvious problem is if the application causes an error message to be returned to the user which we have covered earlier in this chapter and will do again in Chapter 10 about security. You need to make sure the error message is shown in the correct fashion and provides the user with information about what occurred. There are other issues with not being able to access external systems. When attempting to access a database often there is a timeout on the connection during which the application expects the server to respond. The problem is that it can lead to the application waiting for a period of time waiting for the database to respond. During this time, the user will have no information about what is happening and most likely just see a blank page. Ideally, you want the connection attempt to die quickly, or at least have a process page returned to the user. This will provide the user with feedback about what is happening and therefore improve the experience.
However, during testing we might not have control over external services to stop and test the reaction of the service going down on the website. Luckily there are a number of different approaches you can take to get around this issue. The easiest solution is to have the URL in the web.config and change this to simulate it being inaccessible. You could also edit your Hosts file (C:WindowsSystem32driversetchosts) and add an entry for the domain to a nonexistence host IP. From the viewpoint of the application, the site will be down. As you may remember from Chapter 4, you can also create service stubs. These stubs replicate the real system; however, they allow you to control how they behave. In Chapter 4 we simply stubbed the email service for the site to make it easier to test. Yet, you can take the approach and simulate error conditions and failures as you would if you injected the stub into the system itself. This has the advantage that you can perform end-to-end testing while being in control of the external systems. It also means you don't need to physically cause the problem to occur; you just need to know how to simulate it.
To be able to do this, you need to create a stub application to be able to read and respond correctly. Depending on how large your application is will determine if this is worth the effort. However, if you go to the effort of creating a stub, then you have the advantage of reusing it to perform testing beyond just the server being inaccessible. For example, you could return different error messages and verify that the application performed as you expected. A second advantage is being able to simulate high-load on the service and slow down the response time to understand how your application would cope as a result.
A similar approach to stubbing services is fault injection. The board term is often used with mocks and stubs to simulate how the system behaves. A less common approach is to inject faults into live running applications by modifying the code being executed. There are a number of research projects floating around which has been described at http://blog.benhall.me.uk/2008/11/net-fault-injection-very-early-proof-of.html and http://blog.benhall.me.uk/2008/11/net-fault-injection-its-not-just-about.html. Modifying the executing code to simulate failures has the advantage of stub objects without the effort of actually creating the stubs.
7.4.3. Network Testing
Along with testing the actual service, you should consider the communication between the website and the actual service if they are located on different machines. The two main concerns are latency on the network and the network fault rate. Both can cause problems when trying to access the site which can affect the end-user. To test how your site behaves based on different network conditions, you can use network simulators which allow you to adjust the bandwidth, packet loss, and latency. However, in our experience, testing the network is more of an edge case and is tested only if you are concerned about the network you're relying on.
7.4.4. Edge Cases
Manual testing is a great time to test edge cases around your site. Edge cases are test cases based around how the user might use the site beyond the standard and desired use case. The most common edge cases are around the different types of user input. As we previously discussed, user input is part of exploratory testing and so it is an important part of verifying if the application can cope with how users might use it. Although random input could work, it is much better to use targeted results. For example, in any field that expects a certain format, such as a date, you should attempt to input the date in a different format or enter solely letters to see how the application behaves.
More targeted user inputs are the boundaries of possible inputs. For example, given an input expecting a date, what happens if you enter 01/01/0001, 12/31/9999? What happens if you try −01/00-9999? There are huge amounts of possible inputs and as a result you shouldn't try all of them. Instead, you should pick targeted results based on inputs you think will cause different results. For example, all three previous cases could cause an application to fail in different ways. Identifying these test cases requires experience, understanding your application, and what could potentially break it. You should start exploratory testing and see what breaks.
When it comes to text there are two main test cases. First, you should attempt Unicode characters to ensure that your data store can structure it correctly. This includes foreign languages and characters to ensure that you support localization. The second main case is the amount of data. Given a single-line textbox, how much text is it possible to enter? Given a multi-line textbox, how many lines could you enter? Could you enter this entire book? These types of questions are what you should be asking when given a textbox. The aim is to see how the application copes with the most random input you could possibly think of. This is exploratory testing.
Microsoft research is currently creating a product called Pex (http://research.microsoft.com/pex). Pex is an automated white box testing tool for.NET. It finds input values for test cases in an attempt for 100 percent test coverage, finding edge cases for you. This can be a useful tool to use on your code-base to find any potential problems.
Another interesting ASP.NET input is to use <s. ASP.NET includes a by-default option called ValidateRequest. The aim of this feature is to protect against cross site scripting (XSS) attacks, discussed more in Chapter 10. How it works is by parsing input on a request, and when it encounters unencoded HTML Markup it will throw an exception. In reality, you can simply enter <s for the exception to occur. As a tester, you want to ensure a nice error message is returned to the user instead of the default ASP.NET message. ASP.NET can also throw error messages as you're navigating around the site. If you attempt to access a page which does not exist, then a 404 error will happen, and as a result an exception is raised. You should test to ensure that correct error pages are returned when you cause these errors to occur. ASP.NET has the concept of custom error pages, allowing you to specify different pages based on the error encountered. As a result, this should be tested.
Finally, there are issues where browsers have worked fine when the user has just had a single window open, however the application was confused when the browser visited the site on the same machine at the same time but from different browsers. These kinds of issues are what you are looking for during exploratory testing.
7.4.5. Authentication
Depending on how your application is structured, authentication could be a particularly important area or non-existent. Although you need to test authentication in terms of security, which will be discussed in Chapter 10, you also need to test to ensure that the authentication is transparent and doesn't affect the structure of the application. By this we mean that parts of the UI shouldn't have large empty gaps, and links such as edit or delete should not appear if the user is not authenticated to access them. Users should be unaware they are running as an account with less access than others, unless of course this is a marketing ploy in an attempt to get people to sign up or upgrade.