2.10 beta版站点实现

　　一旦模拟站点可以接受，就可以着手实现真实的站点。真实的内容应该放在网页上，后端构件和交互的要素也应该与最后的外观设计集成为一个整体。这里要讨论的技术和实现问题太多，第1 0章到第1 3章会单独讨论这些问题。尽管实现看起来是项目最消耗时间的方面，但如果所有的构件已经收集好并且已经实现好原型，实际的站点实现做起来会比较快。

2 . 11 测试

　　对大多数程序员来说，测试可能是web开发过程中最不喜欢的一个方面。在完成了所有艰苦的任务如规范说明书、设计和实现后，大多数程序员只是准备好发布。应该防止这种冲动。对积极的用户综合印象来说，测试是非常关键的。在发布后，不要促使用户测试站点。如果他们在实现好的站点上遇到一个问题，他们是不会原谅的。一定要记住以下设计规则：规则：站点一定会存在一些问题，必须好好测试你的站点。

　　不幸的是，web站点的测试经常就是简单的归为用浏览器快速地访问站点，或者检查站点的链接体。问题一定会在站点中存在，无论是什么样的。不幸的是，大多数开发者认为只要站点的外观看起来没有问题，它就是没有问题的。记住第1章中所说的，站点设计不只是仅仅包括外观设计：必须同时测试站点的其他方面，就像以下规则所综述的：

规则：测试应该涉及站点的各个方面，包括内容、外观、功能和目标。

　　附录b详细讨论了站点的评估和测试，尤其是针对完成的站点。这里简单综述一下web的测试。 1. 外观可接受度测试外观可接受度测试可以保证web的外观与设想的一致。浏览站点的每个网页，确信它们在样式、颜色和风格上一致。用不同的浏览器和分辨率或与真实用户一致的浏览环境来浏览网页。用浏览器快速地访问站点，看看样式是否一致。在浏览站点的同时，注意寻找样式不规则的地方。外观可接受度测试可能要求每一个网页都打印出来。记住不要专注于为在线消费设计的打印测试网页。 2. 功能测试既然大多数网页的基本功能就是在屏幕上显示自己，功能测试和外观测试在某种意义上经常重叠。然而，大多数站点至少包括导航这样的基本功能。确信检查了站点上每个链接体并校正了每个断开的链接体。断开的链接体应该当作一个非常严重的错误。确信测试了诸如窗体这样的交互元素。通常采用现实情况和极端情况这两种测试条件。通过输入明显的错误来测试窗体。记住，用户不会按照你所想的行事，尽量考虑一些不可预料的情况。 3. 内容验证站点的内容细节很重要。确信所有的内容都是合适的且词语的用法保持一致。检查诸如产品名、版权日期和商标等细节。一定要记住检查单词的拼法。客户和用户会仅因为一个印刷错误而认为整个站点很糟糕。这种重要性怎么强调也不过分。进行测试的最好办法是把每一个网页打印出来并认真阅读每一行。 4. 系统和浏览器兼容性测试在开发时可能就考虑到了系统和浏览器的限制，但测试时一定要验证。在浏览站点的时候，一定要用用户会使用的同样类型的系统和浏览器。不幸的是，大多数情况下测试用的系统比用户采用的系统一般要强大些。项目规划应该有详细的浏览器需求，一定要让站点用指定的浏览器访问时非常顺利。 5. 发送测试检查一下站点发送得是否充分。在用户的真实条件下浏览站点。如果站点是为“美国在线”的调制解调器用户设计的，建立一个“美国在线”用户账号，用调制解调器测试站点发送速度。为了模拟站点流量，考虑用测试软件创建虚拟用户点击站点。这会模拟出站点的响应速度。测试时一定要用真实的服务器和大致相同的系统。一定不能低估站点发送的影响。在设计规范说明书时，如果对此考虑得不够充分，整个项目可能偏离轨道。关于发送条件的更多信息，请参看第1 4章。用户接受程度测试用户接受程度测试应该在站点看起来正常后进行。对于软件，这种测试通常成为b e t a测试。让用户使用站点，并做最后一次的评价。不要直到明显的错误被校正后再进行这种测试，就像下面规则所说的。

