51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6121|回复: 4
打印 上一主题 下一主题

无忧测试QQ整理——关于测试考试认证、过程改进,以及软件评审

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-6-17 20:38:16 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
消息类型:聊天记录
==================================================

2005-06-16 16:48:37 gladys(19785708)
能说下在测试过程改进中怎样引入自动化工具吗?

2005-06-16 16:54:41 唵嘛呢叭咪吽(183666087)
这个问题我回答你
http://www.51testing.com/emagzine/No2_10.htm
看看这个文章吧
讲测试化测试引入的

2005-06-17 10:30:22 songfun(6975740)
我刚把我们群BBS的 成员介绍重新更新了一遍,希望在潜水的各位XDJM一起到群里报道一下吧,谢谢啦。
bobli --51testing慧谷博为峰创始人,[软件测试职业发展] [慧谷-博为峰软件测试沙龙] 版主
testing  --51testing慧谷博为峰创始人,51testing论坛站长,[软件测试论坛公告] [ 版主讨论区 ] 版主
songfun --[软件测试新手上路] 版主
shanjiyong --[QuickTest Pro] [TestDirector] 版主
skinapi --[软件测试外文翻译版] 版主
sincky --[TestView] 版主
sunshinelius --[LoadRunner] 版主
jzhao --[TestDirector] 版主
司空公子 --[Rational Robot] 版主
szxutao  --[软件测试资源交流区] 版主
archonwang --[软件测试新手上路] 版主
QA_BAY --[WinRunner] [QuickTest Pro] 版主
smartbaby --[软件测试技术杂谈] 版主
jacky  --[嵌入式软件测试] 版主
pokemon --[软件测试新手上路] 版主
遥远 --深圳软件测试协会论坛(www.sztest.org)总版主floating
Zhangyv --CSDN前任专题开发版版主,C语言和数据结构技术专家
jinchen  --matrix.org.cn  Tomcat && Resin 版主

2005-06-17 10:45:13 songfun(6975740)
通知:
  感谢这个群的朋友来捧场,现在我把这个群转给 【LOADRUNNER版】版主 sunshinelius 来管理,希望以后大家相处愉快,互相交流。


2005-06-17 10:51:26 小鱼(66944928)
我很想了解单元测试的实施经验,不知哪位可以传授一二

2005-06-17 10:51:56 T.E.(28707264)
先找个实际一点的主题讨论吧,例如,假如我是测试经理,那么我要如何来管理测试组.

2005-06-17 10:52:27 songfun(6975740)
阿里巴巴的测试经理 上次沙龙提过,国内真正实施单元测试的公司没几家。
神州数码号称有,不过不太清楚具体的实施情况,要请教ppyeer版主了。

2005-06-17 10:53:53 gladys(19785708)
请教各位一个问题,大家觉得测试经理的技术力量是否一定要大于组员?

2005-06-17 10:54:32 T.E.(28707264)
有人看过JUnit实践这本书么,讲单元测试的,不知道有没有帮助

2005-06-17 10:55:03 遥远(38135388)
最好是大于组员

2005-06-17 10:56:09 ivy(380514686)
我想问问作测试这行,考认证(比如厂家MI,软考等)的必要性?

2005-06-17 10:56:13 songfun(6975740)
测试经理 和 测试组长有一些区别。测试经理偏重于管理,技术上能比组员强自然是好事,但我觉得他可以不是技术最强的,不过至少水平上也比较均衡。

2005-06-17 10:56:40 T.E.(28707264)
测试经理的重任在于协调

2005-06-17 10:57:04 gladys(19785708)
因为我以前也算是带过测试队伍的,但因为还要分管质量那块的工作,所以技术力量肯定不如测试人员的强。所以在工作中还是遇到很多问题的。

2005-06-17 10:57:21 虫子(79542048)
单元测试的实施经验

2005-06-17 10:57:33 songfun(6975740)
目前测试方面的认证,好像 我就听过 软考 的软件评测师。 至于MI的认证,属于专业厂商的,也可以考虑,不过比较贵,呵呵。

2005-06-17 10:57:39 遥远(38135388)
测试经理当然应该把管理放在第一位,但技术比较强更有助于工作


2005-06-17 10:58:27 ╋映映╋(53447901)
JUnit in action中文版 很不错!

2005-06-17 10:58:33 gladys(19785708)
特别是对测试组在做测试计划的时候,有时候会把计划计划的超长。。因为我不太了解新的测试工具,所以一点办法都没有。

2005-06-17 10:58:58 T.E.(28707264)
基础知识还是很重要的,所以本人建议考软件评测师比那些厂商认证更实际

2005-06-17 10:58:59 songfun(6975740)
会做单元测试 和 实施起来还是有相当的距离的。

2005-06-17 10:59:05 ivy(380514686)
呵呵,软考那个考试题我看了一下,范围还是比较广的

2005-06-17 10:59:52 T.E.(28707264)
单元测试还是让有开发经验的人或开发人员完成比较好

2005-06-17 10:59:53 ivy(380514686)
厂商的认证,我个人认为是比较细分的,比如说性能测试

2005-06-17 10:59:57 lemon(9042829)
软件评测师,书可以看,考,我认为意义不大

2005-06-17 11:00:02 songfun(6975740)
软考的 评测师主要是 高程的内容,你把历年的高程题看好了,做熟了,就差不多了。

2005-06-17 11:00:22 ivy(380514686)
就是说更专业了,而软考的,有点广

2005-06-17 11:00:58 gladys(19785708)
软件工程是不是也可以考证的?

2005-06-17 11:01:21 ivy(380514686)
个人认为:作测试,就要有一方面的专长,作管理就令当别论

