在播布客中看到一个关于TD8.0的培训视频，是Mike Gao老师的杰作，感觉不错，现整理出来和大家共享。

TD8.0 视频：
第一部：软件测试管理工具TestDirector8.0介绍
本视频的内容主要包括：
1.TD8.0简介
2.安装及配置
URL：http://www.boobooke.com/v/bbk1004

第二部：软件外包测试的基本介绍
URL：http://www.boobooke.com/v/bbk1015

第三部：TD8.0后台项目管理
本视频的内容主要包括：
1.如何在TD后台添加项目
2.如何在TD后台删除项目
3.如何在TD后台重命名项目
4.如何在TD后台编辑项目
另：将TD中Defects关键字改为Bugs:Insert into dataconst(dc_const_name,dc_value)values('replace_title','Defect:Bug;Defects:Bugs')
URL：http://www.boobooke.com/v/bbk1018

第四部：TD8.0后台用户管理
本视频的内容主要包括：
1.如何在TD后台添加用户
2.如何在TD后台编辑用户
3.如何在TD后台把用户分配到特定的项目并分配特定的角色。
URL：http://www.boobooke.com/v/bbk1022

第五部：TD的需求管理
本视频的内容主要包括：
1.添加需求;
2.查看需求;
3.修改需求;
4.转换需求;
URL：http://www.boobooke.com/v/bbk1035

第六部：TD的计划测试
本视频的内容主要包括：
1.开发测试计划树
2.设计测试步骤
3.复制编辑测试步骤
4.建立需求和测试相互连接
URL：http://www.boobooke.com/v/bbk1038/

第七部：TD的测试运行
本视频的内容主要包括：
1.定义测试集
2.将测试添加到测试集
3.运行测试
URL：http://www.boobooke.com/v/bbk1039/

用TD的TestDirector Checker检查了一下，看见里面有一些红字如下：
 
The TestDirector installation process creates a virtual directorywhich it attempts to places in High (Isolated)Application Protection,If,after the installationprocess,the virtual directory is otherwise protected,TestDirector cannot word properly,To rectify thissituation,you must resynchronize the IWAM_XXXX accountpassword,or place the virtual directory in Low(IIS process) Application Protection,For instructions onsynchronizing IWAM_XXXX account passwords,refer toArticle#324 on the following Web site:www.IISFAQ.com.
根据上面的提示，到IIS里面的TDBIN目录里修改了属性“应用程序保护”，选择“高（独立）”结果提示如下：
com+无法与Mircrosoft分布式事务协调程序交谈

我在网上搜索后，发现很多网友提供了以下解决方法：

解决方法一：首先先到IIS里面的TDBIN目录里修改属性的“应用程序保护”，选择“高（独立）”，（附图1）再浏览主页就没事了。如果选择项为灰色的话（附图2），则需要点击创建，将应用程序名建立即可，然后再选择“应用程序保护”的“高（独立）”属性，再用TestDirector Checker检查一遍就OK了
如果上面的方法不行，就先试试下面的，再试试上面的
解决的办法如下：
进入注册表，删除注册表中的下面三键值：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC 
HKEY_CLASSES_ROOT\CID 
打开“运行”框，输入：“net stop msdtc”（不含引号，下同） 停止MSDTC服务命令
接着打开“运行”框，输入：“msdtc -uninstall” 卸载MSDTC服务命令
再打开“运行”框，输入：“msdtc -install” 重新安装MSDTC服务命令
然后在“运行”框，输入：“net start msdtc”
再在事件查看器中确认msdtc服务已经正常启动，这步很关键，如果启动了就代表成功了
注意 ：有很多人在删除注册表里面的“HKEY_CLASSES_ROOT\CID”时，发现CID键删除不了，这是很多人安装了360安全卫士造成的，只要下载个"IISfixer"的修理程序，然后再删除CID就可以删除了，然后按着我刚说的过程来就可以安装成功了

解决办法二：
手工同步IIS用户密码，步骤如下：
1)重新设置IIS的IWAM账号密码。右键单击我的电脑->管理，打开计算机管理界面打开本地用户和组->用户　右键单击启动IIS进程帐号　IWAM_****（注：****一般是计算机名）点击设置密码，设置为一个你想要的密码。
2)同步IIS metabase中IWAM_MYSERVER的密码，在CMD中：c:\inetpub\adminscrīpts>adsutil set w3svc/wamuserpass "yourpassword"
3)同步COM+应用程序所用的IWAM_MYSERVER密码，在CMD中：c:\inetpub\adminscrīpts>cscrīpt synciwam.vbs -v。
但是在进行第三步操作时总是报8004e00f错误。进入组件服务，查看组件服务/计算机/我的电脑/COM+应用程序，结果报错"COM+ 无法与 Microsoft 分布式事务协调程序交谈"，无法查看里面的对象。在事件查看器中msdtc服务没有正常启动。解决方法：运行 msdtc -resetlog

我使用以上两种方法问题都没有得到解决，最后卸载了IIS和TD，再重新安装IIS和TD问题解决了。:)

注：在安装TD时提示:“[87,22]属性值无效: progid”,详细如下图：

解决方法：在安装IIS时记得安装：UDDI服务，这样此问题可以得到解决。

     报表的重要性，大家都知道它有举足轻重的地位，特别是成本/利润类报表、月报、年报等，这里就废话少说了！所以，它对测试条件的要求、测试覆盖率的要求、测试深度的要求都非常高，而且不是一般的测试员和新手随便就能测试的，一定是对业务和相关的法规非常熟悉，最好能有实践经验的、较强分析能力、综合能力高的测试员来做！

总结了报表在测试时需要关注的十大特性：
一、 正确性
报表的最低要求和基本特征就是它的正确性！
    1.报表格式的正确
不同的报表有不同的格式，有些是行业内默认的，有些是明文规定的，还有自定义的，按照不同条件还可以分各种各样的，如：按照货品的仓库进出情况，分入库类报表、出库类报表和仓库类报表等；按照报表的类型，分图表，固定行列报表，分栏报表、交叉报表等等！因此，报表的格式不是随便增减的，一般包括表头、表体、表尾、以及附注等，测试时需要具体问题具体分析，根据需求提供的标准格式模板！
    2.报表内容的正确
