ERIC's New Zone

5月27日凌晨

eric — Thu, 26 May 2005 16:47:00 GMT

只身独坐电脑前
欲说还休不得言
蚊子脚下嗡嗡嗡
梦香心里乱通通

常用测试工具分类备查

eric — Thu, 26 May 2005 09:12:00 GMT

测试工具备查
1、从测试功能上分
（1）单元测试
针对不同语言，如JUNIT
（2）功级测试
E—Test：功能强大，由于不是采用POST URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的WEB SITE。
MI公司的WINRUNNER
COMPUWARE的QARUN
RATIONAL的SQA ROBOT
（3）压力测试
MI公司的WINLOAD
COMPUWARE的QALOAD
RATIONAL的SQA LOAD
（4）负载测试
LOADRUNNER
RATIONAL VISUAL QUANTIFY
（5） WEB测试工具
MI公司的ASTRA系列
RSW公司的E—TEST SUITE等
（6） WEB系统测试工具
WORKBENCH
WEB APPLICATION STRESS TOOL（WAS）
（7）数据库测试工具
TESTBYTES
（8）回归测试工具
RATIONAL TEAM TEST
WINRUNNER
（9）嵌入式测试工具
ATTOLTESTWARE。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。
CODETEST是AppliedMicrosystemsCorp.公司的产品,是广泛应用的嵌入式软件在线测试工具。
GammaRay。GammaRay系列产品主要包括软件逻辑分析仪GammaProfiler、可靠性评测工具GammaRET等。
LogiScope是TeleLogic公司的工具套件，用于代码分析、软件测试、覆盖测试。
LynxInsure++是LynxREAL-TIMESYSTEMS公司的产品，基于LynxOS的应用代码检测与分析测试工具。
MessageMaster是ElviorLtd.公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。
VectorCast是VectorSoftware.Inc公司的产品。由6个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。
（10）系统性能测试工具
Rational Performance
（11）页面链接测试
Link Sleuth
（12）测试流程管理工具
Test Plan Control
（13）测试管理工具
TestDirector
Rational公司的Test Manager
Compuware公司的QADirector
TestExpert：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。
（14）缺陷跟踪工具
TrackRecord等
（15）其他测试工具包
TestVectorGenerationSystem是T—VECTechnologies公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。
TestQuestPro是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。
TestWorks是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。
2、从测试的方法上分：
（1）白盒测试工具
白盒测试工主要有：Numega、PuRe、软件纠错工具（Rational Purify）。
内存资源泄漏检查：
Numega中的BounceChecher
Rational的 Purify等
代码覆盖率检查：
Numega的TrueCoverage
Rational的PureCoverage
TeleLogic公司的LogiScope
Macabe公司的Macabe
代码性能检查：
Numega的TrueTime
Rational的Quantify等
代码静态度量分析度量检查工具：LogiScope和Macabe等
黑盒测试工具主要有：QACenter、SQATeamTest、Rational Visual Visual Test。
QACenter：QACenter帮助所有测试人员创建一个快速、可重用的测试过程。这些测试工具自动帮助管理测试过程、快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。

