软件测试极限测试Word下载.docx
《软件测试极限测试Word下载.docx》由会员分享，可在线阅读，更多相关《软件测试极限测试Word下载.docx（10页珍藏版）》请在冰豆网上搜索。
XP与传统的开发过程相比有几处不同。
首先，它避免了大规模项目的综合症，即在开始编码之前客户与编程小组碰头，设计软件的每一个细节，项目经理们都知道这种做法的缺陷，因为为了反映新的业务谁则或市场情况，客户的规格说明和需求必须不停地变更。
举例来说，财务部门可能要求工资报表按处理时间，而不是按支票号码进行排序，而营销部门可能会判断出，如果它没发电子邮件的话．用户将不会购买某产品。
XP的策划阶段将重点放在收集应用程序需求，而不是设计程序上。
XP方法的另一个不同之处是避免了编写不需要的功能。
如果客户认为某个功能虽然需要，但并不是要求实现的，那么在软件发行时通常不包含此项功能。
因此我们可以将重点集中在正在进行的任务上，为软件产品增加价植。
将精力集中在必需的功能之上，有助于在短时间内开发出高质量的软件。
然而，XP方法的主要不同之处是其将精力集中在测试上。
在经历了一个非常全面的设计阶段之后，传统的软件开发模型会建议首先编码，然后才生成测试接口，但在XP方法中，我们必须首先生成单元测试用例，然后才编写代码通过测试。
根据本书第5章中讨论的概念，可以设计出XP环境中的单元测试。
XP开发模型用12个核心实践来驱动该过程。
表8-l总结了这些实践。
简单来说．这12个核心的XP实践可以归纳为4个概念：
1.聆听客户和其他程序员的谈话。
2.与客户合作，开发应用程序的规格说明和测试用例。
3.结对编码。
4.测试代码库。
表8-l中所列的由每个实践提供的注释都是可以自我解释的。
然而，有两个更重要的原则，即计划和测试，有必要进一步讨论。
一个成功的计划阶段为整个XP
过程奠定了基础，XP的计划阶段与传统开发模型不同，通常将需求收集与应用设
计结合起来。
XP中的计划重点是确定客户的应用需求，然后设计使用场景（或案例需求）来满足客户的应用需求。
通过生成使用场景，可以深入地洞悉应用程序的目的和需求。
此外，客户在一个开发周期的最后阶段执行验收测试时也可以用到这些使用场景。
最后，计划阶段带来的一个无形的好处是，用户通过深入地参与进来，从而获得对程序的拥有感和信心。
表8-1极限编程的12个实践
实践注解
1.计划与需求分析•将市场和业务开发人员集中起来，共同确认每个软件特征的最大商业价值
•以使用场景的形式重新编写每个重要的软件特征
•程序员估计完成每个使用场景的时间
•客户根据估计时间和商业价值选择软件的功能特征
2.小规模，递增地发布•努力添加细微的、实在的、可增值的特征，频繁发布新版本
3.系统隐喻，•编程小组确认隐喻，便于建立命名规则和程序流程
4.简要设计•实现最简单的设计，使代码通过单元测试，假设变更即将发生，因此不要在设计上花太多时间、只是不停地实现
5.连续测试•在编写模块之前就生成单元测试用例。
模块只有在通过单元测试之后才告完成。
此外，程序只有在通过了所有的单元测试和验收测试完成之后才算结束
6.重构•清理和调整代码库；
单元测试有助于确保在此过程中不破坏程序的功能。
应在任何重构之后重新进行所有的单元测试
7.结对编程•两位程序员协同工作，在同台机器开发代码库，这样就可以对代码进行实时检查，能极大地提高缺陷的发现率和纠正率
8.代码的集体所有权•所有代码归全体程序员所有，没有哪个程序员只致力于开发某一个代码库
9.持续集成•每天在变更通过单元测试之后将其集成到代码库中
10.每周40小时工作•不允许加班．如果每周都全力工作了40小时，就不需要加班。
在重大发布前的一星期例外
11.客户在现场•开发人员和编程小组可以随时接触客户，这样可以快速、准确地解决问题，使开发过程不至于中断
12.按标准编码•所有的代码看上去必须一致。
设计一个系统隐喻有助于满足该原则
进行连续的测试是基于XP的方法取得成功的关键。
虽然连续测试的原则中包
含了验收测试，但单元测试占了主要的部分。
我们应该确保代码的任何变更都改进了软件的质量，并且没有引入新的缺陷。
连续测试的原则同样也支持为优化和调整代码库所进行的重构。
持续的测试还会带来一个无形的好处，即建立对软件的信心．编程小组对代码库持有信心，源子用单元测试对代码库不断地进行验证。
此外，
客户对投资的信心也会高涨，因为他们知道代码库每天都在通过单元测试。
既然我们已经描述了XP过程的12个实践，那么一个典型的XP项目是如何运作的呢？
下面是一个简单的例子，列举了一个基于XP的项目可能具有的特征：
1.程序员与客户会晤，决定产品需求并建立使用场景。
2.在客户不在场的情况下，程序员进行会晤，将需求分解为独立的任务，并估计完成每项任务所需的时间。
3.程序员向客户提交任务清单和时间估计，并要求客户产生一个功能优先级清单。
4.编程小组依据程序员具备的能力，将任务分配给结对的程序员。
5.每一对程序员依据应用程序的规格说明，对其编程任务生成单元测试用例。
6.每一对程序员完成其任务，旨在编写出通过单元测试的代码库。
7.每一对程序员在所有单元测试通过之前，不断修改和重测他们的代码。
8.所有的结对程序员每天都整合、集成他们的代码库。
9.编程小组发布应用程序的一个预览版本。
10.客户进行验收测试，要么确认该应用程序，要么提交一份报告指出存在的缺陷或不足。
11.程序员在验收测试成功的基础上发布一个产品版本。
12.程序员根据最新的经验更新时间估计。
尽管XP方法魅力无穷，但它并不适合所有的项目和机构。
根据XP倡导者的总结．如果编程小组充分地进行了12个实践，那么成功开发应用程序的机会就会显著提高。
而批评者则认为，由于XP是一个过程，因此要么全部做到，要么什么也别做。
如果漏掉了一个实践，那么XP应用得就不彻底，程序的质量就会受到影响。
此外，批评者还认为，在未来修改程序以增加新的功能其代价要高于起初就将功能加人需求中并进行编码的代价。
最后，一些程序员发现结对编程十分麻烦并侵犯隐私，所以，他们并不接受XP思想。
无论个人的观点如何，都应将XP视为完成项目的一种方法。
应当根据项目的具体特性，仔细衡量XP方法的利弊，并做出可能的最佳选择。
8.2极限测试：
概念
为了满足XP的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试。
正如本章前面所提到的，极限测试主要由两种类型的测试组成：
单元测试和验收测试。
设计测试用例时所采用的原理与第5章描述的原理没有明显差异，但是在开发过程的哪个阶段设计测试用例则有所不同。
尽管如此，极限测试和传统测试的目标仍然相同：
即确定程序中的错误。
本节的余下部分将从极限编程的角度，提供关于单元测试和验收测试的更多信息。
8.2.1极限单元测试
单元测试是极限测试中采用的主要测试方法，它具有两个简单规则：
所有代码模块在编码开始之前必须设计好单元测试用例，在产品发布之前须通过单元测试。
乍看起来，这些原则似乎不太极端。
但是，极限测试中的单元测试与前面描述的单元测试之间的最大差别在于，极限测试中的单元测试必须在模块编码之前就完成设计和生成。
起初我们可能会迷惑为什么，或者如何为尚未编写出的代码设计测试驱动程序。
我们可能还会想到，没有设计测试的时间，因为应用程序的开发必须满足时间限制。
这些考虑都是合理的，也容易克服。
下面列出了在开始编码之前设计单元测试所带来的一些好处：
•获得了代码将满足其规格说明的信心。
•在开始编码之前，就展现了代码的最终结果。
•更好地理解了应用程序的规格说明和需求。
•可以先实现一些简单的设计，稍后再放心地重构代码以改善程序的性能，而无须担心破坏应用程序的规格说明。
在这些优点中，获得对应用程序规格说明和需求的洞察和理解不应被低估。
举例来说，如果编码开始在先，我们可能无法充分理解程序输入值允许的数据类型和边界值。
那么在不理解允许的输入的情况下，如何能够编写单元测试以执行边界分析呢？
程序是否只接受数字、字符或两者都可以？
如果首先设计单元测试，就必须理解规格说明。
首先设计单元测试的做法就是XP方法的闪光点，因为它迫使我们
在开始编码之前，首先理解规格说明，排除了混淆。
正如第5章所述，我们需要确
定单元的范围。
由于目前常用的编程语言，如Java，C#，VisualBasic大部分是面向对象的，因此模块常常就是类，或者甚至是单个的类方法。
我们有时可以将“模块”定义为代表特定功能的一组类或方法。
仅有程序员本人才知道程序的结构，以及任何最佳地为其设计单元测试。
即使是为最小的程序人工进行单元测试，也是一项让人生畏的工作。
随着程序规模的增加，可能要设计数以百计，甚至数以千计的单元测试。
因此，通常要采用一个自动化的软件测试套件来减轻连续执行单元测试的负担。
在这些测试套件的帮助下，编写测试脚本，然后执行全部或其中的一部分。
除此之外，测试套件通常可以生成报告，并对应用程序中频繁出现的缺陷进行分类。
该信息可以帮助我们在将来主动清除这些缺陷。
非常有趣的是，一旦设计并确认了单元测试，这些“测试”用例库就与试图编写的应用软件程序一样有价值。
因此，应当将这些测试用例保存在一个代码库中。
此外，还应确保进行足够的备份，并具备所需的安全保密措施。
8.2.2验收测试
验收测试是XP方法中第二类、也是同等重要的极限测试类型。
验收测试的目的是判断应用程序是否满足如功能性和易用性等其他需求。
在设计/计划阶段，由开发人员和客户来设计验收测试。
与迄今为止讨论的其他测试形式不同，验收测试是由客户，而不是开发人员或编程搭档来执行的。
在这种方式中，客户对应用程序是否满足他们的要求进行客观、公正的确认。
客户通过使用场景来设计验收测试。
使用场景与验收测试之比通常是一对多，也就是说，每一个使用场景都可能需要不止一个的验收测试。
极限测试中的验收测试可以是自动化或非自动化的。
举例来说．当客户必须确认某个用户输入界面的颜色和屏幕布局是否满足其规格说明时，所进行的测试是非自动化的，当应用程序须通过采用某些数据源（比如用二维表格模拟生产数据）作为输入数据来计算工资表格的值时，所进行的测试则是自动化的。
客户使用验收测试来验证应用程序是否得到了预期的结果。
如果与预期结果不
一致，即被当作一个缺陷，报告给开发小组，如果客户发现了多个缺陷，那么在将
列表传递给开发小组之前，得对缺陷进行优先级别排序。
当缺陷被修正，或程序中发生任何变更时，客户都需要重新执行验收测试。
从这点来看，验收测试也是回归测试的一种形式。
需要特别提醒的是，程序可能通过所有的单元测试，却不能通过验收测试。
为什么会这样呢？
因为单元测试是确认程序单元是否满足特定的规格说明，如工资扣除计算是否正确，而并非具体的可操作性或审美特性。
对于商用软件来说，产品的外观和感觉是非常重要的部分。
理解了规格说明，但却不理解其可操作性，通常会发生这种情况．
8.3极限测试的应用
在本节中，我们开发了一个小型的Java应用程序，使用JUnit（一个基于Java的开源单元测试套件）来描述极限测试的概念，例子本身很小，但其概念可适用于大多数的编程环境。
我们的例子是一个命令行的应用程序，仅判断输入值是否为素数。
为简洁起见，程序的源代码check4Primo.java及其测试配件（testharness）check4PrimeTestjava列在附录A中。
在本节中，我们节选了程序片段来说明主要的思路。
程序的规格说明如下：
开发一个命令行的应用程序，接收一个正整数n（0<
=n<
=1000），判断n是否为素数。
如果为素数，程序应返回信息说明其为素数。
如果n不是素数，程序也应返回信息说明其不为素数．知果n不是一个有效的输入，程序应显示一条帮助信息。
遵循XP方法及第5章中列举的原则，我们从设计单元测试开始。
对于这个应用程序，可以确定出两个具体的任务：
确认输入和判断素数。
我们可以分别使用黑盒与白盒测试方法、边界值分析方法和判定覆盖准则。
然而，极限测试要求使用一个独立的黑盒测试方法，消除所有的偏见。
8.3.1测试用例设计
设计测试用例首先从确认测试方法开始．在本例中，我们将使用边界值分析方
法对输入进行确认，因为程序只能接受固定范围内的正整数．所有其他的输入值，
包括字符数据类型和负数都会产生错误，不能被使用。
当然，我们可以这样处理本例，将输入确认划归到判定覆盖准则中，因为程序必须判断输入是否有效，这里一个重要的概念是，在设计测试时必须确定使用某个测试方法。
使用确定的测试方法，根据可能的输入和预期的输出结果开发一份测试用例列表。
表8-2显示了确认的8个测试用例（注意：
我们采用了一个非常简单的例子来说明极限测试的基本理论。
在实际中，会遇到更详细的程序规格说明，可能包含诸如用户界面需求和输出用语措辞等内容。
因此，测试用例列表可能会增长很多）。
表8-2check4Prim.java的测试用例
用例编号
输入
结果
注解
1
n=3
确认n为素数
对有效素数的测试
对边界范围内输入的测试
2
3
n=1,000
n=0
确认n不为素数
对等于上边界输入的测试
对n不为素数的测试对等于下边界的测试
4
n=-1
显示帮助信息
对低于下边界的测试
5
n=1,001
对高于下边界的测试
6
两个或两个以上输入
对输入值得正确个数的测试
7
n=“a”
输入未整数而非字符的测试
8
n为空（空格）
对输入为空的测试
表8-2中的测试用例1结合了两个测试需求。
它检查了输入是否为有效的素数，
以及程序如何处理有效的输入值。
可以在本测试中使用任何有效的素数。
附录B提供了一份小于1,000的可用素数的清单。
使用测试用例2同样会测试到两个需求：
当输入值等于上边界，或输入值不是素数时会发生什么情况？
这个测试用例本可以被分解为两个单元测试，但软件测试总的目标之一是在足以检查出错误的前提下，使测试用例的数量最小。
测试用例3检查有效输入的下边界，以及测试无效的素数。
此项检查的第二部分是不需要的，因为测试用例2已经处理了此需求，但仍然被默认地包括进来，因为0不是素数。
测试用例4和测试用例5保证了输入是在规定的范围之内，即大于0，且小于
或等干1000。
测试用例6测试应用程序是否可以正确地处理字符输入值。
由于我们所做的是数学运算，因此很明显，程序必须拒绝字符类型的输入。
该测试用例假定Jova会进行数据类型的检查，当输入无教的数据类型时，应用程序必项能够处理发生的异常。
该测试用例确保异常得到了处理。
最后，测试用例7和测试用例8检查输入值的正确个数，任何超过t1个的输入都会发生失效。
JUnit是一个可以免费获得的开源工具，用于在极限编程环境下对Java应用程序进行自动化的单元测试。
设计者KentBeck和ErichGamma开发JUnit来支持极限编程环境下进行的单元测试。
JUnit非常小，但非常灵活，并且功能丰富。
我们可以设计单个测试或一系列的测试。
可以自动生成报告，详细描述错误的信息。
在使用JUnit或任何测试套件之前，须充分了解如何使用它。
JUnit非常强大，但只有掌握了其API之后才会发挥作用。
然而，无论是否采纳XP方法，JUnit都是一个对代码进行合理检查的有用工具。
访问www.JUnit.org可以获得更多的信息，并可下载该测试套件。
另外，该站点还提供关于极限编程和极限测试的丰富信息。
8.3.2测试驱动器及其应用
既然我们已经设计出了两类测试用例，那么就可以生成测试驱动器类check4primeTest。
表8-3将check4PrlmoTest中的JUnit方法与覆盖的测试用例对应起来。
表8-3测试驱动器的方法
方法检查到的测试用例
testCheckPrime_true（）1testCheckPrime_false（）2,3testCheck4Prime_checkArgs_char_input（）7testCheck4Prime_checkArgs_above_upper_bound（）5testCheck4Prime_checkArgs_neg_input（）4testCheck4Prime_checkArgs_2_inputs（）6
testCheck4Prime_checkArgs_0_inputs（）8
注意testCheckPrime_false（）方法测试了两种状态，因为边界值并不是素数。
因
此，我们可以采用一个测试方法来检查边界值错误和无效素数．仔细检查该方法可以发现，两个测试
publicvoidtestCheckPrime_false（）{assertFalse（check4prime.primecheck（0））;
assertFalse（check4prime.primecheck（1000））;
}
用例确实在其内部被执行到。
以下是附录A中列举的check4JavaTest类中一个完整的JUuit方法。
注意，JUnit方法assertFalse（）对提供给它的参数进行检查，看看是否有误，参数必须是布尔类型，或是一个返回值为布尔类型的函数。
如果返回的是“false"
，则测试可视为成功。
这个程序片段还提供了一个首先设计测试用例和测试配件所带来好处的例子。
可以看到assertFalse（）方法中的参数是check4prime.primecheck（0）方法。
这个方法会出现在应用程序的某个类中。
首先进行测试设计迫使我们思考该应用程序的结构。
从某些方面来讲，应用程序是按照测试配件设计出来的。
这里我们需要一个方法来检查输入是否为素数，因此在应用程序中我们将其包括进来。
测试设计结束之后，就可以开始程序编码了。
根据程序规格说明，测试用例、测试配件以
publicclasscheck4prime{
publicstaticvoidmain（string[]args）
publicvoidcheckArgs（string[]args）throwsExceptionpublicbooleanprimeCheck（intnum）
及最后的java程序都由单个check4Prime类组成，定义如下：
简单地说，根据Java程序的定义。
main（）过程提供了应用程序的入口点。
checkArgs（）方法判断输入值n是个正数，0<
=1000。
Primecheck（）过程
对照一个已计算出的素数列表来检查输入值。
我们采用Eratosthenes筛选法来快速计算素数。
由于涉及的素数数量比较小，此方法是可以接受的。
8.4小结
随着软件产品间竞争的日益激烈，需要将产品非常快速地投向市场。
因此人们设计了极限编程方法来支持快速的应用程序开发。
这个轻量级的开发过程强调沟通计划和测试。
极限编程中的测试被称为“极限测试”。
极限测试的重点在于单元测试和验收测试。
一旦代码库发生变更，就需要进行单元测试。
在重要的发布结点，由客户来执行验收测试。
极限测试还要求在开始程序编码之前，根据程序的规格说明设计测试配件。
在这种方式中，开发的程序要通过单元测试，从而提高程序满足其规格说明的可能性。
升级会员 