Test-Driven Development- By Example By Kent Beck Chapter 1

CC++TDD单元测试⾮常好的书
测试驱动的嵌⼊式C语⾔开发Test Driven Development for Embedded C
《测试驱动的嵌⼊式c语⾔开发》深⼊介绍如何把测试驱动的开发⽅法应⽤于嵌⼊式c语⾔开发，第⼀部分介绍了两个开源的测试框架，通过测试驱动开发⽅法开发第⼀个模块；第⼆部分深⼊介绍了与系统中其他模块进⾏交互的代码的测试技术，如测试替⾝、仿制对象等；第三部分介绍了设计与持续改进代码，如写出更好代码的⼀些重要原则，建⽴可测并灵活设计的⾼级技术，改进已有代码的实践⽅法—重构技术，改进遗留代码，以及编写和维护测试的指导原则。

本书的代码⼏乎全部⽤c写成，并且可以⽤于嵌⼊式的、受约束的开发和执⾏环境。

Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better by Jeff Langr
In this book, you’ll learn how to use TDD to improve legacy C++ systems
第2本是新出的书，对c++的TDD进⾏了⾮常详尽的描述
⼏个常见的单元测试框架[C/C++]
Google Test/Google Mock
Boost.Test
CppUnit
CppUnitLite
CUTE
CxxTest
Unit++。

内容简介本书清晰地揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。

书中给出了70多个可行的重构，每个重构都介绍了一种经过验证的代码变换手法的动机和技术。

本书提出的重构准则将帮助你一次一小步地修改你的代码，从而减少了开发过程中的风险。

本书适合软件开发人员、项目管理人员等阅读，也可作为高等院校计算机及相关专业师生的参考读物。

