测试管理群聊天记录20050616_读后感

skinapi · 发表于 2005-7-22 02:13:29

songfun整理出来的聊天记录大家都看见了，个人觉得看起来还是有点眼花，所以和songfun沟通后决定为每一个聊天记录写一个读后感，按照主题来划分，粗略列一下大家讨论时发表的观点，然后再谈谈我的看法，希望能让大家了解到讨论的具体话题，也欢迎大家对我提出的看法拍砖。^_^

skinapi · 发表于 2005-7-22 02:15:14

一、单元测试怎么做，如何保证单元测试质量
讨论意见：
1、开发人员不会好好做单元测试
2、有一个标准，规定千行代码的bug数，而已他们的unite test sepc我们也可以提意见，如如果case写的不充分，我们可以不接收的

我的看法：
1、单元测试本身非常繁琐、枯燥、乏味，无论是开发人员做还是测试人员做都是一样难坚持
2、需要通过外部监督来保证单元测试的质量
3、单元测试计划、单元测试大纲、单元测试规范、单元测试报告都需要进行严格的评审
4、从测试用例上可以根据代码的情况规定每千行代码所对应的测试用例数，保证有足够的测试用例
5、从测试报告上可以规定每千行代码所对应的缺陷数，保证单元测试发现了足够多的问题
4、对集成测试、系统测试中发现的缺陷进行归纳总结，针对那些应该在单元测试阶段发现而没有发现的缺陷进行分析，帮助单元测试过程的改进和提高

二、测试管理者如何和测试人员进行良好的沟通
讨论意见：
1、作为主管，不应该总是给下属安排任务
2、平时聊聊天，不要天天谈工作，多位属下争取福利
3、特别不能平白的帮她顶包~~! 工作上不懂，可以帮助她
4、攻心为上，呵呵，你要和她说明，她不是为了你而工作，所以，其实不存在所谓的谁服谁的问题
5、管理的精髓在于对 “人”的管理，而不是“物件”
6、不要轻易跟别人流露出你对下属的意见
7、好话可以多说，坏话绝不能说，对谁都不能说，这是我的理解
8、同事就是同事，永远不可能是朋友。
9、同事之间，是一种竞争关系，朋友之间是要想互相理解互相帮助的
10、很多人都认为开发和测试有矛盾，因为出发点不一致，所以矛盾难免产生，如果大家都是为了把软件做好，那么其实开发和测试应该是很好的伴侣
11、我想知道的就是，领导跟下属是不是本身就存在一点距离的
12、我打算今后增加为下属做职业规划这一行为

我的看法：
1、管理者和下属，工作和生活要严格区分开，工作时大家是合作关系（不同意是竞争关系^_^），生活时大家可以成为朋友
2、管理者不是用来管理下属的，是为下属服务的，这个观念要转变，帮助下属把工作做好，帮助下属提高自己，帮助下属有更好的发展，这样才能和下属良好沟通
3、工作时领导和下属肯定是有距离的，要做到赏罚分明，一视同仁
4、对于不能和团队整体保持一致的下属，该出手时就出手，该拿掉的就拿掉
5、建议大家看看曾仕强的中国式管理

三、过程改进
讨论意见：
1、我现在做软件过程改进方面的工作。另外监管一下CM、QC、QA
2、主要是过程改进了，因为过程改进与CM、QC、QA，RD都有关系，所以都涉及一些，但都不深
3、很正常的，我们公司现在也是QA部，质量管理部，同时监管 SCM 和测试部门，当然还有QA
4、其实业务、销售为主导是没错的，开发和测试是为了这个环节而展开的。
5、这种东西都是长期才能见到效益的
6、企业的首要目的应该就是盈利，这是终极目标，而其他的是中间过程。过程改进也是奔着这个目标而去
7、总体的感觉是：质量、过程是重要的，但是优先级是不高的
8、我认为市场销售和软件生产过程是一个整体，任何一个木片短了，企业的盈利情况就不容乐观
9、没错，现在都在说过程改进，其实人的因素也很重要，甚至可以说是最本质的
10、你有没有和你的上级领导沟通过？实施过CMM的人应该知道，过程的改进需要组织级的推动，自顶向下的改进。首先让公司最大的leader首肯这件事，不是敷衍，是亲力亲为

我的看法：
1、非常同意市场销售和软件生产是一个整体的说法，为了提高效率产生了分工，但要明确的是分工而不是分离，如果领导是技术出身，应该不会忽视开发和测试的，如果是市场和销售出身，就需要好的沟通了
2、都说过程改进需要领导点头，从上向下推动，其实过程改进还是要靠QA去推动，至于从上向下，还是从下向上都不是最重要的。
3、不要想一下子就进行大刀阔斧的过程改进，先从容易入手、见效快的地方入手，上下见到了立杆见影的效果，自然会支持，领导不会无缘无故支持一个他看不到任何效果的改进
4、过程改进整体而言是见效慢，但也有见效快的地方，这些就是比较好的过程改进切入点

四、如何针对测试项目考虑测试
讨论意见：
1、看来你们还是比较幸福的，我们公司好多项目都是突发的，没有任何可以计划
2、更讨厌的是，我们的测试任务还会临时调度下来不得不接
3、没有计划没有文档所进行的测试，应用在V模型上确实显得特别的捉襟见肘
4、就是针对不同的实际情况作出的反应以及处理方法
5、举个例子，你现在有一个测试项目需要你负责测试，第一步你会做什么呢？指定测试计划，人力，设备，等等。第二步你会做哪些工作呢？熟悉设计文档，编写test spec
6、其实在没有文档的情况下，我比较推崇XP的结对概念，不过我把它扩大了，XP里说，结对编程，而我认为应该 “凡事皆结对”，结对测试，结对管理
7、我们公司从代码走查中想到进行用例走查
8、在没有文档的时候，结对工作可以弥补文档不足带来的致命后果
9、其实你可以这样想：为什么要结对？一个人做事容易错，容易把方向搞错；两个人会好很多。当然，这不是绝对的。一个泛泛之谈
10、那你清楚你为什么选择在第二步去熟悉设计文档，编写测试用例呢，而不是选择研究软件需求和同类型的软件功能呢

我的看法：
1、无论是什么项目，不管是计划好的，还是突发的，做测试都应该有计划，这个计划既可以形成文档也可以存在于人的大脑里
2、没有文档的测试和有文档的测试没有本质的区别，只不过后者需要寻找其它的方式来了解被测的对象到底要做成什么样了
3、突发的测试任务，对测试负责人提出了更高的要求，他需要尽快确定如何来进行测试，确定测试策略，比如时间紧迫是采取基于风险的测试策略呢还是说采取探索式的测试策略，当然不同的测试阶段有不同的测试策略选择了
4、不管是一个人测试还是结对测试，对被测对象信息的掌握都是一样重要的，对被测对象的原型越了解越有可能测试的更好，所以大家就不要局限在是做白盒测试还是黑盒测试还是灰盒测试的概念问题上了
5、走查是静态测试的一种形式，任何阶段都可以使用
6、即使是做单元测试，需求文档和设计文档一样都是要看的
7、测试时即使只有设计文档没有真正的代码也一样可以“运行”软件，那就是在纸上进行，国外进行一些设计的评审时测试工程师就经常采用这种方式，在白板上让开发人员对每一个“运行”流程进行确认

[ Last edited by skinapi on 2005-7-22 at 02:16 ]