已有 49953 人访问
毕泽明 ID.32
博客(37)
毕泽明的博客
没有人是完美的，没有人一生下来，就会做很多事情，很多经验都是积累的。什么是听君一席话胜读十年书，就是当你在非常困惑的时候，突然因为旁边的朋友或者同事的一个指点，顿然茅塞顿开。请记得，多跟同事交流，关系好的同事很多，但是知心的同事必须要有，不需要很多个，一个就足够了。当你困惑，当你看不到彼岸，或者当你干活总得不到领导赏识，你就要思考自己是不是方式有问题？态度有问题？哪里做的不对？哪里做的不好？思考可
388°/3827 人阅读/0 人点赞/6 条评论
作为一个下属，不要凡事都要问你阿头？为什么？没有为什么！阿头招你进来，是让你干活的， 不是让你问问题的，帮你解决了那么多问题，还招你干嘛，直接阿头去做就可以了。这是我一个同事教我的，因为我曾经经历过这样一个经历，阿头安排了好多任务给我，我只有一个cpu，不能多任务并发处理，而且我也不是所有事情都会做，我觉得我应该有疑问就去问。但是发现我问的问题，阿头肯定不会回答，还会说，不会自己去想啊，曾经一度让
457°/4291 人阅读/3 人点赞/28 条评论
在51测试网看到这样一个t帖子：讨论大家是如何评估测试人员的工作量？帖子主人为：牵着灵魂漫步。他所认为：大家谈谈所在的测试部门是如何评估测试人员的工作时间是否够用，一个项目中的测试任务是如何进行分解的？我们目前的做法是：先    1.写测试用例(写到每个功能点为止，如添加、删除、导入、导出都算一个功能点)    2.评估每个功能点的复杂程度 &nb
490°/4864 人阅读/0 人点赞/4 条评论
实际上在大部分公司，做测试管理，基本上也坐着开发部门的其他协调之类的杂事。那么就需要考虑如何发挥成员的最大功力调度各个成员的积极性，但是当某人成为拖后腿时？怎么办好呢....
473°/4652 人阅读/0 人点赞/8 条评论
不知不觉作为了测试小组组长。不知不觉也开始要招聘成员。同事推荐的一位朋友过来，我第一时间的反应：有点担心。第一时间的问题就是：婚否，生了没有？翌日，同事反馈信息：部门领导问了同样的问题：婚否，生否至于我为啥要问这个问题，因为经过同事生的这个阶段，那个阶段人力不足的悲壮境地。身兼多个任务，但是cpu核心只有一个，只能单线程处理。可不要告诉我天将降大任于斯人也。难道婚否，生否真的这么重要？
505°/4825 人阅读/0 人点赞/23 条评论
PostgreSQLFindbugs测试管理系统文档测试。。。。。加油，没什么空上来了。。。。
380°/3736 人阅读/0 人点赞/7 条评论
天啊，是不是很多呢，哈哈，你又知道多少？？ 言归正传   范围测试：对于每一个输入，找出系统反应相同的区间范围   恢复性测试：测试一个系统从崩溃、硬件故障或其他灾难性问题中能够恢复到什么程度   回归测试：回归测试根据一个开发螺旋周期或者一个新版本的调试、维护或开发中产生的变化对应用程序加以测试   基于风险的测试：测量一个应用程序系统所具有的业务风险的程
475°/4719 人阅读/0 人点赞/4 条评论
继续： 自由形式测试：使用直觉定义测试用例，随机的或以头脑风暴方式进行   灰盒测试：白盒测试和黑盒测试的组合方式，充分利用了二者的优点   直方图：测量值的一个图形表示，这些测试值根据定位热点问题的出现频率分类组织   增量集成测试：当在一个应用程序中的各个混合部分的进行测试以确定它们的功能是否正确的整合。这些部分可以是代码模块、个体应用程序或者一个网络上的客户端/
361°/3608 人阅读/0 人点赞/1 条评论
测试技术：描述 验收测试：基于最终用户/客户需求的最终测试，或基于最终用户/客户使用一段时间的测试   随机测试：与探索测试相似，但是通常指测试人员在测试以前对软件有较深的理解   Alpha测试：当开发接近结束的时候对应用程序进行的测试；作为测试结果，可能会有一些细微的设计变更。通常由最终用户或其他人员完成，而不是开发人员和测试人员。   基本路径测试：基于程序或系
336°/3360 人阅读/0 人点赞/0 条评论
1，黑盒测试（功能测试）      测试条件主要根据程序或系统的功能实现来制定。也就是说，测试人员所要求的信息是输入的数据和观察到的输出结果，但他们不知道程序或系统是怎么工作的。这一类测试包括决策表、等价类划分、范围测试、边界值测试、数据库集成测试、因果图、正交阵列测试、阵列和表测试、异常测试、极限测试、随机测试。黑盒测试的一个主要的优点就是测试活动本身的行
477°/4756 人阅读/3 人点赞/2 条评论