Head First 软件开发(Software Development) 7-9 CI, TDD, Itera
|
Section7Test&ContinuousIntegration 三个方面检查系统>用户从外部看系统BlackBox检查功能>测试深入探究GreyBox检查数据,硬件,软件>开发系统研究WhiteBox检查设计,代码,细节 BlackBox重点是输入和输出-功能性workflow-用户输入验证输入过滤筛选-输出结果错误验证-状态转换绘制状态说明图-边界案例和缓冲溢出off-by-oneerrors临界测试 GreyBoxweb测试,处理数据和接口-检验审计和登录验证浏览器和数据库表单数据安全性保障-提供底层数据格式和接口以便其他系统使用 -HandCheck系统附加信息数据校验数据HASH表时间戳-残留数据清理系统查询废弃的数据以及注册表Registryentries WhiteBox利用系统内部知识-测试逻辑分支预期的Workflow和特殊的wf-错误处理内存分配MemoryManagerment释放资源,文件句柄FileHandle同步互斥Mutexes -按照文档测试线程安全ThreadSafe->多线程Muli-Thread默认值-处理资源受限的情况占据内存硬盘空间网络连接失败时的情况-编写测试代码 Testingframeworks编写测试程序 >选择测试方案功能性测试,边界情况BoundaryorEdgecases,竞争条件Race,安全风险,合法数据,非法数据 测试库Libraryoftests测试套件Testsuite >构建测试套件>单个命令执行所有测试>RegressionTest/SoftwareRegression为软件增加新的修改,不仅要测试新的代码,还要执行已有的测试,保证没有Regression -测试所花的时间尽可能缩短,测试套件执行时间越长,可能执行的次数就越少 >测试方案让测试自动化>测试框架运行测试(Java-JUnit) Checkin代码的时候调用连续集成工具执行测试-Continuousintegration(CI)持续集成自动完成代码编译,自动化测试,创建Web页面报告和发送Email >CI把版本控制编译和软件测试囊括在单一的可重复的流程之中(CruiseControl) -完整的代码是可运行的代码,通过测是的代码才算完成 -CodeCoverage代码覆盖率-测试逻辑分支-测试覆盖率报告(ComplexCode)85%--90% >GUI测试模拟键盘鼠标输入,对于音频和3D图像等难以设置的测试用人工实践 >难以测试的代码3rdParty,PrivateFunction... -AllStuffs测试成功案例;测试失败案例;数据库规划已知的输入数据后台测试;Review测试代码;审阅用户需求和US,保证系统安装预期要求执行;测试外部条件,断网,浏览器崩溃... 测试SQL攻击或跨网站脚本攻击(XSS);磁盘空间溢出;大负载模拟;测试不同操作系统,Platform,浏览器 Tips创建存储目录代码多人协作HistoryBranches和TagRollback提交前确定代码编译测试代码测试报告 Summary >开发技术从不同视角测试系统测试需要说明成功和失败的原因测试自动化使用CI工具使得Build&Test自动化 >开发原则测试可以时刻掌握项目状况CI保证安全管理代码覆盖率>测试数量,更有效 >本章要点CI监视代码质量自动化测试需要编写代码CI和测试报告对Team公开,项目由Team负责如果自动化测试失败,CI失败,自动发送Email给Submitter,要求Fix测试软件系统的整体功能 Pseudocode,ContinuousIntegration,Automation,Scalability,BoundaryCases,Repository ---Section7End--- Section8Test-drivenDevelopment 测试在先TDD测试驱动实施集中于小段程序代码 规则1在实施应用程序代码前,测试是失败的状态规则2编写让测试通过的简单代码-测试失败-测试通过-重构 >每项测试仅检验一件事>避免重复的代码SteupTeardown>测试代码保留在源码的镜像目录中Test/SameFolderStruct TDD通常与渐进式设计Evolutionarydesign一起使用防止过度设计系统在合适的时候进行重构步骤 利用红灯,绿灯和重构循环进行测试代码->实现功能的步骤 >宗旨为特定的功能创建测试程序然后编写代码满足功能需求对于超过功能的任何事情都暂时不重要 >红灯测试代码失败>绿灯测试通过 简明化代表避免关联 >TDD的要点是使事情简单避免使代码变得复杂的关联>现实中的代码都是相互关联的 检查设计是否需要紧耦合Tightlycoupled 策略模式把接口抽象出来,定义测试实例和真实实例成为可以互相交换的数据 测试产生良好的代码 >良好的代码组织代码与测试分开>代码总是做相同的事情(数据不同)>松散耦合的代码灵活性低耦合度高内聚度Cohesion,接口和策略模式 >自动化的测试驱动开发->很多测试代码Mockobjects >策略模式松散耦合模拟对象替代真实对象使用Mock对象框架(EasyMock) 测试中给需要模拟的对象安排接口replay()验证,equals()比较,关联性注入DepedencyInjection数据库网络,控制逆转InversionofControl 关联性注入比工厂模式Factorypattern效率高 注意>不起作用的测试代码>把握测试的目标焦点>每个测试需要有已知的,可恢复的状态Baseline,Setup,Teardown Process>测试代码先于产品代码>测试失败,然后实现简单的能通过测试的应用>每个测试只测一件事,一个概念>当测试通过可以重构相关代码>进行下一个测试 Tip在实现新功能时保证不破坏原有功能,TDD能帮助检查 >开发技术测试代码先,应用实现后;测试失败,测试成功,重构;使用Mock对象应对各种变化 >开发原则TDD集中于系统的功能;自动化测试让重构变安全,检查Regression,良好的代码覆盖率 >本章要点TDD需要多次重构,配合版本控制工具;平衡测试和设计之间的冲突;策略模式配以关联性注入,帮助去耦合;测试代码保存在Source的平行目录,有利于工具设置; 缩短构建和测试执行的时间,测试可以和开发分开操作 Setter&Getter,Unittest,Constantly,Mock,Automated,YAGNI-youain'tgonnaneedit,Refactor,Intefaces,Anti-patterns,lowCoupling,DependencyInjection ---Section8End--- Section9EndoftheIteration >已有的以客户为导向的功能,可编译的代码,开发监控,持续测试代码,测试覆盖率,适合的开发计划 >TODO流程改进,系统测试,重构,代码清理和文档更新,设计模式应用,开发环境更新,新技术or工具 DailyMeeting 10人以内,15分钟,同一时间地点,参与者对开发循环进度有直接影响,集中于紧迫问题的解决,Done,Plan,Issue,大问题可以offline或者新开会议,团队凝聚感,互相合作沟通 系统测试 把系统作为整体,不是单个部分的测试,与单元测试完全不同,需要测试系统各元件之间的相互作用 >真实的环境BlackBox从前端到后台应用系统的功能性 对比SWD,QA能从不同的角度来看待系统. >避免自己对自己的的代码做系统测试,SWD太了解系统,很难在测试时公正,容易避开代码中的问题 在每轮开发循环结束时,需要做系统测试,在初期对已完成的US做功能性测试,功能完备时做整体系统测试. >良好的系统测试需要两组Iteration开发团队和测试团队 开发和测试之间的沟通一起参加DailyMeeting;在固定的开发循环周期内测试;开发的同时要进行漏洞修复安排fix时间;为变动的目标编写测试程序;沟通开发测试和客户 >在开发过程中大多问题的关键是沟通,遇到问题时与团队和客户展开讨论 >测试循环和开发循环之间的配合按照客户的需求来调整,测试每个循环的结果(循环测试,每月发布)或者在开发完成后的测试(验收测试) 有效系统测试 客户开发测试之间良好和频繁的沟通;准确无误的系统文档(US,Requirement,Reference...);测试清楚的了解整个系统;开发和测试之间的合作,测试使开发更优秀; 自动化测试方式(完成重复性工);建立清晰的成功标准零错误反弹Zerobugbounce;测试文档;熟悉系统开始和结束的状况(初始数据和结束时的状态) >DefectFix流程发现错误DesignUI或者功能;提交错误报告记录Step,Result,Expectedbehavior;为Defects创建Tasks,和客户讨论优先级;开发修复Defect,报告状态改为Fixed; 测试在新的Build上检查和验证Defect,状态改为Closed或者返回给开发做进一步的Fix;更新错误报告,可以作为测试参考资料 >Defect需要被错误报告来记录和跟踪(BugZilla,Mantis,TestTrackPro,ClearQuest) 记录和沟通优先级,排列优先级,在Iteration中先处理高级别的Defect;记录History,讨论测试修改验证以及设计上的决定;产生统计数据提交率Bug区域剩余Defects 软件错误报告 >摘要描述Defect的行为>重现产生错误的步骤是>Result和Expected>版本,平台和定位信息(LocalMachine,CleanEnvironment)>严重性和优先级 Tip对项目而言,正确的做法是在正确的时间把事情做对,并没有一成不变的规则 >TODO流程优化;系统测试;回顾开发循环,了解哪些工作有效或者无效;利用经验来重构代码;代码整理文档更新;设计模式应用;开发环境更新;学习新技术;探索新工具 >已有的编译代码;自动化单元测试;捕捉重要的US;优先级排序;可运行的Build Iteration不只是以反复进行的方式来开发,也是以反复进行的方式来发展和定义流程 开发循环回顾的要素 >事前准备会议Aganda,确保不跑题;>展示未来GoodBadImprovementSolution...>计算统计数据开发进度测试覆盖率; >准备一组标准的问题可以变更或调整-是否对工作质量文档测试结果满意;-对开发循环的步调感觉-对系统的信心... 优先级列表 >Defectfix先和客户沟通优先级>为下一轮开发准备US了解客户对优先级的想法改变,确认团队需要的测试时间 >为下一轮开发准备Prototype编写原型代码,研究需要的测试和开发库>培训和学习和用户组的会议,Presentation,Demo,TeamBuilding Tips>更新时间效率值,当有时间结余并且增加的US没有完成,需要吧这个US延展到下一个循环,不能递交半成品,未测试代码.使用History标识,Release一个稳定Build >定期和客户Reviewdefects>不应该结余很多时间,把任务细分,为下一轮开发循环做准备 .Summary >开发技术在循环结束时候注意工作完成情况;调整循环的步调,增减US;时间结余用来做下一轮的prototype或者学习; >开发原则坚持开发循环,设定中间期限;以平均团队成员的能力来预估时间;规划计划时保证考虑整体,包括系统外部测试;回顾完善流程; >本章要点时间结余可以用来对新的US进行Brainstrom;坚持优先级;保证开发和测试团队间的健康沟通;实际开发时间与估计的时间之间的比较不重要,重点是找出问题,给出方案; Persistenceframework,Ideal,Burndown,BigPicture,Spike,SuccessRiteria,ZeroBugBounce,Velocity,Automate,交互式开发,永续框架 ---Section9End--- （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |