博客园_Don't think you are, know you are

测试策略的两个终极问题

2012-01-31T08:26:00Z

测试的本质就是模拟用户的行为，首先要了解产品，分为positive 测试 negetive 测试，这似乎没有什么好说的。

测试的配置管理就是两个：测试用例管理和缺陷管理

关于测试策略，这是重点，其中我概括的两个终极问题为

1，测试能在何时（那个阶段）、何地（那个层次）参与？

2，如何保证测试的有效性（测试的质量与最终发布的质量的一致，这涉及到regression， code freeze ， sanity check）。

本文链接

Eclipse Hot key

2012-01-18T15:57:00Z

Eclipse快捷键大全(转载)

Ctrl+1 快速修复(最经典的快捷键,就不用多说了)
Ctrl+D: 删除当前行
Ctrl+Alt+↓ 复制当前行到下一行(复制增加)
Ctrl+Alt+↑ 复制当前行到上一行(复制增加)
Alt+↓ 当前行和下面一行交互位置(特别实用,可以省去先剪切,再粘贴了)
Alt+↑ 当前行和上面一行交互位置(同上)
Alt+← 前一个编辑的页面
Alt+→ 下一个编辑的页面(当然是针对上面那条来说了)
Alt+Enter 显示当前选择资源(工程,or 文件 or文件)的属性
Shift+Enter 在当前行的下一行插入空行(这时鼠标可以在当前行的任一位置,不一定是最后)
Shift+Ctrl+Enter 在当前行插入空行(原理同上条)
Ctrl+Q 定位到最后编辑的地方
Ctrl+L 定位在某行 (对于程序超过100的人就有福音了)
Ctrl+M 最大化当前的Edit或View (再按则反之)
Ctrl+/ 注释当前行,再按则取消注释
Ctrl+O 快速显示 OutLine
Ctrl+T 快速显示当前类的继承结构
Ctrl+W 关闭当前Editer
Ctrl+K 参照选中的Word快速定位到下一个
Ctrl+E 快速显示当前Editer的下拉列表(如果当前页面没有显示的用黑体表示)
Ctrl+/(小键盘) 折叠当前类中的所有代码
Ctrl+×(小键盘) 展开当前类中的所有代码
Ctrl+Space 代码助手完成一些代码的插入(但一般和输入法有冲突,可以修改输入法的热键,也可以暂用Alt+/来代替)
Ctrl+Shift+E 显示管理当前打开的所有的View的管理器(可以选择关闭,激活等操作)
Ctrl+J 正向增量查找(按下Ctrl+J后,你所输入的每个字母编辑器都提供快速匹配定位到某个单词,如果没有,则在stutes line中显示没有找到了,查一个单词时,特别实用,这个功能Idea两年前就有了)
Ctrl+Shift+J 反向增量查找(和上条相同,只不过是从后往前查)
Ctrl+Shift+F4 关闭所有打开的Editer
Ctrl+Shift+X 把当前选中的文本全部变味小写
Ctrl+Shift+Y 把当前选中的文本全部变为小写
Ctrl+Shift+F 格式化当前代码
Ctrl+Shift+P 定位到对于的匹配符(譬如{}) (从前面定位后面时,光标要在匹配符里面,后面到前面,则反之)

下面的快捷键是重构里面常用的,本人就自己喜欢且常用的整理一下(注:一般重构的快捷键都是Alt+Shift开头的了)
Alt+Shift+R 重命名 (是我自己最爱用的一个了,尤其是变量和类的Rename,比手工方法能节省很多劳动力)
Alt+Shift+M 抽取方法 (这是重构里面最常用的方法之一了,尤其是对一大堆泥团代码有用)
Alt+Shift+C 修改函数结构(比较实用,有N个函数调用了这个方法,修改一次搞定)
Alt+Shift+L 抽取本地变量( 可以直接把一些魔法数字和字符串抽取成一个变量,尤其是多处调用的时候)
Alt+Shift+F 把Class中的local变量变为field变量 (比较实用的功能)
Alt+Shift+I 合并变量(可能这样说有点不妥Inline)
Alt+Shift+V 移动函数和变量(不怎么常用)
Alt+Shift+Z 重构的后悔药(Undo)

编辑
作用域功能快捷键
全局查找并替换 Ctrl+F
文本编辑器查找上一个 Ctrl+Shift+K
文本编辑器查找下一个 Ctrl+K
全局撤销 Ctrl+Z
全局复制 Ctrl+C
全局恢复上一个选择 Alt+Shift+↓
全局剪切 Ctrl+X
全局快速修正 Ctrl1+1
全局内容辅助 Alt+/
全局全部选中 Ctrl+A
全局删除 Delete
全局上下文信息 Alt+？
Alt+Shift+?
Ctrl+Shift+Space
Java编辑器显示工具提示描述 F2
Java编辑器选择封装元素 Alt+Shift+↑
Java编辑器选择上一个元素 Alt+Shift+←
Java编辑器选择下一个元素 Alt+Shift+→
文本编辑器增量查找 Ctrl+J
文本编辑器增量逆向查找 Ctrl+Shift+J
全局粘贴 Ctrl+V
全局重做 Ctrl+Y

