http://avaxhome.org/ebooks俄罗斯的破解网站,英文最新书籍，天天有更新

http://www.spotbit.com/main/     ——推荐！

http://asiaing.com/index.php    ——强烈推荐！！

http://www.freeclassicaudiobooks.com/

http://ebook.vopen.net/    —— 国内站点！全部英文原版书籍！强烈推荐！！

http://www.ebooksheaven.org/

http://www.screenbooks.net/screenbook_library.html

http://freecomputerbooks.com/

http://www.bookrevyoo.com/

http://www.edu-tec.org/directorio/pages/E-Books/index.html

http://www.foresight.org/UTF/Unbound_LBW/

http://trh990.blogspot.com/index.html

http://www.giuciao.com/

http://www.ateus.net/ebooks/index.php

http://onlinebooks.library.upenn.edu/

http://www.gutenberg.org/wiki/Main_Page

http://www.memoware.com/

http://www.cafeconleche.org/     （编程的）

http://www.librodot.com/index.php

http://www.medicinainformacion.com/

http://www.bookwarez.org/ebooks.html

http://www.biblopia.com/

http://www.pdfchm.com      ——pdf 电子书

http://www.oebook.org/

http://www.33367.com

http://www.chipollo.info/modules.php?name=xNews&new_topic=27

http://www.xpressionsz.com/archives/category/magazine/

http://www.ebookshare.net/category/magazine/

http://avaxhome.ru/ebooks

http://digital.library.okstate.edu/OAS/ ——推荐！！

http://textual.net/access.gutenberg#H --TXT 电子书

http://etext.lib.virginia.edu/ --TXT 电子书

51testing五周年了，我工作一年，

我们共同努力，共同进步，加油！！！

我一直感觉系统测试总像马拉松总是测试不完，什么时候上线，什么时候算终点。虽然提交客户了，可是对于质量仍然心里没底，对于测试的效果没有评价的依据。后来经过高人指点，终于领悟到至关重要的精髓：明确测试目标！
    如果要将系统进行全面测试，那么就要有一套完整的测试阶段，每个阶段都以测试目标为标准，科学、有序地进行测试，那么测试效率也就会自然而然跟着提高。

测试阶段分为：测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。

1.测试前准备阶段
主要是相关业务的学习。业务知识是测试的根本依据，只有业务过关了，以后才能有效的进行测试工作。
了解业务步骤：
a、了解业务名词；
b、对现有系统的学习：功能点、业务场景等；
c、分析现有系统数据库，了解数据的走向。

2.需求分析阶段
需求是项目开发的基础，也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求文档的，那如何进行需求分析呢？
此时分析数据库就是一个非常好的方法：
a、每张表的索引和约束条件；
b、数据的来源、走向；
c、数据的存储、变化；
d、数据间的关联；
e、表与表间的关系；

这些分析都可以为了解业务场景和之后的测试用例设计打好基础。

3.测试计划阶段
    我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态，其实解决这些情况的最好方法就是：制定测试目标。
    在计划初期先明确测试目标，制定不同层次目标的执行标准，指导后期设计不同级别的测试用例，跟踪不同级别的缺陷修改。在测试时间较紧情况下，至少可以先把保证所有功能正常操作的最低目标版本先提交给客户，不会再有手忙脚乱，心里没底的状况。
测试目标分为：
             最低目标
             基本目标
             较高目标
             最高目标   等级别

可以使用表格形式来规范目标准侧，例如：

测试目标准则表

目标	测试范围	需求覆盖率
最低目标： 正常的输入+正常的处理过程，有一个正确的输出	（明确的功能点全部列出来）	1.        功能： 正常功能 异常功能 单功能     业务场景 非功能：16种测试类型   2.        输入覆盖率： 有效无效 处理过程：基本流           备选流 状态变化：正常、异常 输出
	SRS00001
	SRS00002
	SRS00003
基本目标： 对异常的输入有错误的捕获，并进行相应提示或屏蔽
较高目标： 对隐式需求进行测试

根据公司规模不同，确定测试目标级别也可不同。一般小公司有最低标、基本目标即可，大公司可以提高目标标准，直接从基本目标开始，直至最高目标。

4.具体的ST用例的编写以及执行
测试用例设计的粒度一直是个讨论对象，很多时候总会强调时间很紧啊，如果时间再多点，我的用例肯定会设计的再细一些！！
是不是设计的越细就一定越好呢，不一定，测试是无穷尽的，使用穷举方法来进行测试是不科学的。
因为制定了测试目标，那么就应该根据测试目标，在设计测试用例时也要制定设计用例目标。

比如：按照最低目标选择测试用例
输入—>有效
处理—>有效
输出—>有效
按照最低目标的宗旨，只要是设计出来的测试用例足以覆盖和验证系统基本功能可以正常使用，那么这些测试用例的粒度就足够细了！从而提高了设计用例效率，同时也提高了测试效率。

5.测试之后的评估
实现一级测试目标之后都要进行评审工作，根据评审结果进行系统版本发布。例如：

1.保证所有需求都有测试用例
2.保证所有功能的正常操作和正常操作有对应的测试用例           V1.0版本
3.保证所有功能的异常校验有对应的测试用例                     V2.0版本
4.各功能组合形成的业务流有对应的测试用例                     V3.0版本
5.各功能或整体软件所需满足的非功能性需求有对应的测试用例     V4.0版本

这样做既可以对代码版本进行控制，也可以应对需求变更的问题。

    也许“确定测试目标”还不能彻底解决复杂测试工作中出现的问题，但是我觉得这最起码可以让你的测试工作变得有条理；跟领导汇报工作的时候业绩和工作效率有凭可据；面对需求变更的时候有理可依！

