Thông tin tài liệu
Chapter
10
Internet
Troubleshooting
i-NET+ EXAM OBJECTIVES COVERED IN THIS
CHAPTER:
Identify problems related to legacy clients (e.g., TCP/IP sockets
and their implication on the operating system). Content could
include the following:
Checking revision date, manufacturer/vendor
Troubleshooting and performance issues
Compatibility issues
Version of the Web browser
Explain the function of patches and updates to client software
and associated problems. Content could include the following:
Desktop security
Virus protection
Encryption levels
Web browsers
E-mail clients
Describe the process of pre-launch site/application
functionality testing. Content could include the following:
Checking hot links
Testing different browsers
Testing to ensure it does not corrupt your e-commerce site
Load testing
Access to the site
Testing with various speed connections
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
Describe when to use various diagnostic tools for identifying and resolving Internet
problems. Content could include the following:
Ping
winipcfg
ipconfig
ARP
Trace Routing Utility
Network Analyzer
Netstat
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
B
ugs and errors infest the World Wide Web—expect them to
crop up on your Web site. Bugs stop people from using your Web site and
can permanently damage your reputation. So, although some bugs are inev-
itable, it is important to reduce the number and effect of bugs that sneak into
your site.
In the preceding chapter, you learned the importance of advance planning
for the back and front ends of your Web site. Careful planning will reduce
the number of bugs and errors that your users experience, but bug detection
and fixing is an ongoing process.
In this chapter, you’ll learn about important areas of troubleshooting and
debugging:
Fixing bugs before your audience sees them
Resolving Internet problems
Virus protection
Software updates
Legacy clients
A clear understanding of these topics will limit the number of bugs you inflict
on your users and can lead to quicker resolution of errors that you do find.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
456
Chapter 10
Internet Troubleshooting
Web Site Pre-Rollout Testing
B
efore you roll out a new Web site, or change an existing site, you
should make sure it has as few bugs as possible. A new site is kept “private”
until its launch date. When it is rolled out, everyone is allowed in to try it
out. You should only make your site public once you have ironed out most
of the bugs.
You probably have similar concerns for your existing sites—you don’t
want to make your big mistakes in public. Changes to a Web site can make
the site unreadable or make Web applications return an error. Web sites are
complicated and contain unexpected dependencies—so even changes to one
page may break something on a different part of the site. Just as new sites are
kept private until they are rolled out, changes to existing sites should be
tested in a private area, and then the changes can be installed once they are
verified as correct.
To “break” a Web site is to make it unusable. There are many ways to break
a Web site, most of them unexpected. You might corrupt the graphic layout of
a page, make a CGI script stop performing its duties, or even make the server
freeze.
There are two things you need before you make your site public:
A method for privately testing your changes
A checklist of what problems to look for
With a method and checklist in place, you can tinker with your Web site and
not be afraid that your changes will break the chairman of the board’s favor-
ite page.
Develop a Testing Methodology
If avoiding errors in your public Web site is important to you, you should use
a standard
testing methodology
. A testing methodology is the set of proce-
dures you perform each and every time you make a change. The goal is to
check the validity of every page. With a written methodology, you will use the
same procedure each time you check your site, reducing the possibility of
missing a potential problem through carelessness, sloppy work, or ignorance.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
Web Site Pre-Rollout Testing
457
Whether your Web site is small or large, a testing methodology decreases
the likelihood that you’ll seriously break it. By following a standard proce-
dure, you’re less likely to forget to check for whatever broke your site the last
time you changed something. As time goes on, you can fine-tune the extent
of your testing, depending on how often things break and how effective your
testing is in finding errors.
In the following sections, we’ll give you an example of a simple test-
ing methodology and then discuss some components of a more advanced
testing methodology—a location for testing and a storyboard to follow.
Later, we’ll review the different types of problems you may discover in a
Web site. You can then proceed to develop a testing methodology that fits
your needs.
Simple Error Checking
Different scale Web sites require different scale tests. Joe’s home page proba-
bly doesn’t need as much testing as Amazon.com’s home page; the cost of an
uncaught bug is significantly smaller for Joe than it is for Amazon.com. Joe
could probably get away with a simple testing methodology like the following:
1.
Download old page from public Web site.
2.
Edit page on local computer.
3.
View local page in browser.
4.
Upload page to public Web site.
5.
View public page in browser to make sure the changes show up.
These steps reduce the chance that Joe will break his home page and that
the broken page will remain broken until someone e-mails Joe. For example,
he’ll know when he performs step 5 if his upload failed. Notice two key
points about Joe’s method:
Joe used his hard drive as a private area for development.
Joe double-checked his changes to make sure he didn’t break
anything.
More advanced checking builds on these two fundamental aspects of Joe’s
testing methodology.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
458
Chapter 10
Internet Troubleshooting
Private Testing Area
One component of a good testing methodology is the use of a private testing
area. Joe had this component in his methodology—he tried out changes on
his hard drive. He could experiment freely without worrying that people
would view his rough drafts. Although Joe might be perfectly happy using a
hard drive as a development area, this won’t work for all Web sites.
More complex Web sites require different types of private areas. If more
than one person will be testing a Web page, it needs to be published on a pri-
vate site. Once it is on a private site, the testers can collaborate on the page.
Depending on your needs, there are a couple of areas where you can try out
your changes:
A private area on your main Web server
An entirely separate test server
In the following sections, you’ll see the differences between these two testing
areas. You’ll also learn about tools for moving your files from your testing
area to the main server.
Main Web Servers
For most Web sites, the best option for a private testing area is in a private
section of the main Web server. This is a common choice because it provides
a more functional test environment than a stand-alone hard drive but doesn’t
require many additional resources. By reusing an existing server, you can
also save the cost of an additional server.
You will certainly want to consider publishing your changes to a Web
server if you have multiple people looking at a site or if you use pages that
need to be tested on a server. By publishing to a private section of a server,
you can test server functionality before releasing your site to the public. If the
pages being edited use CGI scripts, for example, they can’t be easily tested on
a hard drive.
Staging Servers
If you find that the private version of your Web site is interfering with your
main site, you may need a
staging server.
A staging server is a separate Web
server on which you can put a private version of your public Web site. It has
almost all the functionality of the public Web site, yet it won’t interfere with
the public site. Staging servers are useful because tests to it will accurately
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
Web Site Pre-Rollout Testing
459
predict how changes will affect the public site, but tests that corrupt the stag-
ing server will not affect the main site.
Staging servers are particularly useful if you are experimenting with new
versions of an operating system, new databases, or anything that might crash
a whole server. If you ever find yourself wondering if your actions on your
test site are going to crash the server, you may want to consider getting a
staging server.
Quality assurance
is a job function in which applications are checked to make
sure they work as expected. People doing quality assurance report bugs.
Copying Files between Servers
Whatever the complexity of your testing needs, it should be fairly simple to
move files between the private testing area and the main area. If it is too com-
plicated, errors can be introduced in the transfer process. HTML editors, such
as NetObjects Fusion or Microsoft FrontPage, have publish/export/save as
settings that explicitly support uploading development code to multiple serv-
ers or to different areas on a single server. These HTML helpers make sure the
file location tags are rewritten to accommodate multiple servers.
Figures 10.1 and 10.2 demonstrate the capabilities available in many
HTML helpers. Figure 10.1 shows the Server Locations tab in the Publish
Setup dialog box of NetObjects Fusion. In this dialog box, users can add,
edit, or delete server locations. Notice that there are presently three server
locations defined: Main Server, My Computer, and Remote Staging Server.
Figure 10.2 shows the Publish Site dialog box. Here, the user can select
which server to publish to, as well as whether to publish the entire site or
only the changed assets. Once you set up the location of each server, it should
be easy to try out and debug changes before your audience can find them.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
460
Chapter 10
Internet Troubleshooting
FIGURE 10.1
Defining multiple servers
FIGURE 10.2
Publishing to a staging server
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
Web Site Pre-Rollout Testing
461
Use the Storyboard
Another crucial component to any testing methodology is checking to make
sure the page does what it is supposed to do. When Joe double-checks the
changes to his home page, he can just look at the single new page and see if
the changes are correct. If you happen to have a more complex site, it is more
difficult to determine if a set of pages works correctly. A common way to
ensure that changes are correct is to check the new pages against a compre-
hensive description of how the pages should look and function. This descrip-
tion is often called a
storyboard
.
A storyboard is a document that describes how the pages should look and
function. It lists screen-by-screen how the pages will look and how the user
might interact with them. It will often separate the different elements that go
into each screen: what text, graphics, animations, and application code should
be on each page. Also, it charts out the relationships between the pages, espe-
cially what actions occur when users choose each option on each page.
People performing quality-assurance checks can follow each path on the
storyboard (like a map) and make sure the text, graphics, and applications
all behave as expected. They should make sure the new pages have all the
functionality called for in the storyboard, as well as look for any bugs.
Avoid Corrupting E-Commerce Web Sites
Changes to e-commerce Web sites require special care. Bugs in
e-commerce sites mean lost money, so it is especially important that
these sites don’t suffer from errors. E-commerce Web sites also typically
rely on complex interactions between application servers, SQL databases
like Microsoft SQL Server and Oracle, and legacy order-fulfillment systems.
Whereas updating a normal Web site is much like releasing the new version
of a book, updating an e-commerce Web site is like releasing a software
upgrade. Changes in the user interface often accompany changes in the
software that runs the site and talks to the database, credit card companies,
and possibly an order-fulfillment system.
Private testing areas for e-commerce Web sites need to be carefully
designed by the people who wrote the software for the e-commerce
main site.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
462
Chapter 10
Internet Troubleshooting
In this section, we looked at two key elements you need to have in place
in order to properly test your Web site—a private location to test the pages
and a storyboard to check the pages against. We haven’t gone over what you
should be testing—you need to decide what is important to you. The next
section will serve as a pointer to some of the things you may want to put on
your checklist.
What to Check
As quality control testers go through the site, they should look for everything
that could appear to be a bug to the target audience. Basically, they ask the
following questions:
Do all pages exist?
Do pages appear and function correctly?
Do new pages cause applications to generate error messages or use the
wrong logic?
Do pages meet site policies, such as on content types and file size?
Can the server handle the new files?
In the following sections, we’ll cover each of these elements in more detail.
Once all of these elements have been checked, you can safely roll out your site.
Link Checking (Checking Hot Links)
Link checking
solves a common problem with Web sites: broken hot links.
Broken hot links are links that return a “404—File not found” message when
you follow them. The server says “File not found” because the links are to files
that don’t exist. Link checking is the process of ensuring that all of the files are
in place. To check links, follow the site map or storyboard and click every link.
If you find a broken link, report it. You should also look for paths that the
storyboard or site map indicates should exist yet do not.
Nothing beats the human eye, but there are some automated tools that visit
every link on the site for you and report broken links and malformed HTML.
See
tucows.tierranet.com/htmlval95.html for a list of Windows utilities
that do this.
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
[...]... for a funny user/sysadmin translation phrase book Troubleshooting Steps When you’re troubleshooting, it’s helpful to follow a procedure so you don’t forget important steps You can follow CompTIA’s Network+ Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 468 Chapter 10 Internet Troubleshooting troubleshooting model, for example, to debug your Internet problems This model has eight steps: 1 Identify... prerollout testing methodology Troubleshooting Tips These eight steps are a good overall methodology for troubleshooting You can bolster this methodology with tips and advice from the following sections Here’s a guide for when to use the tips in the following sections during the model troubleshooting process Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 472 Chapter 10 Internet Troubleshooting Understanding... www.sybex.com 476 Chapter 10 Internet Troubleshooting Connectivity problems often go away if you try again in a minute or two You can see Internet Explorer failing to find the DNS entry for www google.com in Figure 10.7 and then finding the DNS entry and displaying the Web page seconds later in Figure 10.8 FIGURE 10.7 Internet Explorer can’t find the DNS entry FIGURE 10.8 Internet Explorer can find the... and the Internet If a site is inaccessible only to people on certain Internet backbones, there is probably a connectivity problem between the site’s Internet access provider and other backbones In this case, the only thing you can do is report the connectivity problem to the site’s Internet access provider and wait for them to fix the problem User Connectivity Problem If it turns out the entire Internet. .. www.sybex.com 478 Chapter 10 Internet Troubleshooting Some Web server software (e.g., Microsoft IIS) allows you to configure your own error messages to make a Web site more “friendly.” FIGURE 10.9 A Netscape “File not found” error Isolate the Cause of HTTP Errors The first part of step 3 (of the troubleshooting steps discussed earlier) is to determine where on the network an Internet problem occurs The... Inc., Alameda, CA www.sybex.com 474 Chapter 10 Internet Troubleshooting FIGURE 10.5 A Netscape online error message In the following sections, we’ll examine in more detail these three different types of error messages and what they may indicate Browser Functionality Errors Many error messages that the browser generates may have nothing to do with the Internet If a browser recognizes that it is being... from multiple places on the Internet This allows you to get a better sense of where Internet connectivity problems are Server or Server’s Network Is Down If the problem occurs for everyone trying to look at a site, either the server is down or the target site’s network connection is down If you have access to the server, see if it is on and if it has network connectivity to the Internet (see “Network Connectivity... download points This helps them avoid bandwidth and latency problems Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 466 Chapter 10 Internet Troubleshooting FIGURE 10.3 MySQL download mirrors Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com Resolving Internet Problems 467 If you are unsure of whether you need to worry about the capacity of your server, keep an eye on your network and server... In the following sections, you’ll learn when to use various diagnostic tools for identifying and resolving Internet problems Specifically, you’ll learn about the following utilities: ARP Netstat Ping winipcfg ipconfig Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 484 Chapter 10 Internet Troubleshooting Trace Routing utility Network analyzer utilities The i-Net+ exam only covers when to use these... is responding Copyright © 2000 SYBEX Inc., Alameda, CA www.sybex.com 486 Chapter 10 Internet Troubleshooting You can use both Ping and tracert to see if you can reach a host You generally will use Ping if you just want to see if the host is responding to you If you also want to see how your packets are routed over the Internet to the host, use tracert The winipcfg and ipconfig Utilities Of all the TCP/IP . Alameda, CA.
www.sybex.com
468 Chapter 10
Internet Troubleshooting
troubleshooting model, for example, to debug your Internet problems.
This model has eight. Chapter 10
Internet Troubleshooting
FIGURE 10.3 MySQL download mirrors
Copyright © 2000 SYBEX Inc., Alameda, CA.
www.sybex.com
Resolving Internet Problems
Ngày đăng: 17/01/2014, 06:20
Xem thêm: Tài liệu Internet Troubleshooting pptx