2005-06-17 11:01:19 T.E.(28707264)
通过考评测师,对于基础的巩固我想是有很大帮助的,如果你注重准备的过程而不是单纯为了考试

2005-06-17 11:01:26 lemon(9042829)
评测中心编书的人都说:他考都考不过

2005-06-17 11:01:40 songfun(6975740)
可以的话,单元测试应该交给tester来完成——现在最大的阻碍恐怕是技术问题,tester 水平不够,无法完成。双重矛盾。




(未完,具体内容见附件整理内容)

[ Last edited by songfun on 2005-6-22 at 15:10 ]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
 楼主| 发表于 2005-6-17 20:44:55 | 只看该作者
2005-06-17 11:02:20 T.E.(28707264)
让测试开发员做单元测试还差不多.

2005-06-17 11:02:52 gladys(19785708)
做管理技术不精通做起来太痛苦啦,这就是我个人的经验。。。虽然说测试管理是需要管理,但这个应该是技术型的管理。。。要不真的难众呀。

2005-06-17 11:02:58 ivy(380514686)
呵呵,那就比较奇怪了,真是没有规范出台,都是比较难的


2005-06-17 11:05:46 小鱼(66944928)
我考了软件评测师的认证,觉得学习的过程更享受,让我确实知道了很多,不过题目我觉得挺难的

2005-06-17 11:06:12 愫夕(41375549)
软件评测师的认证是什么时候考的?

2005-06-17 11:06:20 songfun(6975740)
pcl版主 不也考了MI的LR认证了

2005-06-17 11:06:27 ivy(380514686)
评测师是今年5月份考的

2005-06-17 11:06:58 songfun(6975740)
今年考评测师的人太少了,比系统分析员还少,下半年就不举办了,明年5月第二次考。

2005-06-17 11:07:01 愫夕(41375549)
考题难吗?

2005-06-17 11:07:46 songfun(6975740)
我见过MI的认证,呵呵,还不错,挺精致的,反正比软考的 高级程序员 证书精致多了


2005-06-17 11:08:05 小鱼(66944928)
我想考个mi的认证,不知道有没有必要呢?

2005-06-17 11:08:18 虫子(79542048)
过MI的认证好贵

2005-06-17 11:08:21 songfun(6975740)
pcl是51testing的版主,工具这块非常强,现在可是专业的顾问哦


2005-06-17 11:08:28 愫夕(41375549)
好像今年是第一次举行软件评测师的认证啊


2005-06-17 11:08:55 宝宝的笨笨(4286677)
mi认证多少钱啊


2005-06-17 11:09:11 小鱼(66944928)
几K吧

2005-06-17 11:09:26 songfun(6975740)
是的,第一次的评测师考题概念性太强

2005-06-17 11:09:31 小鱼(66944928)
要看你报什么拉,MI的

2005-06-17 11:09:34 ivy(380514686)
这个MI的LR cpc 认证

2005-06-17 11:09:46 愫夕(41375549)
songfun你考过了是吗?

2005-06-17 11:10:41 songfun(6975740)
我没去报名,不过做了一遍考题而已

2005-06-17 11:13:04 愫夕(41375549)
要考评测师认证,以各位大侠看,至少要知道多少哪些知识?

2005-06-17 11:13:08 songfun(6975740)
http://bbs.51testing.com/viewthread.php?tid=13576&fpage=1
考题在这里。

2005-06-17 11:23:31 ivy(380514686)
呵呵,是这个,全国计算机技术与软件专业技术资格(水平)考试
2005 年上半年软件评测师上午试卷


2005-06-17 11:24:37 ivy(380514686)
to songfun:pcl在咱们组里吗?


2005-06-17 11:25:37 songfun(6975740)
他暂时不在,不过工具这块你可以管理员shanjiyong,小单对工具也很有研究。
还有sincky也不错,呵呵。
单元测试方面可以问skinapi,测试管理 方面,这个群很多朋友都是测试经理、主管。
当然还有 sztest的总版主,大家也可以和他多交流交流



(未完,具体内容见附件整理内容)

[ Last edited by songfun on 2005-6-17 at 20:46 ]
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2005-6-17 21:11:52 | 只看该作者
2005-06-17 11:56:23 digman(6310930)
上午刚刚开完会,整整和开发人员和项目经理争吵了一上午
主要就争执开发与测试关系的问题,以及开发文档到底应该写成什么样
感觉阻力很大啊

2005-06-17 11:57:21 tomsyang(421532874)
你们的qa能起作用吗

2005-06-17 11:57:41 digman(6310930)
各位在推行时有什么好的办法没有

2005-06-17 11:57:49 digman(6310930)
我们没有QA

2005-06-17 11:58:13 tomsyang(421532874)
那就是了,其实你上午的工作大多都应当是qa这个职位的职责

2005-06-17 11:58:14 digman(6310930)
今天上午已开始在分配下一阶段的工作任务
接着我就提到需求文档需要完善,结果开发人员觉得麻烦,不想搞
结果就开始就各类情况争吵

2005-06-17 11:59:16 tomsyang(421532874)
要想解决这种局面只能在这种环境下对于他们的测试要万分仔细,测出无数的问题后他们就没话说了

2005-06-17 11:59:52 tomsyang(421532874)
你不可能立刻有改观,除非你们的上层发话

2005-06-17 12:00:38 lemon(9042829)
文档问题一定要力争,它对测试工作很有帮助

2005-06-17 12:00:42 digman(6310930)
本来我也想通过事实说服他们,可是如果前期没有做这些工作的话,后期我们的压力很大啊,我们主要开发的是财务软件,功能较多,相互之间的关联关系很复杂,我不得不拿出来争吵