目录Chapter 1：Refactoring，a First Example 重构，第一个例子　　The Starting Point 起点　　The First Step in Refactoring 重构第一步　　Decomposing and Redistributing the Statement Method 分解并重组slalemenl 方法　　Replacing the Conditional Logic on Price Code with Polymorphism 用多态代替价格条件逻辑代码　　Final Thoughts 结语　Chapter 2：Principles in Refactoring 重构原则　　Defining Refactoring 何谓重构　　Why Should You Refactor? 为何重构　　When Should You Refactor? 何时重构　　What Do I Tell My Manager? 怎样说服经理　　Problems with Refactoring 重构的问题　　Refactoring and Design 重构与设计　　Refactoring and Performance 重构与性能　　Where Did Refactoring Come From? 重构的起源　Chapter 3：Bad Smells in Code(by Kent Beck and Martin Fowler) 代码坏昧 Duplicated Code 重复代码　　Long Method 过长方法　　Large Class 过长类　　Long Parameter List 过长参数列表　　Divergent Change 发散式变化　　Shotgun Surgery 霰弹式修改　　Feature Envy 特性依恋　　Data Clumps 数据泥团　　Primitive Obsession 基本类型偏执　　Switch Statements switch语句　　Parallel Inheritance Hierarchies 平行继承体系　　Lazy Class 冗余类　　Speculative Generality 理论上的一般性　　Temporary Field 临时字段　　Message Chains 消息链　　Middle Man 中间人　　Inappropriate Intimacy 过度亲密　　Alternative Classes with Different Interfaces 接口不同的等效类　Incomplete Library Class 不完整的库类　　Data Class 数据类　　Refused Bequest 拒绝继承　　Comments 注释过多　Chapter 4：Building Tests 构建测试　　The Value of Self-testing Code 自测试代码的重要性　　The JUnit Testing Framework Junit测试框架　　Adding More Tests 添加更多测试　Chapter 5：Toward a Catalog of Refactorings 重构目录　　Format of the Refactorings 重构描述的格式　　Finding References 寻找引用　　How Mature Are These Refactorings? 这些重构的成熟度如何 Chapter 6：Composing Methods 组合方法　　Extract Method 提取方法　　Inline Method 内联方法　　Inline Temp 内联临时变量　　*Replace Temp with Query 用查询方法代替临时变量　　Introduce Explaining Variable 引入解释性变量　　Split Temporary Variable 分离临时变量　　*Remove Assignments to Parameters 去除参数赋值　　Replace Method with Method Object 用方法对象代替方法　　Substitute Algorithm 替换算法　Chapter 7：Moving Features Between Objects 在对象之间移动特性 *Move Method 移动方法　　Move Field 移动字段　　Extract Class 提取类　　Inline Class 内联类　　Hide Delegate 隐藏委托类　　Remove Middle Man 去除中间人　　Introduce Foreign Method 引入外加方法　　*Introduce Local Extension 引入本地扩展类　Chapter 8：Organizing Data 组织数据　　Self Encapsulate Field 自封装字段　　Replace Data Value with Object 用对象代替数据值　　Change Value to Reference 将值对象改为引用对象　　Change Reference to Value 将引用对象改为值对象　　Replace Array with Object 用对象代替数组　　Duplicate Observed Data 重复被观察数据　　*Change Unidirectional Associationto Bidirectional 将单向关联改为双向 Change Bidirectional Association to Unidirectional 将双向关联改为单向 *Replace Magic Number with Symbolic Constant 用字面常量代替魔数　　Encapsulate Field 封装字段　　Encapsulate Collection 封装集合　　Replace Record with Data Class 用数据类代替记录　　*ReplaceType Code with Class 用类代替类型码　　Replace Type Code with Subclasses 用子类代替类型码　　Replace Type Code with State/Strategy用State/Strategy 代替类型码　　Replace Subclass with Fields 用字段代替子类　Chapter 9：Simplifying Conditional Expressions 简化条件语句　　Decompose Conditional 分解条件语句　　Consolidate Conditional Expression 合并条件语句　　Consolidate Duplicate Conditional Fragments 合并重复的条件片段　　Remove Control Flag 去除控制标志　　Replace Nested Conditional with Guard Clauses 用守卫语句代替嵌套条件语句　　Replace Conditional with Polymorphism 用多态代替条件语句　　Introduce Null Object 引入Null对象　　Introduce Assertion 引入断言　Chapter 10：Making Method Calls Simpler 简化方法调用　　Rename Method 重命名方法　　Add Parameter 添加参数　　Remove Parameter 去除参数　　Separate query from Modifier 将查询方法与修改方法分离　　Parameterize Method 参数化方法　　Replace Parameter with Explicit Methods 用显式方法代替参数　Preserve Whole Object 保持对象完整　　Replace Parameter with Method 用方法代替参数　　Introduce Parameter Object 引入参数对象　　Remove Setting Method 去除设置方法　　Hide Method 隐藏方法　　Replace Constructor with Factory Method 用工厂方法代替构造器 Encapsulate Downcast 封装向下转型　　Replace Error Code with Exception 用异常代替错误码　　Replace Exception with Test 用测试代替异常　Chapter 11：Dealing with Generalization 处理泛化关系　　Pull Up Field 上移字段　　Pull UP Method 上移方法　　Pull Up Constructor Body 上移构造器主体　　Push Down Method 下移方法　　Push Down Field 下移字段　　Extract Subclass 提取子类　　Extract Superclass 提取超类　　Extract Interface 提取接口　　Collapse Hierarchy 合并继承层次　　Form Template Method 形成Template Method　　Replace Inheritance with Delegation 用委托代替继承　　Replace Delegation with Inheritance 用继承代替委托　Chapter 12：Big Refactorings(by Kent Beck and Martin Fowler) 大型重构 Tease Apart Inheritance 分解继承层次　　Convert Procedural Design to Objects 将过程式设计转换为面向对象　　Separate Domain from Presentation 将领域逻辑与表现分离　　Extract Hierarchy 提取继承层次　Chapter 13：Refactoring，Reuse，and Reality(by William Opdyke) 重构，复用与现实　　A Reality Check 现实的检验　　Whv Are Developers Reluctant to Refactor Their Programs？ 开发人员为何不愿重构程序　　A Reality Check(Revisited) 再谈现实的检验　　Resources and References for Refactoring 重构的资源和参考文献　　Implications Regarding Software Reuse and Technology Transfer 对软件复用与技术传播的意义　　A Final Note 结语　　References 参考文献　Chapter 14：Refactoring Tools(by Don Roberts and John Brant) 重构工具　　Refactoring with a Tool 使用工具重构　　Technical Criteria for a Refactoring Tool 重构工具的技术标准　　Practical Criteria for a Refactoring Tool 重构工具的实用标准　　Wrap Up 结语　Chapter 15：Putting It All Together(by Kent Beck) 集大成　References参考文献　List of Soundbites 要点列表　Updates 更新内容　Index 索引点击此处查看更多内容。

