📄 ch6.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 6 -- Testing and Debugging</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 6</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Testing and Debugging</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#TheProcessandMethodology" >The Process and Methodology</A>
<UL>
<LI><A HREF="#TheReviewCycle" >The Review Cycle</A>
<LI><A HREF="#AtYourCommand" >At Your Command…</A>
</UL>
<LI><A HREF="#SolitaryConfinement" >Solitary Confinement</A>
<UL>
<LI><A HREF="#PreventingHarmtoOriginalData" >Preventing Harm to Original Data</A>
<LI><A HREF="#IsNotEasilyAccessibletoGeneralUser" >Is Not Easily Accessible to General Users</A>
</UL>
<LI><A HREF="#LadiesandGentlemenStartYourTesting" >Ladies and Gentlemen, Start Your Testing</A>
<UL>
<LI><A HREF="#TheTestingProcess" >The Testing Process</A>
</UL>
<LI><A HREF="#DebuggingtheApplication" >Debugging the Application</A>
<UL>
<LI><A HREF="#CommonErrors" >Common Errors</A>
<LI><A HREF="#MakeUseofErrorLogs" >Make Use of Error Logs</A>
<LI><A HREF="#DebuggingFlags" >Debugging Flags</A>
<LI><A HREF="#ReTestingYourApplication" >Re-Testing Your Application</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
Can you picture yourself buying a car that has only been tested
in making right turns or at speeds less than 30 miles an hour?
Probably not, and for the same reasons you shouldn't picture yourself
shipping out a piece of software without extensive debugging.
You, along with other intelligent consumers, expect the products
you use to meet your standards for quality when used in situations
that they were designed for. Whether it's a word processor that
doesn't save files, a toaster that doesn't toast, or a CGI program
that just sits there and never finishes or returns an error, running
into something that fails to meet a user's standards is a bad
thing.
<P>
Debugging applications certainly isn't the high point of programming.
It's bad enough when someone else hunts them down and you have
to fix them, but it's worse when you have to do it all yourself.
Besides being time-consuming, it's often frustrating-here's this
great piece of work that you put together, and now you have to
go through it bit by bit to check everything, instead of tossing
in those cool new features you thought of during last night's
movie. Is debugging really worth it? You'd better believe it.
<P>
CGI applications really need debugging. The reason for this is
that there are lots of variables involved in the program's function-who
accesses it, where they're accessing it from, what it's being
accessed with, what kind of server it's running on, and more!
Assuming that it'll work fine because it seems to do what you
want when it's accessed from your desk just isn't enough. You
have to be sure that anyone who should be able to use it can use
it.
<P>
We'll look at the phases of testing and debugging to see how you
can ensure that what you've created meets your expectations and
behaves after you've set it loose on the world. These phases include
information on
<UL>
<LI><FONT COLOR=#000000>Command Line Testing</FONT>
<LI><FONT COLOR=#000000>Creating a Test Server</FONT>
<LI><FONT COLOR=#000000>Solving general problems</FONT>
<LI><FONT COLOR=#000000>Tracking down elusive problems</FONT>
<LI><FONT COLOR=#000000>Putting it all under the microscope</FONT>
</UL>
<H2><A NAME="TheProcessandMethodology"><FONT SIZE=5 COLOR=#FF0000>The
Process and Methodology</FONT></A></H2>
<P>
The best testing and debugging really starts in the planning stage.
If you've planned your application out well in advance, you're
less likely to have mistakes because of things that are overlooked
or hastily done. When you're just in the beginning stages of writing
the code, it's also easier to put messages and functions in that
allow you to analyze why the problem is occurring. Just like preventative
maintenance, this is preventative coding.
<P>
Does preventative coding mean that you'll have no problems at
all when you go to use this application you've spent so long creating?
Heck no. It's inevitable that there will be minor problems in
the code- things like typos, missed semi-colons or line feeds,
or just things that you hadn't originally considered when planning
it out. If you didn't plan it out at all, and just typed it in
between the Late Late Show and sunrise, it wouldn't be surprising
to find a rather large number of those little annoying bits stuck
in random places.
<P>
Because you can have problems, and they could be major or minor,
there are a couple of steps you can take before making the code
publicly accessible to ensure that you're not going to cause problems
for either yourself, your server, or any person that might end
up using the code. I'll call these the phases of CGI Testing and
Debugging.
<OL>
<LI>Review it
<LI>Isolate it
<LI>Test it
<LI>Debug it
<LI>Test it again
<LI>Go for it
</OL>
<P>
Each of these has special reasons for being where it is, and each
one is no less important than any other. The reason for this order
is to eliminate errors and problems that can end up being compounded
if you skip too far ahead. For example, if you take a completely
untested script and get an error when you first run it from your
Web server, it could be the script, it could be the machine, it
could be the server software-there are too many variables to efficiently
narrow it down.
<H3><A NAME="TheReviewCycle">The Review Cycle</A></H3>
<P>
Reviewing your code is done before it ever sees the light of day.
It doesn't involve a Web server, and it doesn't need an advanced
method of checking. All it involves is taking a good long look
at your code.
<P>
Why in the world would you want to stare at a printout of your
code, or scroll through it onscreen? Because it's easy. Out of
all the possible testing methods, this is the one that's easiest
to do on a bus, on a plane, sitting in the park, or even discussing
it with a friend. What you're looking for is anything that seems
out-of-place-any obvious omissions, any function that you thought
you weren't going to include but is still sitting in the code,
checking your comments (you did put comments in the code, didn't
you?), and generally ensuring that what you're looking at is what
you intended to create. If it isn't what you thought it was, now
is the time to back off the testing phase and go back to the drawing
board. After all, why test stuff you don't plan to use, or that
doesn't even look complete?
<P>
The review phase is also a great time to identify possible trouble
spots, or areas that are critical to the application functioning
correctly. This doesn't mean that you're going over every line
of code over and over again, but, rather, that you pick out spots
such as where it reads data from the user, and where it's performing
an operation that you're only somewhat sure will work. Mark them
with comments, circle them in red pen or highlighter, but make
sure you point them out to yourself. These will come in handy
when you're starting to do the real testing, because anything
that sticks out now should be a big red flag when it comes time
to create a testing plan. If you're worried about it, it should
get tested often, and tested hard.
<H3><A NAME="AtYourCommand">At Your Command…</A></H3>
<P>
Command Line testing is the next part of the review process. At
this stage of the game you can attack your program in almost a
casual manner, because you have complete control over how it sees
the world around it. There are no networks to get in the way,
no beta software for a Web server, no extra processes. There are
you, your program, and the command prompt of your choice.
<H4>Hard-Coded Data</H4>
<P>
There are several ways to use the command line for testing. The
simplest method is to test with hardcoded data. So, if you're
expecting someone to submit a serial number, you can create the
ideal serial number. You can then verify that with the ideal case
of all data the application will process correctly. For instance,
take the example of Listing 6.1 for processing a form.
<HR>
<BLOCKQUOTE>
<B>Listing 6.1. An example of Forms processing in Perl.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">require 'cgi-lib.pl';<BR>
<BR>
#Use the 'ReadParse' subroutine from cgi-lib.pl to gather data
<BR>
&ReadParse(*input);<BR>
<BR>
#Now print a header and process the data..<BR>
print "Content-type: text/html \n\n";<BR>
if ($input{'serial'}) {<BR>
&BadSerial;<BR>
}<BR>
else {<BR>
print "<h1>Form Received</h1>\n";
<BR>
&StoreInformation;<BR>
}<BR>
......</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
Though this is a simplistic case, where it's just checking to
see if the variable named <TT><FONT FACE="Courier">$input{'serial'}</FONT></TT>
is empty in order to determine which subroutine is run, it's still
impossible to get the program to go through its paces correctly
without having some real data in <TT><FONT FACE="Courier">$input{'serial'}</FONT></TT>.
That's easily remedied-just edit the script and place the value
in there.
<HR>
<BLOCKQUOTE>
<B>Listing 6.2. Using hard-coded data for testing purposes.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/usr/bin/perl<BR>
require 'cgi-lib.pl';<BR>
<BR>
#Use the 'ReadParse' subroutine from cgi-lib.pl to gather data
<BR>
&ReadParse(*input);<BR>
<BR>
#Data used for command-line testing - TEMPORARY USE ONLY!<BR>
$input{'serial'}="1234567";<BR>
<BR>
#Now print a header and process the data..<BR>
print "Content-type: text/html \n\n";<BR>
if ($input{'serial'}) {<BR>
.....</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
Be sure to place the hardcoded value somewhere after the process
that reads data from the source, otherwise you'll really get everything
confused. You should also very obviously mark the hardcoded values
to be removed later on. You wouldn't want to leave a hardcoded
serial number in a program that is supposed to provide information
to people based on that number. It would think everyone was the
same person.
<P>
Although hardcoding values is very easy to do, you shouldn't rely
on it for anything other than spot checks of the code. The main
reason for this isn't that it's monotonous to go in and keep changing
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -