Head First 软件开发(Software Development) 7-9 CI, TDD, Iteration

Section 7 Test & Continuous Integration

三个方面检查系统 >用户从外部看系统 Black Box 检查功能 >测试深入探究Grey Box 检查数据, 硬件, 软件 >开发系统研究 White Box 检查设计, 代码, 细节 

BlackBox 重点是输入和输出 -功能性 workflow -用户输入验证 输入过滤筛选 -输出结果 错误验证 -状态转换 绘制状态说明图 -边界案例和缓冲溢出 off-by-one errors 临界测试 

GreyBox web测试, 处理数据和接口 -检验审计和登录 验证浏览器和数据库表单 数据安全性保障 -提供底层数据格式和接口 以便其他系统使用 

-Hand Check系统附加信息 数据校验 数据HASH表 时间戳 -残留数据 清理系统 查询废弃的数据以及注册表Registry entries 

WhiteBox 利用系统内部知识 -测试逻辑分支 预期的Workflow和特殊的wf -错误处理 内存分配Memory Managerment 释放资源, 文件句柄 File Handle 同步互斥 Mutexes

-按照文档测试 线程安全 Thread Safe-> 多线程 Muli-Thread 默认值 -处理资源受限的情况 占据内存 硬盘空间 网络连接失败时的情况 -编写测试代码

Testing frameworks 编写测试程序

>选择测试方案 功能性测试, 边界情况 Boundary or Edge cases, 竞争条件 Race, 安全风险, 合法数据, 非法数据

测试库 Library of tests 测试套件 Test suite

>构建测试套件 >单个命令执行所有测试 >Regression Test/Software Regression 为软件增加新的修改, 不仅要测试新的代码, 还要执行已有的测试, 保证没有Regression

-测试所花的时间尽可能缩短, 测试套件执行时间越长, 可能执行的次数就越少

>测试方案让测试自动化 >测试框架运行测试(Java-JUnit)

Checkin代码的时候调用连续集成工具执行测试 -Continuous integration (CI) 持续集成 自动完成代码编译, 自动化测试, 创建Web页面报告和发送Email

>CI把版本控制 编译和软件测试囊括在单一的 可重复的流程之中 (CruiseControl)

-完整的代码是可运行的代码, 通过测是的代码才算完成

-Code Coverage代码覆盖率 -测试逻辑分支 -测试覆盖率报告(ComplexCode) 85%--90%

>GUI测试 模拟键盘鼠标输入, 对于音频和3D图像等难以设置的测试用人工实践

>难以测试的代码 3rdParty, Private Function...

-AllStuffs 测试成功案例; 测试失败案例; 数据库规划已知的输入数据 后台测试; Review测试代码; 审阅用户需求和US, 保证系统安装预期要求执行; 测试外部条件, 断网, 浏览器崩溃... 

测试SQL攻击或跨网站脚本攻击(XSS); 磁盘空间溢出; 大负载模拟; 测试不同操作系统, Platform, 浏览器

Tips 创建存储目录 代码多人协作 History Branches和Tag Rollback 提交前确定代码编译 测试代码 测试报告

Summary

>开发技术 从不同视角测试系统 测试需要说明成功和失败的原因 测试自动化 使用CI工具使得Build&Test自动化

>开发原则 测试可以时刻掌握项目状况 CI保证安全管理 代码覆盖率>测试数量, 更有效

>本章要点 CI监视代码质量 自动化测试需要编写代码 CI和测试报告对Team公开, 项目由Team负责 如果自动化测试失败, CI失败, 自动发送Email给Submitter, 要求Fix 测试软件系统的整体功能

Pseudo code, Continuous Integration, Automation, Scalability, Boundary Cases, Repository

---Section7 End---

Section 8 Test-driven Development

测试在先 TDD 测试驱动实施 集中于小段程序代码

规则1 在实施应用程序代码前, 测试是失败的状态 规则2 编写让测试通过的简单代码 -测试失败 -测试通过 -重构

>每项测试仅检验一件事 >避免重复的代码 Steup Teardown >测试代码保留在源码的镜像目录中 Test/SameFolderStruct

TDD通常与渐进式设计Evolutionary design一起使用 防止过度设计系统 在合适的时候进行重构步骤

利用红灯, 绿灯和重构循环进行测试代码->实现功能的步骤

>宗旨 为特定的功能创建测试程序 然后编写代码满足功能需求 对于超过功能的任何事情都暂时不重要

>红灯 测试代码失败 >绿灯 测试通过

简明化代表避免关联

>TDD的要点是使事情简单 避免使代码变得复杂的关联 >现实中的代码都是相互关联的

检查设计 是否需要紧耦合 Tightly coupled

策略模式 把接口抽象出来, 定义测试实例和真实实例 成为可以互相交换的数据

测试产生良好的代码 

>良好的代码组织 代码与测试分开 >代码总是做相同的事情(数据不同) >松散耦合的代码 灵活性 低耦合度 高内聚度 Cohesion, 接口和策略模式

>自动化的测试驱动开发->很多测试代码 Mock objects

>策略模式 松散耦合 模拟对象替代真实对象 使用Mock对象框架 (EasyMock)