13
XP - Design




Follows the KIS (keep it simple) principle Encourage the use of CRC (classresponsibility-collaborator) cards (Chapter 8) For difficult design problems, suggests the creation of ―spike solutions‖—a design prototype Encourages ―refactoring‖—an iterative refinement of the internal program design Design occurs both before and after coding commences

7
The Politics of Agile Development
There is considerable debate about the benefits and applicability of agile software development No one is against agility. The real question is:
– – – – Planning Design Coding Testing
11
Extreme Programming (XP) - 2
user stories values acceptance test criteria iteration plan
simple design CRC cards spike solutions prototypes

关于软件测试的外国文献软件测试是软件开发过程中至关重要的一环，而外国文献中关于软件测试的研究和实践也非常丰富。

下面我将从不同角度介绍一些相关的外国文献，以便更全面地了解软件测试的最新发展。

1. "Software Testing Techniques" by Boris Beizer:这本经典著作详细介绍了软件测试的各种技术和方法，包括黑盒测试、白盒测试、基于模型的测试等。

它提供了许多实用的指导和案例，对软件测试的理论和实践都有很深入的探讨。

2. "Testing Computer Software" by Cem Kaner, Jack Falk, and Hung Q. Nguyen:这本书介绍了软件测试的基础知识和常用技术，包括测试计划的编写、测试用例设计、缺陷管理等。

它强调了测试的全过程管理和质量保证，对于软件测试初学者来说是一本很好的入门指南。

3. "The Art of Software Testing" by Glenford J. Myers, Corey Sandler, and Tom Badgett:这本书从理论和实践的角度探讨了软件测试的艺术。

它介绍了测试的基本原则和策略，以及如何设计有效的测试用例和评估测试覆盖率。

这本书对于提高测试人员的思维和技巧非常有帮助。

4. "Foundations of Software Testing" by Aditya P. Mathur:这本书系统地介绍了软件测试的基本概念、技术和方法。

它涵盖了测试过程的各个阶段，包括需求分析、测试设计、执行和评估。

这本书还提供了丰富的案例和练习，帮助读者深入理解和应用软件测试的原理和技术。

5. "Software Testing: Principles and Practices" by Srinivasan Desikan and Gopalaswamy Ramesh:这本书介绍了软件测试的原则、实践和工具。

程序员所做的测试工作并非真正意义上的软件测试，从本质上来说，应该称作“调试“。

调试就是，在已知错误的情况下，对软件程序代码作出一系列检查，校正的过程。

而软件测试则是在未知错误的情况下，检查程序代码是否有问题的过程。

1。

2.2 软件测试的定义a。

软件是一个集合，包括三部分:程序代码,文档，数据。

b。

软件测试就是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程，其目的在于在软件交付使用前充分发现缺陷并协助相关部门定位、解决缺陷，最后交付一个高质量的软件给用户.c。

