|
1. 功能测试 |
-
测试的招聘与面试！
2007-09-11 14:29:50
-
分享：一个软件测试人员的工作经历2
2007-09-11 14:19:33
-
分享：一个软件测试人员的工作经历
2007-09-11 14:18:30
-
综合
2007-06-06 17:31:46
-
如何应对面试“面试的十大必考题”
2007-06-06 17:30:04
-
浅谈软件测试（基础）
2007-06-06 17:27:28
一、软件测试概述
软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。
软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。
测试人员在软件开发过程中的任务：
1、寻找Bug；
2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。
二、常用的软件测试方法
1. 黑盒测试
黑盒测试顾名思义就是将被测系统看成一个黑盒，从外界取得输入，然后再输出。整个测试基于需求文档，看是否能满足需求文档中的所有要求。黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关的知识或经验，它适用于对系统的功能进行测试。
黑盒测试的优点有：
1）比较简单，不需要了解程序内部的代码及实现；2）与软件的内部实现无关；
3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
5）在做软件自动化测试时较为方便。
黑盒测试的缺点有：
1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；2）自动化测试的复用性较低。
2. 白盒测试
白盒测试是指在测试时能够了解被测对象的结构，可以查阅被测代码内容的测试工作。它需要知道程序内部的设计结构及具体的代码实现，并以此为基础来设计测试用例。如下例程序代码：
HRESULT Play( char* pszFileName )
{
if ( NULL == pszFileName )
return;
if ( STATE_OPENED == currentState )
{
PlayTheFile();
}
return;
}
读了代码之后可以知道，先要检查一个字符串是否为空，然后再根据播放器当前的状态来执行相应的动作。可以这样设计一些测试用例：比如字符串（文件）为空的话会出现什么情况；如果此时播放器的状态是文件刚打开，会是什么情况；如果文件已经在播放，再调用这个函数会是什么情况。也就是说，根据播放器内部状态的不同，可以设计很多不同的测试用例。这些是在纯粹做黑盒测试时不一定能做到的事情。
白盒测试的直接好处就是知道所设计的测试用例在代码级上哪些地方被忽略掉，它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：
1）程序运行会有很多不同的路径，不可能测试所有的运行路径；
2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
3）系统庞大时，测试开销会非常大。
3. 基于风险的测试
基于风险的测试是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。
基于风险测试的两个决定因素就是：该功能出问题对用户的影响有多大，出问题的概率有多大。其它一些影响因素还有复杂性、可用性、依赖性、可修改性等。测试人员主要根据事情的轻重缓急来决定测试工作的重点。
4. 基于模型的测试
模型实际上就是用语言把一个系统的行为描述出来，定义出它可能的各种状态，以及它们之间的转换关系，即状态转换图。模型是系统的抽象。基于模型的测试是利用模型来生成相应的测试用例，然后根据实际结果和原先预想的结果的差异来测试系统，过程如下图所示。
三、软件测试的类型
常见的软件测试类型有：
BVT (Build Verification Test)
BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如无大的问题，就可以进行相应的功能测试。BVT优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。
Scenario Tests（基于用户实际应用场景的测试）
在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。
Smoke Test
在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安装升级测试）等。
四、微软的软件测试工作
1. 基本情况
测试在微软公司是一项非常重要的工作，微软公司在此方面的投入是非常巨大的。微软对测试的重视表现在工程开发队伍的人员构成上，微软的项目经理、软件开发人员和测试人员的比例基本是1：3：3或1：4：4，可以看出开发人员与测试人员的比例是1：1。对于测试的重视还表现在最后产品要发布的时候，此产品的所有相关部门都必须签字，而测试人员则具有绝对的否决权。
测试人员中分成两种职位，Software Development Engineer in Test（测试组的软件开发工程师）实际上还是属于开发人员，他们具备编写代码的能力和开发工具软件的经验，侧重于开发自动化测试工具和测试脚本，实现测试的自动化。Software Test Engineer（软件测试工程师）具体负责测试软件产品，主要完成一些手工测试以及安装配置测试。
2. 测试计划
测试计划是测试人员管理测试项目，在软件中寻找Bug的一种有效的工具。测试计划主要有两个作用，一是评判团队的测试覆盖率以及效率，让测试工作很有条理的逐步展开。二是有利于与项目经理、开发人员进行沟通。有了测试计划之后，他们就能够知道你是如何开展测试工作的，他们也会从中提出很多有益的意见，确保测试工作顺利进行。总之，有了测试计划可以更好的完成测试工作，确保用户的满意度。
测试人员在编写测试计划之前，应获得以下文档：
1）程序经理编写的产品功能说明书或产品开发计划；
2）程序经理或开发人员提供的开发进度表。
根据产品的特性及开发进度安排，测试人员制定具体的测试计划。测试计划通常包括以下内容：
1）测试目标和发布条件：
a. 给出清晰的测试目标描述；
b. 定义产品的发布条件，即在达到何种测试目标的前提下才可以发布产品的某个特定版本。
2）待测产品范围：
a. 软件主要特性/功能说明，即待测软件主要特性的列表；
b. 特性/功能测试一览，应涵盖所有特性、对话框、菜单和错误信息等待测内容，并列举每个测试范围内要重点考虑的关键功能。
3）测试方法描述：
a. 定义测试软件产品时使用的测试方法；
b. 描述每一种特定的测试方法可以覆盖哪些测试范围。
4）测试进度表：
a. 定义测试里程碑；
b. 定义当前里程碑的详细测试进度。
5）测试资源和相关的程序经理/开发工程师：
a. 定义参与测试的人员；
b. 描述每位测试人员的职责范围；
c. 给出与测试有关的程序经理/开发工程师的相关信息。
6）配置范围和测试工具：
a. 给出测试时使用的所有计算机平台列表；
b. 描述测试覆盖了哪些硬件设备；
c. 测试时使用的主要测试工具。
此外，还应列出测试中可能会面临的风险及测试的依赖性，即测试是否依赖于某个产品或某个团队。比如此项测试依赖性WindowsCE这个操作系统，而这个系统要明年2月份才能做好，那么此项测试就可能只有在明年5月份才能完成，这样就存在着依赖关系。如果那个团队的开发计划往后推，则此项测试也会被推迟。
3. 测试用例开发
一个好的测试用例就是有一个合理的概率来找到Bug，不要冗余，要有针对性，一个测试只针对一件事情。特别是功能测试的时候，如果一个测试是测了两项功能，那么如果测试结果失败的话，就不知道到底是哪项功能出了问题。
测试用例开发中主要使用的技术有等价类划分，边界值的分析，Error Guessing Testing。
等价类划分是根据输入输出条件，以及自身的一些特性分成两个或更多个子集，来减少所需要测试的用例个数，并且能用很少的测试用例来覆盖很多的情况，减少测试用例的冗余度。在等价类划分中，最基本的划分是一个为合法的类，一个为不合法的类。
边界值的分析是利用了一个规律，即程序最容易发生错误的地方就是在边界值的附近，它取决于变量的类型，以及变量的取值范围。一般对于有n个变量时，会有6n+1个测试用例，取值分别是min-1, min, min+1, normal, max-1, max,max+1的组合。边界值的分析的缺点，是对逻辑变量和布尔型变量不起作用，还有可能会忽略掉某些输入的组合。
Error Guessing Testing完全靠的是经验，所设计的测试用例就是常说的猜测。感觉到软件在某个地方可能出错，就去设计相应的测试用例，这主要是靠实际工作中所积累的经验和知识。其优点是速度快，只要想得到，就能很快设计出测试用例。缺点就是没有系统性，无法知道覆盖率会有多少，很可能会遗漏一些测试领域。
实际上在微软是采用一些专门的软件或工具负责测试用例的管理，有一些测试信息可以被记录下来，比如测试用例的简单描述，在哪些平台执行，是手工测试还是自动测试，运行的频率是每天运行一次，还是每周运行一次。此外还有清晰的测试通过或失败的标准，以及详细记录测试的每个步骤。
4. Bug跟踪过程
在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
5. Bug的不同处理方式
在某些情况下，Bug已处理并不意味着Bug已经被修正。开发工程师可以推迟Bug的修正时间，也可以在分析之后告知测试工程师这实际上不是一个真正的Bug。也就是说，某特定的Bug经开发工程师处理之后，该Bug可能包括以下几种状态。
已修正：开发工程师已经修正了相应的程序代码，该Bug不会出现了。
可推迟：该Bug的重要程度较低，不会影响当前应提交版本的主要功能，可安排在下一版本中再行处理。
设计问题：该Bug与程序实现无关，其所表现出来的行为完全符合设计要求，对此应提交给程序经理处理。
无需修正：该Bug的重要程度非常低，根本不会影响程序的功能，项目组没有必要在这些Bug上浪费时间。
五、成为优秀测试工程师的要求
要成为一名优秀的测试工程师，首先对计算机的基本知识要有很好的了解，精通一门或多门的编程语言，具备一定的程序调试技能，掌握测试工具的开发和使用技术。同时要比较细心，会按照任务的轻重缓急来安排自己的工作，要有很好的沟通能力。此外，还要善于用非常规的方式思考问题，尽可能多的参加软件测试项目，在实践中学习技能，积累经验，不断分析和总结软件开发过程中可能出错的环节。这样，一名优秀的测试工程师就从软件测试的实践中脱颖而出了。
-
软件测试,从零开始:测试新手入门必读
2007-06-06 17:07:58
-
测试工具大全(各类测试工具简介)
2007-06-06 17:04:57
企业级自动化测试工具WinRunner
提名理由：Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
工业标准级负载测试工具Loadrunner
提名理由：LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
全球测试管理系统testdirector
提名理由：TestDirector 是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。
功能测试工具Rational Robot
提名理由：IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。
单元测试工具xUnit系列
提名理由：目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit （Delphi ），NUnit（.net），PhpUnit（Php ）等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。
功能测试工具SilkTest
提名理由：Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。
性能测试工具WAS
提名理由：Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。
自动化白盒测试工具Jtest
提名理由：Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。
性能测试和分析工具WEBLODE
提名理由：webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。
测试工具大全
Author: Vince
工具类别 工具名称 生产厂商 相关网站 通用功能自动化测试工具 Winrunner Mercury Quicktest pro Mercury Xrunner Mercury QARun Compuware TestPartner Compuware WebKing Parasoft http://www.parasoft.com Robot IBM Rational http://www.ibm.com/cn Visual Test IBM Rational http://www.ibm.com/cn Functional Tester IBM Rational http://www.ibm.com/cn SilkTest Segue SilkTest International Segue e-Tester Empirix WebFT Radview TestComplete AutomatedQA QA Wizard Seapine Software EggPlant RedStone Test Edition Microsoft Visual Studio PureTest Minq Autotester Autotester Testbench400 Original Software TestExpert VEReCOMM TestRunner Qronus TTCN suite Telelogic http://www.telelogic.com.cn QC/Replay Centerline Web AutoTester eValid Software Research WebART OCLC MaxQ 开源 WebInject 开源 Marathon 开源 性能测试/监控工具 LoadRunner Mercury SiteScope Mercury Topaz Mercury QaLoad Compuware PerformaSure/benchmark Quest Silkperformer Segue Silkperformer Lite Segue SilkCentralTM Performance Manager Segue e-Load Empirix Robot IBM Rational http://www.ibm.com/cn Performance Tester IBM Rational http://www.ibm.com/cn WebLoad RadView Web applicaton stress tool Microsoft Application center test Microsoft PureLoad Minq Athene APR Metron ForeCast Facilita Impact/Impact for CBT Cyrano Berkeley Laboratory sniffer Lawrence Jmeter 开源 openSTA 开源 Siege 开源 StressMark 开源 DBMonster 开源 白盒测试/代码分析工具 VcTester ezTester http://www.eztester.com Jtest Parasoft http://www.parasoft.com C++test Parasoft http://www.parasoft.com SOA test Parasoft http://www.parasoft.com .test Parasoft http://www.parasoft.com Codewizard Parasoft http://www.parasoft.com Insure++ Parasoft http://www.parasoft.com DataRecon Parasoft http://www.parasoft.com Numega devpartner studio Compuware DevPartnerJavaEdition Compuware BoundsChecker Compuware SmartCheck Compuware DBPartner Compuware Bean-test Empirix Aqtime AutomatedQA QESatJava AutomatedQA Visual Unit Unitware PC-lint Gimpel Software Macabe Macabe Optimizeit Suite Borland JProbe Suite Quest Software Application assurance suite Quest Software Sql optimizer Quest Software Jprofiler ej-technologies workbench Cyrano Logiscope TeleLogic http://www.telelogic.com.cn rulecheck TeleLogic http://www.telelogic.com.cn SilkPerformer Component Test Edition Segue Purifyplus IBM rational http://www.ibm.com/cn Rational Test Realtime IBM rational http://www.ibm.com/cn junit 开源 cactus 开源 Hansel 开源 TestNG 开源 StrutsTestCase 开源 JFCUnit 开源 Httpunit 开源 Dunit 开源 cppunit 开源 http://sourceforge.net/projects/cppunit Nunit 开源 Xunit 开源 JTR 开源 MallocDebug Linux平台工具 Valgrind Linux平台工具 Kcachegrind Linux平台工具 dmalloc Linux平台工具 ElectricFence Linux平台工具 LeakTracer Linux平台工具 memprof Linux平台工具 ccmalloc Linux平台工具 mprof Linux平台工具 yamd Linux平台工具 njamd Linux平台工具 mpatrol Linux平台工具 嵌入式测试工具 VcTester ezTester http://www.eztester.com codetest Metrowerks Cantata/cantana++ IPL IceMaster Reflex Technology System test Reflex Technology scorecast DDC-I Testquest Testquest UniText ATTOL vectorcast Vector software testrunner Qronus Logiscope Telelogic http://www.telelogic.com.cn 测试管理工具 TestDirector(QualityCenter) Mercury QADirector Compuware certify Worksoft Product manager Aimware SilkCentral Test Manager Segue Doors Telelogic http://www.telelogic.com.cn e-manager Empirix testmanager IBM Rational http://www.ibm.com/cn TestView Manager RadView Professional T-Plan 缺陷管理工具 TestDirector(QualityCenter) Mercury ClearQuest IBM Rational http://www.ibm.com/cn TrackRecord Compuware TestTrack pro Seapine TrueTrack McCabe Devtrack Techexcel Notes IBM Lotus SilkCentral Issue Manager Segue PVCS Tracker Merant AR System Remedy URTrack LealSoft Butterfly Hansky Bugzilla 开源 Mantis 开源 JIRA 开源 BugFree 开源 配置管理工具 ClearCase IBM Rational http://www.ibm.com/cn PVCS Version Manager Merant VCS Diamond StarTeam Borland Perforce Perforce TRUEchange McCabe SYNERGY CM Telelogic http://www.telelogic.com.cn VSS Microsoft Firefly Hansky CVS Subversion SCCS RCS CCC/Harvest Computer Associates -
软件测试常用单词
2007-06-06 17:03:13
-
如何使用VS2005的WebTest对webservice进行数据源绑定测试
2007-06-06 15:50:06
VS2005中的WebTest工具主对是针对于HTTP协议来做的，所以他不仅能测ASP.net的应用，还可以测任何基于http协议的应用，比如JSP、PHP等等。
WebTest在做数据源绑定时，只能很好地分拆Http的Get、Post请求数据包，这对测试webSite已经够了。但如果测web Service就相对不够用，因为WebTest不能分拆Soap包，没有对Soap包内数据进行绑定操作的界面，这一功能需要手工完成。下面就是一个使用VS2005 WebTest工具对webservice进行数据源绑定测试的例子。
1. 先准备一个WebService,并部署到IIS上。
这里有一个简单的WebService:
[WebMethod]
public int Add(int i,int j)
{
return i + j;
}
服务调用说明如下：
2. 准备测试数据
3. 新建Web测试
a) 新建测试项目
b) 新建Web测试
c) 当出现IE录制界面进，按Stop停止录制。
d) 在webtest1里添加Web service request
e) 在web service request里添加Header,其Name=SOAPActioin, Value=” http://tempuri.org/Add”，也就是服务协议里SOAPActioin的值。
f) 在web测试中添加数据源，指向test表。
g) 在http://localhost:8001/webservice/service.asmx?op=Add中注意SOAP请求中下列数据：
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Add xmlns="http://tempuri.org/">
<i>int</i>
<j>int</j>
</Add>
</soap:Body>
将其中的i和j的值改为：{{数据源名.表名.列名}}，如下所示：
<i>{{MyComics1.tset.i}}</i>
<j>{{MyComics1.tset.j}}</j>
h) 将上面的信息加到Webservice request的stringbody中，如下图所示：
i) 将Web测试的URL改为所测的URL，如下图所示：
到此，测试设置完成。
4. 运行测试
a) 直接运行测试，结果正常。
b) 修改测试，让数据源中的每一条记录都做一次测试。
c) 结果如下图所示，每条数据都执过。
-
LoadRunner监控Windows和Linux常见问题
2007-06-06 15:46:27
-
怎么样提高软件测试员自身素质培养?(转帖)
2007-06-06 15:44:51
-
测试人员面试三步曲
2007-06-06 15:30:38
-
常用的功能测试方法
2007-06-06 15:22:15
-
什么是SQA
2007-06-06 15:15:09
-
如何测试web网站？
2007-06-06 15:10:32
-
测试的心理要求
2007-06-06 15:03:52
-
微软公司是如何测试的
2007-06-06 14:57:18
-
软件测试的基本方法
2007-06-06 14:24:04
软件测试的方法和技术是多种多样的。
对于软件测试技术，可以从不同的角度加以分类：
从是否需要执行被测软测试和动态测试。
从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试；
1、黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
2、白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：
– 对程序模块的所有独立的执行路径至少测试一次；
– 对所有的逻辑判定，取 “ 真 ” 与取 “ 假 ” 的两种情况都至少测试一次；
– 在循环的边界和运行界限内执行循环体；
– 测试内部数据结构的有效性，等。
具体包含的逻辑覆盖有： – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定－条件覆盖 – 条件组合覆盖 – 路径覆盖。=====引用 天网======
“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？”
答案在于软件自身的缺陷：
1、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
2、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。
正如Beizer所说的：“错误潜伏在角落里，聚集在边界上”，而白盒测试更可能发现它。3. 灰盒测试
灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。4．ALAC(Act-like-a-customer)测试
学习宝典.chm::/软件测试常识/软件测试分类及方法/ff1.jpg" width=435>
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。
-
排错的基本方法
2007-06-06 14:18:27
排错（即调试）与成功的测试形影相随。测试成功的标志是发现了错误。根据错误迹象确定错误的原因和准确位置，并加以改正的主要依靠排错技术。
１． 排错过程
如下图所示，排错过程开始于一个测试用例的执行，若测试结果与期望结果有出入，即出现了错误征兆，排错过程首先要找出错误原因，然后对错误进行修正。因此排错过程有两种可能，一是找到了错误原因并纠正了错误，另一种可能是错误原因不明，排错人员只得做某种推测，然后再设计测试用例证实这种推测，若一次推测失败，再做第二次推测，直到发现并纠正了错误。
排错是一个相当艰苦的过程，究其原因除了开发人员心理方面的障碍外，还因为隐藏在程序中的错误具有下列特殊的性质：
（1） 错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构此类现象更为严重；
（2） 纠正一个错误造成了另一错误现象（暂时）的消失；
（3） 某些错误征兆只是假象；
（4） 因操作人员一时疏忽造成的某些错误征兆不易追踪；
（5） 错误是由于风时而不是程序引起的； （6） 输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）；
（7） 错误征兆时有时无，此现象对嵌入式系统尤其普遍；
（8） 错误是由于把任务分布在若干台不同处理机上运行而造成的。
在软件排错过程中，可能遇到大大小小、形形色色的问题，随着问题的增多，排错人员的压力也随之增大，过分地紧张致使开发人员在排除一个问题的同时又引入更多的新问题。
尽管排错不是一门好学的技术（有时人们更愿意称之为艺术），但还是有若干行之有效的方法和策略，下面介绍几种排错方法。
２． 排错方法
无论采用哪种排错方法，目标只有一个，即发现并排除引起错误的原因，这要求排错人员能把直观想象与系统评估很好的结合起来。 常用的排错策略分为三类：
① 原始类（brute force）
② 回溯类（backtracking）
③ 排除类（cause eliminations）原始类排错方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是"通过计算机找错"。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。
回溯法能成功地用于程序的排错。方法是从出现错误征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。
排除法基于归纳和演绎原理，采用"分治"的概念，首先惧与错误出现有关有所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击。
上述每一类方法均可辅以排错工具。目前，调试编译器、动态调试器（"追踪器"）、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。然而，无论什么工具也替代不了一个开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。此外，不应荒废排错过程中最有价值的一个资源，那就是开发小组中其他成员的评价和忠告，正所谓"当事者迷，旁观者清"。
前面多次提到，修改一处老问题可能引入几处新问题，有时程序越改越乱，但若能做到每次纠错前都扪心自问三个问题，情况将大为改观：51Testing软件测试网① 导致这个错误的原因在程序其他部分还可能存在吗？
② 本次修改可能对程序中相关的逻辑和数据造成什么影响？引起什么问题？
③ 上次遇到的类似问题是如何排除的？
