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 电子书

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

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

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



嗯，没错。

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

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

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

首先软件在开发阶段要在结构设计和数据类型支持上，满足世界各地用户的需要。例如，微软开发的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、 至于应用软件类的导航条，先暂时不写了，等那天心血来潮，想写了再把它补上。大家如果有想写的也可补充补充。^_^。

SQL2005 分五个版本，如下所列，
　　1.Enterprise(企业版),
      2.Development(开发版),
　　3.Workgroup,(工作群版)
　　4.Standard,(标准版)
　　5.Express.(嗯，估且就叫它简易版吧)
　　这几个版本，我们究竟应该使用哪一版呢﹖
　　这是许多初学SQL2005的人最常问的问题。
　　我简单的比较一下 Enterprise, Development 和 Express 等三个版本:以功能言，Enterprise 版和 Development 版的功能一模一样。两者的差别，除了授权不同外，最主要的差别是:
　　Enterprise版的数据库引擎只能安装在Win2003Server(或其他Server)。
　　如果你想安装在WindowsXP Pro系统上，你应该安装SQL2005Development版(开发版)。
　　注:有人问，什么是「数据库引擎」。嗯，数据库引擎是SQL2005的核心，是最主要的数据库管理功能模块。没有它，就不是数据库管理系统了。
　　很多人下载 SQL2005Express版，因为它是免费的，可以直接从微软网站上下载。但是，它除了支持的内存比较少外，最主要的是
　　它缺少相当于SQL2000下的「企业管理器」和「查询分析器」。
　　注:SQL2000下的「企业管理器」和「查询分析器」在SQL2005已合为一，称为 Management Studio。
　　因此，如果你是初学者，如果你只是想要在家里学习学习，如果你的环境是 WindowsXP Pro，那么，你应该选择的是 SQL2005Development(开发版)，而不是SQL2005Enterprise(企业版)或SQL2005Express(简易版)。
　　SQL2005 入门者，你选择正确了吗﹖
 
     我就是从“ Microsoft.SQL.Server.2005.Enterprise.Edition.DVD-ZWTiSO，请大家下载加速 "
上下载的,说明文件里显示是"标准版和企业版",但是我在安装的时候显示不能满足最低的硬件要求（我的机器的配置：server2003企业版 AMD2800+，512M DDR400内存，系统盘有16G的空闲空间），在组件选择框里，只能看见native client和安装sample 数据库，这究竟是什么原因？2005的硬件要求真的那么高吗？ 或者说这到底影响安装和使用吗?
在我不改变硬件的情况下怎么解决上面的问题啊
 
应该是满足硬件要求的，看安装时的提示是什么吧
 
2005数据库安装心得

我的环境是xp sp2 EN，SQL 2005 Dev版，内存512MB。
　　首先，我的系统已经使用半年多了，装有VS2003，以前还装过SQL2000，netFramework2.0beta，还有好几个beta版的SQL 2005，可谓十分“肮脏”了，呵呵。最早的时候我下过一个2005EE版，怎么也安装不上，后来发现原来是EE不支持xp =_= ，然后就下了DE版的。

　　刚开始安装的时候吓了我一跳，丫的居然要占用我C盘1300多MB!!忍了。(我是把SQL装在F盘的，但是居然还需要C盘1300多MB)。但是却安装失败，看了一下安装日志，天书，不明白。只知道是native client几个组件安装不成功。重复多次问题依旧。

　　研究安装包之后，发现里面有两个主要的文件夹，是server和tools。顾名思义，server里面肯定是服务的安装文件了，而tools里面应该是那些工具组件的安装文件。进入tools里面，果然有个setup，运行之，竟然安装成功了，而且只占了我C盘200多MB，好兴奋(没有选择BI，就是那个商业智能组件，太大了)。然后重启电脑(不是必须的，只是一次setup之后系统慢的不行了)，进入server目录下面，当然也有一个setup啦，运行之，呵呵，果然是安装服务用的啊。这次也顺利安装成功了。再去看C盘，哈哈，一共只用了我300多MB，竟然节省了1GB。

　　当然了，其实一起安装的话，也不一定会用完1300MB的空间的，因为安装结束之后还会自动删除一些垃圾文件的。但是不管怎么说，至少让我能正常安装了。我的C盘只有1400的空闲空间了，不知道起初安装失败是不是跟这有关系。