从广义上讲，软件测试是指软件产品生存周期内的所有检查、评审和确认活动。

如设计评审、文档审查、单元测试、集成测试、系统测试、验收测试等。

d。

软件测试中称找缺陷的过程为找Bug.Bug表示电脑系统或程序中隐藏的错误、缺陷和问题.一切不完美的地方，我们都可以认为其实一个Bug。

1。

2。

3 软件测试分类(1）一般的，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手动测试、自动测试等。

1)黑盒测试黑盒测试又叫做功能测试、数据驱动测试或基于需求规格说明书的功能测试。

该测试类型注重于测试软件的功能性需求。

测试工程师无需了解程序代码内部结构，完全模拟软件产品的最终用户使用该软件,检查软件产品是否达到了用户的需求。

2）白盒测试白盒测试又称为结构测试、逻辑驱动测试或基于程序代码内部构成的测试.测试工程师将深入考察程序代码的内部结构，逻辑设计等。

3）灰盒测试灰盒测试是前两种测试的集合,一方面考虑程序代码的功能性表现,另一方面又要考虑程序代码内部结构。

像我们的功能测试，自动化功能测试就采用了灰盒测试的方法。

4)静态测试静态测试，顾名思义，就是静态的、不执行被测对象程序代码而寻找缺陷的过程。

通俗的讲,静态测试就是用眼睛看，阅读程序代码、文档资料等，与需求规格说明书中的客户需求进行比较，找出程序代码中设计不合理以及文档资料有错误的地方。

Develop an Overall Model
Build Feature List
Plan By Feature
Design By Feature
Build By Feature
Test Finished Code Build Cycle
Bug Reports
FDD Milestones & EV
Lead Tim e Control Chart
16 14 12 10
Time
Inventory Started Designed Coded Complete
But…
WIP Introduction Rate Chart 35 30 25 20 15 10 5 0
M ar M ar 2M 9M -F -F -F
8 6 4 2 0
17 0 11 0
ar
Calendar Days
Features
ar
ar
Fe
Fe
Fe
ar
ar
M
M
M
M
16 -
17 -
10 -
24 -
23 -
30 -
2-
9-
M
WIP Inv entory Control Chart
M ar
ar
eb
eb
eb
ar
100 90 80 70 60 50 40 30 20 10 0
240 220 200 180 160 140 120 100 80 60 40 20 0
eb eb eb 10 -F 17 -F 24 -F
Features
Lead Time WIP
2M ar 9M ar 16 -M ar 23 -M ar 30 -M ar

优势
快速反馈
灵活应对变化
极限编程强调通过频繁的评审和修改来快 速获取反馈，有助于及时发现问题并进行 调整。
极限编程鼓励拥抱变化，能够快速适应需 求变更，减少因需求变动带来的损失。
简化开发过程
提高团队沟通
极限编程提倡简单的设计和开发原则，降 低复杂度，提高开发效率。
极限编程注重团队之间的沟通与协作，有 助于提高团队的凝聚力和工作效率。
设计游戏的玩法和机制，确保 游戏具有吸引力和可玩性。
游戏资源规划
合理分配游戏开发资源，确保 游戏开发的顺利进行。
简单设计
01
设计原则
以简单、清晰的设计实现游戏功能 和用户体验。
游戏界面设计
设计游戏的用户界面，包括菜单、 界面布局和交互方式等。
03
02
游戏架构设计
设计游戏的整体架构，包括游戏系 统、模块和数据结构等。
它遵循一系列原则，如“一 次只做一件事”、“先写测 试后写代码”和“及时重构
”。
这些原则旨在帮助开发团队更 好地应对变化，提高软件质量 ，并促进团队成员之间的协作
和信任。
02 极限编程的实践
需求管理
需求管理原则
明确、可测试、可跟踪的需求是项目成功的 关键。
需求获取
通过与客户的沟通，了解他们的需求和期望 。
挑战
技术风险
由于追求快速迭代和变化，可能导致技术债务的积累，影响软件质量。
人力资源
对团队成员的技能和经验要求较高，需要具备快速学习和适应变化的能力。
需求稳定性
频繁的需求变更可能影响开发进度和稳定性，对项目管理带来挑战。
过度优化
在追求简化开发过程和快速反馈时，可能导致过度优化和过早优化的问题。