http://www.edunet.com/elt 主题：是一个全方位的学英语作为第二语言的网站 功能：聊天室，语法讲解，练习，小测试，成语讲解 特色：特别深入地介绍了语法，听力，沟通技巧等 对象：ESL教师和学英语人士 《世界日报》北美版-生活美语 http://www.chineseworld.com/publish/37_9999.r/r.htm 主题：生活化和实用化的英语网页 功能：分主题讲解英语的实用方法，还有母语非英语人士闹的语言笑话 特色：灵活生动，有许多实例 对象：英语基础教好的人士 http://www.englishtown.com 主题：是目前网上最有深度的英语学习网站 功能：非常好的语法讲解，练习，和阅读材料 特色：正宗英国英语 对象：学英语人士 http://www.english-at-home.com/ 主题：是一个全方位的学英语作为第二语言的网站 功能：聊天室，语法讲解，练习，小测试，成语讲解 特色：特别深入地介绍了语法，听力，沟通技巧等 对象：ESL教师和学英语人士 http://www.englishbaby.com/ 主题：是一个年轻人学习交流的美国英语网站 功能：每天不同的网上课程，以美国流行文化为主题 特色：可以学到很多美国俚语和方言 对象：面向年轻人 http://www.englishclub.net/ 主题：丰富齐全的商业性英文网站 功能：语法讲解，练习，参考资料，教师材料 对象：ESL教师和学英语人士 http://www.englishpage.com/index.html 主题：针对英文基础较好的学习人士和教师的网站 功能：阅读，游戏。语法讲解，讨论等 特色：深入讲解了时态用法，每周有新课程推出，旧课程可以在存档中找到 对象：ESL教师和学英语人士 http://members.home.net/englishzone/index.html 主题：非商业性英文学习网站 功能：语法讲解，练习，小成语讲解，英文笑话，阅读和写作 对象：学英语人士 http://www.homestead.com/ESLflow/Index.html 主题：内容组织得很好的英文网站 功能：语法讲解，口语，英语对话，阅读和课程安排 特色：用流程图的方式讲解英语语法概念 对象：ESL教师和学英语人士 http://www.eslhouse.com/ 主题：内容广泛，参考资料甚多 功能：大量词汇讲解，课程安排和参考资料 特色：多媒体中心可播放课程 对象：ESL教师和学英语人士 http://www.eslpartyland.com/default.htm 主题：自学和互相交流 功能：75个互动式测试和15个论坛，让学生互相交流，教师可以下载课程材料 特色：互动式 对象：ESL教师和学英语人士 http://gwis2.circ.gwu.edu/~gwvcusas/ 主题：由George Washington University的Professor Christine Meloni维护的ESL链接网页 功能：有学多学习英语的链接 对象：ESL教师和学英语人士 http://www.ToLearnEnglish.com 主题：内容广泛，资源丰富，值得一看 功能：聊天室，语法讲解，练习，小测试，图片，论坛 特色：做完练习可以得到评语，老师可以在线制作试题 对象：ESL教师和学英语人士 http://deil.lang.uiuc.edu/ 主题：包括了网上学英语的一些最基本的内容 功能：语法讲解，练习，互动式3听力训练，笔友交换，教师参考 对象：ESL教师和学英语人士 http://www.longman-elt.com/index.html 主题：为中国朋友所熟知的朗曼英语教学方法 功能：测试，专题文章，链接，小窍门 对象：ESL教师和学英语人士 http://www.parlo.com/index.asp 主题：学语言的网站 功能：对语言结构，国际文化作出探讨 特色：教你怎样学语言，而不仅是英语 对象：ESL教师和学英语人士 http://www.peakenglish.com 主题：在线的远程英语学习网站 功能：词汇，阅读，听力(用REALAUDIO)，语法课程， 特色：所教英语是用于美国的 对象：学英语人士 http://schmooze.hunter.cuny.edu:8888/ 主题：英语学习个网站，可以一对一或分小组进行对话 功能：在线字典，语言游戏，USENET 对象：学英语人士 http://members.tripod.com/~towerofenglish/index.htm 主题：非常友好的英文学习网站 功能：设计专业的网站，大量的有用资源 对象：学英语人士 非常不错，大多数是英语教学的英语网站，国内网站其实学英语的都不错，而且一些英语听力和口语的网站还有不少，特别是那些VOA等原声听力网站。 博客网址中还有一些： http://wz.blogchina.com/2650405/index.htm 可以参考。比如这个 http://www.unsv.com 是英语听力的好帮手。

 

cntesting.com原创，转载请注明作者和出处。

点击这里查看原文

 

好了，现在案例有了，我们来看看测试用例是什么？下面是对测试用例的关键字解释：

测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

以上解释引用pennychueng，大家可以通过这个联结和他联系。

实际上不同的应用虽然都有测试用例，但是它们的侧重点不一样，今天我们面对的是ATM取款机，这样某些测试用例就要设计的非常“与众不同”了。你现在马上就要动手写吗？No，No，好的设计来自于更多的思维，如果是我我习惯在一张纸上先把业务的流程画出来，它可能是这样的：




看起来有点歪歪扭扭的，当然了这是我想得随手画出，其实这里面肯定有某些方面的逻辑错误和遗漏，不过这样做算是我对要测试物粗浅的理解好了。正规流程是我们先找到这个ATM取款机的用例（UserCase），也可以是详细设计文档，也可以是需求规格说明等等，反正你要找到描述这个ATM取款机业务逻辑和操作逻辑的文档，不然只是靠想象100%做不好测试，第一份用例是这样的：

ATM取款机系统

用例规约

登录ATM取款机用例

版本：草案

修订历史记录

日期     版本 说明   作者
21/Dec/98 草案 草案版本 Fastpoint

目录

1. 简要说明
2. 事件流
  2.1 基本流 - 输入用户密码
  2.2 备选流
    2.2.1 密码后台验证
3. 特殊需求
4. 前置条件
4.1 插卡动作
5. 后置条件
6. 扩展点

登录ATM取款机用例

