Tài liệu Testing and Debugging pdf

Testing and Debugging CERTIFICATION OBJECTIVES 7.01 Creating a Unit Test Plan 7.02 Implementing Tracing 7.03 Instrumenting and Debugging a Windows Service, a Serviced Component, a .NET R

Testing and Debugging

CERTIFICATION OBJECTIVES

7.01 Creating a Unit Test Plan 7.02 Implementing Tracing 7.03 Instrumenting and Debugging a

Windows Service, a Serviced Component, a NET Remoting Object, and an XML Web Service 7.04 Using Interactive Debugging 7.05 Logging Test Results

Q&A Self Test

In this chapter, you will learn about the testing process and specifically how unit testing fits

into the overall testing of the application You will also look at what tracing is and how you

can make use of it, as well as how you implement your remote components and retrieve

that information

Debugging and especially how you debug remote components interactively willalso be handled here Another interesting area you will look at is how you can useSOAP extensions to debug the components

CERTIFICATION OBJECTIVE 7.01

Creating a Test Plan on the Evolutionary Model

This section will deal with software testing and the unit test in particular Unittesting takes the smallest part of software practical and validates its function The

unit test must be planned and documented according to what is called the unit test

plan The software that usually is produced to perform the unit test is called the test harness—software that has stubs and functions that can call on and respond to any

functionality in the unit being tested

Software testing is a high-priority activity in the production of softwareapplications Among other things, the testing process

■ Measures the quality of the software The assumption is that there willalways be flaws in the software that are waiting to be discovered By testingand debugging prior to release, you can ensure that your software is regarded

as high-quality

■ Validates that the application behaves as the user expects it to The application

is tested to ensure that it behaves as described in the documentation, and as theusers expect the application to work

■ Reduces the cost of development Testing will reduce those costly last-minuteerrors that traditionally have delayed products and added to the cost The unittest methodology results in individual software components being tested andvalidated before they are assembled into increasingly more complex units

■ Reduces the cost of ownership by minimizing the cost of maintenance

Maintenance cost is determined on how much testing must be performed tovalidate the code after the maintenance Because the testing plans are alreadywritten the unit and integration tests are faster and more accurate

Creating a Test Plan on the Evolutionary Model 3

■ Replaces the traditional development and test planning process Thetraditional process follows the waterfall model, where one task flows into thenext in an ordered manner as in the following list:

■ Analyze requirements

■ Create designs and specifications

■ Create the code

■ Test

■ ReleaseWhen you reach the testing phase in this model, the application is already finished,and when problems are identified, there is a major issue: in order to make repairs, youmake changes, but those changes will modify the application, so you need to starttesting again This cycle of testing and modifications on the finished application can benever-ending The development cost also increases enormously—there are estimatesthat the cost can increase by 100 times when testing is delayed until the application isfinished

Unit testing becomes almost automatic because the methodology leads us to test as you go along, building test harnesses to validate your implementation.

The waterfall model matched the development model for most proceduralenvironments, but when you moved into object-oriented development, the developmentmodel changed to the evolutionary model, where testing is an ongoing process that isintegrated into the development process

The steps in the evolutionary model are to

1 Analyze requirements:

■ Discover classes

■ Develop classes

■ Test the classes

2 Repeat until the system is completeThe repetitious evolution of the application by building increasingly more complexparts of the application on already tested units makes it possible to arrive at the end ofthe development project with a fully tested application The additional payback is that

at the end when the complete application is assembled from all the units, there will not

be any devastating errors that require rewriting parts of the application

Expect questions that make you select between the waterfall model and the evolution model You can rest assured that the evolution model will be the right answer.

The evolution model uses the iterative steps from object-oriented analysis anddesign (OOAD) to continuously analyze the application and build fully testedparts of that application before moving on to the next cycle, which starts withanalysis again

The unit test becomes a central task in the development of the application Asyou move forward, you will have more and more fully tested units that can beassembled into larger units that are then tested, and so on until the application isfinished

Testing should be planned in a fashion similar to the main development effort

Planning for testing should be requirements based, drawing the test design from therequirements section of the software specification Testing generally identifies defects(bugs) that allow, create, or cause unexpected behaviors in terms of the requirements.The requirements for the software must be written in such a way that they can bedirectly translated into test documentation For example, requirements should be

