大头
Table_bottom

标签云
Table_bottom

分类
Table_bottom

日历
二月
28293031123
45678910
11121314151617
18192021222324
252627282912
Table_bottom

评论
Table_bottom

留言
Table_bottom

微博
Table_bottom

热门文章
Table_bottom

随机文章
Table_bottom

豆瓣上谁关注这里
Table_bottom

链接
Table_bottom

搜索栏
Table_bottom

RSS
RSS Link
Table_bottom

功能
Table_bottom

页面
Table_bottom

计数器
463989
Table_bottom

访客统计
Table_bottom

存档
Table_bottom

关于自动测试工具

来自51testing的一个讨论。

阅读全文

看一个项目经理是如何协调与测试团队的关系的

http://topic.csdn.net/u/20090723/11/a51ddd7c-d76d-4df7-986c-d75b1bdbbe66.html

我排斥测试工具

“项目管理不适合做讲座,只适合做咨询,因为每个公司的情况是不一样的。”

阅读全文

代码之美 - 081007

《漂亮的测试》这一章很容易阅读,Alberto Savoia介绍如何写测试用例,漂亮的。

他举例说明如何写漂亮的测试代码,这个过程又是如何使被测代码变得更好。其实,更加强调的是程序员本来就应该测试自己的代码。

有多少程序员像画家一样,常常放下笔,站远点,从不同角度,在不同光线下,审视自己的作品呢?

我很少编写程序去测试自己写的函数,我的同事也一样。我们更多依赖运行整个程序检查结果是否正确,依赖测试组的同事们。

作者介绍的是Java程序员常用的JUnit

不要给自己找借口,只要想做,办法总是有的。

挑了几个错误,填写到这里

计划啥?

有人问:“在做测试计划时,如何估计软件的缺陷数量?”
这实在是一个很二的问题。
做计划的时候干吗要去估计Bug有多少?
有人回帖说:“作测试计划的时候,是应该估计一下该软件的BUG数量,BUG集中点,以及修改该BUG的难度与时间,如果这些不估计,那编写测试用例的时候无法对某些重要模块作出着重测试”。
神了,做测试计划的时候都能估计出修改Bug的难度和时间了,也别计划了,赶紧解Bug去吧。