这是测试的重中之重，包括数据的算法、数据的来源、数据的对应关系、小数位问题、四舍五入问题、单位换算问题、税率换算问题、明细与合计是否一致、单据的类型/状态改变后对报表的影响等！

二、 时段性
这个很容易了解，没有那张报表在时空上的统计是漫无边际的，就算是“所有”或者“全部”，都是有它的时效！特别是财务类报表，有月报、季报、年报、甚至还有现金日记帐等，都表现出时段在报表中的必要。

三、 条件性
每个报表都是针对特定的条件而作出的输出，要想达到目的，是需要一定条件的。如：统计XX供应商XX业务员在XX时期采购XX商品的情况，在查询时就至少需要四个条件了！
在测试查询条件时，通常采用正交的方法来增加它的测试覆盖率，但是要注意的是，测试数据的选取非常重要，我们都尽量模拟真实的、有代表性的、经过精心设计的数据！

四、 可比性
这在报表的分析和成效的判定上，显得尤其重要，通常报表的测试，不仅只是对单张报表的测试，还需要多张同时进行比较，多张可以是指同一时期不同类型的报表、不同时期同一类型的报表、不同类型与不同类型的报表（但它们之间必然存在某种关系的）；还有什么同比的、类比的等！
目的是找出它们之间的联系和区别，然后获得更深层次的某种规律或者业务流程的脉络。简单来说，就是从实践上升到理论！
举个简单的例子：我们都知道财务报表的会计原则是“有借必有贷，借贷必相等”，因此，每个财务类报表都有借、贷两方；然而从销售收入报表、销售支出报表和销售利润表，显然得出：销售收入-销售支出=销售利润，这一条无人不晓的规律！

五、穿透性
这个也很容易理解，大多数的报表都不是孤立的，例如：从汇总表可以穿透到明细表，从明细表又可以穿透到单据，从单据甚至可以穿透到具体的产品；虽然它们的层次深度可能不一样，但它们与某某之间有着奇妙的联系！
在测试中，一定要理清它们之间的层次、顺序，这就需要对业务的理解和知识的积累！

六、隐蔽性
这里不是指报表的数据或者结果隐蔽，而是指所统计的数据来源的隐蔽。例如：入库类的，除了正规的采购入库，还会有估价入库、退货入库、盘盈入库、报溢入库、拆卸入库（将组装产品或者已经打包的产品，拆卸后将元素产品重新入库）等；出库类的，除了常见的销售出库，还会有采购退货、盘亏出库、报损出库、生产领用、组装领用等。请注意的是，有些进销存系统还分有帐面库存数和实际库存数两种的！
另一个陷阱：有些进销存系统的应收帐款是由正常的应收帐款加上预付转应收的部分组成的；同理，应付帐款是由正常的应付帐款加上预收转应付的部分组成！

七、时序性
上面说了时段性，现在到说说时序性，顾名思义，就是指业务发生的时间顺序。在明细报表中，每项明细都应该有记录业务发生的时间，它的先后顺序很重要。
举个简单的例子：某仓库库存量为100，三月份销售出库50，四月份采购入库也是50，如果将四月份的采购入库计入三月份的，虽然年仓库库存量还是100，没有变，但是对于月度库存量和季度库存量就影响大了！

八、安全性
    1.这个主要体现在报表的权限控制上。因为报表是针对不同的用户设计的，特别是敏感的数据，如个人资料、产品成本、商业信息等，这就需要加强访问权限的控制，有的是只读的，不能过滤条件或者修改其他的查询条件；有的根据用户等级来分配权限等！
    2. 通过用户角色和密码来控制：业务员只能看到自己的业绩报表
    3.通过用户角色的等级来控制：非财务主管不能打开销售收入利润表等

九、 直观性
报表的数据、结果清晰明了，页面简洁、排版合理，不能给用户产生模糊或者引起奇异的感觉；一般合计的部分或者关键字段都需要突出显示；有的报表需要图文并茂，选择最佳的报表类型。

十、 打印
仅仅测试通过查询得到的报表，是不足够的；通过屏幕看到报表的效果，也是不能全信的，需要持有怀疑的态度，把报表打印出来，重新检查是否适合所需的效果！
包括：打印模板的设计、套打样式、自定义模板、打印调试、打印时间等方面。

　　你能从可用性测试获得什么？在每一轮的可用性测试中，你都应该先明确具体的测试问题和目标，针对这些目标进行测试。举例来说，项目刚刚起步，你可以对定量的指标（如时间，错误率和满意度）进行测试，为日后修改网站提供参照。再例如，如果你已经设定了可测量的可用性目标，你可以看看你的产品是否切合这些目标。对于一个典型的可用性测试，你可以：找出该产品的任何的可用性问题从测试参与者的表现收集定量数据确定该产品的用户满意度

　　可用性测试和以用户为中心的设计的关系？可用性测试是以用户为中心的设计的一个重要组成部分。用户为本的设计过程本身就应该包括对性能和偏好进行评价的一系列测试。

　　什么时候该做可用性测试？尽早做，经常做。可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。 问题越早发现和弥补，所造成的损失就越低。这些问题是找到并固定好，越昂贵的补丁程序。随着项目的进展，对设计主体进行改动会变得越来越困难和昂贵。你测试的越多，并就相应测试进行改进，你就可以更加确信你的网站没有偏轨，确信它是符合您的目标和用户的需要的。迭代开发过程——开发原型，测试用户，分析结果，随之修改原型，然后再重复测试、分析、修改周期——是开发一个成功的网站或软件的最好方式。

　　通过可用性测试你能学到什么？通过一个典型的可用性测试，你可能找到这些问题的答案：测试参与者能成功完成任务吗？在成功完成的任务中，每项任务能做的多快？在成功完成的任务中，每项任务要多少页（或者点击多少次）才能完成？测试参与者的表现是否满足可用性目标？测试参与者对网站的满意度如何？做出什么改变才能确保更多用户能够完成地更顺利？可能还有更具体的问题。举例来说，如果这一轮测试主要关注的是搜索功能，你可能会关注这些问题：测试参与者会在页面上浏览还是直接使用搜索？他们搜索时最常用的关键字是什么？搜索框是否足够大，能呈现大部分的搜索关键字？它的位置是否合理？搜索结果是否能引导用户的快速找到答案？如果搜索结果恰好包含用户想要的答案，这些答案是否经常显示在第一页？搜索是否能检测到拼写错误并帮助纠正？

