软件测试理论
软件测试[1] 是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。
Glenford J.Myers曾对软件测试的目的提出过以下观点:
软件测试
软件测试
(1)测试是为了发现程序中的错误而执行程序的过程。
(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。
(3)成功的测试是发现了至今为止尚未发现的错误的测试。
(4)测试并不仅仅是为了找出错误。通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进。
(5)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性。
(6)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。
(7)另外,根据测试目的的不同,还有回归测试、压力测试、性能测试等,分别为了检验修改或优化过程是否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等。
测试原则
一,测试应该尽早进行,最好在需求阶段就开始介入,因为最严重的错误不外乎是系统不能满足用户的需求。
二,程序员应该避免检查自己的程序,软件测试应该由第三方来负责。
三,设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况下还要制造极端状态和意外状态,如网络异常中断、电源断电等。
四,应该充分注意测试中的群集现象。
五,对错误结果要进行一个确认过程。一般由A测试出来的错误,一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析,对测试结果要进行严格地确认,是否真的存在这个问题以及严重程度等。
六,制定严格的测试计划。一定要制定测试计划,并且要有指导性。测试时间安排尽量宽松,不要希望在极短的时间内完成一个高水平的测试。
七,妥善保存测试计划、测试用例、出错统计和最终分析报告,为维护提供方便。
测试目标
1.发现一些可以通过测试避免的开发风险。
2.实施测试来降低所发现的风险。
3.确定测试何时可以结束。
4.在开发项目的过程中将测试看作是一个标准项目。
测试的对象
程序。
数据。
文档。
测试过程:
第一步:对要执行测试的产品/项目进行分析,确定测试策略,制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针,这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚,才能决定测试资源的投入。第二步:设计测试用例。设计测试用例要根据测试需求和测试策略来进行,进度压力不大时,应该设计的详细,如果进度、成本压力较大,则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。
第三步:如果满足“启动准则”(EntryCriteria),那么执行测试。执行测试主要是搭建测试环境,执行测试用例。执行测试时要进行进度控制、项目协调等工作。
第四步:提交缺陷。这里要进行缺陷审核和验证等工作。
第五步:消除软件缺陷。通常情况下,开发经理需要审核缺陷,并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后,进入到回归测试阶段。如果满足“完成准则”(ExitCriteria),那么正常结束测试。
第六步:撰写测试报告。对测试进行分析,总结本次的经验教训,在下一次的工作中改。
软件测试过程管理,主要包括软件测试是什么样的过程,如何评价一个软件测试过程,如何进行配置管理和测试风险分析以及测试成本的管理。
心理依据
人类行为具有高度目标性,确立一个正确的目标有着重要的心理学影响。软件测试的心理学问题就是如何摆正测试的两个目标的关系,使得测试活动更加富有成效。
1.程序测试的过程具有破坏性
每当测试一个程序时,人们总希望为程序增加一些价值。利用测试来增加程序的价值,是指通过测试,找出并修改尽可能多的程序缺陷,从而提高程序的可靠性或质量。
因此,不要只是为了证明程序能够正确运行而去测试程序。相反,应该一开始就假设程序中隐藏着错误(这种假设几乎对所有的程序都成立),然后测试程序,发现尽可能多的错误。
事实上,如果把测试目标定位于要证明程序中没有缺陷,那么就会在潜意识中倾向于实现这个目标。也就是说,测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。另一方面,如果把测试目标定位于要证明程序中存在缺陷,那么就会选择一些容易发现程序缺陷的测试数据。而后一种态度会比前者给程序增加更多的价值。
软件测试技术
软件测试技术
事实上,如果在测试某个程序段时发现了可以纠正的缺陷,或者测试最终确定再没有其他缺陷,则应将这次合理设计并得到有效执行的测试称作是“成功的”。而所谓“不成功的”测试,仅指未能适当地对程序进行检查,未能找出程序中潜藏缺陷的测试。
“软件测试就是证明软件不存在错误的过程”。对几乎所有的程序而言,甚至是非常小的程序,这个目标实际上是无法达到的。因为即使程序完全实现预期要求,仍可能包含有缺陷。也就是说,如果程序不按要求工作,它显然有缺陷,但如果程序做了不要它做的事,它也有缺陷。
心理学研究告诉我们,当人们在干一件已经知道是不合适的或不可能做到的事时,往往他们的表现就相当糟糕。把程序测试定义为在程序中找出错误的过程,就使测试成了可以做到的任务,从而克服了心理上存在的问题。虽然这看起来像是个微妙的文字游戏,但对成功地进行软件测试有很大的影响。
总之,软件测试更适宜被视为试图发现程序中错误(假设其存在)的破坏性的过程。一个成功的测试,通过诱发程序发生错误,可以在这个方向上促进软件质量的改进。当然最终人们还是要通过软件测试来建立某种程度的信心:软件做了其应该做的,而没有做其不应该做的。
2.程序员应避免测试自己的程序
由开发人员来测试自己的代码是一件很不妥当的事情。开发和测试生来就是不同的活动。开发是创造或者建立某种事物的行为,如一个功能模块或整个系统。而测试的重要目的是证实一个模块或者一个系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演地很好,因此应当限制开发人员在测试中的参与,给他们比较合适的任务是进行最底层的测试——单元测试。
当一个程序员完成了设计与编写程序的建设性工作后,要一夜之间突然改变他的观点,设法对程序形成一个完全否定的态度,那是非常困难的。所以,大部分程序员都由于不能使自己进入必要的精神状态(不是抱着要揭露出自己程序中错误的态度),就不能有效的测试自己的程序。除了这个心理学问题之外,还有一个重要的问题:程序中可能包含由于程序员对问题的叙述或说明的误解而产生了错误。如果是这种情况,当程序员测试自己的程序时,往往还会带着同样的误解致使问题难以发现。
3.程序设计组织不应测试自己的程序
在宏观意义上,一个程序设计组织或一个工程项目是个有生命的有机体,它同样有心理学问题。在大多数情况下,人们都以“在给定日期内,以一定代价完成程序编制任务的能力”来衡量程序设计组织和项目管理人员的。这样做的理由是时间和成本指标便于衡量,而程序的质量很难度量。要程序设计组织在测试自己的程序时持客观态度是很困难的,因为如果用正确的定义看待测试,就不大可能按预定计划完成测试,也不大可能把耗费的代价限制在要求的范围以内。
测试内容
软件测试主要工作内容是验证(verification)和确认(validation),下面分别给出其概念:验证(verification)是保证软件正确地实现了一些特定功能的一系列活动, 即保证软件以正确的方式来做了这个事件(Do it right)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。
2.程序正确性的形式证明,即采用形式理论证明程序符合设计规约规定的过程。
3.评审、审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认(validation)是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。(Do the right thing)
1.静态确认,不在计算机上实际执行程序,通过人工或程序分析来证明软件的正确性。
2.动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期间各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。
测试方法
等价类
1.定义
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。
2.划分等价类
等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
1)有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
2)无效等价类
与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。
设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性。
3.划分等价类的标准
1)完备测试、避免冗余;
2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;
3)并是整个集合:完备性;
4)子集互不相交:保证一种形式的无冗余性;
5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到"相同的执行路径"。
边界值
1. 定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。2. 与等价划分的区别
1) 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
2) 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
3. 边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
4. 常见的边界值
1) 对16-bit 的整数而言 32767 和 -32768 是边界
2) 屏幕上光标在最左上、最右下位置
3) 报表的第一行和最后一行
4) 数组元素的第一个和最后一个
5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次
详细分类
角度细分
从是否关心软件内部结构和具体实现的角度划分(按测试分类)
A.
白盒测试
B.
黑盒测试
C.
灰盒测试
从是否执行程序的角度
A.
静态测试
B.
动态测试。
阶段细分
从软件开发的过程按阶段划分有
A.
单元测试
B.
集成测试
C.
确认测试
D.
系统测试
E.
验收测试
F.
回归测试
G.
Alpha测试
H.
Beta测试
* 测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发布测试。