3、部分具体测试工具的介绍
（1）、性能优化工具EcoScope
EcoScope是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoScope可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其他网络管理工具所不能提供的。EcoScope能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoScope能帮助IT部门就如何提高应用性能提出多方面的决策方案。
EcoScope的应用主要表现在以下几个方面：
确保成功部署新应用
维护性能的服务水平
加速问题检测与纠正的高级功能
定制视图有助于高效地分析数据
（2）、数据库测试数据自动生成工具——TestBytes
在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用例数据，我们可能会发现当数据库中只有少量数据时，程序可能没有问题，但是当真正投入到运用中产生了大量数据时就出现问题了，这往往是因为程序的编写没有达到，所以一定及早地通过在数据库中生成大量数据来帮助开发人员完善这部分功能和性能。
TestBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。
（3）、PC—LINT
PC—LINT 主要进行更严格的语法检查功能，还完成相当程度的语义检查功能。可以这样认为：PC—LINT是一个更加智能、更加严格的编译器。PC—LINT在实现语法和某些语义规则检查时，是通过参数配置完成的，它的选项就有数百个之多，因此，在使用PC—LINT过程中，了解选项的含义也很重要。
（4）、TCL
TCL是Tool Command Language的缩写，它是一种很流行的脚本解释器，尤其在测试领域，它的最大特点是可移植性好，接口简单，方便，可以很容易地嵌入到软件中，作为自己的解释器使用。
TCL提供两种接口：编程接口和用户接口。编程接口是通过LIB或DLL形式提供的，提供了一些函数（命令）供调用，包括：分配一个解释器指针（对象）；初始化解释器（指针）；注册扩展函数等。用户接口很简单，即编写的脚本，脚本里面包含对扩展命令的调用。
（5）VB测试工具：VB Watch
（6）Java 程序的测试工具
1）Bean—Test
2）EJBQuickTest
3）JStyle
4）JTest
5）HttpUnit
6）JUnit
（7）、覆盖测试
C—Cover
C—Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。C—Cover
只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制。
===============================================
单元测试方面：（对开发人员比较有用） J-Unit工具。
  功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。
  如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。
  另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序，如SMTP Server等。这两个工具都是使用Post URL的方法测试Web Application的。对大量使用JavaScript的页面不太适合。当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。
  另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。
  另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。
  测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试白盒测试工具主要有：
  内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等
  代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等代码性能检查：Numega中的truetime,Rational的Quantify等
  代码静态度量分析质量检查工具：logiscope和Macabe等
  黑盒测试工具主要有：客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
  服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等
  Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等
  测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。
  数据库测试工具:TestBytes
  黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。
  回归测试工具：Rational TeamTest，WinRunner（MI公司）
  WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）
  白盒测试工具：Numega 、PuRe、软件纠错工具（Rational Purity）。
  嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。
  系统负荷测试工具：RationalPerformance
  涵盖测试工具范围评估工具
  软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify
  测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）

Web应用程序测试方法吓测试技术详述

eric — Thu, 26 May 2005 09:08:00 GMT

1. 概述
l 随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多，很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。
l 测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。
l 相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
l 一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
l 当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。
l 有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。

2.1 界面测试
l 现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。
l 方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的HTML，CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格，那样可能会很糟糕。
主要包括以下几个方面的内容：
Ø 站点地图和导航条位置、是否合理、是否可以导航等内容布局布局是否合理，滚动条等简介说明说明文字是否合理，位置，是否正确
Ø 背景/色调是否正确、美观，是否符合用户需求；
Ø 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等
Ø 连接连接的形式，位置，是否易于理解等
l web测试的主要页面元素
Ø 页面元素的容错性列表（如输入框、时间列表或日历）
Ø 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
Ø 页面元素的容错性是否存在
Ø 页面元素的容错性是否正确
Ø 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
Ø 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
Ø 页面元素是否显示正确（主要针对文字、图形、签章）
Ø 元素是否显示（元素是否存在）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
l 测试技术
Ø 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。
Ø 可以结合数据定义文档查看表单项的内容，长度等信息。
Ø 对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用XML封装要做的工作会多一点等等。
界面测试要素:
符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性
l 1.直观性:
Ø 用户界面是否洁净,不唐突,不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该明显,并在预期出现的地方.
Ø 界面组织和布局合理吗?是否允许用户轻松地从一个功能转到另一个功能?下一步做什么明显吗?任何时刻都可以决定放弃或者退回,退出吗?输入得到承认了吗?菜单或者窗口是否深藏不露?
Ø 有多余功能吗?软件整体抑或局部是否做得太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂?
Ø 如果其他所有努力失败,帮助系统真能帮忙吗?
l 2.一致性
Ø 快速键和菜单选项.在Windows 中按F1键总是得到帮助信息
Ø 术语和命令.整个软件使用同样的术语吗?特性命名一致吗?例如,Find是否一直叫Find,而不是有时叫Search?
Ø 软件是否一直面向同一级别用户?带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息.
Ø 按钮位置和等价的按键.大家是否注意到对话框有OK按钮和Cancle按钮时,OK按钮总是在上方或者左方,而Cancle按钮总是在下方或右方?同样原因,Cancle按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致.
l 3.灵活性
Ø 状态跳转.灵活的软件实现同一任务有多种选择方式.
Ø 状态终止和跳过,具有容错处理能力.
Ø 数据输入和输出.用户希望有多种方法输入数据和查看结果.例如,在写字板插入文字可用键盘输入,粘贴,从6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动.
l 4.舒适性
Ø 恰当.软件外观和感觉应该与所做的工作和使用者相符.
Ø 错误处理.程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据.如大家认为undo /redo是当然的.
Ø 性能.快不见得是好事.要让用户看得清程序在做什么,它是有反应的.
2.2 功能测试
l 对功能测试是测试中的重点
主要包括一下几个方面的内容
Ø 连接这个连接和界面测试中的连接不同那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式。这里的连接注重功能。如是否有连接，连接的是否是说明的位置等。
Ø 表单提交应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
Ø Cookies 验证如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。功能易用性测试完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
l 测试技术功能测试的测试技术可是很多的，我们可以结合实际环境选择使用
Ø 白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在JAVA平台使用Xunit系列工具进行测试，Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
Ø 黑盒测试技术（Black Box Testing）黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面
 正确性 (Correctness)：计算结果，命名等方面
 可用性 (Usability)：是否可以满足软件的需求说明。
 边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等.
 性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着
