高绩效Scrum团队的4个特征

作者:Bill Li 李国彪

最近的课程碰到了很多ScrumMaster和Product Owner对于打造高效能团队(效率和效果并重)的困惑和疑问,这也促发我们对这个问题再次的关注、思考及总结。简而言之,我们觉得团队的打造方向就是四个重点特征:纪律性;主动性;合作性;创新性

Read More

Docker初探

工作步骤

Docker所用的虚拟镜像的基线版本都是Ubuntu系统。
当运行docker run xxx之后,

  1. Docker客户端连接到Docker守护进程
  2. 如果本地没找到xxx镜像的话,Docker守护进程就从Docker Hub仓库中拉下(pull) xxx镜像
  3. Docker守护进程根据xxx镜像创建一个新的容器(container), 从其中来执行程序并产生输出内容
  4. Docker守护进程将输出内容流到(stream)Docker客户端,然后发送到终端

常用命令

官网入门教程的几个常用命令

docker version
docker search tutorial
docker pull learn/tutorial
docker run learn/tutorial echo "hello world"
docker run learn/tutorial apt-get install -y ping
docker ps -l
docker commit 698 learn/ping
docker run learn/ping ping google.com
docker ps
docker inspect efe
docker images
docker push learn/ping

Read More

在Windows上采用IIS来运行Django

给客户做一个内部软件项目,客户愿意配合敏捷、精益创业的思维,快速交付之后再不断通过用户反馈来调整。
于是就采用基于Python语言v2.7的Django框架V1.4来进行开发。
花了些日子,初具雏形。双方约定先部署,让内部员工开始试用。然后客户把目标服务器交给我了。