　　可用性测试中你该注意什么？必须牢记以下四点：1. 你测试的是产品，而不是使用者。2. 更多地依靠用户的表现，而不是他们的偏好。3. 把你掌握的测试结果应用起来。4. 基于真实的用户体验，找出问题的最佳解决方法。1. 你测试的是产品，而不是使用者。对一些用户而言， "测试"有负面的涵义。我们要努力确保他们不认为测试是针对他们。我们要让他们明白，他们正在帮助我们测试原型或网站。事实上，我们可以不使用“测试”这个术语。相反，我们是邀请参加者为我们提供帮助，"勇于尝试原型" 。当用户难以完成任务时，我们应该改变网站，而不是改变用户。同时我们还应该思考该网站能在多大程度上符合那些典型用户的的目标，而不是关注用户在这个任务做的多好。2. 更多地依靠用户的表现，而不是他们的偏好。通过测试我们可以测量到用户的表现，以及他们的偏好。用户的表现包括是否成功完成，所用时间，产生的错误等等。偏好包括用户自我报告的满意度和舒适度 。一些设计人员认为，如果他们的设计能迎合用户的喜好，用户在该网站上就会有良好的表现。但证据并不支持这一点。事实上，用户的表现以及他们对产品的偏好并非一一对应。一项研究发现，约有百分之七十的用户同意表现和喜好有联系。也就是说，他们在喜爱的网站上表现良好，在不喜欢的网站上表现欠佳。然而，还有相对比较大比例的人（ 30 ％ ）认为 ，用户的表现以及他们对产品的偏好并非一一对应。他们在不喜爱的网站上可能表现良好，在喜欢的网站上也可能表现不佳。关于人们为什么会对自己表现欠佳的网站给出较高的评价有多种解释。他们可能会把表现不佳归结到自己，而不是网站。或者说，他们可能担心给一个较低的评价会伤害网站设计者，也就是我们的感情。或者说，他们可能并没有完成任务，却自认为成功完成了，他们并没有意识到问题所在。基于所有这些理由，我们建议你：更多地依靠用户的表现，而不是他们的偏好。3. 把你掌握的测试结果应用起来。可用性测试不仅仅是用于核对项目进度的一个里程碑，你要知道，当最后一个参与者完成任务的时候，可用性测试还没有结束。整个团队必须仔细研究结果，设定优先次序，基于结果对或者网站原型进行修改。4. 基于真实的用户体验，找出问题的最佳解决方法。制造任何产品，包括大部分网站和软件，需要考虑许多不同的用户的工作方式、体验、问题以及需要。大多数项目，包括设计或修改网站，都要处理时间、预算和资源等方面的限制。平衡各个方面对大部分项目来说都是一个重大的挑战。在你权衡利弊时，最好优先开发那些能使最多用户完成任务的网站或软件。有研究表明，产品推出后，用于支持失败客户的花费远远高于开发时对产品修正所付出的花费。你需要认真考虑假定用户、使用场景以及可用性测试的结果，试图找出针对不同客户需求的理想解决方法。找不到最好的解决方法，用户就不能够顺畅地完成任务。有证据表明，即使用户延长使用时间在一个不太完美的产品界面完成任务，也远不及在一个更好的产品界面带来的成功感。

　　你是否需要一个实验室做可用性测试？用不着，无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备，你都可以采用各种正式或非正式的方法。使用下述任何一种设置，你都可以进行有效的可用性测试：两室或三室的固定实验室，配备视听设备会议室，用户的家或工作室，配备便携式录音设备会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替当用户在不同地点可以远程控制因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。不要说，“因为我们没有一个可用性实验室，所以我们没法做可用性测试。"只要去做！在任何空间你都可以完成。可用性测试需要多少人参与？看情况。一个典型的测试需要8至16个人（每用户组）。如果每个用户将花费一小时，就意味着每个用户组的测试需要一到两个工作日。当你的项目处在：纸上原型或早期开发阶段计划通过几轮测试整个开发有相当一致的用户群如果只要人帮忙找出严重问题，你可能只需要4到6人。如果您有不同的潜在用户群组（例如医生、病人、研究人员），你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试，6至8个用户通常是不足以揭露产品的大部分问题的。如果在网站开发过程中你一直在做迭代（重复）的可用性测试，就会有许多用户参加其中一个或另一个版本的网站测试。因此，尽管每个可用性测试只有少于10名的测试参予者，但在网站推出前你可能需要15到30人参加测试。

　　做可用性测试需要多少费用？成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。在对可用性测试进行预算时应该考虑这些因素：计划所用的时间：确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试场景。招聘的花费：公司人员的时间，给招聘公司（通常是一个很好的选择）的花费，可用性专家需要花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室或便携式摄录设备的租金。团队观察用户（进行测试）花费的时间付给测试参与者的报酬或礼物分析视听资料，查找存在的问题以及推荐解决办法所用的时间和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。记住，预算分析要包含多个可用性测试。打造一个网站（或产品）的可用性是一个反复迭代的过程。你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。

　　1.1　内容

　　规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

　　1.2　适用范围

　　对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减。

　　1.3　术语和缩略语

　　1.3.1　软件配置管理（Software Configuration Management，SCM）

　　软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。

　　1.3.2　配置（Configuration）

　　配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此配置包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的配置包括更多的内容并具有易变性。

　　1.3.3　配置项（Configuration Item，CI）

　　凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。一个纯软件的CIs通常也称之为软件配置项（Computer Software Configuration Items，CSCIs）。

　　配置项主要有两大类：

　　1) 属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等；

　　2) 项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。

　　每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

　　1.3.4　基线（Baseline）

　　在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑（Milestone）处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。

　　基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

　　建立基线的好处：

　　1) 重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。

　　2) 可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。

　　3) 版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。

　　二、相关人权责

　　2.1　项目经理（Project Manager，PM）

　　责任：

　　1) 与CCB协商确定项目起始基线和开发里程碑；

　　2) 接受配置管理计划，并按相关规定贯彻执行；

　　3) 接受配置控制委员会的报告。

　　权利：

　　1) 提出配置管理计划的修改要求；

　　2) 提出管理管理的建议和要求。

　　2.2　配置控制委员会（Configuration Control Board，CCB）

　　责任：

　　1) 制定和修改项目的配置管理策略；

　　权利：

