软件测试相关.docx
《软件测试相关.docx》由会员分享，可在线阅读，更多相关《软件测试相关.docx（35页珍藏版）》请在冰豆网上搜索。
软件测试相关
软件测试相关
软件测试的基本概念
测试的含义为“以检验产品是否满足需求为目标”是生产中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。
软件测试的经典定义是在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
测试用例：
把软件测试的行为活动做一个科学化的组织归纳。
软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式，测试用例就是将测试行为具体量化的方法之一。
使用测试用例的好处主要体现在以下方面：
1.在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
2.测试用例的使用另软件测试的实施重点突出、目的明确。
3.在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。
4.功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
ANSI/IEEE829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，同时还明确指出，使用具体测试用例产生的测试程序的限制。
早期的软件定义指出软件测试的目的是寻找错误，并且尽最大的可能找出最多的错误
·测试是程序的执行过程，目的在于发现错误；
·一个好的测试用例在于能发现至今未发现的错误；
·一个成功的测试是发现了至今未发现的错误的测试。
测试的目的，是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。
基于测试是为了寻找软件的错误与缺陷，评估与提高软件质量，提出如下原则：
·所有的软件测试都应追溯到用户需求。
·尽早地和不断地进行软件测试。
·完全测试是不可能的，测试需要终止。
·测试无法显示软件潜在的缺陷。
·充分注意测试中的群集现象。
·程序员应避免检查自己的程序。
·尽量避免测试的随意性。
测试的分类
从测试方法的角度可以分为手工测试和自动化测试。
手工测试：
不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。
自动化测试：
就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动地测试，它是软件测试的一个重要的组成部分，它能够完成许多手工无法完成或者难以实现的一些测试工作。
自动化测试的优点：
·提高测试质量：
软件开发的过程就是一个持续集成和改进的过程，而每一次修改都有可能产生错误。
·提高测试效率，缩短测试工作时间
·提高测试覆盖率
·执行手工测试不能完成的测试任务
·更好地重现软件缺陷的能力
·更好地利用资源
·增进测试人员与开发人员之间的合作伙伴关系。
按照开发阶段划分软件测试可以分为单元测试、集成测试、确认测试、系统测试和验收测试。
·单元测试（模块测试）：
是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。
一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。
单元测试的依据是系统的详细设计；一般由项目组开发人员自己完成。
驱动模块：
接收测试数据，把这些数据传送给所测模块，最后再输出测试结果。
桩模块：
用来代替所测模块调用的子模块。
·集成测试（组装测试）：
在单元测试的基础上，将所有模块按照设计要求组装进行测试。
一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。
·确认测试：
通过检验和提供客观证据，正是软件是否满足特定预期用途的需求。
确认测试是检测与正是软件是否满足软件需求说明书中规定的要求。
模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。
·系统测试：
为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。
系统测试是在真是或墨迹的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。
·验收测试：
按照项目任务或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
按照测试实施组织划分，软件测试可分为开发方测试（验证测试，α测试）、用户测试（β测试）。
第三方测试。
·开发方测试（验证测试，α测试）
主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
·用户测试（β测试）
在用户的应用环境下，用户通过运行和使用软件，检测与合适软件实现是否符合自己预期的要求。
通常情况用户测试不是指用户的“验收测试”，而是指用户的实用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对是用质量进行评价。
·第三方测试
介于软件开发方和用户方之间的测试组织的测试。
第三方测试也称为独立测试。
按照测试技术划分为：
白盒测试、黑盒测试和灰盒测试。
白盒测试：
通过对程序内部结构的分析、检测来寻找问题。
白盒测试可以把程序看成装在一个透明的白盒子里，通过程序的源代码进行测试而不使用用户界面，也就是清楚了解程序结构和处理戳成，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。
白盒测试又称结构测试。
黑盒测试：
是通过使用整个软件或某种软件功能来严格地测试,而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。
测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。
在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收和正确的输出。
灰盒测试：
介于白盒测试与黑盒测试之间的测试。
灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、时间、标志来判断内部的运行状态。
灰盒测试：
灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。
甚至于还读过部分源代码。
因此测试人员可以有真对性地进行某种确定的条件/功能的测试。
软件测试方法和技术的分类与软件开发过程相关联，它贯穿了整个软件生命周期。
走查、单元测试、集成测试、系统测试用于整个开发过程中的不同阶段。
开发文档和源程序可以应用单元测试应用走查的方法；单元测试可应用白盒测试方法；集成测试应用近似灰盒测试方法；而系统测试和确认测试应用黑盒测试方法。
黑盒测试
黑盒测试方法主要有等价类划分法、边界值分析法、因果图法、错误推测法、判定表驱动法、正交试验法、功能图法和场景法。
等价类划分法
等价类划分：
是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，及需求规格说明书。
我们必须仔细分析和推敲说明书的各项需求，特别是功能需求。
把说明中对输入的要求和输出的要求区别开来并加以分解。
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:
测试某等价类的代表值就等于对这一类其它值的测试.
因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:
有效等价类和无效等价类.
有效等价类:
是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:
与有效等价类的定义恰巧相反.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
确定等价类的原则；
1.在输入条件规定了取值范围或值的个数的情况下，可以确定一个有效等价类和两个无效等价类。
2.在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确定一个有效等价类和一个无效等价类。
3.在输入条件是一个布尔量的情况下，已确定一个有效等价类和一个无效等价类。
4.在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5.在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6.在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
确定测试用例
1.为每个等价类规定一个唯一的编号。
2.设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。
重复这一步，最后使得所有有效等价类均被测试用例所覆盖。
3.设计一个新的测试用例，使其只覆盖一个无效等价类。
重复着一步使所有无效等价类均被覆盖。
边界值分析：
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。
边界值设计测试用例，应遵循以下几条原则：
1.如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2.如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据。
3.根据规格说明的每个输出条件，使用前面的原则1.
4.根据规格说明的每个输出条件，使用前面的原则2.
5.如果程序的规格说明给出的输入域或输出域的有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
7.分析规格说明，找出其他可能的边界条件。
错误推测法：
基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法.错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例.例如,在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等,这些就是经验的总结.还有,输入数据和输出数据为0的情况.输入表格为空格或输入表格只有一行.这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例。
因果图法：
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
利用因果图导出测试用例需要经过以下几个步骤：
1.分析程序规格说明的描述中，那些是原因，哪些是结果。
原因常常是输入条件或者输出条件的等价类，而结果是输出条件。
2.分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
3.标明约束条件。
由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。
为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
4.把因果图转换成判定表。
5.为判定表中每一列表示的情况设计测试用例。
判定表驱动法：
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
判定表有4部分组成：
条件桩，动作桩，条件项，动作项。
规则：
任何一个条件组合的特定取值及其相应要执行的操作。
在判定表中贯穿条件项和动作项的一列就是一条规则。
显然，判定表中列出多少组条件取值，也就有多少条规则，条件项和动作项就有多少列。
判定表的建立：
1.确定规则的个数。
假如有n个条件，每个条件有两个取值（0，1），固有2n中规则。
2.列出所有的条件桩和动作桩。
3.填入条件项
4.填入动作项。
制定出事判定表。
5.简化。
合并相似规则或者相同动作。
正交实验法：
正交试验设计方法是从大量的实验数据中挑选适量的、有代表性的的点，从而合理地安排测试的一种科学的试验设计方案。
正交表具有两条性质：
每一列中各数字出现的次数都一样多；任何两列所构成的各有序数对出现的次数都一样多。
所以称之为正交表。
正交实验设计测试用例的步骤：
1.提取功能说明，构造因子“——”状态表。
把影响实验指标的条件成为因子，而影响实验因子的条件叫做因子的状态。
利用正交试验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，吧他们当做因子，而把各个因子的取值当做状态。
对软件需求规格说明中的功能要求进行划分，把整体的、概要性的功能要求进行层层分解与展开，分解成具体的、有相对独立性的基本的功能要求。
这样就可以把被测试软件中所有的因子都确定下来，并未确定因子的权值提供参考的依据。
确定因子与状态是设计测试用例的关键。
因此，要求尽可能全面地、正确地确定取值，以确保测试用例的设计做到完整与有效。
2.加权筛选，生成因素分析表。
对因子与状态的选择可按其重要程度分别加权。
可根据各个因子及状态作用的大小、出现频率的大小以及测试的需要，确定权值的大小。
3.利用正交表构造测试数据集，正交表的推到依据Galois理论
功能图法
功能图法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。
功能图模型由状态前意图和逻辑功能模型构成。
状态迁移图用于表示输入数据序列以及相应的输出数据。
在状态迁移途中，由输入数据和当前状态决定输出数据和后续状态。
逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。
逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。
测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。
从功能图生成测试用例的过程如下。
1.生成局部测试用例：
在每个状态中，从因果图生成局部测试用例。
局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。
2.测试路径生成：
利用上面的规则生成从出事状态到最后状态的测试路径。
3.测试用例合成：
合成测试路径与功能图中每个状态的局部测试用例。
结果是视状态到最后状态的一个状态序列，一斤每个状态中输入数据与对应输出数据组合。
4.测试用例的合成算法：
采用条件构造树。
场景法
用例场景用来描述流经用例的路径，从用例开始到结束便利这条路径上所有基本流和备选流。
一条备选流可能从基本流开始，再某个特定条件下执行，然后重新加入基本流中；也可能起源于另一个备选流，或者终止用例而不再重新加入到某个流。
从软件特性上分为功能测试和性能测试。
功能测试：
是指为了确保软件系统功能实现的正确性，完整性和其他特性而进行的测试。
性能测试：
是指为了评估软件系统的性能状况，和预测软件系统性能趋势而进行的测试和分析。
白盒测试
词法分析与语法分析
通过词法分析与语法分析可以获取软件组成的重要基本因数，例如：
变量标识符、过程标识符、常量等，组合这些基本因数可以得到软件的基本信息。
如：
·标号交叉引用表。
列出在各模块中出现的全部标号，在表中标出标号的属性，包括已说明、未说明、已使用、未使用。
表中还包括在模块以外的全局标号、计算符号等。
·变量交叉引用表，即变量定义与引用表。
在表中应标明各变量的属性，包括已说明，未说明、隐式说明以及类型及使用情况，进一步还可以区分是否出现在赋值语句的右边，是否属于COMMON变量。
全局变量或特权变量等。
·子程序、宏和函数表。
在表中列出各个子程序、宏和函数的属性，包括已定义、未定义、定义类型；以及参数表、输入参数的个数、顺序、类型，输出参数的个数、顺序、类型；已引用、未引用、引用次数等。
·等价表。
表中列出在等价语句或等值依据中出现的全部变量和标号。
·常数表。
表中列出全部数字常数和字符常数，并指出它们在哪些语句中首先被定义。
按功能分类，引用表的作用有以下三种。
·直接从表中查出说明/使用错误。
如循环层次表、变量交叉引用表、标号交叉引用表。
·为用户提供辅助信息。
如子程序（宏、函数）引用表、等价表、常数表。
·用来做错误预测和程序复杂度计算。
如操作符和操作数的统计表等。
静态错误分析
1.类型和单位分析
为了强化对源程序中数据类型的检查，在程序设计语言中扩充一些新的数据类型，例如，仅能在数组中使用的“下标”类型及在循环语句中当作控制变量使用“计数器”类型。
这样就可以静态预处理程序，分析程序中的类型错误。
2.引用分析
在静态错误分析中，最广泛使用的技术就是发现引用异常。
如果沿着程序的控制路径，变量在赋值以前被引用，或变量在赋值以后未被引用，这是发生了引用异常。
通常采用类似深度有限的方法便利程序流图的每一条路径，也可以建立引用一场的探测工具，这种工具包括两个表：
定义表和未引用表。
每张表中都包含一组变量表。
为引用表中包括已被赋值但还未被引用的一些变量。
3.表达式分析
·在表达式中不正确地使用了括号造成错误；
·数组下标越界造成错误；
·除数为零造成错误；
·对负数开平方，或对π求正切造成错误；
4.接口分析
接口一致性是程序的静态错误分析和设计分析共同研究的题目。
接口一致性的设计可以分析检查模块之间接口的一致性和模块与外部数据库之间接口的一致性。
程序关于接口的静态错误分析检查过程与实参在类型、函数过程之间接口的一致性，因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性；检查全局变量和公共数据区在使用上的一致性。
程序插桩技术
设计插桩程序时需要考虑的问题包括：
·探测哪些信息；
·在程序的什么部位设置探测点；
·需要设置多少个探测点。
以Fortran程序为例，列举至少应在哪些部位设置计数语句：
·程序块的第一个可执行语句之前；
·Entry语句的前后
·有标号的可执行语句处
·do、dowhile、dountil及do终端语句之后；
·block-if、elseif、else及endif语句之后；
·logicalif语句处；
·输入/输出语句之后；
·Call语句之后
·计算goto语句之后。
白盒测试方法
1.代码检查法：
桌面检查，代码审查，走查。
2.代码检查项目
·检查变量的交叉引用表：
重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列、临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用。
·检查标号的交叉引用表：
验证所有标号的正确性，检查所有标号的命名是否正确，转向制定位置的标号是否正确。
·检查子程序、宏、函数：
验证每次调用与所调用位置是否正确，确认每次所调用的子程序、宏、函数是否存在，检验调用序列中调用方法与参数顺序、个数、类型上的一致性。
·等价性检查：
检查全部等价变量的类型的一致性，解释所包含的类型差异。
·常量检查：
确认敞亮的取值和数制、数据类型，检查常量每次引用同它的取值、数制和类型的一致性。
·标准检查：
用标准检查工具软件或手工检查程序中违反标准的问题。
·风格检查：
检查发现程序在设计风格方面的问题。
·比较控制流；比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并修正错误。
·选择、激活路径：
在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。
如果选择的路径在实际控制流图尚不能被激活，则源程序可能有错。
·对照程序的规格说明，详细阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从他们的差异中发现程序的问题和错误。
·补充文档：
桌面减产的文档是一种过渡性的文档，不是公开的正式文档。
通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。
管理部门也可以通过审查桌面检查文档，了解模块的质量、完全性、测试方法和程序员的能力。
根据检查项目可以编制代码规则、规范和检查表等作为测试用例。
3.编码规范
编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等。
4.代码检查规则
在代码检查中，需要依据被测软件的特点，选用适当的标准与规则规范。
在使用测试软件进行自动化代码检查时，测试工具一般会内置许多的编码规则，我们需要根据编程语言以及被侧程序的特点挑选适当的规则进行检查。
5.缺陷检查表
进行人工代码检查时，代码缺陷检查表是我们用到的测试用例。
静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图。
内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图标，检查软件有没有存在缺陷或错误。
其中函数调用关系图通过应用程序中各函数之间的调用关系展示了系统的结构。
通过查看函数调用关系图，可以检查函数之间的调用关系是否符合要求，是否存在递归调用，函数的调用层次是否过深，有没有存在孤立的没有被调用的函数。
从而可以发现系统是否存在结构缺陷，发现哪些函数是重要的，哪些是次要的，需要使用什么级别的覆盖要求。
模块控制流图是与程序流程图相类似的由许多节点和连接节点的边组成的一种图形，其中一个节点代表一条语句或数条语句，边表示节点间的控制流向，它显示了一个函数的内部结构。
模块控制流图可以直接地反映出一个函数的内部逻辑结构，通过检查这些模块控制流图，能够很快发现软件的错误与缺陷。
静态质量度量法
以ISO9126质量模型作为基础，我们可以构造质量度量模型，用于评估软件的每个方面。
逻辑覆盖法
白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
·保证一个模块中的所有独立路径至少被使用一次；
·对所有逻辑值均需测试true和false；
·在上下边界及可操作范围内运行所有循环；
·检查内部数据结构以确保其有效性。
从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：
语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
1.语句覆盖：
选择足够多的测试数据，使被测程序中每条语句至少执行一次。
2.判定覆盖：
设计足够偶的测试用例，使得策划你工序中的每个人判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
3.条件覆盖：
构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
4.条件判定组合覆盖：
设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
5.多条件覆盖：
设计足够的测试用例。
使得每个判定中条件的各种可能组合都至少出现一次。
显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
6.修正条件判定覆盖：
这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。
它要求满足两个条件：
首先，每个程序模块的入口和出口都要考虑至
升级会员 