软件测试工具之测试用例管理工具比较

zt425

工具名 综述 优点 缺点 备注
TestManager Rational测试解决方案中推荐的测试用例管理工具。 1. 功能强大。

2. 文件夹形式的管理，可以对测试用例无限分级。

3. 可以和Rational的测试工具robot、functional相结合。

4. 有测试用例执行的功能，但必须先生成对应的手工或自动化脚本。
1. 本地化支持不好。汉字显示太小。

2. 测试用例很多时不太稳定。有时会造成测试用例的丢失。

3. 必须安装客户端才可使用。和开发人员交流不方便。

4. 测试用例的展示形式单一。
   
Wiki 使用wiki做测试用例的管理工具。 1. Web界面形式，交流方便。

2. 测试用例的展示形式多样，可以贴图。可以进行格式化的编辑。

3. Wiki提供测试用例的版本控制、版本比较功能。

4. Wiki提供测试用例的添加注释（评论）功能，方便测试用例评审。

5. Wiki本身强大的全文索引功能。

6. 可以任意为测试用例添加标签。
1. Wiki并不是专业的测试用例管理工具。

2. 无法和其他测试工具集成。

3. 测试用例的统计不方便。需要编写专门的程序。

4. 没有测试用例的执行跟踪功能。

5. 有一些wiki本身的限制，如不同产品的测试用例名也不能重复。

6. 目前还没有定制统一的模板
Wiki本身有多种实现，这儿列出的是Confluence wiki。其他的wiki可能没有优点中列出来的某些功能。
Bugzilla+Test Runner 开源的测试管理解决方案，有很多开源软件使用此方式管理。 1. 开源免费。

2. Web方式的管理界面。

3. 自动邮件提醒。

4. 和缺陷管理系统Bugzilla结合紧密。有测试用例执行管理。

5. 测试用例可以分优先级。

6. 测试用例可以有评审的功能。（测试用例有不同的状态）
1. 安装设置较繁琐。

2. 没有配置过的经验。

3. 测试用例的编写上必须按照一个步骤对应一个验证点的形式来编写。
听说后来Test Runner升级后名字改为了Testopia，没有常试过。
TestDirector   1. 和Rational测试系列其名的测试管理工具，功能强大。

2. Web方式的界面。

3. 有测试用例执行跟踪的功能。

4. 有灵活的缺陷定制。

5. 和自身的缺陷管理工具紧密集成。

6. 界面较友好。
1、每个项目库同时在线人数有限制（具体个数忘记了）

2、可能存在部分不稳定性，但是基本功能没有问题
没有配置过的经验。不了解其具体的一些特征。
新版CQ（7.0） 新版本的CQ中增加了测试用例管理的功能。 1. 和cq的缺陷管理紧密结合。

2. 可以使用cq强大的查询和图表功能。
1. Eclipse的界面，较为笨重，需要安装。

2. 不知道有没有web形式的界面。
看过演示，没有实际用过。
TestLink   1. Web方式的界面。

2. 和bugzilla缺陷管理工具的整合

3. 可以自定义和其他缺陷管理工具的整合。

4. 同时具有需求管理的功能。
1. 没有配置过的经验。

2. 不了解其具体的一些特征。
没有实际用过，只看过网上的一些介绍。
Excel形式 适合小型项目。

如果充分利用excel的功能也可适合大型项目
依托Excel本身的强大功能；很灵活，易于扩展。
将来的维护等较麻烦；统计、度量等也不方便。   
Word形式   依托Word本身的强大功能。很灵活，易于扩展。 不如excel格式统一；不如excel容易统计。

zt425

1、指导测试的实施

　　测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

　　根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

　　2、规划测试数据的准备

　　在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

　　除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

　　3、编写测试脚本的“设计规格说明书”

　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

　　4、评估测试结果的度量基准

　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

　　5、分析缺陷的标准

　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
珍惜时间！！！学习知识

zt425

　部署在Internet上的WEB应用毫无疑问每时每刻都在遭受着各种考验，有些是出自恶意的破坏者（Cracker），有些是来自无心的攻击者（中了病毒或是木马的菜鸟），还有一些是来自系统内部的出于好奇或是有目的的恶意访问。下面是计算机安全学会CSI（www.gocsi.com）协同旧金山联邦调查局开展的2002计算机犯罪和安全调查提供的数字：

　　90%的被调查者在过去12月中探测到有计算机漏洞

　　74%的被调查者称其Internet连接遭受频繁攻击，而40%的被调查者探测到有来自外部的系统渗透；

　　75%的被调查者估计他们在过去所受的攻击的一部分可能来自心怀不满的雇员。

　　而根据CERT的统计（www.cert.org），2002年度收到的与安全相关的报告事件的数目是43136个，2001年是51658个，2000年是21756个。毫无疑问，安全问题正在成为计算机领域的关键问题，作为具有最多访问方式和最大的网络基础的WEB应用，其面临的安全考验更是严峻。

　　据知，国内的公司很少会专门为自己的WEB项目进行安全性测试，而且，大部分公司也不知道着手进行安全性测试。

　　一般来说，一个WEB应用包括WEB服务器运行的操作系统、WEB服务器、WEB应用逻辑、数据库几个部分，其中任何一个部分出现安全漏洞，都会导致整个系统的安全性问题。