　　至此，SQL 2005已经成功的在我电脑上安家了。安装的时候，如果你的电脑和我的一样是内存不足(小于1GB)，性能也不足够大(我的CPU是centrio 1.3G，呵呵，装在本本上了)，建议在安装的时候把系统开始是需要运行的服务全都不选择，用的时候再手动运行好了。

　　运行Management Studio，嗯，速度还挺快的呢。连接服务器，竟然没有localhost，呵呵，打开server configuration manager,把右边那个MSSQLSERVER运行起来。ok，这次没有问题了。

　　使用一切正常，就是发现从sql2000里面备份出来的数据库在2005下只能通过sql语句修改数据，而不能所见及所得的修改，不知道怎么回事。

　　btw:后来又把商业智能组件装上了，只用了C盘150MB，开心。
 
SQL2005安装过程提示com+目录问题警告处理

安装sql2005一直失败,以为提示的问题是这个com+目录问题警告所致,找了很久找到这个问题的解决方案
sql2005_STD_X86在XPSP2下安装失败的一点经验
软环境是XPSP2，安装SQL2005_STD_X86版。
故障提示：
1。如果 SQL Server 安装程序失败，安装程序将回滚所安装的系统，但可能不会删除所有 .manifest 文件。解决方法是重命名这些文件，然后重新运行安装程序。有关详细信息，请参阅“如何处理 SQL Server 安装过程中的 COM+ 检查失败问题”。如果未运行 Microsoft 分布式事务处理协调器 (MS DTC)，或者，在使用 Microsoft 群集服务器的情况下，如果 MS DTC 不是群集资源，则可能会发生 COM+ 错误。COM+ 依赖于 MS DTC，而 Integration Services 中的消息队列任务依赖于 COM +。如果出现 COM+ 错误，则只有将 COM+ 系统正确配置后，Integration Services 中的消息队列任务才可用。
  2。对性能监视器计数器注册表值执行系统配置检查失败。有关详细信息，请参阅自述文件或 SQL Server 联机丛书中的“如何在 SQL Server 2005 中为安装程序增加计数器注册表项值”。
安装中止。
查找联机丛书，有如下提示：
  1。Microsoft SQL Server 2005 安装程序检查 COM+ 是否已正确配置。如果发现配置错误，安装程序仍将继续，但是在系统配置检查 (SCC) 报告中显示以下警告：
“如果 SQL Server 安装程序失败，安装程序将回滚所进行的安装，但可能不会删除所有的 .manifest 文件。解决方法是重命名这些文件，然后重新运行安装程序。”
如果未运行 Microsoft 分布式事务处理协调器 (MS DTC)，或者，在使用 Microsoft 群集服务器的情况下，如果 MS DTC 不是群集资源，则可能会发生 COM+ 错误。COM+ 依赖于 MS DTC，而 Integration Services 中的消息队列任务依赖于 COM +。如果出现 COM+ 错误，则只有将 COM+ 系统正确配置后，Integration Services 中的消息队列任务才可用。
若要使用消息队列（亦称 MSMQ），请确保 MS DTC 正在运行并且已正确配置。如果 SQL Server 安装在群集上，则 MS DTC 必须是群集资源。
  按照下列过程重新安装 COM+。
  安装组件服务管理单元
  在 Windows 桌面上，单击“开始”，然后单击“运行”。
  在“打开”框中，键入 MMC，然后单击“确定”。
  在“控制台”窗口中，单击菜单栏上的“文件”，然后单击“添加/删除管理单元”。
  在“添加/删除管理单元”窗口，单击“添加”。
  在“添加独立管理单元”窗口，从管理单元列表中选择“组件服务”，然后单击“添加”。
单击“关闭”以关闭“添加独立管理单元”窗口，然后单击“确定”以关闭“添加/删除管理单元”窗口。
  在“控制台根节点\组件服务”窗口，展开“组件服务”树。这就是当 COM+ 出现问题时，错误消息可能发生的地方。