2005-06-17 12:01:17 digman(6310930)
是啊,文档问题我一定坚持

2005-06-17 12:01:35 tomsyang(421532874)
你们的大老板能不能支持你一下

2005-06-17 12:01:39 digman(6310930)
因为第一阶段的开发就是无序的,吃了很多亏
这次说什么我也要顶住压力

2005-06-17 12:01:58 tomsyang(421532874)
那就是开发管理都有问题了

2005-06-17 12:02:19 digman(6310930)
我现在隶属于质量保障组,组长是部门经理兼任的,暂时可以认为是支持我的工作的

2005-06-17 12:02:34 digman(6310930)
其实就是开发管理问题,开发人员认识不足

2005-06-17 12:02:38 lemon(9042829)
他们开发人员不知为什么,不喜欢写文档是通病

2005-06-17 12:02:46 digman(6310930)
对测试到底需要那些工作和资源根本就不知道
还没有给他们讲道理呢,就拿一些特例和我争执
所以说还是一个意识问题,
他们会体会到这样做的好处的,

2005-06-17 12:03:49 tomsyang(421532874)
嗯,那就找你的领导谈谈,

2005-06-17 12:04:24 digman(6310930)
今天只是一个开头,接下来我把各类问题好好整理一下,一样一样解决,

2005-06-17 12:22:40 skinapi(53068351)
to lemon:开发人员不喜欢写文档的原因有很多的,比如没有认识到文档的重要性,或者写文档的工具并不好用,或者文档的模板冗余太多等,需要针对不同的原因进行处理。

2005-06-17 12:29:36 gladys(19785708)
开发人员不喜欢写文档还有一个原因:写文档的时候需要把系统思考的比较严谨,而这个时候开发人员兴趣多在技术细节上,不愿意浪费时间。特别是在开发过程中引入新的工具时。

2005-06-17 12:37:12 lemon(9042829)
说得有道理

2005-06-17 12:38:17 skinapi(53068351)
开发人员不喜欢写文档,那我们测试人员喜欢写文档吗,是不是也有类似的问题,大家可以讨论一下。^_^

2005-06-17 12:39:10 lemon(9042829)
呵呵,说得也是,我也不喜欢

2005-06-17 12:40:21 gladys(19785708)
呵呵,写测试报告的时候比较喜欢!  因为出成果了,而且代表工作告一段落。
开始写测试计划和测试用例设计的时候,有点想拖。

2005-06-17 12:41:31 lemon(9042829)
我们公司现在很喜欢流于形式上的东西,我很讨厌

2005-06-17 12:42:45 skinapi(53068351)
这是不少公司的通病了

2005-06-17 12:43:58 skinapi(53068351)
gladys可不可以谈谈为什么写测试计划和测试用例时想拖呀

2005-06-17 12:44:04 gladys(19785708)
其实不要讨厌,没有流于形式的这个过程。你想一步到位是不可能的,因为就算是形式,也是需要花时间和费用的。

2005-06-17 12:45:01 lemon(9042829)
但是我觉得它影响到正常的工作了

2005-06-17 12:46:21 gladys(19785708)
想拖,是因为又要开始工作啦~~~  而且又知道会面临测试过程中会遇到的各种技术、人际等一系列问题。

2005-06-17 12:46:38 skinapi(53068351)
在大家没有养成好的习惯前流程是肯定需要的,但执行流程的过程中需要更关注的是其中的内容而不是形式

2005-06-17 12:47:12 gladys(19785708)
这点不符合,喜欢测试这个要求  嘿嘿

2005-06-17 12:58:13 gladys(19785708)
我觉得执行过程中  形式和内容  一样重要,只有以形式做保障后才能持续改进。或者说才能更有执行力。。。

2005-06-17 13:01:30 lemon(9042829)
我不这样认为,对自己有用才用,流于形式的东西,是在浪费宝贵的时间

2005-06-17 13:34:30 digman(6310930)
本人倒是很喜欢写测试计划和测试用例的
不过这个兴趣也是最近才有的,因为以前公司的测试计划是个虚的,流于形式,没有任何实际指导意义,
现在是因为参加一个大项目,而且周期较长,所以才显示出计划的重要性了

2005-06-17 13:37:14 gladys(19785708)
其实还有个原因不喜欢写,因为测试用例写起来是很考技术的。这方面自己感觉不行。

2005-06-17 13:37:55 digman(6310930)
有难度才会有兴趣的,我喜欢这样

2005-06-17 13:42:46 songfun(6975740)
digman,你先和大家说说你目前公司的组织结构。
我觉得你这样和开发组讨论、争吵没有用,因为“把力气用错了地方”

2005-06-17 13:43:31 digman(6310930)
我们公司的开发部门大约有30多个人,正是的测试人员有五个

2005-06-17 13:44:10 digman(6310930)
目前部门成立了一个新的质量保障组,把测试、内审和文档都纳进来了

2005-06-17 13:44:42 digman(6310930)
产品线有两条,一个是税务行业的,一个是财务行业

2005-06-17 13:44:50 songfun(6975740)
那QA和测试部是否分开了?而你在其中扮演什么样的角色?

2005-06-17 13:45:10 digman(6310930)
目前是我和另外一个女孩一起负责财务软件的测试和文档编写工作

2005-06-17 13:45:48 digman(6310930)
我们没有qa这个角色,部门经理担任质量保障组的组长

2005-06-17 13:46:47 ivy(380514686)
你是测试组长?

2005-06-17 13:47:40 digman(6310930)
上午和他们进行争论,主要是财务行业的项目经理安排工作,对于开发文档有点想省略或者简化的意思,而且下面的开发人员对于文档的作用认识也不清楚,所以我才很着急