查看
作用域功能快捷键
全局放大 Ctrl+=
全局缩小 Ctrl+-

窗口
作用域功能快捷键
全局激活编辑器 F12
全局切换编辑器 Ctrl+Shift+W
全局上一个编辑器 Ctrl+Shift+F6
全局上一个视图 Ctrl+Shift+F7
全局上一个透视图 Ctrl+Shift+F8
全局下一个编辑器 Ctrl+F6
全局下一个视图 Ctrl+F7
全局下一个透视图 Ctrl+F8
文本编辑器显示标尺上下文菜单 Ctrl+W
全局显示视图菜单 Ctrl+F10
全局显示系统菜单 Alt+-

导航
作用域功能快捷键
Java编辑器打开结构 Ctrl+F3
全局打开类型 Ctrl+Shift+T
全局打开类型层次结构 F4
全局打开声明 F3
全局打开外部javadoc Shift+F2
全局打开资源 Ctrl+Shift+R
全局后退历史记录 Alt+←
全局前进历史记录 Alt+→
全局上一个 Ctrl+,
全局下一个 Ctrl+.
Java编辑器显示大纲 Ctrl+O
全局在层次结构中打开类型 Ctrl+Shift+H
全局转至匹配的括号 Ctrl+Shift+P
全局转至上一个编辑位置 Ctrl+Q
Java编辑器转至上一个成员 Ctrl+Shift+↑
Java编辑器转至下一个成员 Ctrl+Shift+↓
文本编辑器转至行 Ctrl+L

搜索
作用域功能快捷键
全局出现在文件中 Ctrl+Shift+U
全局打开搜索对话框 Ctrl+H
全局工作区中的声明 Ctrl+G
全局工作区中的引用 Ctrl+Shift+G

文本编辑
作用域功能快捷键
文本编辑器改写切换 Insert
文本编辑器上滚行 Ctrl+↑
文本编辑器下滚行 Ctrl+↓

文件
作用域功能快捷键
全局保存 Ctrl+X
Ctrl+S
全局打印 Ctrl+P
全局关闭 Ctrl+F4
全局全部保存 Ctrl+Shift+S
全局全部关闭 Ctrl+Shift+F4
全局属性 Alt+Enter
全局新建 Ctrl+N

项目
作用域功能快捷键
全局全部构建 Ctrl+B

源代码
作用域功能快捷键
Java编辑器格式化 Ctrl+Shift+F
Java编辑器取消注释 Ctrl+\
Java编辑器注释 Ctrl+/
Java编辑器添加导入 Ctrl+Shift+M
Java编辑器组织导入 Ctrl+Shift+O
Java编辑器使用try/catch块来包围未设置，太常用了，所以在这里列出,建议自己设置。
也可以使用Ctrl+1自动修正。

运行
作用域功能快捷键
全局单步返回 F7
全局单步跳过 F6
全局单步跳入 F5
全局单步跳入选择 Ctrl+F5
全局调试上次启动 F11
全局继续 F8
全局使用过滤器单步执行 Shift+F5
全局添加/去除断点 Ctrl+Shift+B
全局显示 Ctrl+D
全局运行上次启动 Ctrl+F11
全局运行至行 Ctrl+R
全局执行 Ctrl+U

重构
作用域功能快捷键
全局撤销重构 Alt+Shift+Z
全局抽取方法 Alt+Shift+M
全局抽取局部变量 Alt+Shift+L
全局内联 Alt+Shift+I
全局移动 Alt+Shift+V
全局重命名 Alt+Shift+R
全局重做 Alt+Shift+Y

本文链接

开始Scrum 4 : Defects of Scrum

2011-09-26T13:59:00Z

1, 整体架构上缺少规划，要注意后期的重构和优化。

2，会议很多，某些时候增加了沟通的成本，对技术人员也是一种干扰。

3，需要客户不断的参与

4, 定了质量这个轴，时间这个轴就不确定了.即你无法确定在一个release内deliver多少feature.

5, 民主导致的低效。

6, 关于测试的一点, 如果你的测试用例是根据User Story设计的，那么你可能要整合一些测试用例，因为User Story 是缺乏整体性的。你需要后期把一些

测试用例合并或串联起来。

本文链接

开始 Scrum 3: Values of Scrum

2011-09-08T16:19:00Z

1,Agility (for requirement)

2,Commitment

3,Focus

4,Openness

5,Respect

6,Courage

本文链接

People management skill

2011-09-08T16:04:00Z

转贴一篇作为结束。结合前面的Manager role in Agile