再次运行 SQL Server 2005 安装程序。如果收到错误消息，请重新安装 COM+。
重新安装 COM+
从控制面板的“添加或删除程序”中，单击“添加/删除 Windows 组件”。
在“Windows 组件向导”中，不对选择做任何更改，单击“下一步”。
一直单击以完成向导，然后再次运行 SQL Server 2005 安装程序。
  2。在 SQL Server 安装开始前，Microsoft SQL Server 安装程序中的安装配置检查器 (SCC) 会验证计数器注册表项的值。如果 SCC 无法验证现有的注册表项，或 SCC 无法运行 lodctr.exe 系统程序，则 SCC 检查会失败，致使安装受阻。
错误编辑注册表会严重损坏您的系统。更改注册表项之前，建议您备份计算机中的所有重要数据。
手动设置计数器注册表项的增量
在 Microsoft Windows 2003 或 Windows XP 桌面上，依次单击“开始”、“运行”，然后在“打开”中键入 regedit.exe，再单击“确定”。在 Windows 2000 中，使用 regedt32.exe 启动注册表编辑器。
定位到以下注册表项：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib]
"Last Counter"=dword:00000ed4 (5276)
"LastHelp"=dword:00000ed5 (5277)
上一步的“Last Counter”值 (5276) 必须与以下注册表项中“Perflib\009”的“Counter”项的最大值匹配，并且上一步的“Last Help”值 (5277) 必须与以下注册表项中“Perflib\009”的“Help”项的最大值匹配。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009]
注意 009 是英文中的一个示例。“Last Counter”和“Last Help”值是由 Windows 动态分配的；这两个值会因计算机的不同而不同。
如有必要，可修改“\Perflib”项中的“Last Counter”和“Last Help”值的值：在右侧窗格中，右键单击“Last Counter”或“Last Help”，单击“修改”，再单击“Base = "Decimal"”，在“值数据”中设置值，再单击“确定”。如有必要，对另一个项重复以上过程，然后关闭注册表编辑器。
再次运行 SQL Server 安装程序。
解决过程：
COM+检查失败不用说肯定是组件消息队列下的组件没安装或服务没启动。本机没有安装过消息队列，找出系统盘安装消息队列组件，在组件安装中提示MSDTC服务没有启动，在这步晕了长很时间，MSTDC在服务中怎么也找不到，后来想会不会是DTC（脑子有点笨，其实从MSMQ这名称上就应该想到），一看果然有Distributed Transaction Coordinator（DTC），但是这个服务启动不了，后来查找相关资料：MSDTC( Distributed Transaction Coordinator )服务必须在 NT AUTHORITY\NetworkService 帐户下运行；即使是 NT AUTHORITY\Network Service（注意，Network和Service中间有空格）也不行（至于这两个帐户的区别，在网上也没有找到，还望大家不吝赐教 ）。如果登录帐户被更改，MSDTC服务会继续运行，但是在执行的时候可能会出错。而且，在事件日志的“应用程序”里面可以发现如下的出错信息：
正在运行 MS DTC 服务的帐户无效。 如果使用 Microsoft Management Console (MMC) 中的“服务”管理单元更改了服务帐户信息，就会发生这种情况。 MS DTC 服务将继续启动。请确认使用“组件服务管理器”更新了 MS DTC 服务帐户信息。
要更改成正确的登录帐户，我们可以：
在服务中找到Distributed Transaction Coordinator服务，选择“属性”；
在“登录”选项卡中，选择“此帐户”，帐户名填写“NT AUTHORITY\NetworkService”，密码为空；
在点击“确定”后重新启动服务。
或者，在命令行下运行 msdtc -uninstall ，卸载 msdtc 服务；
再运行 msdtc -install ，安装 msdtc 服务。
MSTDC服务成功启动，组件服务中“COM+应用程序”可以访问，上面第2项故障没去解决，先试着安装看看有没有错误，令人惊喜，安装检查一切顺利，第2项错误同时也解决了。
当然，解决问题的过程同样的系统环境也不尽相同，在这里谈一下我安装的小挫折，希望可以给碰到相同问题的朋友有些提示作用。
 
 
sql2005安装过程owc11错误处理