　　对操作系统来说，最关键的操作系统的漏洞，例如Unix上的缓冲区溢出漏洞、Windows上的RPC漏洞、缓冲区溢出漏洞、安全机制漏洞等等；

　　对WEB服务器来说，WEB服务器从早期仅提供对静态HTML和图片进行访问发展到现在对动态请求的支持，早已是非常庞大的系统，即使发展多年的Apache也难逃经常被发现安全漏洞的缺陷，更不要说千疮百孔的IIS了；

　　对应用逻辑来说，根据其实现的语言不同、机制不同、由于编码、框架本身的漏洞或是业务设计时的不完善，都可能导致安全上的问题；

　　对数据库来说，数据库注入攻击一直是数据库厂商和网站开发者的噩梦。

　　除此之外，安全问题还存在于管理等各个方面，不完善的管理制度、缺乏安全意识的员工都会是内部的突破口，同样，一些开发工具生成的备份文件和注释也会成为Cracker发送攻击的参考资料。

　　对WEB的安全性测试是一个很大的题目，首先取决于要达到怎样的安全程度。不要期望网站可以达到100%的安全，须知，即使是美国国防部，也不能保证自己的网站100%安全。对于一般的用于实现业务的网站，达到这样的期望是比较合理的：

　　1、能够对密码试探工具进行防范；

　　2、能够防范对cookie攻击等常用攻击手段；

　　3、敏感数据保证不用明文传输；

　　4、能防范通过文件名猜测和查看HTML文件内容获取重要信息；

　　5、能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1个小时；

　　最后补充一点，浏览器的漏洞也可能会导致网站的不安全。

zt425

软件测试在国内仍处于起步阶段，各种软件测试的方法、技术和标准都还在探索阶段。国内软件行业普遍规模偏小，缺乏大型软件产品经验，开发过程不够规范，这决定了国内软件质量和测试行业，必须根据国内行业现状，确定软件质量目标和测试策略方法，而不是照搬照抄国外成熟软件企业的测试方法。

　　1、观念创新

　　提高软件质量的决定因素不是软件测试技术，而是对软件质量和测试的思想观念。只有把提高软件质量上升到企业战略发展的高度，才能从根本上解决问题。长期以来，国内软件行业对软件质量重视程度不足，对于软件测试的作用认识不够，造成项目因质量问题造成进度推迟甚至失败。

　　为了彻底改变这种被动现象，企业高层管理人员必须从管理思想、资源支持等方面为软件质量和测试部门提供全力支持。软件项目经理必须坚持软件开发和软件测试并行处理并且互相协调。软件开发人员重视和配合软件测试人员。

　　观念创新不要仅停留在口头上，而要落实在具体行动上，通过软件质量和测试的有效流程进行推动，通过过程改进进行提高。通过有效组织管理，形成以重视软件质量为荣，以轻视软件质量为耻的工作氛围。

　　2、流程创新

　　测试流程决定软件质量。软件测试如同软件开发一样，需要经过收集测试需求、确定测试策略、设计测试、执行测试、分析测试等流程。软件测试不是软件开发的最后阶段，而是贯穿于软件项目的整个生命周期。决定软件测试成败的关键是软件测试需求是否完整、准确，测试策略是否有效和实用，测试设计是否覆盖了测试需求。

　　软件测试流程既不是僵化的生搬硬套，也不是随机的增添取舍。软件企业的质量管理部门和项目开发团队需要根据公司技术、资源现状，针对项目的特点和客户需求，从保证软件质量、项目进度和测试成本等方面，进行优化设计并且不断改进流程管理。对于项目周期长、应用领域广、对质量要求高的软件，必须制定和遵守严格的测试流程。

　　测试流程创新的目标是在公司内部制定和执行完善的项目质量管理体系。优化项目生产方式，跟踪和度量生产过程和产品，使得生产过程和各阶段产品处于可控制和可度量状态，保证产品符合客户的功能和进度需求。

　　3、技术创新

　　软件测试是一项软件工程领域的专业技术，而不是简单的把软件测试认为随便找个人运行几次软件，就可以发现全部的软件问题。前文已经提到，软件测试需求和测试设计是决定软件测试效果的关键因素，因此，加强测试技术创新的重点是在测试需求和设计设计的创新。

　　在软件测试技术创新方面，要避免陷入过渡追求自动化测试技术的误区。自动化测试确实可以在某些方面显著提高测试效率和准确性，但是自动化测试只适合测试软件的某些方面的质量（例如性能测试，回归测试等），80%左右的软件缺陷是靠测试人员手工测试发现的。

　　对于某些特别需要自动化测试的软件特性，需要加强开发软件测试工具，而不是全部依赖市场上的现有测试工具。这是因为商业工具功能繁多，价格昂贵，培训和学习周期很长，选择不当就会造成巨大浪费。

　　4、管理创新

　　软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强过程跟踪，从而顺利完成质量保证和测试任务。

　　测试管理创新的核心是软件质量和测试的团队建设，软件质量和测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。质量和测试团队建设的重点是设置和培养各类技术和管理人才，进行有效交流，形成良好的评估和促进机制。

vl0120

收下了。关于“软件测试的创新之路”，怎样能让老板们也认识到软件测试创新的必要性呢？