■ Binding The customer demanded them

■ Testable If you can’t test the requirement, there is no way of provingcompliance

■ Clear They must be unambiguous and interpretable in only one way

Planning then proceeds by designing test cases that will validate each of therequirements The test plan will outline the entire process with the individual test casesincluded The development of a solid test plan is built on the systematic analysis of theapplication to make sure that everything is tested without repetitions The plan ensuresthat testing procedures are known and do not depend on accidental or random testing

One closely related task to testing is optimization The optimization task is the process

that removes bottlenecks (overuse of resources) in the software and hardware to producethe best combination that minimizes resource use After performing optimization, youmust perform the tests for each unit again to ensure that the optimization exercise didnot break the application

Testing

The testing exercise consists of three related tasks that together ensure the quality ofthe developed software They are

Creating a Test Plan on the Evolutionary Model 5

■ The unit test Testing the smallest possible software unit

■ The integration test Testing combinations of software units

■ The regression test Retesting after modifications to the software unitsThe exam focuses on the unit test, but to fully understand the testing methodology,you will cover the other two as well

Unit Testing

The goal of unit testing is to take the smallest possible testable software that is part of

the application, remove it from the remainder of the software, and test to ensure itbehaves as expected Unit testing is a natural fit with the OOAD methodology usedfor modern software design because it flows naturally from the unit-by-unit iterativedevelopment that you are used to from the OOP world

The testing process usually requires that you write a test harness that is used tocommunicate with the software unit The terminology used to describe this scenario

is that you will write a driver to simulate the caller and possibly a stub to simulate a

called unit The test harness becomes part of the applications code base and will beused for validation through the lifetime of the application

The cost in time that is involved in writing the test harness makes it tempting totry to test larger units rather than identifying and testing the smallest possible unit.The problem with testing larger units is that it increases the difficulty in identifyingwhere a problem is located If you have two software units and you decide to testthem together as one unit, you may face the following list of questions, which givesyou an idea of the complexity of finding a bug:

■ Is the error caused by a defect in the first unit?

■ Is the error caused by a defect in the second unit?

■ Is the error caused by a defect in the test harness?

■ Is the error caused by a defect in both the first and second units?

■ Is the error caused by a defect in the interface between the two units?

The complexity introduced makes it very hard to find the source of thedefect—this is one compelling reason for implementing unit testing

Always select the smallest possible unit for the test.

EXERCISE 7-3

Unit Testing

In this exercise, you will investigate writing a test harness For this example, youhave chosen a class as the unit you will test The exercise is based on a consoleapplication to minimize the complexities

1 Open a Visual Studio NET Command Prompt (Start | Programs | MicrosoftVisual Studio NET | Visual Studio NET Tools | Visual Studio NETCommand Prompt)

2 Change to the C:\VB directory, or create it if you do not have that directory

3 Make a new directory named Testing (md Testing).

4 Change to the Testing directory (cd Testing).

5 Create a new Visual Basic NET class file using your favorite editor Name

the file Class.vb.

6 Enter the following source code in the Class.vb source file:

Public Class Temperature Private m_temperature As Integer Public Property Temp As Integer Get

Return m_temperature End Get

Set(value As Integer) m_temperature = value – 273 ' Kelvin End Set End Property

Public Function Celsius() As Integer Return m_temperature

End Function Public Function Fahrenheit() As Integer Return m_temperature

End Function End Class

7 Next, write the test harness to test the Temperature class The logicbehind the test is that you will test the Celsius() and Fahrenheit()functions to ensure that the class returns the correct value The test plan is touse a value of 30 Celsius and verify that it is correctly returned Create a new

source file in the Testing directory; name the file Harness.vb.

Creating a Test Plan on the Evolutionary Model 7

8 Enter the following Visual Basic NET code in the Harness.vb file:

Public Class Tester

Public Shared Sub Main() Dim t As Temperature = New Temperature() Static Thirty As Integer = 30

t.Temp = Thirty ' assign the property 30 Celsius ' Now test the behavior when the temperature is set to 30 C