Just Have Conversations About anything! Talking to and more importantly, listening to your people regularly and informally is a great asset. It doesn't matter what it's about, Your understanding of them and their trust in you will magnify if you devote priority time to this each and every day.
Listen & Show you are Listening Take the time to really listen to each of your people, rather than just tell. If you truly hear, they will respond. Hearing is more - it is about what you do with the stuff you've listened to. And by using your face, your body language, eye contact and what you say (see 3 below), you will go a long way to showing that you are listening closely.
Ask Another Question Such a simple tactic. Ask secondary questions about what you've been told. Nothing, but nothing builds rapport and relationships like this. It shows that what they have been telling you is valuable, is interesting and builds their confidence. And you have been there to make that happen.
Support Your people need you to help them along the way. With your support, they will flower and grow. Support is what they hear from you - it works both ways.
Coach Don't get bogged down with technicalities. Coaching is about helping them see where they want to get to from where they are now. It's about exploring the possibilities - their possibilities, not yours and calling to action. Simple as that.
Clear Expectations By ensuring that all your people know exactly what you expect of them, they will tune in to delivering it. Confusion over performance is demoralizing and saps energy. Take the time to be clear.
Pay attention In any conversation with your people, take the time to give your full attention. Do your utmost to avoid being interrupted or distracted and truly value them for what they are saying to you - or the message you are giving them.
Show an Interest in Them These are real people and if you delve a little, it will show up. Having a real interest in who they are, their hopes and fears, their passions and what's important to them makes a big, big difference to how they perceive you. Get to know the name of their dog, if their dog is their most prized possession!
Follow Through During conversations you may offer actions that will be of value to them. Responses to what they have said to you. Make sure that you deliver these. Follow up and report back. Take actions you say you will. If you can't, tell them why.
Remember Conversations When you have subsequent conversations, recall something that was said previously and bring it up. This is hugely rewarding for them and lets them know that they said something of value.

Article Source: http://EzineArticles.com/101619

本文链接

自动化脚本准备数据的几种方式

2011-09-08T00:24:00Z

1，一个测试用例一个脚本一组数据，每个脚本创建按自己的数据，然后清理。好处显而易见：独立，灵活。坏处：累

2，一个测试集，一组数据。我觉得这样平衡比较好。当然你说，我想只run一个脚本怎么办？这种一般是改了bug，那么你不需要做一下回归吗？也许run一个测试集比较好吧。

本文链接

适合自动化的测试与不适合做自动化的测试

2011-09-07T15:50:00Z

适合的：

l 单元组件测试

l API， webservice 测试

l UI 底层测试，（比如自动生成的XHTML代码）

l UI 测试

l 这几种，从前往后，需要的投入越大，ROI 越低，但对开发的要求越低。

不适合的：

l 易用性测试

l 探索性测试

l 重复率非常低的测试

l 不能快速返回结果的测试（比如说你需要等某个时间点完成一个job,与其这样，不如maual 来做。

本文链接

测试天生就要自动化的理由

2011-09-07T15:43:00Z

1，测试是一项重复的活动。这个重复体现在：

l 我们在每次迭代、每个sprint结束，都应重复以前的测试用例。

l 版本控制中，我们在每个版本分支上有许多重复测试。

l 因为FFR，每次改完BUG，我们需要重复。

l 最可怕和最必要的重复：发布前的不断回归

l 重要的一点，重复是严格的重复，只有机器能保证这一点

2，测试是一项需要快速给出反馈的活动，需要快速的原因在于

l 越快修改的代价越低

l 越快越有利于发现Root Cause

3, 测试是步骤重复，但是数据却不重复的测试。其他的独立于步骤的因素还有：

l 不同权限的帐户

l 产品不同的配置、不同的略微差异的版本。

4，最后一点理由：测试脚本是强大的“动态”的文档。

本文链接

Manager 如何在Scrum team中体现作用？

2011-09-06T02:57:00Z

1，确保敏捷原则的贯彻执行，在团队成员受到压力时给予支持。决策由team来做可能一直都是一个好主意？

2，解决跨团队的问题

3，团队的划分，人员划分

4，解决Scrum 的风险，客服Scrum 的缺点。

5，人员培训，多技能的测试人员：需求、文档、UI、自动化

5 ，测试策略的制定，平时的scrum，稳定阶段呢（regression会出现）， realease 阶段？把关？

Question:

Scrum 团队中包含tester? 比例？

团队人员构成，成分？

自动化工具？覆盖率？

scrum 周期，release 周期？

是否应用TDD？

测试人员能有多大自主权？时间？ velocity?

Manager 的角色？

测试人员要注意进入稳定时的质量，要注意us中的acceptance cretiaria

本文链接

测试与开发的冲突举例

2011-08-29T02:15:00Z

1，有Block的bug，测试要不要继续？

2，给Bug如何定级？

3，要不要给Bug加regression 标签

4，性能测试的指标谁说了算？

5，开发能否干扰测试计划？

6, 测试能不能给单元测试定标准？

7, regression bug 多，开发有没有反省设计缺陷，还是抱怨测试不及时？

8, 设计是否有足够健壮的中间层供测试？

9，是否只依赖于基于UI的自动化测试做为防护网，还是有单元测试、API测试？

本文链接