最近安装了很久的sql2005,过程中间出现很多问题,之前的com+目录警告是一个部分,处理过之后还是发现一直无法安装成功,(为此我安装了10+)次才解决问题
在安装过程中发现以下错误
Product         : OWC11
Error           : 错误 1706。安装程序找不到需要的文件。请检查网络连接或 CD-ROM 驱动器状态。对于这个问题的其他可能的解决方案，请参阅 C:\Program Files\Microsoft Office\OFFICE11\2052\SETUP.CHM。
--------------------------------------------------------------------------------
发现自己的ocw11没有安装导致服务器的有关组件全部无法安装,每次都是安装失败,
在microsoft ocw11下载地址
找到microsoft的ocw11,选择简体中文后下载安装后发现还是出现相同的问题,
把下载下来的ocw11解压缩后观察该ocw11.xml,发现sql 2005的server的setup目录下面有相同文件名文件,再次逐次对比发现该ocw11里面的文件包里面的文件对应的setup里面全部都有,不过发现2个chm的后缀不同,一个是10XX,一个是2052,呵呵,原来是版本不同
直接运行setup目录下面的setup,选择修复或全新安装全部提示错误的文件源,再次观察,把setup目录下面对应的的ocw11文件全部拷贝到硬盘上面,再次运行修复成功,之后安装sql2005终于一路成功,困扰了我2天的问题终于解决,特此把本文于全体学习sql2005的朋友分享,希望大家少走弯路.一起交流sql的有关功能

使用VU时，测试代码是自动生成的，但了解手工编写测试代码的方法，有助于更好地实施单元测试。这里用一个简单的例子，说明如何编写测试代码进行单元测试。可以用一个简单的方式来组织测试代码：一个类对应一个测试类，一个函数对应一个测试函数。

产品类：
class CMyClass 
{
public:
    int Add(int i, int j);
    CMyClass();
    virtual ~CMyClass();

private:
    int mAge; //年龄
    CString mPhase; //年龄阶段，如"少年"，"青年"
};

建立对应的测试类CMyClassTester，为了节约篇幅，只列出源文件的代码：
void CMyClassTester::CaseBegin()
{
    //pObj是CMyClassTester类的成员变量，是被测试类的对象的指针，
    //为求简单，所有的测试类都可以用pObj命名被测试对象的指针。
    pObj = new CMyClass();
}

void CMyClassTester::CaseEnd()
{
    delete pObj;
}
测试类的函数CaseBegin()和CaseEnd()建立和销毁被测试对象，每个测试用例的开头都要调用CaseBegin()，结尾都要调用CaseEnd()。

接下来，我们建立示例的产品函数：
int CMyClass::Add(int i, int j)
{
    return i+j;
}
和对应的测试函数：
void CMyClassTester::Add_int_int()
{
}
把参数表作为函数名的一部分，这样当出现重载的被测试函数时，测试函数不会产生命名冲突。下面添加测试用例：
void CMyClassTester::Add_int_int()
{
    //第一个测试用例
    CaseBegin();{ //1
    int i = 0;    //2
    int j = 0;    //3
    int ret = pObj->Add(i, j); //4
    TEST_ASSERT(ret == 0);     //5
    }CaseEnd();                //6
}
　　第1和第6行建立和销毁被测试对象，所加的{}是为了让每个测试用例的代码有一个独立的域，以便在多个测试用例中使用相同的变量名。
　　第2和第3行是定义输入数据，第4行是调用被测试函数，这些容易理解，不作进一步解释。第5行是预期输出，它的功能是当实际输出与预期输出不同时自动报错，TEST_ASSERT(exp)是一个断言宏，表示当exp的计算结果为真时，测试通过，否则，输出报告错误的信息。
　　示例中的格式显得很不简洁，2、３、4、5行可以合写为一行：TEST_ASSERT(pObj->Add(0, 0) == 0);但这种不简洁的格式却有很大的优点，因为它一目了然，易于建立多个测试用例，并且具有很好的适应性，同时，也是极佳的代码文档。
　　建立了第一个测试用例后，最好编译并运行测试，以排除语法错误，然后，使用拷贝/修改的办法建立其他测试用例。由于各个测试用例之间的差别往往很小，通常只需修改一两个数据，拷贝/修改是建立多个测试用例的最快捷办法。
　　
上面是一个最简单的例子，下面再举一个涉及成员变量的例子，这是产品函数：
void CMyClass::Grow(int years)
{
    mAge += years;

    if(mAge < 10)
        mPhase = "儿童";
    else if(mAge <20)
        mPhase = "少年";
    else if(mAge <45)
        mPhase = "青年";
    else if(mAge <60)
        mPhase = "中年";
    else
        mPhase = "老年";
}

    这是测试函数中的一个测试用例：
    CaseBegin();{
    int years = 1;
    pObj->mAge = 8;
    pObj->Grow(years);
    TEST_ASSERT( pObj->mAge == 9 );
    TEST_ASSERT( pObj->mPhase == "儿童" );
    }CaseEnd();