程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题
 压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能,.
错误恢复 (Error Recovery) 错误处理，页面数据验证,包括突然间断电,输入脏数据等.
安全性测试(Security)这个领域正在研究中,不过防火墙,补丁包.杀毒软件等的就不必说了,不过可以考虑破坏性测试时任意.看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是,需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件是的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容.
 兼容性 (Compatibility) 不同浏览器，不同应用程序版本在实现功能时的表现,不同的上网方式,如果你测试的是一个公共网站的话.
l 兼容性测试内容详述
Ø 硬件平台
Ø 浏览器软件和版本:浏览器插件,浏览器选项,视频分辨率和色深.文字大小,调制解调器速率.
 软件配置 (Configuration) 如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何.
单元测试技术(Unit Test):
2.2.1 下面是对白盒测试和单元测试的区别的论述:
l 单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
l 另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
l 不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2.2.2 功能测试边界测试\越界测试技术详述
Ø 边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值速度字符地址位置尺寸数量
同时,考虑这些类型的下述特征:
第一个/最后一个最小值/最大值
开始/完成超过/在内
空/满最短/最长
最慢/最快最早/最迟
最大/最小最高/最低
相邻/最远
Ø 越界测试
通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1
l 另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
2.2.3 状态测试技术

Ø 软件可能进入的每一种独立状态;
Ø 从一种状态转入另一种状态所需的输入和条件;
Ø 进入或退出某种状态时的设置条件及输入结果.

