部分白盒测试工具介绍
Parasoft白盒测试工具集
Jtest java 代码分析和动态类、组件测试
Jcontract Java 实时性能监控以及分析优化
C++ Test C,C++ 代码分析和动态测试
CodeWizard C,C++ 代码静态分析
Insure++ C,C++ 实时性能监控以及分析优化
其它公司
.test .Net 代码分析和动态测试
logiscope c/c++ Verlog公司的静态、动态分析工具
还有testbed、Cantata c/c++等
Rational工具集中的puricoverage和purify、quantify
Compuware白盒测试工具集
BoundsChecker C++,Delphi API和OLE错误检查、指针和泄露错误检查、内存错误检查
TrueTime C++,Java,Visual Basic 代码运行效率检查、组件性能的分析
FailSafe Visual Basic 自动错误处理和恢复系统
Jcheck M$ Visual J++ 图形化的纯种和事件分析工具
TrueCoverage C++,Java,Visual Basic 函数调用次数、所占比率统计以及稳定性跟踪
SmartCheck Visual Basic 函数调用次数、所占比率统计以及稳定性跟踪
CodeReview Visual Basic 自动源代码分析工具
Xunit白盒测试工具集
Aunit Ada http://www.libre.act-europe.fr
CppUnit C++ http://cppunit.sourceforge.net
ComUnit VB,COM http://comunit.sourceforge.net
Dunit Delphi http://nit.sourceforge.net
DotUnit .Net http://dotunit.sourceforge.net
HttpUnit Web http://c2.com/cgi/wiki?HttpUnit
HtmlUnit Web http://htmlunit.sourceforge.net
Jtest Java http://www.junit.org
jsUnit(Hieatt) javascript 1.4以上 http://www.jsunit.net
PhpUnit Php http://phpunit.sourceforge.net
PerlUnit Perl http://perlunit.sourceforge.net
XmlUnit Xml http://xmlunit.sourceforge.net
DUnit .net
JUnit java
Ⅱ 软件测试一般都用到哪些工具
常用的软件测试工具一般是：QTP+LoadRunner+QC
软件测试中还需的工具如下：
功能测试工具：QTP（HP），WinRunner（MI），Robort（IBM），QARun（Compuware）
性能测试工具：LoadRunner（HP），WAS（MS），Robort（IBM）【必须下载相应的插件才支持性能方面的测试】，QALoad（Compuware）
测试管理工具：TestDirector/Quarlity Center【这两个工具一个横版一个竖版，功能完全一样】，Rational TestManager
缺陷跟踪工具：Bugzilla、Mantis
其他：Rational Purify、Rational PureCoverager
一般测试流程：
需求分析阶段：只要就是对业务的学习，分析需求点。
测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。
测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。
测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档
Ⅲ 什么是单元测试
单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。 其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。 对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。 要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。 一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。 有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。 为什么要使用单元测试 我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。 幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。 什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。 由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。 关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。 在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。 单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。 经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。 一些流行的误解 在明确了什么是单元测试以后，我们可以进行"反调论证"了。在下面的章节里，我们列出了一些反对单元测试的普遍的论点。然后用充分的理由来证明这些论点是不足取的。 它浪费了太多的时间
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。 在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。 在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。 使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。 它仅仅是证明这些代码做了什么
这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住(希望能够)罕见的编译器Bug，但是他们能够做的仅仅是这些。 如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。 在实践中会出现这样的情况： 一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是发现编译器的Bug？第一步是理解这个单元原本要做什么， --- 不是它实际上做了什么。 比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释， 主要针对这个单元， 及调用它和被它调用的相关代码。画出流程图是非常有帮助的，你可以用手工或使用某种工具。 可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有基本的错误， 有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。 我是个很棒的程序员， 我是不是可以不进行单元测试？
在每个开发组织中都至少有一个这样的开发人员，他非常擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进行测试。你是否经常听到这样的借口？ 在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。 但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。 编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应， 并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？ 这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。
Ⅳ 怎样测试一个程序的速度
其实很多是有测试工具可以帮你完成的，看你要测试什么了，不同的程序有对应的软件，给你列举些：
厂商 工具名称
Mercury Winrunner
Mercury Quicktest pro
Mercury XRunner
Compuware QARun
Compuware WebCheck
Compuware TestPartner
Parasoft WebKing
IBM Rational Robot
IBM Rational Visual Test
IBM Rational Functional Tester
Segue SilkTest
Segue SilkTest International
Empirix e-Tester
Radview WebFT
AutomatedQA TestComplete
Seapine QA Wizard
RedStone Software EggPlant
Microsoft Visual Studio Test Edition
Minq PureTest
Autotester Autotester
Original Software Testbench400
VEReCOMM TestExpert
Qronus TestRunner
Telelogic TTCN suite
Centerline QC/Replay
AutoTester Web
Software Research eValid
OCLC WebART
开源 MaxQ
开源 WebInject
开源 Marathon
性能测试/监控工具
厂商 工具名称
Mercury LoadRunner
Mercury SiteScope
Mercury Topaz
Compuware QaLoad
Quest PerformaSure/benchmark
Segue Silkperformer
Segue Silkperformer Lite
Segue SilkCentralTM Performance Manager
Empirix e-Load
IBM Rational Robot
IBM Rational Performance Tester
RadView WebLoad
Microsoft Web applicaton stress tool
Microsoft Application center test
Minq PureLoad
Metron Athene APR
facilita ForeCast
Cyrano Impact/Impact for CBT
Lawrence Berkeley Laboratory sniffer
开源 Jmeter
开源 openSTA
开源 Siege
开源 StressMark
开源 DBMonster
白盒测试/代码分析工具
厂商 工具名称
Parasoft Jtest
Parasoft C++test
Parasoft SOA test
Parasoft .test
Parasoft Codewizard
Parasoft Insure++
Parasoft DataRecon
Compuware Numega devpartner studio
Compuware DevPartnerJavaEdition
Compuware BoundsChecker
Compuware SmartCheck
Compuware DBPartner
Empirix Bean-test
AutomatedQA AQtime
AutomatedQA QESatJava
Unitware Visual Unit
Gimpel Software PC-lint
Macabe Macabe
Borland Optimizeit Suite
Quest Software JProbe Suite
Quest Software Application assurance suite
Quest Software Sql optimizer
ej-technologies JProfiler
cyrano workbench
TeleLogic Logiscope
TeleLogic rulecheck
Macabe Macabe
Segue SilkPerformer Component Test Edition
IBM rational Purifyplus
IBM rational Rational Test Realtime
开源 junit
开源 cactus
开源 Hansel
开源 TestNG
开源 StrutsTestCase
开源 JFCUnit
开源 Httpunit
开源 Dunit
开源 cppunit
开源 Nunit
开源 Xunit
开源 JTR
Linux平台工具 MallocDebug
Linux平台工具 Valgrind
Linux平台工具 Kcachegrind
Linux平台工具 dmalloc
Linux平台工具 ElectricFence
Linux平台工具 LeakTracer
Linux平台工具 memprof
Linux平台工具 ccmalloc
Linux平台工具 mprof
Linux平台工具 yamd
Linux平台工具 njamd
Linux平台工具 mpatrol
嵌入式系统测试工具
厂商 工具名称
Metrowerks codetest
IPL Cantata/cantana++
Reflex Technology IceMaster
Reflex Technology System test
DDC-I scorecast
testquest Testquest
ATTOL UniText
Vector software vectorcast
qronus testrunner
telelogic Logiscope
RT-Builder
测试管理工具
厂商 工具名称
Mercury TestDirector(QualityCenter)
Compuware QADirector
worksoft certify
aimware Proct manager
segue SilkCentral Test Manager
telelogic Doors
empirix e-manager
IBM Rational testmanager
RadView TestView Manager
T-Plan Professional
testlink
缺陷管理工具
厂商 工具名称
Mercury TestDirector(QualityCenter)
IBM Rational ClearQuest
Compuware TrackRecord
Seapine TestTrack pro
McCabe TrueTrack
Techexcel Devtrack
IBM Lotus Notes
Segue SilkCentral Issue Manager
Merant PVCS Tracker
Remedy AR System
LealSoft URTrack
缺陷管理系统BMS
Clarion
Hansky Butterfly
开源 Bugzilla
开源 Mantis
开源 JIRA
开源 BugFree
配置管理工具
厂商 工具名称
IBM Rational ClearCase
Merant PVCS Version Manager
Diamond VCS
Computer Associates AllFusion Harvest Change Manager/CCC Harvest
Borland StarTeam
MKS Source Integrity Enterprise and Integrity Manager
Serena ChangeMan Professional
Perforce Perforce
McCabe TRUEchange
Telelogic SYNERGY CM
Microsoft VSS
JBCM
Hansky Firefly
开源 CVS
开源 subversion
开源 SCCS
开源 RCS