4.3.7 放大.............. 54 4.3.8 公共 API 中的 Javadoc............ 55 4.4 坏注释......... 55
4.4.1 4.4.2 4.4.3 4.4.4 4.4.5
喃喃自语 55 多余的注释....................................... 56 误导性注释....................................... 58
3.13 小结............. 45 3.14 SetupTeardownIncluder 程序......... 46 3.15 文献............. 48 第 4 章 注释.................. 49 4.1 注释不能美化糟糕的代码.................. 50 4.2 用代码来阐述....... 51
3.6.2 标识参数 38
3.6.3 二元函数 38
3.6.4 三元函数 39
3.6.5 参数对象 39
3.6.6 参数列表 40 3.6.7 动词与关键字................................ 40 3.7 无副作用.. 40
3.8 分隔指令与询问 42 3.9 使用异常替代返回错误码.................. 42
1.9 文献 13 . …………………………………………………………………………………………………………………………………………………………………………. 第 2 章 有意义的命名………………………………………………………………………………………………………………………………………………..15 2.1 介绍 15 ……………………………………………………………………………………………………………………………………………………………………………. 2.2 名副其实……………………………………………………………………………………………………………………………………………………………………16 2.3 避免误导……………………………………………………………………………………………………………………………………………………………………17 2.4 做有意义的区分 18 …………………………………………………………………………………………………………………………………………………..

•
•
户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收
钱就完事儿。 把人的能动性调动起来，给动力而不是给压力。 要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不 是盲目机械地实施规范。
•
• •
没有绝对的权威，每个人都有可取之处。
误区三：敏捷是反文档的
• 文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。
Scrum流程图
如何进行Scrum开发？
1、确定Product Backlog（按优先顺序排列的一个产品需求列表）：这是由Product Owner 负责的 Scrum Team根据Product Backlog列表，做工作量的预估和安排； 2、 Sprint Backlog：通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story 作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一 个Sprint Backlog；每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2 天内能完成） 3、Daily Scrum Meeting（每日站立会议）：每次站立会议控制在15分钟左右，每个人都必须发言 ，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到 不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（ Sprint燃尽图）； 4、每日集成：也就是每天都要有一个可以成功编译、并且可以演示的版本；支持每次有成员进行签 入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测 试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存，中间有任何失败，都 会用邮件通知项目管理人员； 5、 Srpint Review Meeting（演示会议）：当一个Story完成，也就是Sprint Backlog被完成，这 时要进行评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的 成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）； 6、Sprint Retrospective Meeting（回顾会议）：也称为总结会议，以轮流发言方式进行，每个人 都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

– Feedback from the system: by writing unit tests,or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
The values of XP : 2. Simplicity
• Proponents 支持者 of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system;
• their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant.
AM is intended to be a collection of values, principles, and practices for Modeling software that can be applied on a software development project in a more flexible manner than traditional Modeling methods. AM is a kind of attitude, not a prescriptive process. AM describes a style of modeling, when used properly in agile environment, that results in better quality software and faster development while avoiding over-simplification and unrealistic expectations.

统稿说明：1)本大纲是在ISTQB的初级大纲的框架下，根据中国的实际情况作了适当的修改和调整，调整和修改的幅度符合ISTQB的规定要求。

2)本次的全面统稿是在各位专家修改意见的基础上进行的。

因为各位专家是分工、分章节对大纲进行修改的，故在很多方面没有考虑到大纲的整体连贯性和表达上的一致性，这次统稿从大纲的整体一致性、连贯性及表达方式等方面作了全面把握，修改的地方比较多，对部分不恰当的内容作了删除，也增加了一些内容。

