软件测试基础.docx
《软件测试基础.docx》由会员分享，可在线阅读，更多相关《软件测试基础.docx（21页珍藏版）》请在冰豆网上搜索。
软件测试基础
软件测试基础
软件测试仍然是目前保证软件质量的主要途径。
它是对软件需求规格说明、软件设计和编码的最后复审。
本小节主题：
•软件测试的目标
•软件测试的原则
•软件测试的对象
•软件测试的方法
•软件测试的信息流
•软件测试与开发的关系
软件测试的目标
•什么是测试？
它的目标是什么？
•基于不同的立场，存在着两种完全不同的测试目的。
•从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。
•从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。
关于软件测试的目的
（1）测试是执行程序的过程，目的是为了发现程序中的错误；
（2）好的测试方案极可能发现至今未发现的错误；
（3）成功的测试是发现了至今尚未发现的错误的测试。
•换言之，测试的目的是
–想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。
如果我们成功地实施了测试，我们就能够发现软件中的错误。
–测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。
软件测试的原则
•所有测试都应该能追溯到用户需求。
从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。
•应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
•测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
•为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
•应该从“小规模”测试开始，并逐步进行“大规模”测试。
6.充分注意测试中的群集现象。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
7.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
8.严格执行测试计划，排除测试的随意性，并每一个测试结果做全面检查。
9.妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
-----8-2原理----
•测试发现的错误中的80%很可能是由程序中20%的模块造成的。
软件测试的对象
•软件测试并不等于程序测试。
软件测试应贯穿于软件定义与开发的整个期间。
•需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。
•为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。
•确认，是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。
–需求规格说明的确认
–程序的确认（静态确认、动态确认）
•验证，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。
测试方法
如果知道产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；如果知道产品的内部工作过程，可以通过测试来检验产品的内部动作是否规定的动作正常进行。
前一种软件产品测试的方法被称为黑盒测试，后一种方法被称为白盒测试。
测试步骤
一般地，测试都是分步骤进行的，后一个步骤在逻辑上是前一个步骤的继续。
大型软件通常都由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件的测试基本上由如下几个步骤组成。
•模块测试：
目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。
所发现的往往是编码和详细设计的错误。
•子系统测试：
着重测试模块的接口，模块相互间的协调和通信是这个测试过程中的主要问题。
•系统测试：
兼有检测和组装两重含义，通常称为集成测试。
在这个步骤中发现的往往是软件设计中或需求说明中的错误。
4.验收测试：
目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
也称为确认测试。
5.平行运行
关系重大的软件在验收之后不立即投入正式的生产性运行，而是新系统和旧系统同时运行，以便比较新旧两个系统的处理结果。
Alpha测试和Beta测试
如果软件是专为某个客户定制的，可以进行一系列的验收测试，如果是为许多客户开发的软件产品，则由每个客户都进行正式的验收测试是不现实的。
Alpha测试和Beta测试用来发现那些看起来只有最终用户才能发现的错误。
Alpha测试
由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
开发者负责记录发现的错误和使用中遇到的问题。
Alpha测试是在受控的环境中进行的。
Beta测试
由软件的最终用户们在客户的场所进行。
开发者通常不在Beta测试的现场，因此，Beta测试是在开发者不能控制的环境中的“真实”应用。
用户记录在Beta测试过程中遇到的一切问题，并且把这些问题反馈给开发者。
开发者对软件产品进行必要的修改，之后发布最终的软件产品。
测试信息流
测试阶段的信息流
测试信息流
•软件配置：
软件需求规格说明、软件设计规格说明、源代码等；
•测试配置：
测试计划、测试用例、测试程序等；
•测试工具：
测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。
•测试结果分析：
比较实测结果与预期结果，评价错误是否发生。
•排错（调试）：
对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。
•修正后再测试：
直到通过测试为止。
•软件可靠性可以通过使用错误率数据，估计将来出现错误的情况，预测软件可靠性。
•利用可靠性分析，评价软件质量：
–软件的质量和可靠性达到可以接受的程度；
–所做的测试不足以发现严重的错误；
•如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。
测试与软件开发各阶段的关系
•软件开发过程是一个自顶向下，逐步细化的过程
•软件计划阶段定义软件作用域
•软件需求分析建立软件信息域、功能和性能需求、约束等
•软件设计
•把设计用某种程序设计语言转换成程序代码
软件开发V型图
1.3软件测试技术
•两种常用的测试方法
–黑盒测试
–白盒测试
测试用例
设计测试方案是测试阶段的关键问题。
测试方案包括测试目的（如预定要测试的具体功能），应该输入的测试数据和预期的结果。
通常又把测试数据和预期的输出结果称为测试用例。
其中最困难的是设计测试用的输入数据。
不同的测试数据发现程序错误的能力差别很大，为了提高测试效率降低测试成本，应该选用高效的测试数据。
因为不可能进行穷尽的测试，选用少量“最有效的”测试数据，做到尽可能完备的测试更为重要。
设计测试方案的基本目标是，确定一组最可能发现某个错误或某类错误的测试数据。
已经研究出许多设计测试数据的技术，这些技术各有优缺点，没有哪一种是最好的，更没有哪一种可以代替其余所有技术；同一种技术在不同的应用场合效果可能相差很大，因此，通常需要联合使用多种设计测试数据的技术。
1.3.1黑盒测试技术
黑盒测试着重测试软件功能。
又称为功能测试或数据驱动测试。
把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
黑盒测试技术
黑盒测试力图发现下述类型的错误：
①功能不正确或遗漏了功能；
②界面错误；
③数据结构错误或外部数据库访问错误；
④性能错误；
⑤初始化和终止错误。
黑盒测试方案
黑盒测试主要用于测试过程的后期。
设计黑盒测试方案时，主要考虑：
（1）怎样测试功能的有效性？
（2）哪些类型的输入可构成好的测试用例？
（3）系统是否对特定的输入值特别敏感？
（4）怎样划定数据类的边界？
（5）系统能够承受什么样的数据率和数据量？
（6）数据的特定组合将对系统运行产生什么影响？
黑盒测试方法
1等价划分
2边界值分析
3错误推测法
4因果图
1等价划分
把程序的输入域划分成若干个数据类，然后从每一部分中选取少数有代表性的数据做为测试用例。
完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
•一个理想的测试用例能独自发现一类错误。
•穷尽的黑盒测试通常是不现实的。
因此，只能选取少量最有代表性的输入数据作为测试数据，以期用较小的代价暴露出较多的程序错误。
•等价划分法力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。
•使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。
启发式规则
划分等价类的几条启发式规则：
（1）如果规定了输入值的范围，则可划分出一个有效的等价类（输入值在此范围内），两个无效的等价类（输入值小于最小值或大于最大值）；
（2）如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类；
（3）如果规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类（任一个不允许的输入值）；
（4）如果规定了输入数据必须遵循的规则，则可以划分出一个有效的等价类（符合规则）和若干个无效的等价类（从各种不同角度违反规则）；
（5）如果规定了输入数据为整型，则可以划分出正整数、零和负整数等3个有效类；
（6）如果程序的处理对象是表格，则应该使用空表，以及含一项或多项的表。
划分出等价类后，根据等价类设计测试方案时主要使用下面两个步骤：
（1）设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；
（2）设计一个新的测试方案，使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。
注意，应该使每个测试方案只覆盖一个无效的等价类。
2边界值分析
等价划分方法的补充。
处理边界情况时程序最容易发生错误。
设计使程序运行在边界情况附近的测试方案，暴露出程序错误的可能性更大一些，可以查出更多的错误。
例如，许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近。
使用边界值分析方法设计测试方案首先应该确定边界情况。
选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。
也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。
通常设计测试方案时总是联合使用等价划分和边界值分析两种技术。
3错误推测
一般说来，即使是一个比较小的程序，可能的输入组合数也往往十分巨大，因此必须依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。
对于程序中可能存在哪类错误的推测，是挑选测试方案时的一个重要因素。
错误推测法的基本想法是：
列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
在很大程度上靠直觉和经验进行。
基本思想是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。
对于程序中容易出错的情况也有一些经验总结出来，例如，输入数据为零或输出数据为零往往容易发生错误；如果输入或输出的数目允许变化（例如，被检索的或生成的表的项数），则输入或输出的数目为0和1的情况（例如，表为空或只有一项）是容易出错的情况。
此外，经验表明，在一段程序中已经发现的错误数目往往和尚未发现的错误数成正比。
因此，在进一步测试时要着重测试那些已发现了较多错误的程序段。
等价划分法和边界值分析法都只孤立地考虑各个输入数据的测试功效，而没有考虑多个输入数据的组合效应，可能会遗漏了输入数据易于出错的组合情况。
选择输入组合的一个有效途径是利用判定表或判定树为工具，列出输入数据各种组合与程序应作的动作（及相应的输出结果）之间的对应关系，然后为判定表的每一列至少设计一个测试用例。
选择输入组合的另一个有效途径是把计算机测试和人工检查代码结合起来。
例如，通过代码检查发现程序中两个模块使用并修改某些共享的变量，如果一个模块对这些变量的修改不正确，则会引起另一个模块出错，因此这是程序发生错误的一个可能的原因。
应该设计测试方案，在程序的一次运行中同时检测这两个模块，特别要着重检测一个模块修改了共享变量后，另一个模块能否像预期的那样正常使用这些变量。
反之，如果两个模块相互独立，则没有必要测试它们的输入组合情况。
通过代码检查也能发现模块相互依赖的关系。
4因果图
•因果图的适用范围
如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是判定表。
它适合于检查程序输入条件的各种组合情况。
•用因果图生成测试用例的基本步骤
（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系?
根据这些关系，画出因果图。
（3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。
为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
（4）把因果图转换成判定表。
（5）把判定表的每一列拿出来作为依据，设计测试用例。
界面测试（UI）
一美观
风络统计（界面风格，文字信息风格和布局风格），包括中文系统尽量使用中文文字作为交互界面信息；
容易理解：
文字信息尽量不使用过份专业的术语，如网址不说明成URL；专业性过强的文字必须分析用户使用者对专业术语的了解程度而作出相应解释；
提示信息书面语化，不口语化；不带地方性方言文字信息。
同时要有唯一性语议性；
有关提示用户的信息应出现在用户能直观看到的地方；
二易用
支持焦点切换并使切换顺序合理，如有可能，尽量支持快捷键。
当系统判断某输入有误要用户重输入时，请将焦点切入输入框并将原文字反选，如遇多个需重输入框请将焦点切换至第一个。
能在客户端验证请在客户端验证，同时对这样的输入框，请尽量支持失焦事件（失去焦点即作验证）。
当验证有误时立刻切换到原输入框并反选择其原文字促使用户作修改。
在一组输入中出现部份输入错误后反回原输入框时，请保留其它未出错的输入框的原值。
避免用户大量重输。
用户登录框请支持回车键确认。
输入框验证基本原则：
1．字符串只限制长度（前提是需求有规定长度），非空项必须用“*”号标明。
2．货币值请遵守货币格式作验证（小数点后两位）。
3．数字验证包括：
正负、小数与整数的验证，同时数字为零时不应该以空的型式体现，而应该以“0”或‘0.00’等格式体现。
4．时间及日期格式验证：
按需求验证需要精确的具体项，时间日期输入应做成从系统选择时间及日期的形式，避免用户直接手工输入，当出现手工输入时，请在后面标明相应格式。
无需精确到毫秒级的无需把毫秒值显示出来，否则带来界面过长并数值过多的影响。
因为精确到秒已经很长了。
5．逻辑值验证：
用户无法通过界面验证，界面中必须用单选框作出可选项（逻辑值是唯一的，要么是要么否）。
6．注意事项验证：
因涉及程序流程特殊性功能时，尽量在显目的位置对此功能作出相应解释引导用户使用。
特别是针对用户量大且不可预计其知识面的情况下的系统。
1.3.2白盒测试
•测试人员根据已知的程序内部的流程、逻辑结构等信息设计或选择测试用例，对程序所有逻辑路径进行测试。
•通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
•因此又被称为结构测试或逻辑驱动测试。
•使用白盒测试方法，主要对程序模块进行如下的检查：
–对程序所有独立的执行路径至少测试一次；
–对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
–在循环的边界和运行界限内执行循环体；
–测试内部数据结构的有效性，等。
1逻辑覆盖
有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。
所谓逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。
测试数据执行（或叫覆盖）程序逻辑的程度可以划分成哪些不同的等级呢?
从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准。
覆盖标准
–语句覆盖
–判定覆盖
–条件覆盖
–判定－条件覆盖
–条件组合覆盖
–路径覆盖。
语句覆盖
•为了暴露程序中的错误，设计若干个测试用例，至少每个语句应该执行一次。
判定覆盖
•又称为分支覆盖
•含义是，不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。
•判定覆盖比语句覆盖强，但是对程序逻辑的覆盖程度仍然不高。
条件覆盖
含义是不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。
条件覆盖通常比判定覆盖强，因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。
判定/条件覆盖
既然判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，自然会提出一种能同时满足这两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。
含义是选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。
有时判定/条件覆盖也并不比条件覆盖更强。
条件组合覆盖
条件组合覆盖是更强的逻辑覆盖标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。
显然，满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。
因此，条件组合覆盖是前述几种覆盖标准中最强的。
但是，满足条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。
点覆盖
边覆盖
路径覆盖
路径覆盖的含义是，选取足够多测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。
2控制结构测试
基本路径测试
TomMcCabe提出的一种白盒测试技术。
使用这种技术设计测试用例时，首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合，从该基本集合导出的测试用例可以保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。
设计基本路径测试用例的步骤
第一步，根据过程设计结果画出相应的流图。
第二步，计算流图的环形复杂度。
第三步，确定线性独立路径的基本集合。
第四步，设计可强制执行基本集合中每条路径的测试用例。
条件测试
尽管基本路径测试技术简单而且高效，但是仅有这种技术还不够，还需要使用其他控制结构测试技术，才能进一步提高白盒测试的质量。
用条件测试技术设计出的测试用例，能够检查程序模块中包含的逻辑条件。
条件测试方法着重测试程序中的每个条件。
条件测试策略有两个优点
①容易度量条件的测试覆盖率；
②程序内条件的测试覆盖率可指导附加测试的设计。
条件测试的目的不仅是检测程序条件中的错误，而且是检测程序中的其他错误。
如果程序P的测试集能有效地检测P中条件的错误，则它很可能也可以有效地检测P中的其他错误。
此外，如果一个测试策略对检测条件错误是有效的，则很可能该策略对检测程序的其他错误也是有效的。
循环测试
循环是绝大多数软件算法的基础，但是，在测试软件时却往往未对循环结构进行足够的测试。
循环测试专注于测试循环结构的有效性。
在结构化的程序中通常只有3种循环，即简单循环、串接循环和嵌套循环。
3种循环
调试
也称为纠错，是在测试发现错误之后排除错误的过程。
与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。
•调试活动由两部分组成：
–确定程序中可疑错误的确切性质和位置。
–对程序（设计,编码）进行修改，排除这个错误。
•调试工作目前在很大程度上仍然是是一个具有很强技巧性的工作。
•软件运行失效或出现问题，往往只是潜在错误的外部表现，而外部症状与内在原因之间常常可能并没有明显的联系。
如果要找出真正的原因，排除潜在的错误，不是一件易事。
•因此，调试是通过症状找出原因的思维分析的智力过程。
调试的过程
调试过程从执行一个测试用例开始，评估测试结果，如果发现实际结果与预期结果不一致，则这种不一致就是一个症状，它表明在软件中存在着隐藏的问题。
调试过程试图找出产生症状的原因，以便改正错误。
（1）从错误的外部表现-症状入手，确定程序中出错位置；
（2）研究有关部分的程序，找出错误的内在原因；
（3）修改设计和代码，以排除这个错误；
（4）重复进行暴露了这个错误的原始测试或某些有关测试。
几种主要的调试方法
调试的目标都是寻找软件错误的原因并改正错误。
通常需要把系统地分析、直觉和运气组合起来，才能实现上述目标。
一般说来，有下列几种调试方法：
强行排错，
回溯法调试，
归纳法调试。
强行排错
目前使用较多，不需要过多的思考，效率较低。
具体做法有：
–通过打印内存的内容，
–在程序特定部位设置打印语句，把打印语句插在出错的源程序的各个关键变量改变部位、重要分支部位、子程序调用部位，跟踪程序的执行，监视重要变量的变化。
–自动调试工具。
利用某些程序语言的调试功能或专门的交互式调试工具，分析程序的动态过程，而不必修改程序。
回溯法调试
这是在小程序中常用的一种有效的调试方法。
一旦发现了错误，人们先分析错误征兆，确定最先发现“症状”的位置。
然后，人工沿程序的控制流程，向回追踪源程序代码，直到找到错误根源或确定错误产生的范围。
•例如，程序中发现错误处是某个打印语句。
通过输出值可推断程序在这一点上变量的值。
再从这一点出发，回溯程序的执行过程，反复考虑：
“如果程序在这一点上的状态（变量的值）是这样，那么程序在上一点的状态一定是这样...”，直到找到错误的位置。
归纳法调试
•归纳法是一种从特殊推断一般的系统化思考方法。
归纳法调试的基本思想是：
从一些线索（错误征兆）着手，通过分析它们之间的关系来找出错误。
–收集有关的数据列出所有已知的测试用例和程序执行结果。
看哪些输入数据的运行结果是正确的，哪些输入数据的运行结果有错误。
–组织数据
由于归纳法是从特殊到一般的推断过程，所以需要组织整理数据，以发现规律。
常以3W1H形式组织可用的数据：
“What”、“Where”、“When”、“How”
–提出假设
分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个关于出错原因的假设。
如果一个假设也提不出来，归纳过程就需要收集更多的数据。
此时，应当再设计与执行一些测试用例，以获得更多的数据。
–证明假设
把假设与原始线索或数据进行比较，若它能完全解释一切现象，则假设得到证明；否则，就认为假设不合理，或不完全，或是存在多个错误，以致只能消除部分错误。
•演绎法调试
演绎法是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。
–列举所有可能出错原因的假设
把所有可能的错误原因列成表。
通过它们，可以组织、分析现有数据。
–利用已有的测试数据，排除不正确的假设
仔细分析已有的数据，寻找矛盾，力求排除前一步列出所有原因。
–改进余下的假设
升级会员 