提高测试效率，降低人工测试成本。
2.3 TestCenter（测试管理工具）
TestCenter是一款功能强大测试管理工具，它可以帮助您：实现测试用例的过程管理，对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。实现测试用例的标准化即每个测试人员都能够理解并使用标准化后的测试用例，降低了测试用例对个人的依赖；提供测试用例复用，用例和脚本能够被复用，以保护测试人员的资产；提供可伸缩的测试执行框架，提供自动测试支持；提供测试数据管理，帮助用户同意管理测试数据，降低测试数据和测试脚本之间的耦合度。
第三章 软件测试的方法
3.1 黑盒测试
黑盒测试，英文是Black Box Testing。又称功能测试或者数据驱动测试。 黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。 软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。
3.1．1 单元测试（Unit Testing）集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。 * 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 * 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
3.1.2 集成测试（Integrated Testing）把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
3.1.3 确认测试（Validation Testing）则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。 * 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含
的信息就是软件确认测试的基础。
3.1.4 系统测试（System Testing）把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。 * 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。 * 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
3.2 白盒测试
白盒测试，英文是White Box Testing。又称结构测试或者逻辑驱动测试。 白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。 白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。 白盒测试是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
3.3 自动化测试
自动化测试，英文是Automated Testing。 使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本，然后执行这个测试脚本来实现测试过程的自动化。自动化测试工具有AutoRunner和TAR等。
3.4 压力测试
压力测试，英文是Stress Testing。和负载测试差不多。 压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在极限环境或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。主要测试有弱信号测试、高速运动测试、DATA内存满测试、后台运行满测试等等
3.5 随机测试
随机测试，英文是Ad hoc testing。 随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。
第四章 软件测试用例
4.1 测试用例的重要性
软件测试的重要性事毋庸置疑的，但是如何以最少的人力、资源投入、在最短的时间内完成测试，发现软件测试系统的缺陷，保证软件的优良品质，则是软件公司探讨和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
影响软件测试的因素有很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试人员）的素质，测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是 流动的，有经验的走了，新人不断补充进来，一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例来实施，都能保障测试的质量，可以把人为因素的影响减少到最小，即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。 因此，测试用例的设计和编制是软件测试活动中最重要的，测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
4.2 功能测试用例
测试种类繁多，针对不同的测试，测试用例的设计方式完全不同。本小节主要探讨的是功能测试中使用的测试用例。
测试用例是测试人员执行测试时的重要参照标准。因此，测试用例必需使测试人员能够明确理解，并能够依据测试用例的描述执行测试。为此，一个设计良好的测试用例应当包括如下几个关键几点： （1）、.用例编号(testcaseIndex)，一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好的用例编号体系，那么通过用例编号，便可对测试用例进行快速定位，查询时事半功倍，以便更快地解决问题。 （2.）、用例名称(testCaseName)，用例名称的编写应使用最精简的文字，描绘出用例的全貌。编写良好的用例名称如同书籍的目录，能够帮助阅读者整理思路，定位用例。 （3）、.前置条件(precondition)，前置条件指测试执行者在执行测试用例的操作步骤前，必须完成的准备工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、前置工序的执行等。 （4）、.测试步骤 (Teststep)，测试用例中，每个操作均可设计为一个步骤。一个测试用例由一个或多个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。正常步骤指普通用户为了实现正常功能，进行的普遍的、正确的、系统期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明，也是程序需要实现的主要功能。
容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。对此类错误操作，系统应有足够的容忍性，进行一些友好的提示、阻止或处理，而不是产生异常。
需求文档中，通常会对正常步骤进行明确定义。因此，正常步骤是严谨的，甚至是唯一的，编写者的发挥空间非常狭小。容错流程恰恰相反。一个思维活跃、经验丰富的测试人员在编写容错步骤时，能够考虑到各类不同的容错步骤，其编写
出的测试用例也是全面、广泛而又犀利的。容错流程的编写深度与广度能够很好的反映编写者的技术实力，这样才能更加全面的进行软件测试。 （5）、.步骤描述(Deseription)，步骤描述是测试步骤的主体，是测试人员执行测试时的重要阅读对象。因此，测试步骤必须表述详细，描述清晰，用语必须规范、严谨而又客观。最基本的要求是能够使其他人理解，并能正确的执行编写者期望的操作。 （6）、.期望结果，期望结果是执行测试时，测试者所进行比对的标尺，是一个测试步骤是否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的后果是严重的。 （7）、.实际结果 (ActualResultS)实际结果供测试人员在运行测试时填写观察到的实际结果。填写的内容同样需做到规范、严谨与客观。 （8）、.测试结论 (TestResult)与实际结果类似，测试结论供测试人员运行测试时填写。若实际结果与期望结果两者一致，或虽然不一致，但在可接受范围内，则可以认为该步骤是通过的，测试结论应置为passed;若两者不一致，且无法接受，则应将结果置为Failed。
第五章 软件测试的心理学问题
5.1 程序测试过程具有破坏性
人类的活动具有高度的目的性，建立适当的目标具有重要的心理作用。如果我们的目的是要证明程序中没有错误，那我们就会不自觉地朝这个方向去做；也就是说，我们会倾向于挑选那些使程序出错的可能性较小的测试数据。另一方面，如果我们的目标是要证明程序中有错，那就会选择一些易于发现程序所含错误的测试数据。而后一种态度会比前者给程序增添更多的价值。心理学研究还告诉我们，当人在干一件已经知道是不合适的或不可能做到的事时，往往做得不好。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。
5.2 程序员应避免测试自己的程序
开发者被指定测试自己的代码是一件很糟糕的事。开发和测试生来就是不同的活动。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试--单元测试。不同当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。许多户主都知道，揭掉糊墙纸（破坏性过程〉是不容易的，若糊墙纸原先是由他而不是别人贴上的，他几平会感到难以忍受的沮丧。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。 除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。再者，可以把测试看
做是对一篇论文或?本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容的。
5.3 程库设计机构不应测试自己的程序
在许多意义上来说，一项工程或一程序设计机构是个有生命的有机体，它同样有心理学问题。再者，在大多数情况下，人们都是以在给定日期内，以一定代价编制程序的能力来衡量程序设计机构和项目管理人员的。这祥做的一个理由是时间和成本指标便于衡量，而程序的可靠性却很难度量。要程序设计机构在测试自己的程序时持客观态度是困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试也不大可能把耗费的代价限制在要求的范围以内。
采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。 ①、客观性
对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。 ②、专业性
独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。 ③、权威性
由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。 ④、资源有保证
独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。 5.4 好的测试工程师应具备的素质 ①、 ②、 ③、 ④、 ⑤、 ⑥、 ⑦、 ⑧、 ⑨、 ⑩、 ?、
沟通能力。 移情能力。 技术能力。 自信心。 外交能力。 幽默感。
很强的记忆力。 耐心。 怀疑精神。 自我督促。 洞察力。