3)由于各位专家在修改时对第五、第六、第七章的内容没作修改，因为这三个章节是根据中国的测试现状调整的部分，没有原稿基础。

在本次统稿过程中进行了全面充实。

4)由于时间紧，加之能力有限，统稿后的大纲中会有不足之处希望大家不吝赐教，我将根据大家的合理意见及时修改。

5)大纲在正式出版前还将进行版面、标点符号等方面的全面修改和完善，到时再通报大家。

CSTQB软件测试初级认证大纲2007 版ISTQB将本书授权给中国软件测试认证委员会（CSTQB）。

本大纲作者（当前的版权所有者,包括中国版修订者）和CSTQB一致同意下面的使用条款：1.本大纲的作者和CSTQB作为本大纲的原始发起者和版权拥有者，并具备在ISTQB认可的国家认证委员会(在中国为CSTQB)官方授权的前提下，个人或培训公司才可以基于本课程大纲开发并使用培训教程。

2.在大纲的作者和CSTQB作为本大纲的原始发起者和版权拥有者认可的前提下, 个人或个人团体可以使用本课程大纲作为文章、书籍或其它资料的参考文献或者主要理论依据。

3.任何ISTQB认可的国家认证委员会可以翻译本课程大纲，同时将本课程大纲（或翻译后的版本）授权给其它组织。

目录1. 软件测试基础（K2） 155分钟 (10)1.1 为什么需要测试 (K2) (10)1.2 什么是测试 (K2) (10)1.3 测试的基本原则 (K2) (10)1.4 基本的测试过程 (K1) (10)1.5 测试的心理学 (K2) (11)2. 软件生命周期中的测试（K2）135分钟 (24)2.1 软件开发模型 (K2) (24)2.2 测试级别(K2) (24)2.3 测试类型(K2) (24)2.4 维护测试 (K2) (25)3. 静态技术（K2） 60分钟 (36)3.1 评审和测试过程（K2） (36)3.2 评审过程（K2） (36)3.3 静态分析的工具支持（K2） (36)4. 测试设计技术（K3）255分钟 (44)4.1 识别测试环境和设计测试用例（K3） (44)4.2 测试设计技术的种类（K2） (44)4.3 基于规格说明的或黒盒测试技术（K3） (45)4.4 基于结构的或白盒测试技术（K3） (45)4.5 基于经验的技术（K2） (45)4.6 选择测试技术（K2） (46)5.传统的结构化软件测试（K3）180分钟 (57)5.1.结构化软件的单元测试(组件测试)（K3） (57)5.2.结构化软件的集成测试(K3) (57)5.3.结构化软件的系统测试(K3) (57)6. 面向对象的软件测试（K3） 150分钟 (61)6.1.面向对象的单元测试(K3) (61)6.2.面向对象的集成测试(K3) (61)6.3.面向对象的系统测试(K3) (61)7.基于GUI的软件测试（K2）120分钟 (65)7.1 GUI测试概述(K1) (65)7.2 GUI测试内容(K3) (65)7.3 GUI测试技术 (K2) (66)8. 测试管理（K3） 180分钟 (69)8.1 测试的组织结构（K2） (69)8.2 测计划划和估算（K2） (69)8.3 测试进度监测（K2） (69)8.4 配置管理（K2） (70)8.5 风险和测试（K2） (70)8.6 缺陷管理（K3） (70)9. 软件测试工具（K2） 80分钟 (84)9.1 测试工具的类型（K2） (84)9.2 高效率使用工具：潜在的利益和风险（K2） (84)9.3 组织中工具的引入（K1） (84)10．参考文献 (95)附录A――课程大纲背景 (97)附录B――学习目标和知识级别 (100)附录C――ISTQB初级课程大纲的规定 (102)附录D――培训机构注意事项 (104)致谢本大纲是在国际软件测试认证委员会初级课程大纲的框架下，按照规定的要求结合中国的实际情况编写。