规则：用户测试是最重要的测试形式，不要在最后才进行。

　　因为用户测试最接近真实的用户，所以它是最重要的测试形式。如果问题没被发现，你可能不立刻纠正错误。如果问题不是很大，你仍可发布站点，而迟些时候再纠正。然而，如果发现了严重的问题，最好延期发布直到问题被纠正。

2.12 发布和以后的问题

　　如果站点准备发布，不要放松—你还没有发布。实际上，你的工作仅仅开始。现在是观察站点实际运作情况的时候了。站点是否符合用户的期望？站点的开发目标是否已达到？是否还需要其他的校正？底线是站点必须继续运行。新的特征可能需要，为了适应技术更新而升级是不可避免的。为了满足市场需要而改变外观也非常可能。这样就开始了被成为维护的持续开发过程。一旦瀑布模型的最后阶段完成，就应该重新返回起始阶段，正如以下规则所述：

规则：站点开发是一个持续的过程：规划、设计、开发和发布，如此周而复始。

2.13 欢迎来到真实世界

　　尽管站点的开发过程看起来非常直观，但它并不是一直都很顺利。对真实世界来说，存在太多的变化。例如，考虑为某个人如老板或客户设计站点。如果某个人为创建某个站点掏钱，你可能需要把他的想法掺杂进去，而不管需求是否与用户的想法一致。一定要劝说别人在做决定时考虑用户的想法。一定要显示设计理论的优越而不是鼓吹规则。做好举一些你的想法的例子的准备。然而，必须做好接受你的想法被别人抛弃的准备。

　　注意有经验的设计者会准备很多站点组合以备讨论。与为顾客准备的发型书相同，用户所想的是很难用词语描述。

　　大多数站点项目容易存在争端问题。不要指望任何人都同意。公司的部门会争夺控制权，这种情况经常出现在技术部门和市场部门之间。会有数不清的自称web专家的人给出建议，这会激起更多麻烦。如果某人的兄弟的朋友声称用微软的f r o n t p a g e自动化工具在一小时内建好一个站点，不要感到惊讶。解决争端的唯一方法是耐心并尽量地说服别人。没有一个适当而清晰的规范说明书，开发者会发现自己处于一个容易受到攻击的不稳定位置。

　　一定要记住，遵循某个进程模型的目的是减少web项目中出现的问题。然而，一个进程模型不能考虑现实世界中的所有问题，尤其是关于人的问题。经验是处理很多问题的唯一老师。web 项目中缺少经验的开发者会被鼓励摸滚打爬，从而在克服障碍时获得经验。

2.14 小结

　　建立一个现代的站点非常具有挑战性，所以站点开发者应该采用一种方法学或进程模型来指导开发过程，从而有希望减小风险和管理的复杂性，并且改进最终结果。诸如修正瀑布模型的软件工程进程模型在大多数web项目中很容易应用。然而，有时候，由于缺乏项目管理经验或清晰的目标，应该采用一种原型驱动方法或联合应用方法。通常，基于原型的方法更适合站点的自然特性，减少不必要的风险，在开发出合适的站点之前反复进化。在站点开发早期阶段进行规划，可以减小风险并提高最后的开发质量。应该撰写一个包括站点目标、访问者、任务分析、内容需求、站点结构、技术需求和管理考虑的内容设计文档。设计文档应该指导站点的实现。在站点实现时，应该利用块结构图、纸张模拟图、情节说明图板、甚至模拟站点来减小后来重新设计站点的可能性。在规划详细且原型实现好后，实现就应该很快速，而需要重复的工作量很小。然而，一旦完成，不要急于实现在线访问—充分的测试是必要的。长时间的维护是必要的，持续的警惕也是必要的，否则你的站点会开始恶化。