l 具体测试方法可以参考如下:
Ø 每种状态至少访问一次;
Ø 测试看起来最常见最普遍的状态转换;
Ø 测试状态之间最不常用的分支
Ø 测试所有错误状态及其返回值
Ø 测试随机状态转换
2.2.4 竞争条件测试技术
l 竞争条件典型情形参考如下:
Ø 两个不同的程序同时保存或打开同一个文档
Ø 共享同一台打印机,通信端口或者其他外围设备
Ø 当软件处于读取或者修改状态时按键或者单击鼠标
Ø 同时关闭或者启动软件的多个实例
Ø 同时使用不同的程序访问一个共同数据库
2.3 负载\压力测试(StressTest)
l 在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
l 使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.
l 负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
l 负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.
Ø 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
Ø 对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的Load Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。
2.4 回归测试 (Regression Test)
l 过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。
Ø 回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
Ø 回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。
2.5 Alpha 和Beta 测试 (Alpha and Beta Test):
l 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。
l 特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题
不同的测试技术区分
3.1 覆盖测试技术
说明:测试覆盖率可以看出测试的完成度,在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
l 覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
l 该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。
l 使用该技术时可以使用以上的任何测试方法和测试技术。
3.2 白盒测试和黑盒测试技术
l 白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。
l 黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行,包括的不同测试类型请参考以上内容。
3.3 手工测试和自动化测试
l 手工测试（Manual Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
l 自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rational或者其他类测试工具说明.
l 根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。
l 自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
3.4 根据RUP标准按阶段区分测试
l 单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
l 集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
l 系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等
l 验收测试可以包括Alpha和Beta测试，在这里就不再详述。
4. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
l 软硬件的测试环境提供上也对测试结果有很大的影响。
l 测试团队的水平，经验，合作效果等
l 整个开发流程对测试的重视程度，测试的进入时间等
l 由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
5. 软件缺陷的原则
l 软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
Ø 软件未达到产品说明书标明的功能。
Ø 软件出现了产品说明书指明不会出现的错误。
Ø 软件功能超出产品说明书指明范围。
Ø 软件未达到产品说明书虽未指出但应达到的目标。
Ø 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
6. 文档测试
l 产品说明书属性检查清单
Ø 完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
Ø 准确.既定解决方案正确吗?目标明确吗?有没有错误?
Ø 精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
Ø 一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
Ø 贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
Ø 合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
Ø 代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
Ø 可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?

l 产品说明书用语检查清单
说明对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
Ø 总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
Ø 当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
Ø 某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
Ø 等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
Ø 良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
Ø 已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
Ø 如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

web应用程序整体测试

eric — Tue, 24 May 2005 02:53:00 GMT

Web应用程序的整体测试

　　随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。

　　B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。

　　首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？

　　如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：

　　1、通用指标（指Web应用服务器、数据库服务器必需测试项）:

　　* ProcessorTime: 指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；

　　* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；

　　* Physicsdisk Time : 物理磁盘读写时间情况；

　　2、Web服务器指标：
　　
　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

　　* Attempted Connections ：尝试链接数；

　　3、数据库服务器指标：

　　* User 0 Connections ：用户连接数，也就是数据库的连接数量；

　　* Number of deadlocks：数据库死锁；

　　* Butter Cache hit ：数据库Cache的命中情况；

　　上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持）的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧。
　　在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。

　　这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。

　　对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。

　　上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：

　　一、性能达不到目标；

　　二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；

　　三、服务器稳定性的问题，比如内存泄漏……。

　　要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与java ,C++都有支持，而且分析效果特别专业，我们先了解一下Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

　　我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库。

　　数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。

　　同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情。

　　内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:

　　1、 Array Bounds Read (ABR) ：数组越界读

　　2、 Array Bounds Write (ABW)：数组越界写

　　3、 Beyond stack Read (BSR)：堆栈越界读

　　4、 Free Memory Read(FMR)：空闲内存读

　　5、 Invalid pointer Read(IPR)：非法指针阅读

　　6、 Null Pointer Read(NPR)：空指针阅读

　　7、 Uninitialized Memory Read(UMR)：未初始化内存读写

　　8、 Memory Leak：内存泄漏

　　注：如果需要更多的信息，可以参见Purify的帮助信息。

　　顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了。

　　注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。

软件测试项目资料

eric — Thu, 07 Apr 2005 11:05:00 GMT

选修了软件测试与质量控制的同学：
陆老师给了一份Microsoft的测试文档和以下两个国内比较权威的网站供大家参考
http://www.cstc.org.cn/
http://www.shstc.org.cn/

测试文档范例请到FTP下载
ftp://cs04:cs04@202.38.240.103
老师说这个范例还是比较简单，我们的上交的报告要比这个更详细。

ExceptionManagement Application Block中的config文件的设置问题

eric — Thu, 31 Mar 2005 13:40:00 GMT

Web Service中返回DataSet出现PlatformNotSupportedException解决方法