2005-06-17 13:47:46 digman(6310930)
算是测试组长吧

2005-06-17 13:48:42 songfun(6975740)
digman,你说的情况我也遇到过,后来我体会到,这种方式收效甚微。

2005-06-17 13:49:11 digman(6310930)
按照公司目前的作法,可能是我们两个都负责这个项目,都是测试员,而没有组长这个角色

2005-06-17 13:49:46 lemon(9042829)
只有与高层沟通

2005-06-17 13:50:12 digman(6310930)
是啊,我也感觉效果很不好,可是我如果不说,到后来会把我们压死,我现在就是要这么说,声音大些,引起部门经理和项目经理的足够重视

2005-06-17 13:50:23 lemon(9042829)
高层不支持就没有办法了

2005-06-17 13:51:16 digman(6310930)
我们的部门经理到是支持组织的良性发展,任何对组织发展有帮助的工作他都回去做,

2005-06-17 13:52:21 songfun(6975740)
开发人员不写文档确实有很多堂而皇之的理由,比如他们会告诉你详细设计文档 没有写的意义,因为伪码无法进行debug,真正开发的流程不是先写LLD,再coding,而是coding完,debug之后了,才开始写注释,写LLD

2005-06-17 13:52:31 digman(6310930)
可惜,他是开发人员出身,而且对自己的技术很自信,所持的理念是优秀的开发或者水平高的人,写出来的代码错误很少,需要很小量的测试,
这好像是整个中国软件业的通病
是公司急功近利的一种表现

2005-06-17 13:53:44 songfun(6975740)
你听到这样的解释理由还真没办法,你如何说服他们?因为他们的理由听起来还确实挺有道理。所以正是这种原因,最后由于项目进度的拖延,详细设计文档不了了之,干脆取代以 user manual了

2005-06-17 13:53:49 lemon(9042829)
看来你的阻力确实不小

2005-06-17 13:55:10 digman(6310930)
是啊,主要是管理层对测试没有正确的认识,而且认为测试人员就是比开发人员底一级,

2005-06-17 13:56:01 digman(6310930)
可是我觉得测试人员除了不用编写代码之外,其他任何一样开发产品需要的技能都需知道和了解

2005-06-17 13:56:19 songfun(6975740)
同时由于没有LLD文档,造成我们的单元测试更是无从实施——所以单元测试也做不起来。当然另一方面的原因是单元测试实施起来工作量太可怕,耗费的成本让PM看不到收益的可能。他觉得风险大,没办法实施。加上tester往往要靠开发的帮忙才能进展工作。就更加困难了

2005-06-17 13:57:52 lemon(9042829)
你可以明确的告诉他,没有文档,我们不知道需求,如何测试!

2005-06-17 13:57:59 songfun(6975740)
其实同样的问题也存在,就像skinapi说的,我们测试人员自己都不喜欢写文档,用例就是最大的问题。没有在变更流程中受到管理。
我们的test case有时 根本和实际系统的测试步骤都无法衔接起来。

2005-06-17 13:58:49 ivy(380514686)
你的问题已经涉及到改变公司流程和质量观念啦

2005-06-17 13:59:13 digman(6310930)
如果你说不知道需求,如何测试,他们会说现在让你前期加入进来,就是来学习需求,学习业务的,你知道了这些还不会测试么
听到这个我都头晕

2005-06-17 13:59:48 小鱼(66944928)
系统测试用例怎么评审,是项目负责人负责,还是测试组长负责,注,测试组长可能不负责这个项目的测试工作

2005-06-17 14:00:03 lemon(9042829)
一个项目的需求分析又不是测试人员做

2005-06-17 14:00:15 digman(6310930)
但是你可以学习

2005-06-17 14:00:47 songfun(6975740)
其实问题都很普遍,关键是你的作用范围太小。digman一定体会到了,为什么推行起来难度这么大,其实是你的分量不够,呵呵!

2005-06-17 14:01:02 lemon(9042829)
没有文档就相当于没有测试标准

2005-06-17 14:01:21 ivy(380514686)
to digman:如果你有信心,通过这件事能把公司对质量的认识扭转过来,呵呵,就继续讨个说法

2005-06-17 14:01:25 digman(6310930)
后来我说,我因为需要一个判断系统功能正确性,就需要一个标准,而需求分析文档就是我一个很重要的标准来源

2005-06-17 14:01:53 songfun(6975740)
就以文档的事情来说,靠你一个测试组长的建议不够的,这种牵扯到过程改进的东西,需要更高一级领导的介入,就是组织级的推动。

2005-06-17 14:02:36 ivy(380514686)
如果你觉得找不到这样的志同道合的领导来和你并肩作战

2005-06-17 14:03:04 lemon(9042829)
我们现在就是强行要求,而且要详细

2005-06-17 14:03:09 ivy(380514686)
呵呵,恕我直言,就找个正规的地方去,因为这样的事情以后还会发生

2005-06-17 14:03:11 ray(8085413)
前期加入是为了从需求中提取测试需求
如果需求没有文档化,是不是意味着每个人都有自己对需求的理解

2005-06-17 14:03:38 songfun(6975740)
to 小鱼,测试用例的评审可以交给测试组长来负责,问题在于你的分工没做好,测试组长当然应当对这个项目熟悉。测试经理-(测试主管)-测试组长。
组长都不熟,那你还做什么项目啦?

2005-06-17 14:03:48 ray(8085413)
那么需求就会变得千差万别,就没有标准依据了

2005-06-17 14:03:55 digman(6310930)
呵呵,部门经理倒是有提高质量的意识,但是怎么样提高,没有什么认识,而且很自负,也掺合了一部分私人的不可告人的目的,所以注定了我的一些建议不会被采用