　　前面说过，如果以函数作为测试单元，成员变量的初始值可以看作是输入数据的一部分，其结果值是输出数据的一部分。示例中，首先设定成员变量mAge的初始值，运行被测试函数，在预期输出中，断言成员变量mAge的结果值。如果需要，运行被测试函数前还可以调用其他成员函数，例如：执行被测试函数前可能需要读取文件中的数据保存到成员变量，或需要连接数据库，这些操作称为前置操作。
　　为了访问私有成员，可以将测试类定义为产品类的友元类。例如，定义一个宏：
　　#define UNIT_TEST(cls) friend class cls##Tester;
　　然后在产品类声明中加一行代码：UNIT_TEST(ClassName)。

　　实际上，测试代码中还可能涉及到其他数据，例如全局变量、文件中的数据，或数据库中的数据，后文会作进一步的论述。

1. 为减少重复测试工作的自动化测试工具
2. 高精度专业化的专用测试工具
3. 软件开发过程中各阶段使用的辅助测试工具

     在测试工作中除拥有一个好的测试人员外，更加拥有一个适合的比较优秀的测试工具，这两者相结合，那么做好一项测试工作就很容易了，只要拥有了这两项利器相信测试工作会获得更大的成功，需要说明的是并不是每一项测试工作一定需要测试工具来辅助完成，而是需要应该需要的工具。当然还需要组织及团队有效的推动和支撑，这样其测试工作将会发挥到极致，以至登上华山之颠！时至那时，测试行业的发展将会拔开云雾阳光普照。 【文章来源：文斯测试技术研究中心 ht

文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest

1  概述
    随着软件行业的迅猛发展，软件测试也逐渐受到越来越多的软件公司所重视，然而开发出来的软件直接就可以拿出来做测试吗？根据近几年来的实践证明，在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行，直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持，即要求软件具有可测试性。基于可测试性的目标考虑，良好的架构设计，完备的接口，使得软件测试更加高效和可行，同时产品维护也更加便利。 【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

    本文描述的范围：可测试性定义、可测试性特征、可测试性设计。

    读者对象：系统分析和设计人员、开发人员、测试人员。
 
    参考文献：
    1.《软件可测试性需求设计》               Vince
    2.《高质量C++/C编程指南》              林锐
    3.《软件工程思想》                          林锐

 

2  软件可测试性定义
2.1  可测试性定义
    软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。
    一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。】

2.2  可测试性特征
  1.可操作性：“运行得越好，被测试的效率越高。”
    1)系统的错误很少；
    2)没有阻碍测试执行的错误；
    3)产品在功能阶段的演化(允许同时的开发和测试)。
   
  2.可观察性：“你所看见的就是你所测试的。”
    1)每个输入有唯一的输出；
    2)系统状态和变量可见，或在运行中可查询；
    3)过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)；
    4)所有影响输出的因素都可见；
    5)容易识别错误输出；
    6)通过自测机制自动侦测内部错误；
    7)自动报告内部错误；
    8)可获取源代码。

  3.可控制性：“对软件的控制越好，测试越能够被自动执行与优化。”
    1)所有可能的输出都产生于某种输入组合；
    2)通过某种输入组合，所有的代码都可能被执行；
    3)测试工程师可直接控制软件和硬件的状态及变量；
    4)输入和输出格式保持一致且有结构；
    5)能够便利地对测试进行说明、自动化和再生；
    6)接口和模块易控制；
    7)业务流程和场景易控制。

  4.可分解性：“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试。”
    1)软件系统由独立模块构成；
    2)能够独立测试各软件模块；
    3)业务流程和场景易分解。

  5.简单性：“需要测试的内容越少，测试的速度越快。”
    1)功能简单性(例如：特性集是满足需求所需的最小集合)；
    2)结构简单性(例如：将体系结构模块化以限制错误的繁殖)；
    3)代码简单性(例如：采用代码标准为检查和维护提供方便)。

  6.稳定性：“改变越少，对测试的破坏越小。”
    1)软件的变化是不经常的；
    2)软件的变化是可控制的；
    3)软件的变化不影响已有的测试；
    4)软件失效后能得到良好恢复和隔离。

  7.易理解性：“得到的信息越多，进行的测试越灵巧。”
    1)设计能够被很好地理解并遵循行业规范；
    2)内部、外部和共享构件之间的依赖性能够被很好地理解；
    3)设计的改变被通知；
    4)可随时获取技术文档；
    5)技术文档组织合理；
    6)技术文档明确详细；
    7)技术文档精确性稳定；
    8)相关环境配置说明与操作指导。

 【文章来源：文斯测试技术研究中心 3软件可测试性设计