eric — Sun, 27 Mar 2005 17:58:00 GMT

在Pocket PC端引用Web Service时，如果函数返回的是Dataset时，有可能会出现上面这种错误
解决方法是：
在Web Service中：
     string xmldata=dataset.GetXML();
     return xmldata;

在pocket pc中：
     String xmldata = ser.GetOnlineList();
     DataSet ds = new DataSet();
    System.IO.StringReader sr = new System.IO.StringReader(xmldata);
    System.Xml.XmlTextReader xReader = new System.Xml.XmlTextReader(sr);
    ds.ReadXml(xReader);
这样就可以得到DataSet

配置Smart Device的开发环境的安装软件顺序

eric — Sun, 27 Mar 2005 17:50:00 GMT

1、首先安装Microsoft ActiveSync3.7
2、然后安装Visual Studio.NET 2003（如果已经安装了VS.NET 2003，然后才安装ActiveSync的话，就要在安装完ActiveSync后，在“添加删除程序”重选择修复VS.NET2003）
3、安装Pocket PC2003 SDK
4、安装EmulatorConfig

开发电子商务解决方案－先启阶段－工作流程明细：（5）开发领域模型

eric — Mon, 21 Mar 2005 05:51:00 GMT

主题

目的

如何配备人员

工作指南

目的

您可以选择开发一个“不完整的”业务对象模型，把重点放在解释对于业务领域来说比较重要的产品、可交付工件或事件上。这种模型不包括人员所担负的职责，经常被称为领域模型。

这种备选的工作流程明细的目的是：

确定所有对于业务领域来说比较重要的产品、可交付工件和事件。
详细说明业务实体的定义。
正式核实业务对象建模的结果是否符合涉众对业务的看法。

如何配备人员

此工作流程经常由一系列的研讨班构成，而这些研讨班又由核心开发团队（担任业务设计员）和某些应邀参加的领域专家组成。至少还应该有一个以前担任过业务流程分析员的人参加，以确保业务用例模型是可理解的，并保持词汇是最新的。如果业务设计员缺乏业务领域中某个方面的知识，可以从应邀参加的涉众得到弥补。

工作指南

可以将以下技巧示例应用于此工作流程明细：

核心开发团队应该在业务设计员的帮助下进行数轮内部走查，以便在规模更大的团队正式检查和复审工作之前消除掉所有不必要的不一致现象。

该团队将材料分成若干部分。这样，他们就不必一次对所有内容都进行复审。一起进行复审所花的时间不得超过一天。

活动：复审业务对象模型中包含的核对清单将帮助您复审业务实体。另请参见工作指南：复审。

Rational Unified Process

此研讨班的重点是确定参与一个业务用例实现的业务角色和业务实体。一个有效的工作方式是召集 3-7 个人，使用白板、黑板架和 Post-it® 即时贴。随着研讨班的进行，会议室的四壁应该写满您的结果，确保每个人都能看到并比较不同类型的图，它们显示了业务流程实现的不同侧面。按照您引入这些图的顺序进行介绍，但这些图引入后，它们是并行发展的。

研究业务用例的工作流程。标记文本中的每个部分，以显示适合业务角色或业务实体的职责。或者，如果您已经画出了工作流程的活动图，在图中标出活动状态。使用两种颜色的 Post-it® 即时贴：一种用于业务角色，另一种用于业务实体。

创建新活动图，每个业务角色具有一个泳道，在这一点上，该业务角色正在参与活动。讨论活动如何在参与的业务角色之间进行分配，一些活动可能需要分开，一些活动可以合并。

具有泳道的活动图示例。

如果您了解每个业务角色拥有什么职责，就可以开始使用活动图中的对象流将业务实体添加到图中。但是，为了避免混乱，您经常需要限制向对工作流程来说主要的活动图中添加业务实体。有关业务实体的详细信息，请参考类图。

添加了对象流的活动图示例。

要概述您的结果，可以创建显示业务角色和主要业务实体的类图。在此类图中，您还可以开始添加业务角色和业务实体之间的关系，它们对执行业务用例实现来说必不可少。