　　1) 批准、发布配置管理计划；

　　2) 建立、更改基线的设置，审核变更申请；

　　3) 根据配置管理员的报告决定相应的对策。

　　2.3　配置管理员（Configuration Management Officer，CMO）

　　责任：

　　1) 编制配置管理计划；

　　2) 执行配置项管理方案；

　　3) 执行版本控制和变更控制方案；

　　4) 编制配置状态报告；

　　权利：

　　向CCB汇报有关配置管理流程中的不符合情况。

　　2.4　程序库管理员（Program Librarian，PL）

　　责任：

　　1) 配置库的建立和权限分配；

　　2) 配置管理工具的日常管理与维护；

　　3) 配置库的日常操作和维护；

　　权利：

　　1) 各配置项的管理与维护；

　　2) 对开发人员进行相关的培训。

　　2.5　开发人员（Developer）

　　责任：

　　1） 根据确定的配置管理计划和相关规定，提交配置项和基线；

　　2） 负责软件集成和版本生成。

　　权利：

　　按照软件配置管理工具的使用模型来完成开发任务。

　　2.6　测试人员（Tester）

　　责任：

　　根据配置管理计划和相关规定，提交测试配置项和测试基线；

　　权利：

　　负责软件变更的测试验证。

　　2.7　软件质量保证员（Software Quality Assurance，SQA）

　　责任：

　　负责配置审核并提交报告。

　　权利：

　　对配置审核中发现的不符合项，要求相关责任人进行纠正。

“VMware Tools”的作用：如果虚拟机中安装了VMware Tools，鼠标就可以随意进出vm虚拟机系统和自己的主机系统，主机的东西可以直接拖到（或者粘贴、复制到）虚拟机里，虚拟机里的东西也很方便的粘贴、复制到主机中。如果没有安装，你是不是要按住ctrl+alt才能释放鼠标吧，操作很不方便。

第一步、在上方菜单栏找到并点击“安装VMware Tools”。如没有反应，请按第二步手动安装（以虚拟win98系统为例）：

第二步、在虚拟机-虚拟机-设置-硬件中，选中你的光驱选项(cd-rom)在右侧的连接中选使用ISO镜像，然后浏览找到你主机上的VMware安装目录，例如D:\Program Files\VMware下面，选中其下的windows.iso，这时虚拟机会自动启动VMware Tools安装程序。(如果你禁止了光驱自动运行，需手动到光驱盘符下安装)

以下是51testing中关于测试用例设计方法的讲解，觉得比较全面，因而汇总于此和大家共同分享、学习。

 1.场景设计方法：http://www.51testing.com/html/200811/n97993.html

 2.因果图方法：http://www.51testing.com/html/200811/n97777.html

 3.错误推测方法：http://www.51testing.com/html/200811/n97674.html

 4.等价类划分方法：http://www.51testing.com/html/200811/n97668.html

 5.边界值分析方法：http://www.51testing.com/html/200811/n97459.html

 6.功能图分析方法:http://www.51testing.com/html/200811/n96773.html

 7.正交实验设计方法：http://www.51testing.com/html/200811/n96675.html

 8.判定表驱动分析方法：http://www.51testing.com/html/200801/n73189.html

十一:TD8.0连接SQL 2000,ping不通,也不能建立新的Project

