帮你做到零bug的编程方法 - atdd

帮你做到零bug的编程方法 - atdd

ID:5324371

大小:446.22 KB

页数:6页

时间:2017-12-08

帮你做到零bug的编程方法 - atdd_第1页
帮你做到零bug的编程方法 - atdd_第2页
帮你做到零bug的编程方法 - atdd_第3页
帮你做到零bug的编程方法 - atdd_第4页
帮你做到零bug的编程方法 - atdd_第5页
资源描述:

《帮你做到零bug的编程方法 - atdd》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、《验收测试驱动开发:ATDD实例详解》第一本成功实施和应用ATDD的入门实践操作指南1ATDD的原则传统的软件需求(Specification)存在一个问题:需要特别的努力才能做得好。然而一旦它们编写完成,很快就会因为各种原因(你能控制的,或无法控制的)而迅速过时。举个例子,如果一个竞争对手发布了一个新特性,你的需求要立刻响应以保持你的市场份额。由于这显然是一个非技术决策,所以至少需要一些有业务背景的人参与需求决策过程。在确定需求过程中获得的意见越是多样化,你就越能看清楚整个应用的全景。通常来说,你至少需要从三个不同的视角考虑。首先,需要

2、考虑业务视角。在敏捷团队中,这方面需求通常由客户代表、客户代理人或是Scrum中的产品负责人(ProductOwner)来提出。其次需要考虑技术视角。在传统的团队中,资深开发人员或技术负责人通常会站在这个视角。在敏捷团队中,你会希望讨论会中有一个参与实际开发工作并熟悉源代码的团队成员参加。最后,需要有人在这两种视角中充当中间人。在传统项目中,你会发现业务分析人员会提供这种视角。一个富有经验的软件测试人员会带来同样的价值。1 见识“三的力量”可是为什么这三种不同的视角可以帮助我们确定产品的需求呢?设计软件系统包含很多对这两个方面的权衡:业务

3、功能与技术限制。我们的软件代码中充满了对功能和限制所做的折衷。另一方面,我们的缺陷数据库中则充满了由明显决策失误而导致的问题。这些决策中,有些在软件开发过程中很难改变,有些则很容易改正。通过尽早让业务功能和技术限制这两种不同的视角接触,我们可以尽早找到正确的决策平衡点。因而,可以将引入难以改正的bug和容易改正的bug的概率降到最低。顺便我们也可以避免这两种极端情况中间的那些bug。软件系统的功能分布在一个解决方案空间中[GW89]。这个解决方案空间中存在很多可以实现所需功能的可行设计方案。这就解释了为什么你可以带着性能或负载等特性的需要

4、去探索解决方案空间。这些特性限制了解决方案空间中能满足用户期望的方案的数量。另一方面,软件实现还存在技术方面的制约。这些制约同样限制了实现所有功能以及特性的设计方案数目。将业务功能和特性与技术的制约尽早放在一起考虑,可以帮助参与者在解决方案空间中探索可能的设计。这是验收测试驱动开发方法可以成功的重要因素之一。并且,它证明了测试人员在这个探索过程中也能发挥作用,他们可以对软件在功能、特性以及制约方面提出问题和建议。但是,怎么看待独立的测试团队能带来独特的视角这一观点呢?在过去数十年的测试培训中,我们学到的观点是:开发人员和测试人员应当基于需

5、求文档这一共同的基础而完全独立的工作。这避免了在现代心理学中被称为共识偏见(confirmationbias)的现象。测试人员必须避免受到开发人员观点的影响,并且在应当在适当的时候对产品作出评价。一些团队将这条规则发挥到这样一种极致:开发人员与测试人员被完全禁止与对方交谈。与开发人员一起描述软件需求并不会给测试人员带来先入为主的偏见。相反,开发人员、测试人员与业务专家应该一起捕捉软件需求。如果你认为这也会使测试人员产生偏见,那么你是不是该开始怀疑阅读需求文档也同样会使测试人员产生偏见?对于测试人员,与开发人员以及业务专家一起描述需求实例和

6、参加需求讨论会的功用是一样的,这也是大多数测试人员在他们的职业生涯中都梦想能做到的。事实上,在GojkoAdzic的书《实例化需求》(SpecificationbyExample)[Adz11]中采访到的团队反映,由至少一个开发人员和一个测试人员提供的综合观点,会让我们在项目初期就更好地理解需求。就像我们在机场的实例中看到的一样,这种讨论通常会达到以下的效果,开发人员通过提出技术性的问题来澄清业务流程,同时测试人员提出的问题则增加了需求的可理解性,并且用表格这一更加可视化的方式记录了需求。1《验收测试驱动开发:ATDD实例详解》第一本成功

7、实施和应用ATDD的入门实践操作指南2在迭代过程中,开发人员与测试人员基于对特性共同的基本理解开展工作。作为验收测试的实例则成为衡量团队进度的指标。为了达到最好的结果,确认需求的过程应包含以下三种不同的角色:一个业务专家(例如ProduceOwner,或驻厂的用户)、一个开发人员和一个测试人员。基于所包含的角色个数,JanetGregory和LisaCrispin把这叫做“三的力量”。“三种解释原则”[Wei93,90页]提醒我们在对收到的信息下结论之前,至少要想到3种可能的情况。如果我对收到的信息不能想到至少3种解释,就说明我对它的含义

8、考虑的还不够全面。“三的力量”可以帮助我们克服想象力的不足。让代表三种视角的人坐在一张桌子旁,充分理解特性或用户故事的可能性就会大大增加。这就是“三的力量”为何如此强大的原因。“三的力量”不仅

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。