测试中给需要模拟的对象安排接口 replay() 验证, equals() 比较, 关联性注入 Depedency Injection 数据库 网络, 控制逆转 Inversion of Control

关联性注入比工厂模式Factory pattern效率高

注意 >不起作用的测试代码 >把握测试的目标焦点 >每个测试需要有已知的,可恢复的状态 Baseline, Setup, Teardown

Process >测试代码先于产品代码 >测试失败, 然后实现简单的能通过测试的应用 >每个测试只测一件事, 一个概念 >当测试通过可以重构相关代码 >进行下一个测试 

Tip 在实现新功能时保证不破坏原有功能, TDD能帮助检查

Summary

>开发技术 测试代码先,应用实现后; 测试失败, 测试成功, 重构; 使用Mock对象应对各种变化

>开发原则 TDD集中于系统的功能; 自动化测试让重构变安全, 检查Regression, 良好的代码覆盖率

>本章要点 TDD需要多次重构,配合版本控制工具; 平衡测试和设计之间的冲突; 策略模式配以关联性注入, 帮助去耦合; 测试代码保存在Source的平行目录, 有利于工具设置; 

缩短构建和测试执行的时间, 测试可以和开发分开操作 

Setter&Getter, Unit test, Constantly, Mock, Automated, YAGNI-you ain't gonna need it, Refactor, Intefaces, Anti-patterns, low Coupling, Dependency Injection 

---Section8 End---

Section 9 End of the Iteration

>已有的 以客户为导向的功能, 可编译的代码, 开发监控, 持续测试代码, 测试覆盖率, 适合的开发计划

>TODO 流程改进, 系统测试, 重构, 代码清理和文档更新, 设计模式应用, 开发环境更新, 新技术or工具

Daily Meeting

10人以内, 15分钟, 同一时间地点, 参与者对开发循环进度有直接影响, 集中于紧迫问题的解决, Done, Plan, Issue, 大问题可以offline或者新开会议, 团队凝聚感, 互相合作沟通

系统测试

把系统作为整体, 不是单个部分的测试, 与单元测试完全不同, 需要测试系统各元件之间的相互作用

>真实的环境 BlackBox 从前端到后台 应用系统的功能性

对比SWD, QA能从不同的角度来看待系统.

>避免自己对自己的的代码做系统测试, SWD太了解系统, 很难在测试时公正, 容易避开代码中的问题

在每轮开发循环结束时, 需要做系统测试, 在初期对已完成的US做功能性测试, 功能完备时做整体系统测试.

>良好的系统测试需要两组Iteration 开发团队和测试团队

开发和测试之间的沟通 一起参加DailyMeeting; 在固定的开发循环周期内测试; 开发的同时要进行漏洞修复 安排fix时间; 为变动的目标编写测试程序; 沟通 开发 测试和客户

>在开发过程中大多问题的关键是沟通, 遇到问题时与团队和客户展开讨论

>测试循环和开发循环之间的配合按照客户的需求来调整, 测试每个循环的结果(循环测试, 每月发布)或者在开发完成后的测试(验收测试)  

有效系统测试 

客户 开发 测试之间良好和频繁的沟通; 准确无误的系统文档(US, Requirement, Reference...); 测试清楚的了解整个系统; 开发和测试之间的合作, 测试使开发更优秀;

自动化测试方式(完成重复性工); 建立清晰的成功标准 零错误反弹 Zero bug bounce; 测试文档; 熟悉系统开始和结束的状况(初始数据和结束时的状态) 

>Defect Fix流程 发现错误 Design UI或者功能; 提交错误报告 记录Step, Result, Expected behavior; 为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, 确保不跑题; >展示未来 Good Bad Improvement Solution... >计算统计数据 开发进度 测试覆盖率; 

>准备一组标准的问题 可以变更或调整 -是否对工作质量 文档 测试结果满意; -对开发循环的步调感觉 -对系统的信心...

优先级列表

>Defect fix 先和客户沟通优先级 >为下一轮开发准备US 了解客户对优先级的想法改变, 确认团队需要的测试时间 

>为下一轮开发准备Prototype 编写原型代码, 研究需要的测试和开发库 >培训和学习 和用户组的会议, Presentation, Demo, TeamBuilding

Tips >更新时间效率值, 当有时间结余并且增加的US没有完成, 需要吧这个US延展到下一个循环, 不能递交半成品, 未测试代码. 使用History标识, Release一个稳定Build

>定期和客户Review defects >不应该结余很多时间, 把任务细分, 为下一轮开发循环做准备

.Summary

>开发技术 在循环结束时候注意工作完成情况; 调整循环的步调, 增减US; 时间结余用来做下一轮的prototype或者学习;

>开发原则 坚持开发循环,设定中间期限; 以平均团队成员的能力来预估时间; 规划计划时保证考虑整体, 包括系统外部测试; 回顾完善流程; 

>本章要点 时间结余可以用来对新的US进行Brainstrom; 坚持优先级; 保证开发和测试团队间的健康沟通; 实际开发时间与估计的时间之间的比较不重要, 重点是找出问题, 给出方案;

Persistence framework, Ideal, Burndown, Big Picture, Spike, SuccessRiteria, ZeroBugBounce, Velocity, Automate, 交互式开发, 永续框架 

---Section9 End---