2005-06-17 14:04:17 ray(8085413)
我最恨部门经理自负
尤其是用友的


2005-06-17 14:05:12 小鱼(66944928)
songfun:我自己都负责3个项目的测试工作,没有精力再去评审其他人的测试文档了

2005-06-17 14:06:01 ray(8085413)
呵呵,我的意思,如果部门经理的观念不转变,很难靠一个测试人员的力量去做流程规范

2005-06-17 14:06:15 digman(6310930)
是啊

2005-06-17 14:06:33 ivy(380514686)
呵呵,千里马还需伯乐啊

2005-06-17 14:06:40 ray(8085413)
而部门经理或者技术经理,一般都是技术很牛的人

2005-06-17 14:06:44 lemon(9042829)
加强与高层沟通
我们干测试沟通很重要
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2005-6-17 21:12:39 | 只看该作者
2005-06-17 14:07:18 ray(8085413)
在他们看来,规范的东西流于形式,或者增加他们的负担,而且潜意识里面看不起测试,所以很难接受测试人员的建议
沟通,这个被测试人员说烂了的词
说实话,也要看对方是什么人
如果是一头牛,那就要考虑别的了

2005-06-17 14:08:01 digman(6310930)
我和一个同事在经历过很多次类似情况后,认为对于那些自负和沟通起来很难的人,就没有必要下个功夫了,“对牛弹琴”。
咱们想到一块了


2005-06-17 14:08:49 ray(8085413)
我上次去用友面试,碰到一个这样的技术经理
差点就打起来了


2005-06-17 14:09:14 digman(6310930)
这就牵扯到一个思想了,对于君主不能接受你的思想和方法时,就不要再坚持了,换一个君主

2005-06-17 14:09:31 ray(8085413)
我觉得过CMM5也不能说明什么
本身用友各个部门之间的测试水平和规范都不一样

2005-06-17 14:10:24 digman(6310930)
ray做测试多长时间了,

2005-06-17 14:10:40 ray(8085413)
3年多了

2005-06-17 14:10:41 digman(6310930)
去用友做测试我还没有敢想过

2005-06-17 14:10:54 songfun(6975740)
CMM5确实不容易过,CMM确实也不说明什么,但是一般来说,做产品的公司,矛盾比项目型公司少一些。

2005-06-17 14:11:12 ╋映映╋(53447901)
用友现在大量招人呢,去看看啊

2005-06-17 14:11:31 ray(8085413)
不去,现在列在我黑名单首位的就是用友

2005-06-17 14:11:36 ray(8085413)
第二位就是神码

2005-06-17 14:11:52 songfun(6975740)
to 小鱼:
这说明你的测试工作安排有问题,当你没有经理介入项目的时候,应该安排一个相关的测试负责人介入项目——毕竟总有人在做测试,写TC对吧,所以要学会适当的放权。

2005-06-17 14:12:29 ray(8085413)
映映,你倒是可以尝试,里面有专门做百盒的测试

2005-06-17 14:12:51 songfun(6975740)
用例评审 因为涉及到从测试角度去考虑问题,所以理应由项目的测试组长负责。除非PM比较开通,对测试也比较了解,否则评审会出问题。

2005-06-17 14:12:54 小鱼(66944928)
我们每个项目配备一个测试人员,从需求就开始介入,但是自己写的东西自己能进行评审么?

2005-06-17 14:13:17 ╋映映╋(53447901)
我不用尝试了,只要能达到我的目标在哪干都是一样的了

2005-06-17 14:13:46 digman(6310930)
小鱼,不一定非要叫评审,可以换个名词

2005-06-17 14:14:03 ivy(380514686)
可以peer review

2005-06-17 14:14:09 digman(6310930)
叫开发人员审查

2005-06-17 14:14:25 小鱼(66944928)
cmm,iso里面都有这么个过程,实际我们也需要这么个过程开控制用例的质量

2005-06-17 14:14:51 ray(8085413)
我觉得应该审查

2005-06-17 14:14:51 小鱼(66944928)
peer review是同行评审吧

2005-06-17 14:15:07 ray(8085413)
具体的执行起来可能较为麻烦,但是还是要做的

2005-06-17 14:15:40 小鱼(66944928)
现在就是不知道怎么做,要我每个项目都要深入去了解,我没时间,和精力

2005-06-17 14:16:03 digman(6310930)
cmm,iso中用这个名词是为了能够让受众明白这个过程,具体作的时候换个名词或者内部工作流程也未尝不可,只要适合自己就好,

2005-06-17 14:16:28 ray(8085413)
小鱼,把自己作为经理的角色去考虑,然后找一个项目测试负责人去做项目的具体测试所有工作

2005-06-17 14:16:30 小鱼(66944928)
名字无所谓,关键是起到监控的作用

2005-06-17 14:16:37 digman(6310930)
你搞一个评审,很多人会认为占用他们的时间,而且对他自己意义不大,

2005-06-17 14:17:35 小鱼(66944928)
真实情况,测试组三个人,我是负责人,每个人手底下同时有两个以上项目进行测试,每个项目只配备一名测试人员,现在这种情况,用例怎么控制?

2005-06-17 14:18:15 digman(6310930)
这个监控在资源不足的情况下,很难坚持下来

2005-06-17 14:18:32 digman(6310930)
你们这样力量太分散了
难道这些项目都是同时提交测试么

2005-06-17 14:19:46 遥远(38135388)
小鱼,你们公司对测试质量的要求应该不高吧?