Select Case t.Celsius() Case Thirty

System.Console.Out.WriteLine( _

"The value is correct: {0} (Expected {1}C)", _ t.Celsius, Thirty)

Case Else System.Console.Out.WriteLine( _

"The value is incorrect: {0} (Expected {1}C)", _ t.Celsius, Thirty)

End Select Select Case t.Fahrenheit() Case ((Thirty* 9 / 5)+32) System.Console.Out.WriteLine( _

"The value is correct: {0} (Expected {1}F)", _ t.Fahrenheit, ((Thirty* 9 / 5)+32))

Case Else System.Console.Out.WriteLine( _

"The value is incorrect: {0} (Expected {1}F)", _ t.Fahrenheit, ((Thirty* 9 / 5)+32))

End Select End Sub End Class

9 Save the source files and compile them using this command line:

C:\VB\Testing>vbc Harness.vb Class.vb

10 Run the harness program; the following is the output:

C:\VB\Testing>harness The value is incorrect: -243 (Expected 30C) The value is incorrect: -243 (Expected 86F)

As you can see, there is a problem, and if you look at the Temperatureclass, you will find that the temperature is stored using the absolute Kelvinscale, but there is no conversion in the Celsius() or Fahrenheit()functions The next step provides the solution to the Celsius() functionproblem

11 Correct the Celsius() function to correctly convert from Kelvin toCelsius Here is the correct conversion:

Public Function Celsius() As Integer Return m_temperature + 273 ' convert from Kelvin to Celsius End Function

12 Save and compile the harness program

13 Execute the harness program This should be the result:

C:\VB\Testing>harness The value is correct: 30 (Expected 30C) The value is incorrect: -243 (Expected 86F)

14 Correct the problem with the Fahrenheit() function using thefollowing code segment:

Public Function Fahrenheit() As Integer Return (((m_temperature + 273) * 9 ) / 5 ) + 32 End Function

15 Save and compile the harness program

16 Execute the harness program

C:\VB\Testing>harness The value is correct: 30 (Expected 30C) The value is correct: 86 (Expected 86F)

Having tested the Temperature class, you can move on to other classes in theapplication

Integration Testing

When the units of the application are completed and tested, they will be assembled(integrated) into larger units These new integrated units need to be tested as well, in

what is called integration testing The most basic integration test takes two tested units

and tests the interface between those two units This process continues until all unitshave been integrated By working with only two units at a time, the integration testingbecomes manageable, and locating a defect will be much easier and faster

There are three approaches to integration testing:

■ The top-down strategy In this strategy, you start at the top of the application

and integrate the units to ensure that high-level logic and dataflow are tested early

in the development cycle The top-down strategy minimizes the need for drivers(callers), but the need for stubs complicates management of the test Thelow-level units are tested late in the development cycle The top-down strategy

Creating a Test Plan on the Evolutionary Model 9

has very poor support for early (proof of concept), limited-functionality releases

■ The umbrella strategy In this strategy, you test along the lines offunctional control and data-flow paths The logic is to integrate low-levelfunctions first—as in the bottom-up strategy—after which the output fromeach function is integrated in the top-down manner This strategy minimizesthe need for stubs and drivers but also makes management of the testingeffort more complicated The umbrella strategy leads to the possible earlyrelease of limited-functionality proof-of-concept versions

The integration testing is completed when the application is ready to be shipped

to the customer

The most common model for testing is a combination of the umbrella model and one of the other two models That way, the early test versions can be brought together with the users to validate the design as well as the formalized top-down or bottom-up model One word of advice, though:

ensure that management of the testing is tightly controlled.

Regression Testing

Regression testing refers to the retesting of units after the unit has been modified You

perform the regression test by rerunning the original tests that were designed for thatunit The testing will determine if the modification broke the unit or not Regressiontesting should not be a long process; rather, it should be a very quick go–no go test.Here are some strategies that can be used during the testing:

■ Look out for side effects of fixes that have been incorporated

■ Write one regression test for each bug that was fixed

■ Test fixed bugs directly after the bug is fixed to ensure that the fix has no sideeffects

■ If multiple tests are similar, throw away the least efficient ones

