测试驱动的设计与开发who

上传人:无*** 文档编号:243926038 上传时间:2024-10-01 格式:PPTX 页数:40 大小:477.09KB
返回 下载 相关 举报
测试驱动的设计与开发who_第1页
第1页 / 共40页
测试驱动的设计与开发who_第2页
第2页 / 共40页
测试驱动的设计与开发who_第3页
第3页 / 共40页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,11111,*,测试驱动的设计和开发,(,Test Driven Design and Development,),基础篇,11111,1,你的代码工作吗?,“这段代码很简单,不可能出错”,“,我试过了,它是正常工作的呀”,“我用,Debugger,测试过了,我遍历了所有程序分支,内存中的值都是对的”,最好的方法是写一段另外的代码来证明它,让电脑来告诉,我们它是工作的。,11111,2,XP,中的测试,Unit Test,Acceptance Test(Functional Test),Regression Test,Nightly Test,Stress Test,所有的测试都应该独立地自动的运行,11111,3,什么是单元测试(Unit Test),单元测试是一段能够放在批处理中自动运行的,用来测试Classes的,程序。单元测试测试一小段代码或一个足够小的功能。单元测,试程序调用这小段代码或功能,并验证返回的结果是否符合预先设,定的结果。,每个单元测试至少应该有两个测试例子(,Test Case,):,Negative,Positive,单元测试是软件工程的一个关键部分。,11111,4,什么是,Acceptance Test,Acceptance Test are programs or scripts configured to test that,packages(groups of clusters of classes)meet external,requirements and achieve goals,such as performance.They,include screen-driving programs that test GUIs from without.,Acceptance Test,是对软件做,End-To-End,的测试,衡量软件是否符合,用户需求的指标,也就是验收测试。,11111,5,什么是,Regression Test,“Regression testing is the process of validating modified parts of,the software and ensuring that no new errors are introduced into,previously tested code.”,一句话,Regresstion Test就是要重新测试所有的代码和功能。,Regression Test,和,Development Test,的不同在于,Regression Test,需要重用已经建立的所有的测试单元,(Unit Test),和功能测试套件,(Functional Test),。,Regression Test,的基础是完整的自动单元测试和功能测试。,11111,6,什么是,Nightly Test,Nightly Test,就是每晚自动运行所有的,Unit Test,和,Acceptance Test。,Nightly Test是XP中的Continuous Test的一个练习(Practice)。,Nightly Test可以准确的反映项目开发的进度和质量。,11111,7,Nightly Test,Nightly Test,是软件开发中一个保证开发之质量的最有效的方法,也,是衡量软件之质量和开发效率的最好的指标。,Nightly Test,就是每天工作结束,所有的代码都,Check in,到,Source,Control,后,自动运行所有的,Unit Test,和,Function Test,。测试的结果,应该自动分发给开发人员和管理层。,两个指标数值:,测试例子的通过率,单,元测试必须是,100%,通过。,Functional Test,应该按计划的通过。,单元测试的覆盖率,表明有多少,Class,被测试过和测试的完善程度。,11111,8,测试优先的编程,在写任何代码之前,先写它的,Unit Test。,“Never write a line of functional code without a broken test case”Kent Beck,Test-First Programming,是一种测试技术吗?,Test-First Programming,首先是一种分析方法。它迫使程序员仔细思考要做什么和不要做什么,(,而不是如何具体的实现)。特别是各种例外的情况,并用程序语言正式的写下来。这就好像在程序员的任务和程序员之间签订了一个清晰的正式合同。,Test-First,Programming是一种设计方法。Unit Test测试的事程序,而不是一个想法。程序员必须清晰的定义程序的界面才能写出它的Unit Test。而这时程序员是不知道(也不需要知道)里面的具体逻辑是如何实现的。程序员只需要考虑Class的界面和功能(Responsibility)。啊,你在做OO设计了。,Test-First,Programming,是一种质量控制方法(Quality Control)。如何控制质量呢?如何知道我的程序是否运行呢?我会不会漏了什么?运行一下Unit Test。,Test-First,Programming,是一种重构和优化的方法。我们总希望自己的代码可以漂亮,运行的效率高,所以我们会不断地去改进。可是如何保证改进和优化后的质量呢?会不会越改越糟?答案还是Unit Test。,Test-First,Programming,不是通常意义上的测试技术,它的目的也不是仅仅用来测试你的代码。,Test-First,Programming,是一种面向对象的开发方法。,11111,9,什么是,Test-Driven Design,(TDD),Test-Driven Design,是一种开发风格,它要求程序员做到:,在写产品代码之前,先写它的单元测试(Unit Tests),没有单元测试的Class不允许作为产品代码,单元测试例子决定了如何写产品代码,不断地成功运行所有的单元测试例子,不断的完善单元测试例子,Test-Driven Design是把需求分析,设计,质量控制量化,的过程!,11111,10,为什么会出现,TDD,现实中的,设计(,Design,),和测试(,Testing,):,面对一个新的开发任务,往往第一个念头就是如何去实现它呢?,“好像是这样做的”感觉上差不多了。,抓起任务就开始编码,一边写,一边修改和设计。,哎,时间很紧。我先把任务实现了,然后再好好测试。,还是不工作,时间不多了。做个快速但丑陋的修改吧。等有空来再来重新整理这些代码吧。,用Debugger运行几次代码,走完所有的我认为可能的分支。我感觉这些代码应该行了。提交吧。,哎,我也知道该写一些自动的单元测试来把刚才在Debugger中的测试走一遍。可是那是很多的活啊。,这种情况要作自动测试太复杂了。还是手工作一下测试好了。,11111,11,为什么会出现,TDD(Continue),程序员心中的测试:,很郁闷的工作。对啊,程序员该做些新的,有创意的东西嘛。写一些新的功能会更有趣些。,我知道这些代码会工作的。我的经验和感觉都这样告诉我。只要没人乱改我的代码,应该就没问题。再说这些边缘情况几乎不可能出现了。,测试是,QA,的工作。,自动测试太花时间(我要赶,Deadline,),不值得。,11111,12,如何面对这些现实和想法,Test-Driven Design and Development,真的能行?,试一试!,11111,13,如何,做,Test Driven Design and Development,再开发一个新的功能之前,首先确定你要做什么(不是要如何,做!),比如说一个论坛的增加用户的功能,我们需要又一个,method,来增加一个用户:,public void addAccount(Account account),当然包括成功增加一个用户(在数据库中插入一条纪录),还包括如果已经由一个相同的用户,应该返回一个用户已存在的消息,OK,我们知道这个,method,中的这段代码要做什么,而且这段代码也足够简单。,11111,14,如何,做,Test Driven Design and Development(,Continue),然后为这个功能(,Method,),写单元测试例子,(,Unit Test),单元测试例子要覆盖这个,Method,的“做什么”。,所以我们至少有了两个测试例子:,Test Case 1:,测试成功增加一个用户,Test Case 2:,测试增加一个已存在的用户,其他边缘情况测试:,Test Case 3:,传入的,Account,对象为,NULL,11111,15,如何,做,Test Driven Design and Development(,Continue),写,Production,代码,我们清楚知道这段代码需要做什么。因为我们有另一段代码摆在那里,清晰的表明这段代码的,Contracts。,不用多,也不能少,只需要能实现再,Unit Test,中的,Contracts,和能够通过它的,Unit Test。,11111,16,如何,做,Test Driven Design and Development(,Continue),运行,Unit Test,如果顺利通过,你已经很好的完成了你的任务。,如果没通过,修补代码直到能通过,Unit Test,为止。,如果出现在,Unit Test,中没预先设定的结果,在,Unit Test,中增加一个,Test Case,,修补代码直到通过所有的,Test Case,为止。,11111,17,TDD,和,PSP,Personal Software Process,的,Development,Design,Code,Build,Test,Test-Driven Design and Development,Analysis,Code Unit Test,Code,Build,Run Test,Analysis,Design,11111,18,XP,采用了,TDD,TDD,是,Extreme Programming,中必须遵行的一个方法。,TDD,是,XP,中,Pair,Programming,的工作模式。,XP中把测试驱动的设计和开发做到极致。,TDD,的整个流程由两个程序员一起执行。,XP正是因为采用了,TDD,才能够做到每天的代码都是,Production Code,和每个小的,Release,都能提供具备,Production,质量的代码并投入使用。,有了,TDD,XP,才能降低风险,去拥抱变化。,有了,TDD,XP,才能在计划的时间内完成计划质量的代码。,有了,TDD,XP,才能减少,CodeFix,环节,从而减少项目成本。,有了,TDD,XP Team,才能对自己的工作充满自信。,11111,19,TDD,防止,Over-Engineering,在开发中采用,TDD,,可以有效的避免过度设计和开发。如果程序员,不愿为一个,Method,写测试例子或者认为现在没有必要测试改,Method,那这个Method多半是现在不需要的。,11111,20,TDD,程序员和管理层,对程序员来说,通过运行,Unit Test,和,Functional Test,,每天下班的时,候都可以清楚的知道自己的代码是,work的,。,对管理层来说,通过,Nightly Test,的结果,每天一早都清楚的知道项,目的质量和开发进度。,11111,21,XP,中谁来写,Tests,Developer:,Unit Test,Acceptance Test(Functional Test),Customer:,Acceptance Test,Customer,为每一个,User Story,写,Functional Test,。但通常用户并不,具备
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 管理文书 > 施工组织


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!