拥抱变化、快速响应、平等协作、持续改进-- PMI-ACP敏捷项目管理与创新之道Copyright by Bruce Yu (于兆鹏)作者简介：大中华区唯一持有PMI-PBA（商业分析）、PMI-ACP（敏捷）、PMP（项目管理）、PgMP（项目集管理）四个认证的项目管理专家，2013年中国十大优秀项目管理培训师，2011年中国知识管理人物，PMI(中国) PgMP(项目集管理)Community Lead，PMI(中国) 上海项目管理社区导师，原上海惠普KM Manager、PMO Lead，原携程知识管理中心总监、项目管理委员会主任随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。

人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。

不仅仅是互联网让我们在变！随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着：----以生产为核心到以需求为核心的转变----以商户为核心到以用户为核心的转变----以产品功能为核心到产品体验和个性为核心的转变中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。

在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。

一句话，正如彼得•德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。

在新的商业模式下，作为项目经理的我们需要关注：----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化；----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点；----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器；----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢；----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环；对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。

Ward Cunningham, quoted on p11 of “Clean Code” by Bob Martin
JavaSolutions.se
11
Kent Beck
Rules for simple design: 1. Appropriate for the intended audience 2. Every idea communicated 3. Factored. (no duplication) 4. Minimal. (fewest elements)
www.jsolutions.se
Join or Start a Dojo
●
There are coding dojos all over the world. Why don't you go along to one and see if you can teach or learn something?
see
• The dojo is the place where you go every week to practice and learn karate. • At XP2005, Laurent Bossavit and Emmanuel Gaillot presented “The Coders Dojo” • Their dojo continues to meet weekly in Paris.
www.jsolutions.se
Tests and Legacy Code
●
How to unit test spaghetti?
The unit I want to test
www.jsolutions.se

软件测试中的行为驱动开发（BDD）软件测试在现代软件开发中扮演着至关重要的角色。

为了确保软件的质量和稳定性，测试人员必须致力于寻找和修复潜在的缺陷和问题。

而在软件测试领域中，行为驱动开发（BDD）被广泛应用，以提高测试的效率和可读性。

BDD是一种敏捷开发方法，其目标是通过明确描述软件的预期行为来减少团队成员之间的沟通障碍，并将这些行为转化为实际的测试步骤。

BDD强调测试用例应该易于理解和使用，并侧重于描述系统行为的场景，而不仅仅是验证代码的正确性。

在BDD中，测试用例通常采用一种称为“给定-当-那么”（Given-When-Then）的格式。

这种格式使得测试用例的目的和期望结果变得清晰明了。

“给定”阐述了测试执行前的预置条件和前提条件。

“当”描述了要执行的具体操作或事件。

“那么”用于描述期望的结果或系统的行为。

举个例子，假设我们正在测试一个登录功能。

一个BDD风格的测试用例可以如下所示：给定用户已经注册并拥有有效的用户名和密码当用户输入正确的登录凭证那么系统应该登录用户，并显示用户的个人信息通过使用BDD的测试方法，开发团队可以更好地理解业务需求和预期行为，从而编写出更全面、可读性更高的测试用例。

此外，BDD还提供了一种称为“行为规范（Specifications by Example）”的方法，该方法通过实际的例子来描述系统的行为。

行为规范是一种自然语言的描述，用于定义如何以某种方式操作系统，以及系统应该如何响应。

行为规范的格式通常如下所示：场景：用户登录- 给定用户已经注册并拥有有效的用户名和密码- 当用户输入正确的登录凭证- 那么系统应该登录用户，并显示用户的个人信息通过使用行为规范，测试人员可以与团队成员一起制定一份清晰的文档，以便大家能够理解系统的行为，并在开发过程中进行验证和对照。