在TD的DBserver中ping SQL 2000,错误提示为：
  [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. | Unspecified error.

主要原因是因为:SQL SERVER安装默认的别名是SQL SERVER,而TD 安装的时默认的数据库别名是TDSQLSERVER，两者不一致。

解决方法：
打开“SQL Server客户端网络实用工具”---别名:添加---服务器别名（TDSQLSERVER）;服务器名称（TDSQLSERVER）；管道名称（主机名）；网络库（Named Pipes）保存后OK.

十二: RPC server is unavailable 

 TD启动时提示:RPC server is unavailable.

解决办法：

1. 重起TD（这种情况，可能是你安装的杀毒软件的原因；你的TD在启动时，加载不成功）

2. 把右下角的TD——start/stop重新启动一下或则再次刷新以下“Run as”选项

3. 最次的一个办法：把有关TD的各个启动项全部刷新.

七:TD如何对发送邮件的发送内容以及发送条件进行设置

1.         进入‘CUSTOMIZE’->‘Configure Mail’，在‘Configure Mail’->‘Fields’中选择你要发送的邮件中所要包含的内容

2.         在‘Configure Mail’->‘Condition’中选择你要发送邮件给指定的条件的用户

l  如果选择了‘Detected By’中的‘All Defects’那么这意味着，在用户提交bug时，在bug界面中Detected By字段被选中的用户将收到邮件

l  如果选择了‘admin’ 中的‘All Defects’那么这意味着，所有bug的缺陷都会提交给用户‘admin’

八:TD8.0中邮件标题过长导致邮件无法显示

问题：

发送bug邮件时，当BUG的标题超过22个字符出现就无法正确显示Html

解决：

1.         点击操作系统‘开始’->‘运行’，输入‘mecury.ini’，点击‘OK’按钮，打开以个名为mecury.ini的文本文档（或者打开<system drive>:\Winnt\mecury.ini进行修改）

2.         在mecury.ini文档中加上一段配置代码

[SAQFORMAT]

Project Name = Subject line

例如：

[SAQFORMAT]

BBM（项目名称） = BBM.BBM - # ？BG_BUG_ID（标题名称，其中？BG_BUG_ID为BUG_ID的变量）

九:打开TD提示:Error:Server is Not Available 的解决方法

问题：

在进入td的start_a.htm时提示Error:Server is Not Available，按确定，再提示：OTA server is not connected。使用TD的TestDirector Checker检查了一下，没有发现任何问题

解决：

1.         在‘开始’->‘运行’中输入‘inetmgr’，打开IIS管理器

2.         点击站点‘TDBIN’，右键‘属性’->‘虚拟目录’查看‘Application name’的使用项为空且右边的按钮为‘Remove’而不是‘Create’。（证明此站点的应用设置有问题）

3.         在‘Application Protection’中选择‘High（Isolated）’，提示error（证明IIS出现问题）

4.         在‘开始’->‘运行’中输入‘iisreset’，重新启动IIS服务

5.         再次进入站点‘TDBIN’，右键‘属性’->‘虚拟目录’，在‘Application Protection’ 中选择‘Low（IIS Process）’，然后点击‘Application name’使用项右边的按钮‘Create’（此时为Create）生成TD站点应用程序成功，可以继续使用TD.

(我安装TD8.0 时出现了这个问题,我的运行环境是Window XP+SQL 2000个人版+ IIS 5.1. 后来运行环境换成window server 2003+SQL 2000+IIS 6.0此问题解决了.)

十:在Windows XP中安装TD8.0后,IIS默认网站不可用

在网上查找有关资料发现是XP系统补丁的漏洞,安装此补丁并重启机器后，winxp系统的IIS默认网站将会停止且无法启动。手动启动时报“服务没有及时响应启动或控制请求”，再进一步检查，World Wide Web Publishing服务不能启动所至，该服务报错为“错误号127，找不到指定的程序”，程序当然是存在的，删除IIS重装还是不行。

解决办法：
打开“控制面板”---“添加删除程序”，将顶部的“显示更新”前打上勾，然后找到2007年7月10日的补丁，卸载。(我安装TD8.0 时出现了这个问题,卸载补丁后系统不能启动. 安装运行环境window server 2003+SQL 2000+IIS 6.0此问题解决了.)

一:TD正常安装后不能正常运行，造成浏览器运行假死的状况

有可能造成的原因是由于杀毒软件阻止了TD的进程运行，需要关闭掉杀毒软件，然后再次运行TD

二:TD中字体如何进行修改

1.         首先下载字体控件

有SP4的字体控件下载地址：

           http://www.51testing.com/cgi-bin/viewthread.php?tid=6961&fpage=1

无SP4 的字体控件下载地址：

                   http://www.51testing.com/cgi-bin/viewthread.php?tid=6977&fpage=1

说明：分别为两个rar的压缩包，下载到本地后，选中任意一个压缩包直接点右键“释放到这里。。。”即可（因为压缩的方式为分卷压缩，实际是把一个文件分成两个部分压缩，解压时rar会自动把两部分合在一起，所以各位同学实在不必为另外一个没有解压而担心）。

解压后的文件名是：TDClientUI.ocx（如果是TD8.0应为TDClientUI80.ocx）

2.         然后进行控件替换

l  关闭TD服务.

l  关闭所有的浏览器.

l  在目录‘InetPub\TDBIN\Install’中，用新的‘TDClientUI.xco’（改写下载文件的后缀）文件进行替换.

l  在目录‘InetPub\TDBIN’中打开文件‘setup_a.ini’，找到节点‘[File_2]’中的‘CheckSize=******’改写CheckSize的大小为新‘TDClientUI.xco’文件的大小.

l  进入C:\program files\common files\Mercury Interactive\TD2000目录，备份原TDClientUI.ocx文件.

l  将下载的字体控件TDClientUI.ocx拷贝至C:\program files\common files\Mercury Interactive\TD2000目录.

l  然后重启TD服务.

三:TD如何新建一个新project

1.         进入‘Site Administrator’->‘DB Servers’，点击‘Create Project’，在‘Create Database Server’选择你要创建的项目名称，数据库的类型;

2.         在‘Site Administrator’->‘Projects’中选择一个域，然后点击‘Create Project’创建一个新project;

创建一个新Project实际上是在数据库里新建了一个库.

四:如何设置TD自动发送邮件

1.         进入‘Site Administrator’，选择一个项目.

2.         勾选上该项目的‘Send defect emails automatically’选项.

3.         进入‘Site Administrator’->‘TD Servers’，点击‘Mail Protocal’，选择你要使用的邮件服务器（最好方式是搭建一个邮件服务器，然后选择‘SMTP Server’选项，输入邮件服务器地址）.

五:TD如何自定义BUG字段选项

1.         进入‘CUSTOMIZE’->‘Customize Project Entities’,在‘Project Entities’中选择‘DEFECT’（其中System Fields为不可编辑和修改的，只能进行常规的操作，User Fields为可编辑的，因此在更多时候添加新的字段会选用User Fields）

2.         点击‘User Fields’->‘New Field’,在‘Field Settings’对你的新字段进行编辑

l  Field Label：字段名称

l  Field Type：字段的选择类型Number（整型）、String（字符型）、Lookup List（下拉框）、Date（日期类型）

l  History：显示修改的历史记录

l  Required：此字段为必填选项

注：如果在Field Type选择了Lookup List选项，那么会让你编辑‘Lookup List’中的内容，其中下拉框里连接的其实为‘Customize Project Lists’内设定的值，也可以点击‘New List’建立一个新的与Lookup List中动态连接的值（具体参见‘Customize Project Lists’）

本文出自51Testing软件测试论坛每周一问活动， 作者: jacky19840707   

一个完整的Web安全体系测试可以从部署与基础结构，输入验证，身份验证，授权，配置管理，敏感数据，会话管理，加密，参数操作，异常管理，审核和日志记录等几个方面入手

　　数据加密：某些数据需要进行信息加密和过滤后才能进行数据传输，例如用户信用卡信  息、用户登陆密码信息等。此时需要进行相应的其他操作，如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多，越来越复杂，但一般数据加密的过程时可逆的，也就是说能进行加密，同时需要能进行解密！

　　登录： 一般的应用站点都会使用登录或者注册后使用的方式，因此，必须对用户名和匹配的密码进行校验，以阻止非法用户登录。在进行登陆测试的时候，需要考虑输入的密码是否对大小写敏感、是否有长度和条件限制，最多可以尝试多少次登录，哪些页面或者文件需要登录后才能访问/下载等。

　　超时限制：WEB应用系统需要有是否超时的限制，当用户长时间不作任何操作的时候， 需要重新登录才能使用其功能。

　　SSL：越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写，是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。（RSA），在位于HTTP层和TCP层之间，建立用户与服务器之间的加密通信，确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的，任何用户都可以获得公共密钥来加密数据，但解密数据必须要通过相应的私人密钥。进入一个SSL站点后，可以看到浏览器出现警告信息，然后地址栏的http变成 https，在做SSL测试的时候，需要确认这些特点，以及是否有时间链接限制等一系列相关的安全保护。

　　服务器脚本语言：脚本语言是常见的安全隐患。每种语言的细节有所不同。有些   脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

　　注：黑客利用脚本允许访问根目录的这个安全隐患特性攻击网站。这个网站包含了脚本代码（有允许访问根目录的特性）就可能有这个安全隐患。

　　日志文件：在服务器上，要验证服务器的日志是否正常工作，例如CPU的占用率是否很高，是否有例外的进程占用，所有的事务处理是否被记录等。

　　目录：WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当，通过简单的URL替换和推测，会将整个WEB目录完全暴露给用户，这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式，如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限，将这种隐患降低到最小程度。

　　（1） 计算平均的并发用户数： C = nL/T

　　（2） 并发用户数峰值： C’ ≈ C+3根号C

　　公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

　　公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

　　实例：

　　假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

　　则根据公式（1）和公式（2），可以得到：

　　C = 400*4/8 = 200

　　C’≈200+3*根号200 = 242

以下是测试用例评审过程中主要评审项：

1《需求规格说明书》是否评审并建立了基线？
2 是否按照测试计划时间完成用例编写？
3 需求新增和变更是否进行了对应的调整？
4 用例是否按照公司定义的模板进行编写？
5 测试用例是否覆盖了《需求规格说明书》？
6 用例编号是否和需求进行对应？  
7 非功能测试需求或不可测试需求是否在用例中列出并说明？
8 用例设计是否包含了正面、反面的用例？
9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果？
10 步骤/输入数据部分是否清晰，是否具备可操作性？
11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述？
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法？是否针对需求不同部分设计使用不同设计方法？
13 重点需求用例设计至少要有三种设计方法？
14 每个测试用例是否都阐述预期结果和评估该结果的方法？
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置；表格和数据格式是否有说明或附件？
16 用例覆盖率是否达到相应质量指标?
17 用例预期缺陷率是否达到相应质量指标?

1.Major Defects Per Test Case Review
每个经评审的测试用例发现的主要缺陷
2.Minor Defects Per Test Case Review
每个经评审的测试用例发现的次要缺陷

3.Total Defects Per Test Case Review
每个经评审的测试用例发现的缺陷总数

4.Ratio of Major to Minor Defects Per Test Case Review
每个经评审的测试用例发现的主要缺陷与次要缺陷的比例

5.Total Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的缺陷总数

6.Major Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷

7.Ratio of Major to Minor Defects Per Test Case Review Hour
每一个小时评审的测试用例发现的次要缺陷

8.Number of Open Defects Per Test Review
每个经评审的测试用例发现的处于Open状态的缺陷个数

9.Number of Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的缺陷个数

10.Ratio of Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的缺陷个数与处于Open状态的缺陷个数的比例

11.Number of Major Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Open状态的主要缺陷个数

12.Number of Major Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的主要缺陷个数

13.Ratio of Major Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的主要缺陷与处于Open状态的主要缺陷的比例

14.Number of Minor Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Open状态的次要缺陷个数

15.Number of Minor Closed Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的次要缺陷个数

16.Ratio of Minor Closed to Open Defects Per Test Case Review
每个经评审的测试用例发现的处于Closed状态的次要缺陷与处于Open状态的次要缺陷的比例

17.Percent of Total Defects Captured Per Test Case Review
每个经评审的测试用例发现的总缺陷个数占缺陷总数的百分比

18.Percent of Major Defects Captured Per Test Case Review
每个经评审的测试用例发现的主要缺陷个数占缺陷总数的百分比

19.Percent of Minor Defects Captured Per Test Case Review
每个经评审的测试用例发现的次要缺陷个数占缺陷总数的百分比

20.Ratio of Percent Major to Minor Defects Captured Per Test Case Review
每个经评审的测试用例发现主要缺陷的百分比与次要缺陷的百分比之间的比例。

21.Percent of Total Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的缺陷数占总缺陷数的百分比

22.Percent of Major Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷数占总缺陷数的百分比

23.Percent of Minor Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的次要缺陷数占总缺陷数的百分比

24.Ratio of Percent Major to Minor Defects Captured Per Test Case Review Hour
每一个小时评审的测试用例发现的主要缺陷的百分比与次要缺陷的百分比之间的比例

25.Percent of Total Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的缺陷的百分比

26.Percent of Major Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的主要缺陷的百分比

27.Percent of Minor Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的次要缺陷的百分比

28.Ratio of Percent Major to Minor Defect Residual Per Test Case Review
每个经评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例

29.Percent of Total Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的缺陷的百分比

30.Percent of Major Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的主要缺陷的百分比

31.Percent of Minor Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的次要缺陷的百分比

32.Ratio of Percent Major to Minor Defect Residual Per Test Case Review Hour
每一个小时评审的测试用例未能发现的主要缺陷的百分比与次要缺陷的百分比之间的比例

33.Number of Planned Test Case Reviews
计划要评审的测试用例的个数

34.Number of Held Test Case Reviews
计划要评审但未评审的测试用例的个数

35.Ratio of Planned to Held Test Case Reviews
计划要评审的测试用例个数与计划要评审但未评审的测试用例的个数之间的比例

36.Number of Reviewed Test Cases
评审过的测试用例的个数

37.Number of Unreviewed Test Cases
未评审的测试用例的个数

38.Ratio of Reviewed to Unreviewed Test Cases
评审过的测试用例的个数与未评审的测试用例的个数之间的比例

39.Number of Compliant Test Case Reviews
评审通过的测试用例的个数

40.Number of Non-Compliant Test Case Reviews
评审不通过的测试用例的个数

41.Ratio of Compliant to Non-Compliant Test Case Reviews
评审通过的测试用例的个数与评审未通过的测试用例的个数之间的比例

42.Compliance of Test Case Reviews
通过的评审次数

43.Non-Compliance of Test Case Reviews
不通过的评审次数

44.Ratio of Compliance to Non-Compliance of Test Case Reviews
通过的评审次数与不通过的评审次数之间的比例

    在嵌入式领域目标系统的应用系统日趋复杂，而由于竞争要求产品快速上市，开发技术日新月异，同时硬件发展的日益稳定，而软件故障却日益突出，软件的重要性逐渐引起人们的重视，越来越多的人认识到嵌入式系统的测试势在必行。提到嵌入式软件测试，首先要简单介绍一些软件工程的一些观点，现在，被普遍接受的软件的定义是：软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。其中程序是按照事先设计的功能和性能要求执行的指令序列；数据是是程序能正常操纵信息的数据结构；文档是与程序开发维护和使用有关的各种图文资料。
　　对于一般商用软件的测试，嵌入式软件测试有其自身的特点和测试困难。
　　由于嵌入式系统的自身特点，如实时性(Real-timing)，内存不丰富，I / O通道少，开发工具昂贵，并且与硬件紧密相关CPU种类繁多，等等。嵌入式软件的开发和测试也就与一般商用软件的开发和测试策略有了很大的不同，可以说嵌入式软件是最难测试的一种软件。
　　嵌入式软件测试使用有效的测试策略是唯一的出路，它可以使开发的效率最大化，避免目标系统的瓶颈，使用在线仿真器节省昂贵的目标资源。自从出现高级语言，开发环境与最终运行环境通常都是存在差异的，嵌入式系统更是如此。开发环境被认为是主机平台，软件运行环境为目标平台。相应的测试为host-target测试或cross-testing。
　　讨论嵌入式软件测试首先就会遇到一个问题：为什么不把所有测试都放在目标上进行呢？因为若所有测试都放在目标平台上有很多不利的因素：
1）测试软件，可能会造成与开发者争夺时间的瓶颈，避免它只有提供更多的目标环境。
2）目标环境可能还不可行。
3）比起主机平台环境，目标环境通常是不精密的和不方便的。
4）提供给开发者的目标环境和联合开发环境通常是很昂贵的。
5）开发和测试工作可能会妨碍目标环境已存在持续的应用
从经济上和开发效率上考虑，软件开发周期中尽可能大的比例在主机系统环境中进行， 其中包括测试。
确定host-target测试环境后，开发测试人员又会遇到以下的问题：
1）多少开发人员会卷入测试工作（单元测试，软件集成，系统测试）?
2）多少软件应该测试，测试会花费多长时间？
3）在主机环境和目标环境有哪些软件工具，价格怎样，适合怎样?
4）多少目标环境可以提供给开发者，什么时候?
5）主机和目标机之间的连接怎样？
6）被测软件下载到目标机有多快?
7）使用主机与目标环境之间有什么限制（如软件安全标准）?
任何人或组织进行嵌入式软件的测试都应深入考虑以上问题，结合自身实际情况，选定合理测试策略和方案。
对于嵌入式软件测试或叫交叉测试（cross-test），在测试的各个阶段有着通用的策略：
1．单元测试：
所有单元级测试都可以在主机环境上进行，除非少数情况，特别具体指定了单元测试直接在目标环境进行。最大化在主机环境进行软件测试的比例，通过尽可能小的目标单元访问所有目标指定的界面。
在主机平台上运行测试速度比在目标平台上快的多，当在主机平台完成测试，可以在目标环境上重复作一简单的确认测试，确认测试结果在主机和目标机上没有被他们的不同影响。在目标环境上进行确认测试将确定一些未知的，未预料到的，未说明的主机与目标机的不同。例如，目标编译器可能有bug，但在主机编译器上没有。
2．集成测试：
软件集成也可在主机环境上完成，在主机平台上模拟目标环境运行，当然在目标环境上重复测试也是必须的，在此级别上的确认测试将确定一些环境上的问题，比如内存定位和分配上的一些错误。
在主机环境上的集成测试的使用，依赖于目标系统的具体功能有多少。有些嵌入式系统与目标环境耦合的非常紧密，若在主机环境做集成是不切实际的。一个大型软件的开发可以分几个级别的集成。低级别的软件集成在主机平台上完成有很大优势，越往后的集成越依赖于目标环境。
3．系统测试和确认测试
所有的系统测试和确认测试必须在目标环境下执行。当然在主机上开发和执行系统测试，然后移植到目标环境重复执行是很方便的。对目标系统的依赖性会妨碍将主机环境上的系统测试移植到目标系统上，况且只有少数开发者会卷入系统测试，所以有时放弃在主机环境上执行系统测试可能更方便。
确认测试最终的实施舞台必须在目标环境中，系统的确认必须在真实系统之下测试，而不能在主机环境下模拟。这关系到嵌入式软件的最终使用。
包括恢复测试、安全测试、强度测试、性能测试，已超出了软件测试的范畴，本文暂不讨论。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，当然正确的测试工具使用也是必不可少的：
总结一下，应用以上测试工具进行.Cross-test时的策略：
A) 使用测试工具的插装功能（主机环境）执行静态测试分析，并且为动态覆盖测试准备好一插装好的软件代码。
B) 使用源码在主机环境执行功能测试，修正软件的错误和测试脚本中的错误。
C) 使用插装后的软件代码执行覆盖率测试，添加测试用例或修正软件的错误，保证达到所要求的覆盖率目标。
D) 在目标环境下重复（B），确认软件在目标环境中执行测试的正确性。
E) 若测试需要达到极端的完整性，最好在目标系统上重复（C），确定软件的覆盖率没有改变。
通常在主机环境执行多数的测试，只是在最终确定测试结果和最后的系统测试才移植到目标环境，这样可以避免发生访问目标系统资源上的瓶颈，也可以减少在昂贵资源如在线仿真器上的费用。另外，若目标系统的硬件由于某种原因而不能使用时，最后的确认测试可以推迟直到目标硬件可用，这为嵌入式软件的开发测试提供了弹性。设计软件的可移植性是成功进行cross-test的先决条件，它通常可以提高软件的质量，并且度软件的维护大有益处。以上所提到的测试工具，都可以通过各自的方式提供测试在主机与目标之间的移植，从而使嵌入式软件的测试得以方便的执行。
使用有效的cross-test测试策略可极大的提高嵌入式软件开发测试的水平和效率，提高嵌入式软件的质量。
附录：
1)HOST-TARGET的连接方法简介：