如果业务角色和业务实体的数目很大，您可能需要几个图。可以采用以下建议：

用一个图显示业务角色之间如何交互（不显示任何业务实体）。
为业务用例实现的每个分支流配备一张图。每个图应该只包含分支流中涉及的业务角色和业务实体。您甚至可以只显示最感兴趣的业务实体来限制图的信息量。

类图显示了业务角色和业务实体如何相互联系，以执行业务用例实现工作流程。

正如前面提到的，在单独的类图中明确需要如何联系业务实体可能很有用。

显示业务实体及其关系的类图。

序列图通常比活动图更具说明性，适于说明以下情况下的工作流程：

部分业务用例实现是复杂的或不清楚的。
涉及的业务角色和业务实体很少，但要执行的操作却很多。
重要的是显示工作流程中的确切顺序，也就是说，业务角色执行操作的消息和业务实体操作的消息。

如果业务角色和业务实体的数目很大，您可能需要几个序列图。我们对协作图的建议对序列图也同样有效。按照结构，从用例实现的一般工作流程开始。然后处理替代分支流。

按照以下步骤画出业务用例实现的序列图：

将所有参与工作流程的业务角色和业务实体加入到序列图中。
说明业务角色如何通过消息进行交互。对于每一条消息，指定它所涉及的操作。如果业务角色处理业务实体，指定它所涉及的操作。
在文字空白处，对每次激活（请求操作的消息）进行说明。

序列图记录了业务角色之间如何交互和处理业务实体，以执行业务用例实现的工作流程。

如果准备完毕，保存有关每个业务角色和业务实体的信息（应该执行哪些活动）。稍后您将对它们进行说明。还应复制白板的内容，将有关业务用例及其实现的信息进行保存。复制的最佳方式是用 Polaroid™ 相机或数码相机拍照，数字照片的优势是我们有可能以数字方式在项目主页上进行共享。

Rational Unified Process

开发电子商务解决方案－先启阶段－工作流程明细：（4）改进业务流程的定义

eric — Mon, 21 Mar 2005 05:46:00 GMT

主题

目的

如何配备人员

工作指南

目的

为每个业务用例分配一名团队成员，由该成员负责详细说明该用例。业务设计员将完成对业务用例的定义，并领导对该业务用例进行复审。业务建模团队的其他成员作为业务模型复审员应邀参加复审。业务设计员可能还会邀请涉众代表（例如最终用户）参与该项目。

此工作流程明细的目的是：

详细说明业务用例的定义。
确保业务用例正确反映业务的进行方式。

如何配备人员

担任业务设计员的人员需具备良好的书面表达能力。如果掌握了该业务领域的知识，那当然也很有帮助，但也可以让领域专家参与进来作为复审员进行弥补。

工作指南

核心开发团队应该在业务设计员的帮助下进行数轮内部走查，以便在规模更大的团队正式检查和复审工作之前消除掉所有不必要的不一致现象。

该团队将材料分成若干部分。这样，他们就不必一次对所有内容都进行复审。一起进行复审所花的时间不得超过一天。

活动：复审业务用例模型中包含的清单将帮助您复审业务用例。另请参见工作指南：复审。

ERIC's New Zone

5月27日凌晨

常用测试工具分类备查

Web应用程序测试方法吓测试技术详述

web应用程序整体测试

软件测试项目资料

ExceptionManagement Application Block中的config文件的设置问题

Web Service中返回DataSet出现PlatformNotSupportedException解决方法

配置Smart Device的开发环境的安装软件顺序

开发电子商务解决方案－先启阶段－工作流程明细：（5）开发领域模型

工作流程明细：开发领域模型

主题

目的

如何配备人员

工作指南

工作指南：业务对象建模研讨班

开发电子商务解决方案－先启阶段－工作流程明细：（4）改进业务流程的定义

工作流程明细：改进业务流程的定义

主题

目的

如何配备人员

工作指南