Testing the .NET upgraded application is arguably the most important part of the conversion process -and of any software development project as well-, which is why you need to design an adequate test strategy depending on the characteristics of the migrated application and the experience of your testing team. This final chapter provides up-to-date information on the main application test methodologies, the VB.NET testing tools available and the upgrade code review process; having a clear understanding of these matters will make testing more efficient and increase the accuracy of the results.
Depending on their level of experience in testing migrated applications, testers can take two approaches. The first approach requires relatively more experience and less test effort than the second option.
In the first approach, it is assumed that the code automatically upgraded by the upgrade wizard works properly except in places where errors, warnings, and issues (EWIs) are present. In this approach, the test effort is focused on testing the fixes for the EWIs. However, even when EWIs are fixed, there can be functional holes whose pattern can be very different from those present in a normal development project. A tester who has considerable experience in testing upgraded applications can identify the functional holes by reviewing the code and the design of the application.
In the second approach, a more traditional test strategy and test process is followed, although this will likely require more test effort than the first approach. This approach is recommended for testers with limited experience testing upgrade projects.
Because you have to ensure that the upgraded application meets the upgrade objectives. If the upgrade objective is only to achieve functional equivalence, the test objective would be to test for functional equivalence. However, if the application is upgraded for performance and/or security enhancement, testing must include performance and security. Furthermore, if the application is being advanced beyond functional equivalence with new features, the test effort must include functional, performance, and security testing of these new features.
Regardless of the test or upgrade strategies used, the testing process includes a basic set of steps that are to be followed:
Because it documents the test cases that will be used to test the upgraded application. It also helps in planning and estimating the actual test effort that is required to prepare the test code and to execute the tests. Finally, the test plan helps in tracking the tests and their results, especially when there are multiple iterations or changes in specifications.
The methodology for creating test cases depends on the type of testing that will be performed. Test cases for design review, white box testing, and code review are prepared by reviewing the source code. Test cases for black box testing are prepared based on the use cases and the functional requirements. In the case of the upgrade project, if test cases are already available for the Visual Basic 6.0 version of the application, these test cases can be upgraded for the Visual Basic .NET version.
Not precisely. This step should be carried out only if design optimization is an upgrade objective or if the application is being upgraded to take advantage of features that are specific to the Microsoft .NET Framework, such as performance or security enhancements.
Review of the upgraded code includes, but is not limited to:
Unit testing involves testing a single component. The components of the upgraded application are unit tested to detect failure scenarios in loops, conditional constructs, and internal subroutines. Unit testing also focuses on testing if upgrade EWIs have been properly fixed without affecting functionality or introducing new defects. Unit testing is also performed to make sure that the behavior of a method in an upgraded component is the same as that of the corresponding method in the original Visual Basic 6.0 version of the component.
Along with profiling, unit testing is part of what is called “white box testing”.
In black box testing, the implementation details of the component or application to be tested are unknown. Black box testing simulates the end-user/client experience and tests the response of the upgraded applications to end-user or client actions. The objectives of black box testing are:
Profiling is the process of gathering statistical information about an application during run time, such as the time and resource usage of an application and the execution tree exercised. This information can be analyzed for different purposes, such as identifying components that can be optimized to improve speed or resource use.
There are three main strategies based on testing practices followed in different software development methodologies. The test process is fairly consistent across the different strategies, but the test planning and the test effort varies for these strategies, which are:
The current version of Visual Studio .NET does not provide tools specifically for automating the testing of Visual Basic .NET applications. However, other tools do exist for automating tests, for example:
NUnit: A popular tool that provides a unit-testing framework that can be applied to any .NET Framework language, including Visual Basic .NET.
FxCop: The FxCop tool is used to automate code review. It analyzes the application binaries to determine whether the implementation adheres to the predefined rules. These rules are customizable and can be extended
Application Center Test (ACT): Application Center Test is a performance testing tool. It is designed to stress Web servers and to test the performance of ASP.NET applications.
Visual Studio Analyzer: It is a performance analysis tool that is used to analyze and debug distributed applications. This tool analyzes components at a high level and presents information that can be used to identify the components that fail in a distributed environment.
Trace and Debug Classes: The .NET Framework comes with a pair of classes that can be used to print useful debugging messages during execution to allow you to see the flow of your application and to help you spot unusual behavior. These classes are Debug and Trace and both are defined in the System.Diagnostics namespace. Both classes are very similar and contain static methods to print arbitrary text messages, print messages only when tested expressions evaluate to true, pause and ask the user what to do when certain conditions do not evaluate to true, and format the text messages using simple indentation commands.
TraceContext Class: The TraceContext class provides functionality similar to the Trace and Debug classes, but it provides this functionality for ASP.NET applications. This class contains fewer methods but allows you to add conditional text to your HTML pages that are generated by ASP.NET and formats them for viewing in your browser. The page also automatically includes information that is related to your request and that can help debug problems in your Web applications.
CLR Profiler: CLR Profiler is a tool used for profiling memory utilization by an application. CLR Profiler profiles the interaction between the managed applications, the managed heap, and the garbage collector. CLR Profiler is used to identify memory leaks.
Enterprise Instrumentation Framework (EIF): EIF is used to instrument a .NET application so that it can be profiled and traced. After it is profiled and traced, application metrics can be captured. EIF encapsulates the functionality of event logging, Event Tracing for Windows (ETW), and Windows Management Instrumentation (WMI).
Performance Counters: Windows monitors many different aspects of the .NET runtime and the rest of the operating system. You can even define your own performance counters and then monitor those counters from the Performance Monitoring tool (Perfmon.exe) or from within your own applications.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com