直接连接

通过仿真器连接

使用介质进行间接连接

使用PROM等传递被测软件

测试的交互界面

无交互界面的连接

1. 运行环境
 需要多高的配置，是否主流机器，是否网吧流行的机器，可以看出这个
 游戏的传播范围及用户群。
2. 资源占用情况
 与其他常用软件的兼用性如何，有无内存泄露的情况
3. 稳定性
 是否经常非法跳出
4. 用户帮助信息
 用户是否能够很容易找到相关的帮助信息（主页网站之类）
5. 界面的复杂度及友好度
 是否可以很快上手，很容易明白各种操作
6. 网络的要求
 对于带宽的要求如何，是否有大量的冗余信息传输
7. 新手帮助系统
 是否有协助新手尽快熟悉游戏的功能
8. 交流系统
 关于聊天、交流是否方便，快捷
9. 提倡的升级方式
 组队？独练？打怪？任务？在线时间？
10. 战斗系统
 技能的作用是否清晰，技能升级是否合理，技能之间是否平衡，有无绝
 对的压倒优势的练法，战斗是否容易控制
11. 经济系统
 是否有灵活的赚钱方式，无论是在线人多的时候，还是人少的时候，是
 否有恶性竞争的情况，是否有赚钱的可能也有花钱的需要，是否容易出
 现通货膨胀