2005-06-17 14:20:17 songfun(6975740)
关于如何进行 评审 ,改进过程,不让评审流于形式,大家可以到群里看看我新上传的 《软件评审》。

2005-06-17 14:20:17 遥远(38135388)
我的原则:多少人就做多少事
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2005-6-17 21:13:03 | 只看该作者
2005-06-17 14:22:02 songfun(6975740)
to 小鱼:
你的项目这么多,而且还是一个在过CMM的公司,唯一的改善措施是增加人力资源。
这是你当前工作最大的瓶颈!


2005-06-17 14:23:43 songfun(6975740)
评审的七大误区,可以参考参考。
误区一:评审参与者不了解评审过程
误区二:评审人员评论开发人员,而不是产品
误区三:评审没有被安排进入项目计划
误区四:评审会议变成了问题解决方案讨论会
误区五:评审人员事先对评审材料没有足够了解
误区六:评审人员关注于非实质性问题
误区七:忽视细节

2005-06-17 14:24:46 ray(8085413)
这个不错,经典

2005-06-17 14:25:01 digman(6310930)
误区四:评审会议变成了问题解决方案讨论会,我们刚刚结束的评审,就是这种情况

2005-06-17 14:25:17 songfun(6975740)
看看吧,小鱼,这里的几个忌讳,你犯了几条?呵呵,对评审材料没有足够了解,你就参与这个评审,你说这样的评审怎么可能不流于形式呢?


2005-06-17 14:27:05 gladys(19785708)
评审的时候,经常是找不到技术方面的专家,来了一帮全是做管理的    我们公司的问题   


2005-06-17 14:28:27 lemon(9042829)
to digman:指出问题就可以了,解决办法可以下次安排会议再讨论
不然很耽搁时间

2005-06-17 14:29:31 digman(6310930)
对啊,可是他们对于问题解决很有兴趣

2005-06-17 14:30:06 lemon(9042829)
to gladys:评审可以让开发人员参加

2005-06-17 14:30:50 songfun(6975740)
应该把我上传的这份软件评审的文档发给大家看看。

2005-06-17 14:31:06 lemon(9042829)
评审会,只需要让他明白这里有问题就可以了

2005-06-17 14:31:27 songfun(6975740)
大家开个会,先把评审的工作过程定下来再做评审,否则恶性循环,评审让人觉得在浪费时间

2005-06-17 14:34:52 gladys(19785708)
评审是会请开发人员参加的,但这个时候开发人员基本上是不会指出技术问题的,因为谁也不愿说自己做差。。如果说了,别人就会问,既然你知道这不对,为什么不事先改正呢?

2005-06-17 14:36:12 digman(6310930)
哈哈,大家说得是测试产品的评审,我刚才说的是需求评审,项目组的所有人员都参加了

2005-06-17 14:37:51 songfun(6975740)
to gladys:
  你这样的评审本身存在问题,开发人员是进行交叉评审。比如一个项目组5个人的话,那么A的部分其实是BCDE在评审。

2005-06-17 14:38:43 songfun(6975740)
还有,评审有很多,比如测试用例的评审,那就是开发的在协助评审测试用例了,就不是“自己”的问题了。

2005-06-17 14:39:22 gladys(19785708)
我们的评审其实没有做那么细,只是在开发过程中的关键点上才做评审。这个时间评审不是针对ABCDE的。。而是针对整个项目组来说,但会请项目组的成员列席参加。

2005-06-17 14:44:03 小鱼(66944928)
今天下午公司开会,我想提出这个问题,跟大家讨论一下测试文档如果进行评审,因为我发现测试质量不高的原因,测试用例的设计不充分是很大原因

2005-06-17 14:45:14 遥远(38135388)
以你的人力资源,你有时间把测试用例写得充分,你有时间执行不?
我同意songfun,你们公司应该考虑招人

2005-06-17 14:45:42 T.E.(28707264)
从你们项目来看,需求在项目进行过程中,变动大么.

2005-06-17 14:45:57 lemon(9042829)
小鱼:你们是做产品还是项目?

2005-06-17 14:46:04 小鱼(66944928)
外包

2005-06-17 14:46:33 T.E.(28707264)
仅仅是测试外包,还是软件全外包

2005-06-17 14:46:41 小鱼(66944928)
变更是家常便饭,即使到了UAT阶段还会有需求变更

2005-06-17 14:46:58 lemon(9042829)
给你们的测试时间是否充裕?

2005-06-17 14:47:00 小鱼(66944928)
body shopping
不充分,但是开发时间同样不充分,到了时间我们就要交

2005-06-17 14:47:40 T.E.(28707264)
V模型试过么.

2005-06-17 14:48:19 小鱼(66944928)
我们用H模式

2005-06-17 14:48:28 小鱼(66944928)
测试驱动开发

2005-06-17 14:48:46 T.E.(28707264)


2005-06-17 14:49:44 lemon(9042829)
在加班都不可能解决的情况下,只有向上级郑重提出:需要加人!

2005-06-17 14:50:01 T.E.(28707264)
对,把风险列出来

2005-06-17 14:50:50 lemon(9042829)
否则你只有权衡一下,列出重点
人的精力毕竟有限
或则你看看是否可以引入工具,提高效率

2005-06-17 14:53:48 阿芳(10294424)
资源不足都存在的。提出来是一个办法,但是不见得能立即解决。像不能解决的情况下,就挑重点做。并将测试范围与重点汇报给干系人。

2005-06-17 14:56:11 digman(6310930)
是不是可以这样,把各个项目的重点以及按照目前的资源能过做那些重点,那些不能做,报告上级,让他们裁决,毕竟我们是具体执行人,而不是决策人

2005-06-17 14:56:17 gladys(19785708)
大多数时候,我都这样做的,而且比较有效