Django对Apache或Nginx的支持会方便些(http://www.jackyshen.com/2012/08/12/running-django-gunicorn-via-nginx/)。可是,这是一台带有公网IP的托管的Windows Server2003。上面运行有IIS 6.0,并且已经有另外两个web应用在运行。为了尽量能不影响原有应用,就考虑尝试一下在Windows上采用IIS来运行Django。

于是google一把,结果发现了PyISAPIe…

Read More

精益软件开发的七种浪费

取自Shigeo Shingo的丰田精益制造。与制造业进行对比,是因为比起想象一个软件,我们更容易想象制造一辆汽车。

制造 软件开发
在制品库存 部分完成的工作
过度生产 额外功能
额外的过程 重复学习和手工动作
运输 任务交接
移动 人员任务切换
等待 延迟
缺陷 缺陷

Read More

SVN pre-commit hook

某团队希望做到Continuous Code Review, 想在每次check-in 到SVN之前,先判断特定用户群体否在commit log里面包含了”Review By: xxx”的字样。

记得以前NSN里面有人用过这个法子,记不太清了。

于是研究了一下脚本,其实SVN/GIT都提供了类似的hook, 在<your repository>/hooks 目录下,都是shell或cmd脚本(要看服务器的操作系统了),会在不同的事件时触发。

为了实现更复杂的功能或者需要跨平台,那不妨用shell或cmd去调用Python脚本咯。

Read More

网球的内心游戏--敏捷教练技术起源必读

The inner game of tennis
《网球的内心游戏》

原著:W.Timothy Gallwey (美国)

导言

每种游戏或活动都包含两个部分,外在的和内在的。外在的或表面的游戏就是和外在的对手进行对抗,并超越外在的障碍,达到一个外在的目标。以网球这种游戏为例,外在的障碍就是为战胜对手必须尽量将每个球打出好的落点和速度,同时减少失误,这样才可能取得比赛的胜利甚至赢得最后的冠军。对于掌握这种外在的游戏,很多书都提供了不少的指示:比如如何引拍,挥拍,随挥。以及眼睛、头、手腕、小臂、大臂、肩、腰、腿、髋,等等甚至脚尖各自该怎么做才能达到最佳的效果。但事实上,我们当中很多人都发现这些指令说起来容易,做起来难。

(好比学跳舞,最有效的学习方式是观察人家如何跳,然后跟着音乐去找那个感觉,第一次可能脚出错了,不要紧,慢慢地你就找到那个感觉了,先是脚的顺序对了,手也跟着动了,胯也跟着动了,接下来,就是多跳,然后熟能生美了。很少有人去看示意图,先左脚45度跨一步出去,然后右脚如何如何,这个习得过程我们基本不思考,只是用我们的身体去感知和模仿别人的身体,意识很淡,基本不用意识去指挥,音乐一响,身体自动地动就行了。译者注)

这本书想要说的是,在尝试掌握任何技能的过程中,只是重视这些外部的指令,而忽视相关的内在技能习得规律,是不可能取得满意的效果的。内在的技能习得规律我们这里暂时称为内心游戏。这种游戏发生在球员的内心,内心游戏所面对的对手是自己,障碍表现的形式是,专注力的失去,过度的紧张,不自信,习惯性自责等。简言之,就是要战胜所有妨碍我们”正常”表现的负面心理习惯。

Read More

learning-go-lang

安装

由于墙,http://golang.org 国内无法访问,其它在线教程也一样
http://tutorial.golang.org
http://go-tour-zh.appspot.com/

可以在本机运行,
先安装Go 编译器 http://code.google.com/p/go/downloads/list

然后安装教程

1
go get code.google.com/p/go-tour/gotour  

或者中文的

1
go get bitbucket.org/mikespook/go-tour-zh/gotour  

最后执行安装产生的 gotour 执行文件,即可在http://localhost:3999 打开教程。
一些练习的答案

##46 练习:斐波纳契闭包

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import "fmt"  

// fibonacci 函数会返回一个返回 int 的函数。
func fibonacci() func() int {
var a int = 1
var b int = 1

return func() int {
c := a+b
a = b
b = c
return c
}
}

func main() {
f := fibonacci()
for i := 0; i < 10; i++ {
fmt.Println(f())
}
}

##69 练习:等价二叉树

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package main  

import (
"bitbucket.org/mikespook/go-tour-zh/tree"
"fmt"
)

type Tree struct {
Left *Tree
Value int
Right *Tree
}

// Walk 步进 tree t 将所有的值从 tree 发送到 channel ch。
func Walk(t *tree.Tree, ch chan int) {
if t != nil {
Walk(t.Left, ch)
ch <- t.Value
Walk(t.Right, ch)
}
}

// Same 检测树 t1 和 t2 是否含有相同的值。
func Same(t1, t2 *tree.Tree) bool {
ch1 := make(chan int, 10)
go Walk(t1, ch1)

ch2 := make(chan int, 10)
go Walk(t2, ch2)

for i := 0; i < 10; i++ {
if <-ch1 != <-ch2 {
return false
}
}
return true
}

func main() {
fmt.Println(Same(tree.New(1), tree.New(1)))
}

##57 练习:错误处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
package main  

import (
"fmt"
)


type ErrNegativeSqrt float64

func (e ErrNegativeSqrt) Error() string {
return fmt.Sprintf("cannot Sqrt negative number: %f", e)
}

func Sqrt(f float64) (float64, error) {

if f < 0 {
return 0, ErrNegativeSqrt(f)
}

x := f
for i := 0; i < 10; i++ {
x = (x + f/x) / 2
}
return x, nil



}

func main() {
fmt.Println(Sqrt(2))
fmt.Println(Sqrt(-2))
}

##44 练习:Map

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package main  

import (
//"fmt"
"strings"
"bitbucket.org/mikespook/go-tour-zh/wc"
)

func WordCount(s string) map[string]int {
result := map[string]int {}
f := strings.Fields(s)
for _, v := range f {
result[v] += 1
}
return result
}

func main() {
wc.Test(WordCount)
}

JavaScript创始人Brendan Eich:我们不需要Native Client

Native Client 是Google支持的开源技术,用来在浏览器中像桌面程序一样运行编译过的代码,满足人们对web应用程序的可移植性和安全性的期望,提供更好的富客户端用户体验,允许开发者编写更强大的移动Web应用程序。
JavaScript创始人Brendan Eich上个月在旧金山召开的O’Reilly Fluent ConfereNative Cliente大会上解释说JavaScript足以满足Google对Native Client的设计目的,并怀疑Native Client是否能够像JavaScript一样,得到浏览器厂商的广泛支持

Read More

如何选择自动化测试框架

如何选择自动化测试框架

软件自动化测试,作为手工测试的替代,越来越受到关注。Pekka Klärck,作为Robot Framework的创建者和核心开发者,按照系统级别,介绍了几种不同的自动化测试方法的区别

五种自动化测试方法

  1. 记录回放的方式流行于商业工具之中,无需编程技能即可快速上手。然而这种方法相对脆弱,一旦UI变化测试就会受到影响,分散的脚本不可重用且难以维护,而且系统在测试前必须可用(也就意味着无法使用A-TDD方法)。因此这种方法并不适合大型自动化测试。

  2. 线性脚本允许使用各种语言来编写非结构化脚本,脚本直接与被测系统交互。能够快速上手,灵活性强。但是编写脚本需要编程技能,系统中一个改动会影响所有脚本,没有经过模块化或重用的大量脚本难以维护。因此这种方法适合简单任务,不适合大型自动化。

  3. 模块化脚本由两部分组成:驱动脚本执行测试,测试库函数完成与被测系统交互。驱动脚本编写起来非常简单,这样可以更快地建立新测试,容易维护。然而需要花时间和编程技能建立测试库,并将测试数据嵌入脚本,建立新测试就需要新的测试脚本。因此,只要拥有编程技能,这种方法还是适合大型项目,但不适合非编程人员。

  4. 数据驱动方法,将数据与测试脚本分离,基于模块化的测试库,一个驱动脚本可以执行多个相似测试,这样非常容易建立新测试。维护工作可以分离,测试人员负责数据,程序员负责写测试库。然而,不同类型测试仍需要新的驱动脚本,初始建立数据解析器和重用组件需要花人力。这种方法适合大型项目,只需要较少的编程技能。

  5. 关键字驱动,将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势,同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行,无需不同的驱动脚本。然而初始成本很大,但是可以使用开源方案!因此非常适合大型项目。

Pekka对以上五种方法的介绍其实也是对自动化测试发展史的介绍,同时也体现了RobotFramework背后的设计思想。

除了测试框架的选择,要想做好自动化测试,还要关注其他方面。

自动化测试需要关注可测性。自动化最难的部分是与被测系统交互,特别是GUI层。确保系统容易被测试,比如给GUI元素增加标识、输出易于解析的文本、提供自动化接口等。

系统一般可以分为GUI层以及GUI之下的业务层。GUI层测试需要调用与普通用户同样的接口,但是某些GUI技术缺乏好的工具支持,会使测试变得脆弱,而且执行相对较慢。从业务层开始测试相对容易,执行快。但GUI层仍然需要被测试,以保证GUI正确连接到了业务层,甚至有时GUI层也具有业务功能。Pekka建议考虑对业务层进行完全测试,而部分地对GUI层实行端到端测试。 不是所有系统都具有GUI层,却可能具有API、数据库、服务器、命令行等。自动化测试框架可以调用不同驱动来进行测试。这些非GUI层相对容易测试,只要把测试用例看作另一个客户端而已。

那么自动化测试应该在什么阶段进行?如果开发完成后单独做自动化,这是典型的瀑布式过程,不同团队之间存在沟通障碍,反馈周期慢,产品在后期难以获得可测性,从而导致复杂和脆弱的测试方案。相反,典型敏捷式过程中,程序员和测试人员协同完成自动化。把自动化看作团队开发的一部分,可测性不再是问题,团队做技术决定时就可以考虑可测性和工具选择,程序员可以提前加入提供可测性的钩子特性。

自动化测试需要版本控制持续集成来支持。将测试和代码放在一起,像管理代码一样管理测试脚本,那么多可用工具,SVN、GIT、Mercurial,没道理不用。持续集成是全方位自动化的关键,当测试或代码有所改动立即执行测试。如果测试运行时间比较长,也可以定期运行。使用Jenkins、Hudson、Cruise Control、 BuildBot吧,自己写定时脚本或Cron Job可以休矣。

选择商业自动化工具还是开源工具?

好东西肯定贵,但是贵的不见得好,再便宜的许可证也会阻止整个团队的协作。而且商业化工具难以和其他自动化工具(特别是其他厂商的)或版本控制、持续集成进行整合和定制化。另外,产品终止或公司关门是潜在的风险。开源工具可供选择余地很大,当然也是良莠不齐。开源工具通常容易与其他工具整合,关键是免费,谁都可以随意使用和定制化,还永远不会消失。至于免费软件,越来越少了,很多自由软件都已经开源。免费软件同样不能定制化,且存在中止的风险。

做自动化需要哪些技能?

一般来说,包括Python、Ruby、Perl、JavaScript、正则表达式、XPath和CSS定位、SQL语句、版本控制等。

有了自动化,手工测试还需要吗?

当然需要!! 不过,要避免手工执行脚本来测试,还是将其完全自动化吧,测试人员可以更多关注于探索性测试。 记住,机器擅长回归测试,人类善于寻找Bug。

后记

本文作者 @申导 自2007年开始在诺基亚西门子内部接触到RobotFramework工具,在团队管理和一线开发的时候,一直坚持和推荐RF工具至今,尤其是基于RF的ATDD/BDD团队协作实践,在敏捷团队中取得良好收益,并形成了一套完成的培训体系。欢迎交流经验。