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

songfun

消息类型:聊天记录
==================================================

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 ]

songfun

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%的人身上,解决重点问题

songfun

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)
我的原则：多少人就做多少事

songfun

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

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

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)
那就是了，其实你上午的工作大多都应当是ｑａ这个职位的职责

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)
加强与高层沟通
我们干测试沟通很重要

songfun

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 ]