2005-06-17 14:56:59 小鱼(66944928)
好办法


2005-06-17 14:59:19 songfun(6975740)
这里做web测试的有多少人?你们测试环境的搭建交给测试组、还是运维组,还是开发组来做?说说利弊。


2005-06-17 14:59:58 小鱼(66944928)
我们的系统测试环境是我自己搭建的,根据开发部门列出的配置清单
我们有个visual work
每个系统都有它自己独立的配置,独立的IP

2005-06-17 15:01:10 愫夕(41375549)
visual work是测试工具吗?


2005-06-17 15:01:27 小鱼(66944928)
虚拟的主机

2005-06-17 15:01:30 ray(8085413)
我们虽然不做web测试,但是我们用的环境是独立搭建的

2005-06-17 15:01:52 songfun(6975740)
举两个例子。测试环境代码的更新,交给开发组专人负责,还是测试组专人负责?利弊何在?
如果测试环境交由测试组自己搞定,那么像权限脚本的生成、代码编译等事情在提交到生成环境的时候将由另外的人去做,这样会不会存在问题?
你们认为应该 测试环境 和生产环境(实际运行环境) 的搭建是统一由一个人来做还是各自为政?

2005-06-17 15:02:31 ray(8085413)
首先测试环境和开发环境一定要分开
但是是否由一个人来搭建,没有这么绝对吧

2005-06-17 15:02:51 小鱼(66944928)
代码我们是这样做的,从单元测试服务器上通过vss获取代码,重新编译,拿到的安装包在我们自己的web服务器上安装,数据库也是分开的

2005-06-17 15:03:04 ray(8085413)
我们一般情况是开发人员协助测试人员搭建

2005-06-17 15:04:04 songfun(6975740)
问题在于,测试环境如果自己搭建,到时候 投入实际环境运行时,搭建环境的可能是:开发部、运维组、工程组、系统组等的其他人在做,这里存在一个问题,不知道大家有没有想到?

2005-06-17 15:04:21 gladys(19785708)
开发人员协助搭建,有的时候直接在用户现场澧

2005-06-17 15:04:56 小鱼(66944928)
我们比较简单就是程序员自己去给用户搭建,而且程序员比我们测试人员更懂,我们只是模拟用户实际安装配置时可能遇到的问题,事实证明,这样做很有必要

2005-06-17 15:05:21 阿芳(10294424)
小鱼,你那个叫安装测试

2005-06-17 15:05:47 小鱼(66944928)
哦,谢谢

2005-06-17 15:05:54 ray(8085413)
我觉得小鱼做的还是对的

2005-06-17 15:06:05 阿芳(10294424)
我没有说错。

2005-06-17 15:06:20 ray(8085413)
第一次,可能这个部门哪个部门去用户哪里安装
但是如果中间出现了问题,用户需要自己安装的时候,要么你们这边过去人,要么用户自己安装
用户安装的时候,大部分都是按照公司提供的说明来做,或者按照一般规律来做,所以还是有必要测试人员自己来搭建

2005-06-17 15:07:19 小鱼(66944928)
我们经常去做support的

2005-06-17 15:07:39 ray(8085413)
阿芳,我没说你说小鱼错了,我说我支持小鱼的做法

2005-06-17 15:08:47 小鱼(66944928)
呵呵,我们也是讲过了血的教训后最近才这么做的,不过测试人员的水平提不高,有个别项目程序员都不需要我们配合他,他嫌我们反而浪费了他的时间,结果他的项目issue特别多


2005-06-17 15:08:48 阿芳(10294424)
我感觉让测试员去做support,是对测试指责的亵渎。


2005-06-17 15:09:21 小鱼(66944928)
不是,是programmer去support

2005-06-17 15:09:36 阿芳(10294424)
小鱼,你自己也是用户,别这么说“用户”

2005-06-17 15:09:58 小鱼(66944928)
我真的有遇到这样的用户的

2005-06-17 15:10:54 阿芳(10294424)
他没错亚,花钱买服务,问几个问题还不行?

2005-06-17 15:11:34 小鱼(66944928)
行,反正support他们也要付钱,我们公司还乐意去呢,只是经常抱怨,我们的口碑就不太好了

2005-06-17 15:11:48 T.E.(28707264)
是啊,技术支持人员往往只是体现了一个传达信息的角色,解决问题还是得prger去


2005-06-17 15:13:04 小鱼(66944928)
我现在的瓶颈是,连我自己都觉得自己的业务水平不够,不能服众

2005-06-17 15:31:25 嘘~garfield~(93220283)
做黑盒测试的时候
不就是要站在用户的立场来想问题吗?
如果小鱼是这样想用户的.那么他的测试出来的结果..........

2005-06-17 15:32:31 songfun(6975740)
说说我的想法,我认为需要有这么一个“角色”,专门负责环境的搭建,无论是 开发环境、测试环境,还是用户环境。
不知道大家怎么看?

2005-06-17 15:33:16 嘘~garfield~(93220283)
有这样的需要吗?
就是说假如在人手不够的情况下

2005-06-17 15:33:31 songfun(6975740)
如果软件规模不大,技术难度不高,那么可以各自为政,但是一旦规模庞大或者环境搭建的技术难度很高,就可能出问题。

2005-06-17 15:34:03 嘘~garfield~(93220283)
那你觉得这个角色,可以把配置管理也负责在内吗?

2005-06-17 15:34:12 songfun(6975740)
分工应当明细化,各司其职,不应当什么人什么事都做。这就跟早期的 开发自己开发自己测试 一个样。
没有明细的分工,最后会发现,大家做的事都好像差不多,测试组 跟开发组 、工程组,有很多重叠的工作。