1. 简要说明
本用例允许普通用户登录ATM取款机系统。本用例覆盖用户密码后台验证。

本用例的主角是普通用户。

2. 事件流
ATM取款机初始化完毕插卡后，本用例就开始使用了。

基本流 - 输入用户密码
1. 初始界面，等待用户密码输入。
2. 普通用户点击键盘“1”。
3. 普通用户点击键盘“2”。
4. 普通用户点击键盘“3”。
5. 普通用户点击键盘“4”。
6. 普通用户点击键盘“5”。
7. 普通用户点击键盘“6”。
8. 系统后台验证普通用户密码，正确。
9. 系统切入ATM取款机普通用户个人帐户界面。
10. 系统后台验证普通用户密码，错误。
11. 系统显示普通用户个人帐户密码错误，返回步骤1。

备选流
1. 密码输入错误内部计数超过3次，普通用户个人帐户封存。
2. 密码后台验证。

特殊需求
特殊需求将在下次迭代中确定。

前置条件
1. 插卡
在本用例开始前，普通用户要登录插卡。

后置条件
后置条件将在下次迭代中确定。

扩展点
业务用例的扩展点将在精化阶段中确定。


 好了，到此为止我们终于看到用例了，该用例模式来自于RUP，比较干净缺点就是以后的文档分支联结过多，下一步我们就要看如何根据用例写测试用例了。