12. 社会系统
 玩家之间的组织性如何，凝聚力如何，有无结婚、帮派之类的提升凝聚
 力的方式，这些方式中的交流程度是否足够，管理方式是否合情合理
13. PK 制度
 有无方便的方式给予玩家解决恩怨，会不会出现恶性PK，屠杀的情况，
 会不会对危害到新人的生存
14. 系统负荷
 能支持多少人在线
15. 持续发展
 随着玩家的成长，有什么可以新的可以做的吸引人的东西
16. 管理制度
 是否有良好的GM管理，畅通的游戏返馈方式
17. 外挂处理
 杜绝恶性外挂的能力如何

初级玩家
1. 详细描述自己遇到的BUG
2. 描述自己遇到的不方便之处
中级玩家
1. 描述自己感觉到的不合理之处
2. 提出自己认为的不平衡的地方
高级玩家
1. 探讨管理模式
2. 探讨游戏平衡
3. 探讨中后期发展
策划模式
1. 玩家的发展问题
2. 游戏的平衡问题
3. 世界经济、社会的均衡发展
4. 玩家的心理与游戏模式的平衡
5. 吸引新手、留住老玩家的平衡
6. 当前需要做工作的轻重缓急

Linux 常用命令

    command  [option]  [argument1]  [argument2]  ...

