软件测试.docx
《软件测试.docx》由会员分享，可在线阅读，更多相关《软件测试.docx（29页珍藏版）》请在冰豆网上搜索。
软件测试
测试简介
软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度（correctness）、完全度（completeness）和质量（quality）的软件过程；是SQA（softwarequalityassurance）的重要子域。
GlenfordJ.Myers曾对软件测试的目的提出过以下观点：
软件测试
（1）测试是为了发现程序中的错误而执行程序的过程。
（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
（3）成功的测试是发现了至今为止尚未发现的错误的测试。
（4）测试并不仅仅是为了找出错误。
通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。
（5）这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性。
（6）没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
（7）另外，根据测试目的的不同，还有回归测试、压力测试、性能测试等，分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
测试原则
一，测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。
二，程序员应该避免检查自己的程序，软件测试应该由第三方来负责。
三，设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，如网络异常中断、电源断电等。
四，应该充分注意测试中的群集现象。
五，对错误结果要进行一个确认过程。
一般由A测试出来的错误，一定要由B来确认。
严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格地确认，是否真的存在这个问题以及严重程度等。
六，制定严格的测试计划。
一定要制定测试计划，并且要有指导性。
测试时间安排尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
七，妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
测试目标
1．发现一些可以通过测试避免的开发风险。
2．实施测试来降低所发现的风险。
3．确定测试何时可以结束。
4．在开发项目的过程中将测试看作是一个标准项目。
测试过程
第一步：
对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。
该计划被审核批准后转向第二步。
测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。
只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。
第二步：
设计测试用例。
设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。
该用例被批准后转向第三步。
第三步：
如果满足“启动准则”（EntryCriteria），那么执行测试。
执行测试主要是搭建测试环境，执行测试用例。
执行测试时要进行进度控制、项目协调等工作。
第四步：
提交缺陷。
这里要进行缺陷审核和验证等工作。
第五步：
消除软件缺陷。
通常情况下，开发经理需要审核缺陷，并进行缺陷分配。
程序员修改自己负责的缺陷。
在程序员修改完成后，进入到回归测试阶段。
如果满足“完成准则”（ExitCriteria），那么正常结束测试。
第六步：
撰写测试报告。
对测试进行分析，总结本次的经验教训，在下一次的工作中改。
软件测试过程管理，主要包括软件测试是什么样的过程，如何评价一个软件测试过程，如何进行配置管理和测试风险分析以及测试成本的管理。
心理依据
软件测试工程师职业发展前景
人类行为具有高度目标性，确立一个正确的目标有着重要的心理学影响。
软件测试的心理学问题就是如何摆正测试的两个目标的关系，使得测试活动更加富有成效。
1.程序测试的过程具有破坏性
每当测试一个程序时，人们总希望为程序增加一些价值。
利用测试来增加程序的价值，是指通过测试，找出并修改尽可能多的程序缺陷，从而提高程序的可靠性或质量。
因此，不要只是为了证明程序能够正确运行而去测试程序。
相反，应该一开始就假设程序中隐藏着错误（这种假设几乎对所有的程序都成立），然后测试程序，发现尽可能多的错误。
事实上，如果把测试目标定位于要证明程序中没有缺陷，那么就会在潜意识中倾向于实现这个目标。
也就是说，测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。
另一方面，如果把测试目标定位于要证明程序中存在缺陷，那么就会选择一些容易发现程序缺陷的测试数据。
而后一种态度会比前者给程序增加更多的价值。
软件测试技术
事实上，如果在测试某个程序段时发现了可以纠正的缺陷，或者测试最终确定再没有其他缺陷，则应将这次合理设计并得到有效执行的测试称作是“成功的”。
而所谓“不成功的”测试，仅指未能适当地对程序进行检查，未能找出程序中潜藏缺陷的测试。
“软件测试就是证明软件不存在错误的过程”。
对几乎所有的程序而言，甚至是非常小的程序，这个目标实际上是无法达到的。
因为即使程序完全实现预期要求，仍可能包含有缺陷。
也就是说，如果程序不按要求工作，它显然有缺陷，但如果程序做了不要它做的事，它也有缺陷。
心理学研究告诉我们，当人们在干一件已经知道是不合适的或不可能做到的事时，往往他们的表现就相当糟糕。
把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。
虽然这看起来像是个微妙的文字游戏，但对成功地进行软件测试有很大的影响。
总之，软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。
一个成功的测试，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。
当然最终人们还是要通过软件测试来建立某种程度的信心：
软件做了其应该做的，而没有做其不应该做的。
2.程序员应避免测试自己的程序
软件测试书籍
由开发人员来测试自己的代码是一件很不妥当的事情。
开发和测试生来就是不同的活动。
开发是创造或者建立某种事物的行为，如一个功能模块或整个系统。
而测试的重要目的是证实一个模块或者一个系统工作不正常。
这两个活动之间有着本质的矛盾。
一个人不太可能把两个截然对立的角色都扮演地很好，因此应当限制开发人员在测试中的参与，给他们比较合适的任务是进行最底层的测试——单元测试。
当一个程序员完成了设计与编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。
所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），就不能有效的测试自己的程序。
除了这个心理学问题之外，还有一个重要的问题：
程序中可能包含由于程序员对问题的叙述或说明的误解而产生了错误。
如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。
3.程序设计组织不应测试自己的程序
在宏观意义上，一个程序设计组织或一个工程项目是个有生命的有机体，它同样有心理学问题。
在大多数情况下，人们都以“在给定日期内，以一定代价完成程序编制任务的能力”来衡量程序设计组织和项目管理人员的。
这样做的理由是时间和成本指标便于衡量，而程序的质量很难度量。
要程序设计组织在测试自己的程序时持客观态度是很困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试，也不大可能把耗费的代价限制在要求的范围以内。
软件生产的三个最重要的因素是：
质量、进度和费用。
由于费用和进度的限制，要开发一种高质量、快速交付和低成本的软件产品并不容易。
也就是说要同时达到三个目标是困难的。
因此在软件产品的开发中要权衡它们之间的关系，使软件的特性能满足用户的要求，这意味着软件产品的特性的度量和预计是必要的。
软件测试由独立测试机构承担有很多好处。
独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。
独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效的测试自己的软件，要找出那些因为对问题的误解而产生的错误就更加困难。
独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，在软件开发的过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自于开发组织同一来源的管理方面的压力，使测试过程受到干扰。
客观性——对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能以揭露软件中错误的态度工作，也能不受发现的错误的影响。
经济上的独立性使测试有更充分的条件按测试要求去完成。
专业性——独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业知识。
同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。
专业化分工是提高测试水平、保证测试质量、充分发挥测试效应的必然途径。
权威性——由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，专业化的独立测试机构的评价，更客观、公正和具有权威性。
资源有保证——独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性可以避免开发单位侧重软件开发而对测试工作产生不利的影响。
测试内容
软件测试主要工作内容是验证（verification）和确认（validation），下面分别给出其概念：
验证（verification）是保证软件正确地实现了一些特定功能的一系列活动，即保证软件以正确的方式来做了这个事件（Doitright）
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。
2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程。
3.评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认（validation）是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。
即保证软件做了你所期望的事情。
（Dotherightthing）
1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性。
2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
测试方法
一、等价类
1.定义
是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
该方法是一种重要的，常用的黑盒测试用例设计方法。
2.划分等价类
等价类是指某个输入域的子集合。
在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：
测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。
等价类划分可有两种不同的情况：
有效等价类和无效等价类。
1）有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。
利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
2）无效等价类
与有效等价类的定义恰巧相反。
无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。
对于具体的问题，无效等价类至少应有一个，也可能有多个。
设计测试用例时，要同时考虑这两种等价类。
因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。
3.划分等价类的标准
1）完备测试、避免冗余；
2）划分等价类重要的是：
集合的划分，划分为互不相交的一组子集，而子集的并是整个集合；
3）并是整个集合：
完备性；
4）子集互不相交：
保证一种形式的无冗余性；
5）同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。
4.划分等价类的方法
1）在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
如：
输入值是学生成绩，范围是0～100。
2）在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。
二、边界值
1.定义：
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
2.与等价划分的区别
1）边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2）边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
3.边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。
因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。
通常输入和输出等价类的边界，就是应着重测试的边界情况。
应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
4.常见的边界值
1）对16-bit的整数而言32767和-32768是边界
2）屏幕上光标在最左上、最右下位置
3）报表的第一行和最后一行
4）数组元素的第一个和最后一个
5）循环的第0次、第1次和倒数第2次、最后一次
5.边界值分析
1）边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。
例：
测试计算平方根的函数
--输入：
实数
--输出：
实数
--规格说明：
当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。
[3]
详细分类
角度细分
从是否关心软件内部结构和具体实现的角度划分（按测试分类）
A.白盒测试
B.黑盒测试
C.灰盒测试
从是否执行程序的角度
A.静态测试
B.动态测试。
阶段细分
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.系统测试
E.验收测试
F.回归测试
G.Alpha测试
H.Beta测试
*测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发布测试。
*开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
*集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
*确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
*系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试（UnitTesting）
*单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。
其目的在于发现各模块内部可能存在的各种差错。
*单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
1.单元测试的内容
*在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
（1）模块接口测试
*在单元测试的开始，应对通过被测模块的数据流进行测试。
测试项目包括：
–调用本模块的输入参数是否正确；
–本模块调用子模块时输入给子模块的参数是否正确；
–全局量的定义在各模块中是否一致
*在做内外存交换时要考虑：
–文件属性是否正确；
–OPEN与CLOSE语句是否正确；
–缓冲区容量与记录长度是否匹配；
–在进行读写操作之前是否打开了文件；
–在结束文件处理时是否关闭了文件；
–正文书写/输入错误，
–I/O错误是否检查并做了处理。
（2）局部数据结构测试
*不正确或不一致的数据类型说明
*使用尚未赋值或尚未初始化的变量
*错误的初始值或错误的缺省值
*变量名拼写错或书写错
*不一致的数据类型
*全局数据对模块的影响
（3）路径测试
*选择适当的测试用例，对模块中重要的执行路径进行测试。
*应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
*对基本执行路径和循环进行测试可以发现大量的路径错误。
（4）错误处理测试
*出错的描述是否难以理解
*出错的描述是否能够对错误定位
*显示的错误与实际的错误是否相符
*对错误条件的处理正确与否
*在对错误进行处理之前，错误条件是否已经引起系统的干预等
（5）边界测试
*注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。
对这些地方要仔细地选择测试用例，认真加以测试。
*如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
2.单元测试的步骤
*模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
–驱动模块（driver）
–桩模块（stub）──存根模块
*如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。
必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
*对支持某些标准规程的程序，更要着手进行互联测试。
有人把这种情况特别称为模块测试，以区别单元测试。
三、集成测试（IntegratedTesting）
*集成测试（组装测试、联合测试）
*通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。
这时需要考虑的问题是：
–在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
–一个模块的功能是否会对另一个模块的功能产生不利的影响
–各个子功能组合起来，能否达到预期要求的父功能；
–全局数据结构是否有问题；
–单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，
发现并排除在模块连接中可能出现
的问题，最终构成要求的软件系统。
*子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
*通常，把模块集成成为系统的方式有两种
–一次性集成方式
–增殖式集成方式
1.一次性集成方式（bigbang）
*它是一种非增殖式组装方式。
也叫做整体拼装。
*使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2.增殖式集成方式
*这种集成方式又称渐增式集成
*首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
*在集成的过程中边连接边测试，以发现连接过程中产生的问题
*通过增殖逐步组装成为要求的软件系统。
（1）自顶向下的增殖方式
*这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
*自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
*选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
（2）自底向上的增殖方式
*这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
*因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。
在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
*自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
*一般来讲，一种方式的优点是另一种方式的缺点。
（3）混合增殖式测试
*衍变的自顶向下的增殖测试
–首先对输入/输出模块和引入新算法模块进行测试；
–再自底向上组装成为功能相当完整且相对独立的子系统；
–然后由主模块开始自顶向下进行增殖测试。
*自底向上-自顶向下的增殖测试
–首先对含读操作的子系统自底向上直至根结点模块进行组装和测试；
–然后对含写操作的子系统做自顶向下的组装与测试。
*回归测试
–这种方式采取自顶向下的方式测试被修改的模块及其子模块；
–然后将这一部分视为子系统，再自底向上测试。
关键模块问题
*在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
*关键模块的特征：
①满足某些软件需求
②在程序的模块结构中位于较高的层次（高层控制模块）
③较复杂、较易发生错误
④有明确定义的性能要求。
四、确认测试（ValidationTesting）
*确认测试又称有效性测试。
任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
*对软件的功能和性能要求在软件需求规格说明书中已经明确规定。
它包含的信息就是软件确认测试的基础。
1.进行有效性测试（黑盒测试）
*有效性测试是在模拟的环境（可能就是开发的环境）下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
*首先制定测试计划，规定要做测试的种类。
还需要制定一组测试步骤，描述具体的测试用例。
*通过实施预定的测试计划和测试步骤，确定
–软件的特性是否与需求相符；
–所有的文档都是正确且便于使用；
–同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试
*在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
–测试结果与预期的结果相符。
这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
–测试结果与预期的结果不符。
这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
2.软件配置复查
n软件配置复查的目的是保证
u软件配置的所有成分都齐全；
u各方面的质量都符合要求；
u具有维护阶段所必需的细节；
u而且已经编排好分类的目录。
n应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
五、系统测试（SystemTesting）
*系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
*系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
六、验收测试（AcceptanceTesting）
*在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
*验收测试是以用户为主的测试。
软件开发人员和QA（质量保证）人员也应参加。
*由用户参加设计测试用例，使用生产中的实际数据进行测试。
*在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可
升级会员 