2005-06-17 15:36:12 songfun(6975740)
我觉得交给SCM可以作为一种考虑。

2005-06-17 15:36:13 嘘~garfield~(93220283)
有你的道理
不过有时侯一样工作由一个人专门来做
前提很大部分是看公司的发展程度

2005-06-17 15:37:01 songfun(6975740)
我提的是一个模糊的概念,给什么部门做暂时不提,就是是否划分出这么一个角色会对工作的效果、质量起到更好的帮助?

2005-06-17 15:38:17 森林狼(6877439)
开发环境应该和测试环境分开,否则互相干扰,问题难以定位。测试环境应该尽量和用户环境一致吧,但其实完全模拟用户环境也是比较困难的,尤其是大型的分布式系统。

2005-06-17 15:38:32 songfun(6975740)
to 嘘~garfield~:
  呵呵,这个问题不大,其实可以兼职,但是要划分出来,有这么一个人在这么做,而不是A在做,B也在做,C也在做,最后到了user那里发现了问题,C搞不定,问B,你当初怎么搞的?B说:我不知道啊,问A吧………………

2005-06-17 15:39:07 gladys(19785708)
songfun, 我们公司以前做过这种尝试,但是失败啦。主要原因是项目太多而且行业也不一样,开发平台也不一样。这样对配置管理人员的要求就很高。。。但事实上配置管理人员的学习能力、技术水平,在公司中只能算一盘的。


2005-06-17 15:39:20 嘘~garfield~(93220283)

我在想
也许在不同的项目安排一个人,比较灵活也达到你说的那种要求

2005-06-17 15:39:28 songfun(6975740)
开发环境肯定是和测试环境分开了的,问题在于不管开发环境还是测试环境还是用户环境, 这个环境搭建需要统一管理。

2005-06-17 15:40:37 songfun(6975740)
to gladys:
  说到底还是一个技术自身限制的问题。在scmchina上常看到有人抱怨:scm不管是文档管理员,一点技术含量都没有。
而 tester也有类似的问题。


2005-06-17 15:41:22 gladys(19785708)
不是的,我们的配置管理人员。是从技术转过来的,技术不能算最好! 但肯定也不是最差的那种。

2005-06-17 15:41:51 嘘~garfield~(93220283)
我觉得不可以这样说
虽然我没有真正做过
但是这次的项目让我觉得其实要管理好文档也不是件容易的事

2005-06-17 15:45:56 digman(6310930)
各位,谁能帮忙给我说一下需求文档的作用和需求文档的变更管理的意义,
我现在需要整理些资料来给开发人员交流一下

2005-06-17 15:47:27 gladys(19785708)
谁对软件度量有研究?能不能讲下课?

2005-06-17 15:52:57 T.E.(28707264)
我们公司有这样的情况,需求没有统一管理,出现了N多版本,有时只有一个最初版本的需求,后面变更的话就是一大串咨询单来陈述变更的内容,你要想阅读完整的需求,得一个需求加一大串咨询但才行,很麻烦.而且,经常是更新不及时.

2005-06-17 15:53:29 digman(6310930)
看来都是如此啊,

2005-06-17 15:53:49 gladys(19785708)
配置管理加强点应该会有所改善吧。


2005-06-17 15:54:45 嘘~garfield~(93220283)
我想如果是你们这种情况
相信不止需求
其他文档也会出现类似的情况

2005-06-17 15:56:28 T.E.(28707264)
配置管理有,整了好几次,工具也用过几个,但是领导似乎不够重视,力度不够

2005-06-17 15:57:10 T.E.(28707264)
没有专门的配置管理员做这项事情

2005-06-17 15:58:25 T.E.(28707264)
我个人对工具的看法是,策略更重要,领导的意思是,先找个工具用起来再说,结果到后面就是不了了之了,唉

2005-06-17 15:58:47 嘘~garfield~(93220283)
领导都发了话了
就看你执行的人做得怎样吧?

2005-06-17 15:59:00 digman(6310930)
推行难度很大啊

2005-06-17 16:00:18 songfun(6975740)
gladys 对圈复杂度有没了解?

2005-06-17 16:00:26 T.E.(28707264)
没有专门的配置管理员做这项事情,买不起工具,策略就只能靠自己摸索,往往工作就非常忙,也没有把这件事当作一项工作来做,结果还是怎么速度快怎么来.

2005-06-17 16:00:53 gladys(19785708)
如果不能有配置管理专员的话,建议选择一位兼职来执行。工具可以用CVS免费的。。。

2005-06-17 16:02:31 gladys(19785708)
songfun,不了解,什么叫圈复杂度呀?扫个盲吧


2005-06-17 16:04:04 songfun(6975740)
呵呵,概念性的东西我不解释了。最简单的讲一下吧,越复杂的东西越容易出错,不知道你是否认同?
圈复杂度就是这么一个意思,复杂度越低越好。

2005-06-17 16:04:33 gladys(19785708)
绝对同意
我处理问题一般是先把问题简单化,再解决掉。

2005-06-17 16:06:33 T.E.(28707264)
赞同

2005-06-17 16:06:49 songfun(6975740)
人类最擅长的就是 分治法:分而治之,把复杂的问题分解成简单的问题。


2005-06-17 16:07:54 gladys(19785708)
我坦白,有时候这样处理问题是想绕过不懂的地方。。。举例说明就是某些技术问题的时候。

2005-06-17 16:08:25 T.E.(28707264)
用80/20原理

2005-06-17 16:09:00 T.E.(28707264)
80%的问题出在20%的人身上,解决重点问题
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-15 01:31 , Processed in 0.078500 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表