这有助于提高软件质量和开发效率。

除了上述的格式和方法，BDD还强调团队合作和积极参与的重要性。

开发人员、测试人员和业务专家应该携手合作，以确保测试过程的成功。

JUnit起步JUnit jumpstart本章内容■手工编写简单测试■安装JUnit以及运行测试■使用JUnit编写更好的测试4第1章JUnit起步Never in the field of software development was so much owed by so many to so few lines of code.软件开发领域中此前从未有过这样的事情：很少几行代码对大量的代码起了重要的作用。

—— Martin Fowler 所有的代码都是通过测试的。

在开发中，我们所做的第一件事是运行我们程序员自己的“验收测试”。

编码，编译，然后运行。

在运行时，我们也在测试。

“测试”可能只是点击一个按钮，看是否会弹出期待的菜单。

但是，不管怎么说，每天我们都在编码，编译，运行，并且测试。

在测试的时候，我们常常会发现问题，特别是在第一次运行的时候。

所以我们再次编码，编译，运行，测试。

我们中的大多数人很快都会形成一种非正式的测试模式：增加记录，查看记录，编辑记录，删除记录。

手工运行这样的小测试集很简单，于是我们就手工做了。

一遍又一遍地做。

有些程序员喜欢做这类重复的事情。

在深入的思索和艰难的编码之后，能做些简单的重复事情是一种愉快的放松。

而且当我们小小的“鼠标点击测试”最后获得成功，我们真切地获得了成就感：Oh yeah，我搞定它了！还有些程序员则不喜欢这种重复工作。

他们宁愿编写一个小程序来自动运行测试，也不愿意手工测试。

运行自动测试和编写测试代码是两码事。

如果你属于编写测试代码的这类开发者，那么本书就是为你所写的。

我们将告诉你，编写自动测试是如何地简单、高效并有趣！如果你已经陷入了测试的困境，那么本书也是为你而写的！我们在第1部分介绍了基础知识，然后就在第2和第3部分中开始探讨现实测试中的困难问题。

1.1 证实它能运作有些开发者觉得自动测试是开发过程的重要部分。

一个组件除非通过了一系列彻底的测试，否则就无从证实它能运作。

behavior-driven development
行为驱动开发（BDD）是一种软件开发方法论，旨在通过明确的业务行为描述和自动化测试来促进团队合作、代码质量和软件交付价值。

BDD强调开发人员、测试人员和业务利益相关者之间的沟通和协作，以实现更高效、可维护和可理解的软件开发过程。

BDD的核心原则包括关注行为、跨角色协作和自动化测试。

它鼓励将关注点放在软件系统的行为上，而不是仅仅实现功能。

通过定义系统的行为，BDD有助于消除业务人员和技术人员之间的分歧，并建立一个共同的理解。

此外，BDD强调跨角色的协作，鼓励团队成员共同参与，以实现更高效的开发和更好的质量保证。

最后，BDD利用自动化测试来确保软件的行为符合预期，从而提高开发效率和软件质量。

BDD的主要步骤包括明确业务目标、定义行为、编写验收条件和自动化测试。

首先，团队需要明确业务目标，并确定需要实现的业务行为。

然后，通过使用自然语言和具体示例来描述这些行为，团队可以共同理解并确定验收条件。

最后，团队将编写自动化测试来验证这些行为是否得到满足。

BDD与测试驱动开发（TDD）的关系在于它们都重视自动化测试，但BDD更关注行为和业务需求，而TDD则更关注代码实现。

BDD可以看作是TDD的扩展和改进，它将测试作为开发过程中的重要组成部
分，并将其与业务需求紧密结合。

总的来说，BDD是一种注重行为和业务需求的软件开发方法论，它通过明确的描述和自动化测试来提高开发效率和软件质量。

通过跨角色协作和自动化测试，BDD可以帮助团队更好地理解需求、减少歧义和提高工作效率。