■ Tests that always pass the program should be archived for historical reasons

■ Test functionality, not design

■ Vary the data for the test, look for data corruption Try to overflow buffers,test for logical behavior.

■ Track the memory use of the program

The groups of tests that need to be maintained in order to be able to performregression testing are most effectively stored in a library that constitutes a battery ofstandard tests that are used whenever the program has to be tested One of the trickyaspects of the test library is to decide what to keep Don’t spend too much timeanalyzing the merits of a particular test case; if you can’t make up your mind, add it

to the library The content of the library should be analyzed every so often to removeduplicated test cases as well as invalid tests

Software testing is as much a science as is software design, and the precedinginformation is included as an overview of the topic Remember that the exam willassume that you know how to write a test harness for a unit

Providing Test Data to Components and Applications

The selection of test data for use with the test cases is as important as the design of thetest cases themselves The data that is used must be selected from the problem domain

of the development project The data is usually identified during the analysis phase ofthe project and should be verified with the domain experts of the project to ensure thedata is valid

When developing components that quite possibly will be used in an internationalenvironment, it is imperative that you provide for data that is valid for the differentlocales of the users of the component To that end, work with the domain experts toidentify the different locales that will be supported in the design and create datadefinitions for each locale

The most important aspect of the localized component is that the tests mustprovide data in the format of the user locale and test that the component performsthe correct conversions For example, if the locale of the user presents dates in theYYYY.MM.DD format (2002.09.07), the test data must include that format toensure that the conversions work

CERTIFICATION OBJECTIVE 7.02

Logging Test Results

The performance of tests is one part of testing—but there is an equally important partthat involves the logging or filing of the test data The logging can be as low-tech as

manually filing screen shots and handwritten notes in a filing system, or it can be ashigh-tech as using a versioning system that stores the test harness as well as the outputtogether with the source code.

How you store the test results is not as important as that you store them in asearchable way Remember that this involves the Quality Assurance (QA) records ofthe software application

One product supplied by Microsoft as part of Visual Studio NET is the VisualSourceSafe (VSS) product You can use VSS to keep versioned copies of virtuallyanything VSS is the application that makes team-based development possible

For the exam, you need to know that VSS is a product that is used to store versioned information about all aspects of the software development process

in a project—including the test reports.

The storing of test results is one of the areas in software testing that usually

is left to chance—which is a shame You spend a lot of time designing and executing the tests, but then the results are just stored in a filing cabinet.

Next year, when you need to return to the same application to test it after maintenance, you need those original results so that you can guarantee that the maintenance action did not break anything.

Logging Test Results 11

One of the most ignored topics in any course

is the importance of proper testing I have made

a point of introducing the concept of the test

harness to the students that I teach When you

implement a class, you always write a small

program—the test harness—that is used to

exercise and test the class

I have found that the software class is amanageable unit for testing, but that is based

on the assumption that the classes are built assmall single-use building blocks that will beassembled into larger classes that in turn areassembled into the application

This brings us back to the proper class designthat is the basis of OOAD With a proper classdesign, the test cases will be easy to design andthe iterative nature of OOAD will lend itself toproviding a functional test plan

FROM THE CLASSROOM

CERTIFICATION OBJECTIVE 7.03

Instrumenting and Debugging a Service

Instrumentation is the process of collecting information about a program while it is

running A number of methods are available to us for collecting that information,ranging from online debugging to using the performance counters that can be monitoredusing operating system tools The exam will test you on how to add trace statements andperformance counters, and how to debug a remote component using these techniques

Two different classes are available to us for getting information from the runningapplication: the Trace class and the Debug class These two classes are equivalent inall but one respect—the Debug class will not be available if the application has beencompiled as a Release build, while the Trace class is available in both Debug andRelease builds As the two classes are equivalent in all but this respect, you willconcentrate on the Trace class in this section You will start with tracing to explorethe different parts of the environment and how to use them

Implementing Tracing

Tracing is the method used to monitor your application while it is running in

production The Trace class gives us the functionality you need to provide a veryfunctional environment for production instrumentation of your application TheTrace class is located in the System.Diagnostics namespace In order to add tracing

to an application, you will need to include the System.Diagnostics namespace anduse the methods of the Trace class