Acceptance testing(验收测试）系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收.它让系统用户决定是否接收系统.它是一项确定产品是否能够满足合同或用户所规定需求的测试.这是管理性和防御性控制.

Ad hoc testing(随机测试),没有测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

Alpha testing(α测试)，是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。

Automated Testing(自动化测试），使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多。

Beta testing(β测试），测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，β测试不能由程序员或测试员完成。

Black box testing(黑盒测试），指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。

Bug(错误），有时称作defect(缺陷）或error(错误),软件程序中存在的编程错误，可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标；软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。

Bug report（错误报告），也称为“Bug record(错误记录）”，记录发现的软件错误信息的文档，通常包括错误描述、复现步骤、抓取的错误图像和注释等。

Bug tracking system(错误跟踪系统，BTS)，也称为“Defect tracking system,DTS”，管理软件测试缺陷的专用数据库系统，可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

Build(工作版本），软件开发过程中用于内部测试的功能和性能等不完美的软件版本。工作版本既可以是系统的可操作版本，也可以是展示要在最终产品中提供的部分功能的部分系统。

Compatibility Testing(兼容性测试），也称“Configuration testing(配置测试）”，测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

Capture/Replay Tool(捕获/回放工具），一种测试工具，能够捕获在测试过程中传递给软件的输入，并且能够在以后的时间中，重复这个执行的过程。这类工具一般在GUI测试中用的较多。

Crash(崩溃），计算机系统或组件突然并完全的丧失功能，例如软件或系统突然退出或没有任何反应（死机）。

Debug（调试），开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时，或者根据测试错误报告指出错误以后，开发人员需要执行调试过程来解决已存在的错误。

Deployment(部署），也称为shipment(发布），对内部IT系统而言，指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

Dynamic testing（动态测试），通过执行软件的手段来测试软件。  

Exception（异常/例外），一个引起正常程序执行挂起的事件。

Functional testing (功能测试)，也称为behavīoral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。

 

Garbage characters（乱码字符），程序界面中显示的无意义的字符，例如，程序对双字节字符集的字符不支持时，这些字符不能正确显示。 

GB 18030 testing（GB 18030测试），软件支持GB 18030字符集标准能力的测试，包括GB 18030字符的输入、输出、显示、存储的支持程度。 

Installing testing（安装测试），确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。 

Integration testing（集成测试），被测试系统的所有组件都集成在一起，找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。 

International testing（国际化测试），国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常，软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语（可选）的混合字符。  

Localizability testing(本地化能力测试)，本地化能力是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本，提高测试效率，本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括：字符的硬编码（即软件中需要本地化的字符写在了代码内部），对需要本地化的字符长度设置了国定值，在软件运行时以控件位置定位，图标和位图中包含了需要本地化的文本，软件的用户界面与文档术语不一致等。 

Load testing（负载测试），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 

Localization testing（本地化测试），本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试，安装/卸载测试，当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。 

Performance testing（性能测试），评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。 

Pilot testing（引导测试），软件开发中，验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中，引导测试通常是客户检查软件测试公司测试能力的一种形式，只有通过了客户特定的引导测试，软件测试公司才能接受客户真实软件项目的软件测试。 

Portability testing（可移植性测试），测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
Priority（优先权），从商业角度出发是指错误的重要性，尤其是从客户和用户的角度出发，是指错误对于系统的可行性和可接受性的影响。与“Severity（严重性）”相对照。 

Quality assurance（质量保证QA），采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。 

Regression testing（回归测试），在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再现。 

Review（评审），在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。 

Sanity testing（健全测试），软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing（冒烟测试）”。 

Screen shot（抓屏、截图），软件测试中，将软件界面中的错误（窗口、菜单、对话框等）的全部或一部分，使用专用工具存储成图像文件，以便于后续处理。 

Severity（严重性），错误对被测系统的影响程度，在终端用户条件下发生的可能性，软件错误妨碍系统使用的程度。与“Priority（优先权）”相对照。 

Smoke testing（冒烟测试），冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing（健全测试）”。 

Software life cycle（软件生命周期），开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。 

Static testing（静态测试），不通过执行来测试一个系统。如代码检查，文档检查和评审等。 

Structured query language（结构化查询语句，SQL），在一个关系数据库中查询和处理数据的一种语言。 

TBD(To be determined，待定)，在测试文档中标是一项进行中的尚未最终确定的工作。 

Test（测试），执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同，并评价软件项的特性软件项的分析过程。软件工程过程的一个活动，它将软件在预定的条件下运行以判断软件是否符合预期结果。 

Test case（测试用例），为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。 

Testing coverage（测试覆盖），指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。 

Testing environment（测试环境），进行测试的环境，包括测试平台、测试基础设施、测试实验室和其他设施。 

Testing item（测试项），作为测试对象的工作版本。 

Testing plan（测试计划），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务，并且任何风险都要冲突计划。 

Testing procedure（测试过程），指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。 

Testing scrīpt（测试脚本），一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。 

Testing suite（测试包），一组测试用里的执行框架；一种组织测试用例的方法。在测试包里，测试用例可以组合起来创造出独特的测试条件。 

Unit testing（单元测试），指一段代码的基本测试，其实际大小是未定的，通常是一个函数或子程序，一般由开发者执行。 

User interface（用户界面，UI），广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 

User interface testing (用户界面测试)，指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 

White box testing（白盒测试），根据软件内部的工作原理分析来进行测试,基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现 

cntesting.com原创，转载请注明作者和出处。

点击这里查看原文

 

我知道这里有很多朋友刚刚进入测试，为了减少新朋友们对“如何写测试用例”的问题，特别制作了这个教程。我趋向于使用自己开发的应用做案例，这里使用的是ATM取款机模拟器，我们使用这个案例来描述书写测试用例的整个过程，如图1：


图1



整个界面是比较干净的，跟银行的路边取款机界面没有什么区别，现在我们来看一下如何操作它。首先模拟插卡动作，这个时候ATM显示器出现这样的状况，如图2：


图2


现在ATM显示器提醒我们输入用户密码，继续操作选择小键盘输入用户密码，ATM显示器显示“******”，点击“确定”按钮，如图3：


图3



如果密码正确我们可以进入个人账户主界面，如图4：


图4



现在我们随意操作，根据平常我取钱的动作我会先查看一下我当前的账户余额，点击ATM显示器右边和“查询”对齐的“<<”help按钮，进入账户当前余额界面，如图5：


图5



哇，我这么挥霍无度的人还有5000大元，足够请我的学生吃饭了，呵呵。现在点击和“返回”对齐的“<<”help按钮，返回个人账户主界面，点击ATM显示器右边和“取款”对齐的“<<”help按钮，进入账户取钱界面，如图6：


图6



啊，我要取2000元呢，好像当前快捷操作的只有“100”、“200”、“500”，那只好操作“自定义取款”了，点击ATM显示器右边和“自定义取款”对齐的“<<”help按钮，进入账户自定义取款界面，点击小按钮“2”，“0”，“00”，点击“确定”按钮，钱就这么出来了，呵呵。如图7：


图7



再检查一下帐户万一这机器不牢靠，扣多了就亏大了，看看：


图8



嗯，没错。

好了，到这里我们整个案例操作完了，现在我们要开始考虑如何测试这么一台冷冰冰的，却让我们爱恨交织的机器了，且听下回分解！

下载mod_auth_mysql.tar.gz, 解压后进行目录

#cd mod_auth_mysql

运行下列代码, 进行模块链接

#/usr/local/apache/bin/apxs

–C –I /usr/local/mysql/include/mysql

–L /usr/local/mysql/lib/mysql

–lmysqlclient –lm lz /home/software/mod_auth_mysql/mod_auth_mysql.c

#/usr/local/apache/bin/apxs –I /home/software/mod_auth_mysql/mod_auth_mysql.a

 

重新修改apache配置文件httpd.conf

LoadModule mysql_auth_module /usr/local/mysql/lib/mysql/.libs/mod_auth_mysql.so

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

<Location /svn>

 DAV svn

 SVNParentPath /home/svnroot/repository/

 AuthzSVNAccessFile /home/svnroot/repository/authz.conf

 AuthType Basic

 AuthName "Subversion.zoneyump"

 AuthUserFile /home/svnroot/repository/authfile

 Require valid-user

 

AuthMySQLEnable on

 AuthMySQLHost localhost

AuthMySQLUser bugs

 AuthMySQLPassword 123

 AuthMySQLNameField login_name

 AuthMySQLPasswordField cryptpassword

#因为bugzilla在default下是用的是crypt,所以这用的是crypt。请注意在不同的#mod_auth_mysql下这个配制有一点不一样！

 AuthMySQLPwEncryption crypt

</Location>

关于什么是测试就不多说了，大家都知道的。关键是理解什么是本地化，什么是国际化？还要理解对什么产品进行本地化和国际化。这里仅以软件作为本地化和国际化的对象进行讨论(实际上，除了软件之外，网站和电子课件都可以进行国际化和本地化)。

软件的国际化和软件的本地化是开发用于全球发行的软件的两个过程和技术。

首先软件在开发阶段要在结构设计和数据类型支持上，满足世界各地用户的需要。例如，微软开发的Word 2003，它最先是用英文开发的。但是，英文的Word 2003可以安装在简体中文的Windows XP Professional上，而且支持中文输入法(IME)，能够正确的输入、显示、打印和保存，而不是乱码。这就是代码能够支持汉字的双子节字符集。

另外，Word 2003能够支持中文的数据格式，例如日期采用年月日，而不是月日年。另外就是中文关键词排序，简体中文词组按照第一个字的汉语拼音的顺序排序，而英文单词按照首字母排序。说明软件能够支持不同国家用户的特殊数据类型。

所以软件国际化是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化习俗，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。

那么什么是软件本地化呢？

还是拿Word 2003为例说明，前面说了，英文Word 2003能够在简体中文Windows 2003上安装和使用，但是大家很少直接使用英文的Word 2003，为什么呢？ 因为使用英文的软件不如使用中文的软件更易于理解。

把英文Word 2003经过语言处理和技术加工，重新制作成简体中文Word 2003的过程，称为英文Word 2003的软件本地化。当然除了简体中文之外，Word 2003还有几十种其他语言的本地化，例如，日语、德语、法语，繁体中文的Word 2003。

所以，软件本地化是对原始语言（例如，英文）开发的软件进行语言转换和工程处理，生成不同语言版本的技术。

最后说说什么是国际化测试和本地化测试？

单独说“本地化测试”和“国际化测试”很容易引起误解，最好限定测试对象。最好的说法是“本地化软件测试”，“软件国际化测试”和“国际化软件测试”。

“本地化软件测试”前面已经说了，就是在本地化的操作系统上测试本地化软件，例如在简体中文Windows XP Professional上测试简体中文的Word 2003。

“软件国际化测试”和“国际化软件测试”是两个不同的概念。“国际化软件”也称为“全球化软件”，是在世界多个国家和地区发行的软件。完整的国际化软件需要经过软件国际化设计和软件的本地化加工两个阶段。

“国际化软件测试”的内容分为“软件国际化测试”和“本地化软件测试”，“软件国际化测试”是“国际化软件测试”的子集。

国际化软件测试首先要经过软件国际化测试，等到本地化软件开发出来后，再进行本地化软件测试。
软件国际化测试的对象是采用国际化方法进行设计的软件，例如英文的Word 2003。 测试的环境是各种不同语言的操作系统，例如简体中文、繁体中文、德语、日语等的Windows 操作系统。
国际化测试的内容包括产品的安装和卸载，是否支持不同区域设置的数据格式（日期、时间、度量衡、地址、电话号码、纸张格式），是否支持不同字符集的编码和输入、编辑、显示和保存。

软件本地化的对象是经过本地化后的软件，例如，简体中文的Word 2003。
对于简体中文的Word 2003的本地化测试的环境是简体中文的Windows，对于德语Word 2003而言测试环境是德语的Windows。
软件本地化测试的内容包括：软件的本地化内容是否准确，软件经过本地化后功能是否失效，软件控件（例如按钮的大小和按钮上的文字）的大小和位置是否适当。 

一、目的

        对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以便进一步指导我们的软件测试工作。

    二、概念

        BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。

    三、 BUG 的类型划分

    功能类

    A. 重复的功能

    B. 多余的功能

    C. 功能实现与设计要求不相符

    D. 功能使用性、方便性、易用性不够

    界面类

    A. 界面不美观

    B. 控件排列、格式不统一

    C. 焦点控制不合理或不全面

    数据处理类

    A. 数据有效性检测不合理

    B. 数据来源不正确

    C. 数据处理过程不正确

    D. 数据处理结果不正确

    流程类

    A. 流程控制不符和要求

    B. 流程实现不完整

    提示信息类

    A. 提示信息重复或出现时机不合理

    B. 提示信息格式不符和要求

    C. 提示框返回后焦点停留位置不合理

    建议类
 
    A. 功能性建议

    B. 操作建议

    C. 检校建议

    D. 说明建议
 
    性能类

    A. 并发量

    B. 数据量

    C. 压缩率

    D. 响应时间

    常识类

    A. 违背正常习俗习惯的，比如日期 / 节日等

    特殊类

    A. 不符合 OEM 版本或 DEMO 版本特殊要求的

 在项目开发团队中，由于资源限制，人们常常敷衍地执行其中的某个活动。经常被忽视的一个活动就是测试管理，这个坏习惯使我在近期一个测试项目中遭受到沉重打击。

测试管理混乱带来的挑战

　　软件测试的 痼疾之一是人们并不清楚究竟该做什么，但却一直忙碌不停地测试，这种情况往往会使测试半途而废，或返工重来，造成很大的损失。一般来说，测试管理应要严格遵循项目活动的内在规律才有可能避免不必要的损失，少走弯路。但常常有许多因素导致项目测试管理出现失控，如何做好测试管理是目前大部分项目团队面临的主要问题之一。
　　
　　（1）资源管理不善，为测试带来隐患

　　在软件测试中，通常合理分配和管理测试所需的资源是一件困难的事情，这些资源不光是硬件设备和软件工具，还包括时间和人力资源。例如，在传统手工管理方式下，测试与需求间的关系很难进行跟踪控制，经常出现测试未完全覆盖需求，导致测试不全面的问题，或造成测试资产遗漏，无法对测试资产进行有效的跟踪管理。
　　
　　另外，测试管理还有一个重要的方面就是时间管理，很少软件项目在开发周期里拥有充足的时间完成许多高水平的测试。通常情况是软件开发生命周期里本来就很短的“测试周期”总是不可避免地会被耽搁。所以，许多项目都很有可能在测试管理上面临时间表和进度的限制。在测试管理中这种限制会不断使测试任务变换优先级，而不断转换工作会为测试结果和测试方法带来隐患。
　　
　　（2）协调复杂，难以保持测试与开发同步

　　软件质量需要测试人员与开发人员团队共同协作，但软件开发中总有一个惯例，那就是测试团队的工作只有测试人员关注。实际上，测试与开发同步协调是十分重要：一方面可让开发人员了解当前的测试质量水平以及哪些已经被测试、哪些还没有被测试。另一方面，也是为了有效地使用宝贵时间，让测试团队更及时跟上不断变化的代码、工作版本和环境。例如，测试管理者必须精确识别要测试的工作版本和测试的合适环境，测试错误的工作版本会导致时间的浪费，并严重地影响项目进度。
　　
　　（3）测试报告信息混乱，严重影响决策和判断

　　测试报告如果能够为项目传达测试状态和一些质量评定标准，这对项目各成员理解测试工作非常有帮助。因此，测试报告应是十分简洁，能提供恰当的信息。如果报告只有非常少的信息，那么除了对测试团队减少认知缺陷的价值外，项目其它成员也将不能充分了解所表示的质量问题。但从另一方面来说，但如果报告有过多的信息，那么测试信息就变得模糊，项目其它成员对于测试和质量信息的实质了解也将被减少。因此，报告信息混乱，过多或过少都会严重影响决策和判断。
　　
　　（4）多区域和多团队协调困难，常使测试管理乱成一团

　　除了软硬件测试等资源以外，还需要管理测试团队。测试管理必须调动和协调团队工作的所有团队成员，对于有多个不同区域和团队合作的项目来说，缺乏有效的测试管理会使到多个区域和团队乱成一团。

为什么需要测试管理工具？

　　（1）什么是测试管理

　　测试最重要的是什么呢？我一直认为是有效的测试管理。测试管理包括对人的管理、对流程的管理、对具体版本的管理等。测试要考虑的所有问题都可以列入此列，例如测试人员的分工、测试规程的制定、测试流程的裁减、采用什么的测试流程、测试设计怎样操作、测试执行如何计划、和测试度量怎样进行等。
　　
　　因此，测试不仅仅是一种技术，不仅仅是开发完成后的验证活动，真正要做好测试，更需要建立起一套测试管理体系。一个测试项目成功需要很多因素，测试管理是其中的重中之重。测试管理包含计划、创作、执行和报告测试，以及如何使测试与软件开发工作的其他部分结合起来。有组织的测试管理将会减少错误而且使得复杂的项目得到更有效的、有力的管理。
　　
　　（2）什么是测试管理工具

　　对于测试管理来说有许多令人生畏而且不可避免的挑战，好消息是有大量管理工具可以应对这些挑战。测试管理工具是指用工具对软件的整个测试输入、执行过程和测试结果进行管理的过程，可以提高测试的效率、测试时间、测试质量、用例复用、需求覆盖等。
　　
　　由于软件项目测试越来越复杂，单纯增加测试人手已不能解决问题，需要一个软件工具来管理测试。软件测试工具的种类繁多，主流的测试工具可分为：测试管理工具，负载测试工具，功能测试工具等等。我的理解是而相比于测试管理工具，其他的具体的测试技术工具都是次要因素，比如各种测试工具、白盒测试、黑盒测试等。这些具体的测试技术都是相对比较“固化”的，测试技术人员都会慢慢的掌握它们。但我们在评价一个测试团队的测试水平，或者在评估一个项目的测试质量时，不会因为这些具体的测试技术掌握与否而断言，更多的考虑应是它的测试管理过程。
　　
　　一个完整的测试管理工具，应能用于测试的计划、文档和缺陷跟踪等各种测试行为的管理,并能提供对人工测试和自动测试基于过程的分析、设计和管理功能，把应用程序测试中所涉及的全部任务集成起来。包括测试中包含的所有工作，跟踪测试资产中的依赖关系和相互关联，并且能对质量目标进行定义、测量和跟踪。

许多项目都会出问题。项目经理应准备一组能够应用于不同场合的问题解决技巧。“因果”图是一个用来分析明显有许多相关原因的复杂问题的技巧。根据它的形状，这个图也称作鱼骨图（你听说过的其他名字可能为石川图。这个名字源自石川薰，在1943年首次应用此图的日本教授。）它包括下面这些优点：

        它允许探讨各种类别的原因。 
        它鼓励通过自由讨论发挥创造性。 
        它提供问题与各类原因的直观图。 
        首先，描述图表最右边的问题。这可能是一个实际问题，也可能是一个征兆——这时你还不能完全确定。

        朝着方框划出一条水平长箭头。这个箭头将作为图的骨干，其他主要或次要原因通过它联系或分类。（见图A）

图A

       

        确定可能的原因，沿着鱼骨图的“骨干”将它们分类为主要类别。应该进行自由讨论以确定主要类别。也就是说，这时一个类别是否有潜在的原因，你不用担心存在不同意见。只要将它们列出来就行。保证在图表上的主要类别之间留有足够的空隙，以便稍后可以增加次要的详细原因。（见图B）

图B

       

        了解上面确定的主要原因类别的更加详细的解释，继续进行自由讨论。团队应询问每个类别是一个原因还是一个征兆。如果它是一个征兆，则设法在连接适当主要类别的斜线上确定更加详细的原因。（见图C）

图C

       

        有时候，详细原因可能有其他更为琐细的原因。如果是这样，在详细原因线上连接其他的线。一般来说，三层细节是这个图表的实际限制。

        在完成对主要原因/征兆以及更为详细的原因和征兆的自由讨论后，团队可以开始对信息进行分析。评估每个主要原因及与其相关的潜在详细原因。记住，原始列表是通过包括所有观念的自由讨论编辑的。现在，你必须决定哪一项最有可能是原因（或原因之一）。圈出最有可能并需要进一步研究的项目。

        如果就研究的首要领域没有取得明显的一致意见，则要应用某种投票机制，通过最大成功率来缩小首要选择。针对每个圈定的项目，讨论他们如何对问题产生影响。

        一旦你圈定了最有可能的原因，你应该制订一个调配这些原因的行动计划。这一计划最可能包括一些高级行动，并将原因指定给一个团队成员，让其在会后进行分析。

        注意，这个技巧要用于解决具有许多原因的复杂问题，并允许你为问题确定潜在的原因，再决定哪个原因最有可能得到解决。

        “鱼骨图”分析法是在不断提出问题的过程中，使问题逐个解决。

        鱼骨图分析法的要诀：确定问题类别，找出主要问题，提出解决方案。

        · 从主刺到小刺的思维。先找出最主要的问题，分析导致此问题的因素，逐层递推，分析导致各个小问题的因素，对最小的问题提出解决方案，从而使主要的问题得到解决。

        · 从小刺到主刺的思维。与从主刺到小刺的思维相反，从各小问题推到主要的问题。

　Web服务器搭建完成上线在即，其能够承载多大的访问量，响应速度、容错能力等性能指标，所有这些是管理人员最想知道也最为担心的。如何才能知晓这一切呢?通过工具进行Web压力测试是个好方法。通过它可以有效地测试Web服务器的运行状态和响应时间等性能指标。

　　一、测试环境：

　　hardsoft：CPU:Athlon XP2500+、内存512MB、硬盘80GB

　　Server OS：Windows Server 2003

　　IIS: 6.0

　　BBS: 动网 7.0

　　IP: 192.1681.20

　　Tool：Web Application Stress Tool

　　二、工具介绍

　　可用来进行Web压力测试的工具有很多，比如微软的Web Application Stress、Linux下的siege、功能全面的Web-CT等等，这些都是非常优秀的Web压力测试工具。虽然这些工具给我们测试服务器承受能力带来方便，但是它们却是“双刃剑”，攻击者利用随便一种比较全面的测试工具就可以对一台小型的Web服务器发动灾难性的拒绝式攻击。

　　下面笔者就以微软的Web Application Stress Tool(简称WAST)为例进行一次Web压力测试。这是由微软的网站测试人员开发的专门用来进行实际网站压力测试以一套工具。透过这套功能强大的压力测试工具，管理人员可以在网站实际上线之前先网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。

　　三、工具设置

　　下载并安装WAST，过程及其简单。然后运行WAST可以看到其界面非常简洁，在对目标Web服务器进行压力测试之前，首先要对它进行一些必要的设置。

　　1、设置并行连接数

　　点击左侧的“Defaults→Settings”打开设置面板。在Concurrent Connections下进行并行连接设置。Stress level (threads)是最少线程，Stress multiplier是最大线程。这里的线程是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么可以设置得更高一些。

　　2、设置持续时间

　　在“Test Run Time”中用来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别。

　　3、其余设置

　　“Rpquest Delay”设置延迟时间，我们设置为100~500。

　　“Suspend”设置设定挂起时间。

　　Warmup时间是初始化测试运行时间。

　　cooldown时间就是指定结束阶段的测试时间。

　　Bandwith”指定带宽瓶颈，允许你模拟从14.4 Kbps的modem连接到T1 (1.5 Mbps)的Local Area Network (LAN)连接的网络带宽。

　　Redirects设置重定向时间。

　　“Throughput”设置用户、密码页面状态保存等是否启用

　　“Name resolution”设置是否进行名称解析。

　　所有以上的选项大家可以根据自己的需要进行设置。

　　四、压力测试

　　设置完成后就可以进行压力测试，测试的步骤如下：

　　第一步：点击工具栏上的“new scrīpt”按钮在打开的面板中点击“Nanual”按钮创建一个新的测试项目。在打开的窗口中对它进行设置，在主选项中的server中填写要测试的服务器的IP地址，这里我们填写192.168.1.20，在下方选择测试的Web连接方式，这里的方式Verb选择get，path选择要测试的Web页面路径，这里填写/Index.asp即动网的首页文件，WAST可以设置更多的Path。

　　第二步：在“Settings”的功能设置中将Stress level (threads)线程数设置为1000。完毕后，点工具中的灰色三角按钮即可进行测试。测试过程中我们可以从服务器的任务管理器中看到CPU使用率已经 达到100%，损耗率达到最大。在CMD窗口中使用命令netstat -an,可以看到客户端的IP地址在服务器上的80端口进行了非常多的连接见图6，而且Web网站已经打不开了，提示过多用户连接。

　　总结：通过Web压力测试，管理员对Web服务器的抗压能力有了大概的把握，从而根据实际需要可以进行服务器硬件扩展，同时也为系统设置、软件选择等提供了依据。总括来说，在Web服务器正式发布前进行压力测试是非常必要的。

基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。

　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。

　　在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就　　会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

　　一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

　　网站测试流程、要求及测试报告

　　一个网站基本完工后，需要通过下面三步测试才可以交活。

　　一、 制作者测试，包括美工测试页面、程序员测试功能。在做完后第一时间内有制作者本人进行测试。

　　a) 页面 包括首页、二级页面、三级页面的页面在各种常用分辨率下有无错位;图片上有没有错别字;各连接是否是死连接;各栏目图片与内容是否对应等

　　b) 功能 达到客户要求;数据库连接正确;各个动态生成连接正确;传递参数格式、内容正确;试填测试内容没有报错;页面显示正确

　　二、 全面测试 根据交工标准和客户要求，由专人进行全面测试

　　也是包括页面和程序两方面，而且要结合起来测，保证填充足够的内容后不会导致页面变形。另外要检查是否有错别字，文字内容是否有常识错误。

　　三、 发布测试 网站发布到主服务器之后的测试，主要是防止环境不同导致的错误

案例：

很多朋友对PHP环境很为难，经过多次尝试都无法正确配置，其实配置PHP环境并不难，掌握要领就会很轻松，对于初级用户和想简单配置PHP环境的朋友，本人提供一种方法和PHP环境文件，就会让您轻松拥有高性能PHP环境，而且还可以使用虚拟主机管理系统哦！

　　安装：首先必须确认系统中已经安装了IIS，系统推荐：win2003服务器版，win2000专业版和xp系统不支持多用户IIS，虚拟主机管理系统无法进行管理,xp系统IIS存在问题调试程序会经常出现不正常。对于作网站和经常调试教本的朋友还是推荐使用win2003服务器版。把系统做好配置好玩游戏的话这两个系统都很不错的，有朋友说win2003系统很多功能都关闭了而且界面也没有XP好看，不适合个人用，其实这个东西只需要您稍微改一下，把默认关闭的东西打开，就是一个很不错的个人电脑用的系统（win2003系统的优化设置方法见：http://www.ie2004.net/jok/index1.htm

　　安装说明：注意：php和mysql均安装到D盘，自己拥有服务器的朋友也建议这样安装
　　大致路径如下：
　　D:盘--serv-u（只对服务器用户，本机调试免）
         mail（只对服务器用户，本机调试免）
         php
         mysql
         EfangVHost4.1（易方虚拟主机管理系统4.1）
　　E:盘--www（IIS用户目录，存贮IIS用户数据或者本机调试数据）

　　1、PHP_setup.exe 安装到D盘PHP目录，完全自动安装自动配置，无需手工配置，解决初级用户不会设置PHP.INI的问题
　　此文件安装完IIS也会自动配置完成，无须手工更改。
　　2、将mysql-4.0.24-win文件夹拷贝到D盘，文件夹重命名为mysql
　　使用mysqladmin，更改默认密码。当然也可以不更改，密码为空
　　进入命令提示符：进入D盘的mysqlin文件夹，mysql的初始管理帐号是root，没有密码。如果想把默认帐号root密码更改为：123456则执行： mysqladmin -u root -p password 123456
其中password不用动，后面的123456是更改后的密码，回车以后会再次提示输入密码，不用改直接回车，密码就会变为123456
　　执行：mysql中BIN中的winmysqladmin.exe文件即可启动MYSQL
　　第一次需要添加一次默认的密码，此密码随意。
　　3、安装ZEND
　　安装路径默认，提示需要加速的WEB目录时选择你的WEB目录，比如WEB目录在E盘的WWW中，就选择e:www此过程需要执行两次
　　提示是否需要更改系统文件夹中的PHP.INI时，选择是。
　　4、安装虚拟主机管理系统：
　　默认安装路径为D盘，安装完执行文件夹中的“安装服务.bat”文件启动易方主机管理系统。
　　浏览器中执行http://127.0.0.1:9999即可登陆管理系统，默认用户名和密码都是admin
　　主机管理系统使用说明请到软件官方www.efang.com.cn下载

　　问题解释：
　　1、如何使系统支持PHP教本：执行安装中的PHP安装系统就可以自动支持。
　　2、MYSQL和主机管理系统的连接：将MYSQL启动。将虚拟主机管理系统安装到D盘
　　执行：D盘EfangVHost4.1文件夹中的“安装服务.bat”文件启动易方主机管理系统。
　　浏览器中执行http://127.0.0.1:9999即可登陆管理系统，默认用户名和密码都是admin
　　进入后选择“系统配置”－“安装设置MySQL”
　　第一次运行需要安装“安装ODBC_3.51.11驱动(MySQL) ”
　　然后填写主机地址：此地址默认不用更改（localhost），MYSQL用户名：root，密码：(此密码为上面安装步骤2中更改后的密码，如果没有更改则密码为空)。如果连接MYSQL成功会有一个成功的提示。
　　3、主机管理系统开通支持MYSQL和PHP的空间：
　　选择“主机类型”，编号处填写：ht01，并设置相应的参数，其中“站点目录”填写“e:www”
　　选择：支持MySQL
　　然后选择“创建站点”选择主机类型为：ht01，管理员帐号和密码随意。
　　然后点击“创建站点”，成功后点击：“立即管理”，选择“设置”中的“创建MYSQL数据库”，则此空间开通完毕并已经支持PHP和MYSQL。如果是本机调试，则需要进入此空间的“IIS设置中”，把主机头的IP中填写进本机调试IP，比如：127.0.0.1设置完成浏览器输入：127.0.0.1就可以显示站点开通成功的画面
　　4、win2003系统无法本机调试：
　　打开IIS，选择：“WEB服务扩展”，将“Active Server Pages”设置“允许”
　　将“应用程序池”中的默认池“DefaultAppPool”中的“标识”中的“预定义帐户”更改为一下就可以了，一般都是“网络服务”。
　　5、我的PHP教本调试的有问题，想把MYSQL库删除重新调试怎么办？
　　很简单，进入mysql文件夹的data目录，删除刚才虚拟主机管理系统中自动建立的那个文件夹中的文件即可，当然也可以在虚拟主机管理系统里把MYSQL建立的数据库删除重新建立。

看到网上写的这篇文章，虽然我没有在windows下配置过PHP，学习一下，下回自己补一个linux下配置文档

这两天网站在进行导航条改版，进行了测试，发现导航条测试有这么些测试点，今天想想记录一下吧，兴许可以唤醒写blog的动力。导航条到底有哪些测试点呢？期待各位同行补充各自的观点。^_^。

        小小的导航条，有啥好测试的呢？通常你测试的时候会发现什么问题和特点吗？我这两天测试了导航条，产生了如下感想，各位同行，你想到的和我一样吗：

        1、 导航条测试分两类：应用软件类、门户网站类

        2、 导航条的价值：

        对于应用软件类

        让用户快速的找到要操作的功能；

        让用户清楚的知道自己在什么地方；

        指导用户如何去使用该软件；

        好的导航条名称让用户能快速的自学学习软件；

对于门户网站类

        导航条可以让用户知道要找、要看的东西在哪个大分类里；

        让用户知道自己目前在网站的那个地方，不会迷失方向

3、 由于这次测试的是门户网站类导航，因此这次把门户网站类的导航条测试点记录如下：

        功能方面：

        1） 一、二级导航中的文字链接页面打开方式一致；要么新页面，要么当前页面；

        2） 各链接页面正确显示，不出现错误；

        UI方面：

        1） 一、二级导航中的文字颜色、大小、风格显示一致；

        2） 每选中导航中的页面，相应的该页面的导航文字为选中显示状态；让用户知道自己在看的是那一页；

        3） 导航条中的页面文字显示正确，无错别字；

        4） 同一导航在不同地方显示的内容和排列的顺序一致；

        兼容性方面：

        在不同的浏览器下查看页面显示是否正确；

        易用性方面：

        1）导航名字容易明白，见名知道其意思；页面内容和其名字表达内容相呼应；

        2）导航栏排列方式符合用户使用逻辑，查看简单，分类级别层次不超过2层；

        4、 至于应用软件类的导航条，先暂时不写了，等那天心血来潮，想写了再把它补上。大家如果有想写的也可补充补充。^_^。