3.1可测试性设计
    软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试，采取合适的设计模式对软件进行设计。
  1.坚持测试驱动设计（测试先行）的方法。
    优先编写测试代码，这是标准的XP方法。不是说应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它，以这种方式编写测试也更少会使人畏缩。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

  2.尽量做到每个操作对应一个函数，使函数小型化。
    使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使你编写比在其它情况下更少的测试。

  3. 数据的显示与控制分离
    把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。

  4.可控制性设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
   1)全局变量的可控制性设计
     I.在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等；
     II. 可以将全局类型的变量进行分类并封装到一个个接口中操作。
   2)接口的可控制性设计
     各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码. 对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于整个被测系统，即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
   3)模块的可控制性设计
     对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
   4)业务流程的可控制性设计
     在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
   5)场景的可测试性设计
     将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。

  5.可分解性设计
    1)业务流程的可分解性设计
      对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
    2)场景的可分解性设计
      对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。

  6.稳定性设计
    测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】

  7.易理解性设计
    1)设计文档的易理解性
      I.设计参考标准
      II.内容描述主次要分清
      III.依赖关系描述明确
    2)接口的易理解性
      I.接口功能明确
      II.参数有意义
    3)业务的易理解性
    4)场景的易理解性

  8.可观察性设计
    1)业务执行状态和过程可观察性设计
    2)异常情况可观察性设计

  9.测试驱动和桩的设置
    为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。

  10.适合增量式开发的可测试性设计
    在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。

  11.可查询设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
    1)对系统级别的全局变量或者状态设置查询接口；
    2)某一业务或场景调用接口设置接口路径查询

  12.自愈合功能
     在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。

  13. 输出结果
     对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的.测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性.在设置的各个控制点或观察点的结果易于查询、修改等。

  14.提供统一的操作执行面板
     操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但可能被测系统是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以操作整个被测系统的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。如下图所示：

    特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。

 【文章来源：文斯测试技术研究中心

3.2  可测试性编码
  1.注释需要详尽。特别对于接口，要描述清楚功能、实现及参数；
  2.使用模块化方法，编码低耦合、高内聚；
  3.为集成测试与系统联调准备调测开关及相应打印函数，并且要有详细的说明；
  4.为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）；
  5.使用断言来发现软件问题，提高代码可测试性；
  6.用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况；
  7.为测试自动化工具提供所需要的特定“钩子（hook）”；
  8.对于每个功能，提供访问、修改“状态”变量的接口，包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印；
  9.提供查询系统状态的接口。比如内存使用、程序使用进程数等；
  10.对于测试因为环境等因素而可能无法测试的功能，提供接口模拟软件实现该功能的过程；
  11.对于修改功能，提供修改功能参数单位的接口，以便于进行如软件性能等的测试；
  12.出错及异常处理保存记录，记录具有详细的属性，并且格式统一、意义明确；
  13.在程序异常时，除了保留日志，还需要提供观察、恢复的外部方法；
  14.对全局变量、特殊结构，提供查询的方法。

 

3.3  可测试性调试与定位
  1.对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改；
  2.在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点，便于系统集成和问题范围的定位；
  3.在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出，便于测试结果的分析。

 

3.4  测试所需文档
  1.需求规格说明书
  2.概要设计说明书
  3.详细设计说明书
  4.系统功能清单
  5.系统运行环境搭建指导书
  6.系统操作指导书