敏捷开发中的可测试性

发表于:2011-7-27 10:48

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:罗斯汀    来源:51Testing软件测试网原创

分享:

  软件可测试性并不是一个新名词,但在敏捷开发中它的重要性和可行性都有一些新的变化。本文将解读敏捷开发中的可测试性。

  传统的对可测试性的理解

  James Bach 这样定义可测试性:“软件可测试性就是一个计算机程序能够被测试的容易程度。”维基百科则这样描述:“软件的可测试性是一个软件产出物(如:软件系统、软件模块、需求或者设计文档)在一个给定的测试环境中对测试的支持程度。可测试性不是软件产出物的内在属性,不能被直接度量。但差的可测试性会导致测试工作量的增加。在极端情况下,缺乏可测试性会阻碍软件某些部分得到充分测试甚至是根本无法被测试。”由此可见,可测试性影响测试的效率和最终产品的质量,值得关注。

  我理解的可测试性

  可测试性虽然貌似针对测试,实际对开发的各个环节(需求、设计、编码、测试)都有特定要求。下面我们逐一探讨在敏捷开发中如何在这些环节关注和改善可测试性。

  1. 需求的可测试性

  需求需要满足以下条件达到可测试的要求:一致、完整、无二意性、可量化(如性能需求)、在实际中在有限资源的情况下可以被验证(而不仅仅是理论上可行)。

  在工作中,我们经常能碰到可测试性有问题的需求。比如:需要模拟无线网络中断的情况下手机能暂存正在发送的短信,这个网络中断就不那么好模拟。又如:一个大的需求虽然需求分析已经全部完成,但在SCRUM的实践中,当前Sprint只做其中的一部分。这部分很可能存在一些由于对后面一部分的依赖而无法测试的需求。还有一些复杂的功能或者不够友好的界面设计,因为难以理解,也就难以测试。

  在敏捷开发中,需求新的表现形式为可测试性提供了更具体、可操作的方法。因为敏捷开发中,需求以用户故事的形式组织,标准的格式是“在何种前提下,何种用户希望达到何种目的。”测试因此能够更容易地识别出“测试环境(前提)”、“操作者(用户)”、“预期结果(目的)””。以往含糊的或者难以被测试的需求通过这种格式表达后更容易在早期被识别出来其不可测试性,因而可以更及时地进行调整。另外,敏捷开发强调“定义每个用户故事的完成条件”并推荐通过演示的方式来验证,这些也为可测试性提供更多的保障。还有BDD、UADD、CADD等各种敏捷开发的方法,提出将需求、开发、测试这些瀑布模型中相对独立的环节在前期就进行统一考虑和安排,将可测试性的考虑也提前到了需求阶段。

  ……………………

  查看全文请点击下载:http://www.51testing.com/html/13/n-241113.html

  3. 测试的可测试性

  从测试角度,我理解的可测试性包括两个层面:可测和易测。其中,可测包含空间(在各个层次、各个粒度都可以测试)和时间(在恰当的时间可以测试)两个维度。易测是指在可测的基础上能够方便、高效地进行测试。

  (1)可测

  1)空间维度

  敏捷开发中强调质量由各个角色一起共同保证(实际上甚至淡化开发和测试两个角色的界限),所以无论开发人员还是测试人员需要分工协作,在不同的层次上进行不同类型和侧重点的测试。如在原子单位、在接口、在面向用户的端到端流程都需要进行测试。

  2)时间维度

  我理解的敏捷开发环境中,测试流程上最大的变化是要实现“边开发边测试”。为此我们需要一点安排上的特殊考虑。例如,有2个开发人员开发2个类似的用户故事。如果他们分头开发,在第4天同时提交测试人员测试,那么就难以将测试提前到开发过程中去。测试人员闲的时候没有东西可测,忙的时候来不及同时测大量的内容。如果我们换一种做法呢?让这两个开发人员先一起完成用户故事1,那么2天后这个用户故事可以提交测试了。等到第4天,用户故事2被提交测试。这样的安排下,测试人员可以及时完成每个用户故事的测试,而且可能通过用户故事1的缺陷提醒了用户故事2在开发过程中就避免了一些类似缺陷的发生。在开发任务分配和协作的安排上,建议考虑用户故事之间的依赖关系,合理协调安排开发资源,以实现“边开发边测试”。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号