man  获取相关命令的帮助信息
     例如：man dir 可以获取关于dir的使用信息。

info  获取相关命令的详细使用方法
      例如：info info 可以获取如何使用info的详细信息。

cat  显示文件内容和合并多个文件 
clear  清屏
chattr  改变文件属性
chgrp  改变文件组权
chmod  改变文件或目录的权限
chown  改变文件的属权
comm  比较两个已排过序的文件
cp  将文件拷贝至另一文件
dd  从指定文件读取数据写到指定文件
df  报告磁盘空间使用情况
diff  比较两个文本文件，列出行不同之处
du  统计目录／文件所占磁盘空间的大小
file  辨识文件类型
emacs  功能强大的编辑环境        
find  搜索文件并执行指定操作(find2)
grep  按给定模式搜索文件内容
head  显示指定文件的前若干行
less  按页显示文件
ln  创建文件链接
locate  查找符合条件的文件
more  在终端屏幕按帧显示文本文件
mv  文件或目录的移动或更名
rm/rmdir  删除文件／目录
sed  利用scrīpt来处理文本文件
sort  对指定文件按行进行排序
tail  显示指定文件的最后部分
touch  创建文件
tr  转换字符
vi  全屏编辑器
wc  显示指定文件中的行数，词数或字符数
which  在环境变量 $PATH 设置的目录里查找符合条件的文件

bzip2/bunzip2  .bz2文件的压缩/解压缩程序
cpio  备份文件
dump  备份文件系统
gzip/gunzip  .gz文件的压缩/解压缩程序
gzexe  压缩可执行文件
restore 还原由倾倒(Dump)操作所备份下来的文件或整个文件系统(一个分区)
tar  将若干文件存档或读取存档文件
unarj  解压缩.arj文件
zip/unzip  压缩/解压缩 zip文件
zipinfo  列出zip压缩文件的详细信息

cd/pwd  切换目录/显示当前工作目录
df  显示磁盘的相关信息
du  显示目录或文件的大小
e2fsck  检查ext2/ext3文件系统的正确性
fdisk  对硬盘进行分区	
fsck  检查文件系统并尝试修复错误
losetup  设置循环设备
ls  列出目录内容
mkdir  创建目录
mformat  对MS-DOS文件系统的磁盘进行格式化
mkbootdisk  建立目前系统的启动盘
mke2fs  建立ext2文件系统
mkisofs  制作iso光盘映像文件
mount/umount 加载文件系统/卸载文件系统
quota  显示磁盘已使用的空间与限制
sync  将内存缓冲区内的数据写入磁盘
tree  以树状图列出目录的内容

alias  设置指令的别名
chkconfig  检查，设置系统的各种服务
clock  调整 RTC 时间
date  显示或设置系统时间与日期
dmesg  显示开机信息
eval  重新运算求出参数的内容
exit  退出目前的shell
export  设置或显示环境变量
finger  查找并显示用户信息
free  显示内存状态
hostid  显示主机标识
hostname  显示主机名
id  显示用户标识
kill  删除执行中的程序或工作
last  列出目前与过去登入系统的用户相关信息
logout  退出系统
lsmod  显示已载入系统的模块
modprobe  自动处理可载入模块
passwd  设置用户密码
ps  process status 报告程序状况
reboot  重启计算机
rhwo  查看系统用户
rlogin  远程登入
rpm  管理Linux各项套件的程序
shutdown  关机 
su switch user 变更用户身份
top  显示，管理执行中的程序
uname  显示系统信息
useradd/userdel	 添加用户 / 删除用户
userinfo  图形界面的修改工具
usermod  修改用户属性，包括用户的shell类型，用户组等，甚至还能改登录名
w  显示目前注册的用户及用户正运行的命令
whereis	 确定一个命令的二进制执行码，源码及帮助所在的位置
who  列出正在使用系统的用户
whois  查找并显示用户信息

arp  网地址的显示及控制
ftp  文件传输
lftp  文件传输
mail  发送／接收电子邮件
mesg  允许或拒绝其他用户向自己所用的终端发送信息
mutt  E-mail管理程序
ncftp  文件传输
netstat  显示网络连接、路由表和网络接口信息
pine  收发电子邮件，浏览新闻组
ping  向网络上的主机发送 icmp echo request 包
ssh  安全模式下的远程登录
telnet  远程登录
talk  与另一用户对话
traceroute  显示到达某一主机所经由的路径及所使用的时间
wget 从网络上自动下载文件
write  向其他用户的终端写信息