The six methods in the Trace class that write output are listed in Table 7-1

Assert() The output is written if the condition for the Assert is False If no text is specified,

Assert() outputs a stack trace.

Fail() The text is outputted if present; else, the stack trace.

Write() Outputs the specified text, no carriage return.

WriteIf() Outputs the specified text, no carriage return, if the condition is True.

WriteLine() Outputs the specified text followed by a carriage return.

WriteLineIfy Outputs the specified text, followed by a carriage return, if the condition is true.

TABLE 7-1 The Output Methods of the Trace Class

Instrumenting and Debugging a Service 13

The output from the methods in Table 7-1 is written to TraceListeners

There is always a default TraceListener (DefaultTraceListener) thatsends the trace information to the default error output for Windows You can addadditional TraceListeners to the TraceListenerCollection that the Listeners property

of the Trace class refers to in order to enable custom tracing Two TraceListenersare supported: the TextWriterTraceListener redirects output to an instance of theTextWriter class or to anything that is a Stream class, and the EventLogTraceListenerredirects output to an event log

You can inherit fromTraceListenersto build your own custom listener.

The following code segment is an example of creating a TextWriterTraceListenerand writing some trace information to it:

Imports System.Diagnostics Imports System.IO

Dim outputFile As Stream = File.Create("OutputFile.txt") ' Add a new text writer to the trace listener collection Dim tl As TextWriterTraceListener = New TextWriterTraceListener(outputFile) Trace.Listeners.Add(tl)

' Write tracing information to the file Trace.WriteLine("This line will be placed in the OutputFile.txt file")

Tracing can be controlled using the trace switches that are provided with the Trace

class; this way, the application can have its trace capabilities modified at run time.The trace switches are as follows:

■ 0 = None

■ 1 = Errors only

■ 2 = Warnings as well as errors

■ 3 = Information messages (and warnings and errors)

■ 4 = Verbose—as its name suggests, everything

By setting the TraceSwitch to one of the preceding levels, you can control thelevel of tracing that will take place The following code segment shows how to usethis technique:

Dim myTraceSwitch as New TraceSwitch("SwitchOne", "The first switch") myTraceSwitch.Level = TraceLevel.Info

' This message box displays true, becuase setting the level to ' TraceLevel.Info sets all lower levels to true as well.

MessageBox.Show(myTraceSwitch.TraceWarning.ToString()) ' This messagebox displays false.

MessageBox.Show(myTraceSwitch.TraceVerbose.ToString())

The TraceLevel enumeration is used to set the Level property of the TraceSwitch.Using this technique, you can use the Main() method and command parameters toindicate the detail of tracing that will take place, as is shown in the following codesegment:

Public Shared Sub Main(ByVal Argh() As String)

If Argh.Length > 0 Then Dim myTraceSwitch as New TraceSwitch("SwitchOne", "The first switch") Dim a as TraceLevel

Select Case CType(Argh(0), Integer) Case 0

a = TraceLevel.Off Case 1

a = TraceLevel.Error Case 2

a = TraceLevel.Warning Case 3

a = TraceLevel.Info Case 4

a = TraceLevel.Verbose Case Else

a = TraceLevel.Off End Select

myTraceSwitch.Level = a End If

EXERCISE 7-3

Tracing

This exercise is based on an XML Web Service that uses the event log for tracing

For a refresher on XML Web Services, please see Chapter 5

1 Start by creating an ASP NET Web Service, using the localhost server

Name the service TracerSample, shown next

Instrumenting and Debugging a Service 15

2 Once the project is created, you will need to provide some functionality Youwill implement the temperature conversions you have seen many times already

3 Create a WebMethod with the signature Public Function CtoF(c As Integer)

As Integer to return a Celsius-to-Fahrenheit conversion ((c*9/5) + 32)

4 Create a WebMethod with the signature Public Function FtoC(f As Integer)

As Integer to return a Fahrenheit-to-Celsius conversion ((f – 32)*5/9) Thesetwo methods are implemented as shown in the following code segment:

<WebMethod()> Public Function CtoF(ByVal c As Integer) As Integer Return ((c * 9 / 5) + 32)