-
07年国庆前的随想
ecust 发布于 2007-09-26 09:08:03
随着CMMI3的推进，测试组的分工越来越明确，开发方的文档质量越来越高。终于带来了负面效果－－测试出的BUG极少，但上线后BUG却仍然存在，很多BUG根本没有测试出来，另外test leader这个位于腰部的关键人物，越来越体现不出应有的作用。目前的工作体系是这样的：
下面先来来说说，测试不出BUG的问题：
对于测试不出BUG的原因，问题的关键在于，开发方提供的需求实在是很“完美”，用看图说话的形势，把所有的测试点都给写了出来，包含了几乎全部路径。测试人员那到这样一个文档，做起来十分轻松，但同时也被限制在这个文档的行程的一个圈里，无法发挥发散性思维，使得测试变的不全面。在正式测试之前，程序员会根据需求文档自测，然后在提交。也就是说，文档里提到的测试点，程序员自己都测试过，拿到测试组这边，只不过是在重复程序员的测试，使得这样的测试变得毫无价值可言。目前来说，如果想解决这个问题，我认为如果让test leader同时参与需求调研，重新确定测试范围，这种方法未必有效果。原因有以下几点：1.test leader本身并不熟悉所有系统业务，也不太可能熟悉所有系统业务，在这种情况下去参与调研，怕是很难明确问题所在，确定下的测试范围会不准确。2.test leader本身并不参加测试，这一个人对需求理解的在透彻，也不可能手把手去带着测试员去完成任务，把范围划出来，给下面的人员执行起来效果如何，还很难说。
我始终认为，测试做的好与不好，关键在于对测试的认识，对项目的认识和做事的态度。目前给我的感觉就是，SRS里写上的东西就测，一些其他的旁支末节的东西，看到了也不会去测，完成分内事而已。当初一直抱怨SRS写的不好，测试不到，现在看来，写的不好，到不如写的好。文档不清楚，会导致测试员不停的去研究究竟是怎么回事，去和开发沟通确认很多细节，而这些细节，就是非常关键的东西，在文档写的不是很好的情况下，很多细节都是测试员自己想象出来的。而现在在文档十分清晰的情况下，测试员丧失了这种思维，固定在这些界面操作上，思维被文档所诱导，实在是很悲哀又很有意思的一件事情。
我老觉得管理层都把下面的人给惯坏了，好像太重视每一个人的得失。就一个团队而言，我始终认为是以公司利益为首，完成任务，保证质量是第一；什么个人发展啊之类，从公司管理层面不客气的说，那是次要的。虽然团队整体的综合实力需要提高，但是那也是在有这样一个需求的情况下，由管理层有目的的培养个别人而产生的。如果公司根本不需要做性能测试，我要底下的人学什么LOADRUNNER啊，纯粹浪费时间。
现在组里没有什么朝气，原因可能有这么几个：1.工作重复太无聊；2.领导对他们太客气；3.压力不大；4.综合因素导致他们个人思想占主导地位，安排的任务喜欢做就做，不喜欢做就拖。5.综合实力不高，导致对未来发展不明，外加人的天生惰性，导致比较懒散，一个带一个，搞的基本都是无精打采。
造成这种情况不是一朝一夕，想改变也不是一时半会。我自己自恃也没那么强的能力，带动所有人改变，这个牵涉的因素太多，有的我无权决定，有的是人的基本思想观念问题，想改变很难。目前李凯辉的积极性很高，不过如果整体大环境不改变，这种积极性也会慢慢的泯灭。良好的局面不是单靠几个人的努力就可以形成，有一个良性循环很难，寻求一个公司利益与个人发展共进步的局面也很难。人总是要靠自己，想自己良好的发展，必须自己积极，而不是靠别人来安排你，让你取的进步。
就需求这点来看，目前我也没想出什么更好的方法去改变现状，可以先按调研的方法去尝试一下。
在来说说这个组织架构的问题。
从整体项目流程来说，提交测试后，基本都会交付组长负责处理，test leader 本身不会接触到项目具体的事宜，这样就导致了很多问题都是组长直接去和开发那边处理，这个腰部的位置，其实是一个累赘。从职责上来说，目前leader其实扮演着测试经理的角色，而组长是leader的角色。而这个四层体系的最高层有一个相当于高级经理的人，而这个人才是对整个项目有决定权的人。这个概念等于就是一个项目经理上面有一个高级经理，而项目经理没权利去决定项目本身的一些事宜，组员有时有的事情也不像项目经理汇报，而是向高级经理汇报，形成一个混乱的管理局面。目前组内差不多就是这样，好像职责不清的感觉，有些事情，经理知道leader不知道，有些leader知道而组长不知道，对某些问题处理起来就没那么顺畅。
目前基于这种四层体系，我也不清楚处于腰部，应该做些什么，哪些应该我做，哪些应该组长做，而长此以往，我自己的进步也是微乎其微。
就管理本身而言，我觉得强硬的作风并不是不可取，软硬兼施才是合适的谋略。对做的有问题的人要严厉处罚，对做的杰出的人要给予奖励。不过说到底，不管是组长还是leader，都没有相应的权利，今天除了测试经理站出来要这样那样，组里人会听听外之外，如果要把我们的管理理念和方法应用到他们身上，怕是没人搭理我们。给我感触很深的就是，号召大家去开会的时候，不管是经理号召还是我号召，一个个都慢慢吞吞，慢条斯理的过来，这种小事就直接反映了目前的状况和问题。XWL的管理作风之所以吃的开，很大原因是因为他有权直接处理一些事，而并不是他人格魅力有多高。
公司在逐渐改变，高层对这个组的支持程度也是十分关键，就目前来看，不管是抽调人手还是对培训的态度，感觉都满随意的，所以给我感觉就不太好。可能有些事情大家都看在眼里，所以积极性就会比较低。
这其实是一个恶性的循环，就我本身而言，对没什么积极性的人，我更没积极性去督促帮助他们进步。我觉得其实团队本身并不是十分稳定，包括人员，制度，职责，能力，配比，测试质量等等，在这样的情况下，应该先稳稳，在寻求更进一步的发展。
大致先写这么多，对团队发展起到影响的因素很多，我的感觉有两句话说的很好： 1.世上不存在完美。 2. 细节决定成败。关于组织架构方面，不知道想法是不是正确，如果这种架构不变，腰部这个关键点的职责又是什么?
-
软件评测师考试经验分享
ppent 发布于 2007-02-02 10:40:13
-
软件过程改进的人文途径（SEPG 2007 China 演讲稿）
thinker 发布于 2007-12-14 12:43:56
-
微软测试工程师面试题
lihang617 发布于 2008-09-27 17:49:01
-
国外软件测试工程师面试题
lihang617 发布于 2008-09-27 17:54:08
-
测试用例图形化
lilyhuang 发布于 2008-04-30 11:10:59
-
关于探索性测试
lilyhuang 发布于 2007-12-12 16:06:09
-
测试用例在实际工作中真正的作用有多大（黑盒功能测试）？
lilyhuang 发布于 2007-11-14 11:11:13
-
[缺陷管理]如何编写更佳的bug report
卧龙公子 发布于 2008-08-21 22:15:13
-
编写优秀Bug报告的艺术[觉得很经典]
卧龙公子 发布于 2008-04-10 19:54:54
-
软件测试并不仅仅是按照testcase测试
lifr 发布于 2008-07-12 16:42:17
-
Ruby+Watir经验谈: 漫谈针对功能的自动化测试框架
lifr 发布于 2007-05-30 21:12:34
-
转贴-航空标准DO-178B的MCDC测试方法
cr19800604 发布于 2007-09-21 12:22:06
-
相同的测试用例，不同的MC/DC覆盖率结果？
huior 发布于 2008-07-08 15:04:24
示例代码：
#include <stdio.h>
int mcdc(int a, int b, int c)
{
int result;
printf("a=%d, b=%d, c=%d\n", a, b, c);
if((a > 1) && ((b > 2) || (c < 3)))
{
result = a*b+c;
}
else
{
result = a+b*c;
}
printf("result = %d", result);
return result;
}通过以上的简单实例，说明一下目前比较常用的几种覆盖率。透过这个过程，相信您也会对覆盖率测试有个基本的认识。
×CASE（a,b,c）表示的是测试用例的输入，如第一个用例输入的是a = 2 b= 3 c = 4
×MC/DC覆盖率翻译名称为“修正条件判定覆盖”。它是DO-178B level A级别的认证标准中规定的。欧美的民用航空飞机的软件要求强制性的遵守DO-178B level A标准。MC/DC是目前要求最严格的覆盖率。
×以上实验的覆盖率数据使用c++test统计完成。
×使用Logiscope TestChecker统计的MC/DC的结果略有不同，如执行完第一条测试用例后，Logiscope TestChecker认为此时MC/DC覆盖率应该是25%，如下图：
×虽然两个工具对单个测试用例的覆盖率数据不同，但二者都认为当执行完表格中的4条用例后，MC/DC覆盖可以达到100%。可以看出两个工具对MC/DC的理解不完全相同。
×我个人认为c++test的理解更准确一些。大家怎么看？欢迎讨论！
-
关于缺陷的优先级和严重级别
songfun 发布于 2007-03-11 02:49:08
今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的文章来告诉大家“看，老外都是这么做的”。
我觉得有必要给大家解释透这两个概念，这样不至于在日后的工作中做错。
以下粉红色部分是对那篇英文的引用，后面则是我的回答（结合微软的实际例子给大家说明）。
QUOTE:原帖由 rivermen 于 2007-3-9 09:12 发表
c) The tester then selects the priority of the defect:
Critical - fatal error
High - require immediate attention
Medium - needs to be resolved as soon as possible but not a showstopper
Low - cosmetic error
从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。
优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管理的知识。
为什么这么说呢？
因为Tester只是项目团队的成员之一，对缺陷管理、项目进度和项目风险都不可避免的会“盲人摸象”、“管中窥豹”，只“看”到自己“看”到的那个部分。
一般来说，一个被测系统往往需要多个tester的，而每个tester往往只关注自己发现的bug，不大会去了解其他tester所发现的bug，那么在这种情况下，他如何能够决定这个bug被修复的优先级别呢？！
这里再次强调一次，大家必须了解“Priority”真正的含义和作用——它是给管理者来据此做项目决策的，也就是说，缺陷优先级将直接导致工作安排的优先顺序。PM正是通过参考缺陷优先级来安排开发人员的工作顺序（这甚至能在Project里体现），使得项目风险降低、项目成本降低，解决问题更高效。
其实，这在微软内部就叫做“基于风险的测试”，也就是指评估测试的优先级，先做高优先级的测试，如果时间或精力不够，低优先级的测试可以暂时先不做。有如下一个图，横轴代表影响，竖轴代表概率，根据一个软件的特点来确定：如果一个功能出了问题，它对整个产品的影响有多大，这个功能出问题的概率有多大？如果出问题的概率很大，出了问题对整个产品的影响也很大，那么在测试时就一定要覆盖到。对于一个用户很少用到的功能，出问题的概率很小，就算出了问题的影响也不是很大，那么如果时间比较紧的话，就可以考虑不测试。
以下是微软公司的缺陷流程（不知道现在做微软外包的公司是否也采用这套流程），给大家参考参考。
Bug跟踪过程
在软件开发项目中，测试人员的一项最重要使命就是对所有已知Bug进行有效的跟踪和管理，保证产品中出现的所有问题都可以得到有效的解决。一般地，项目组发现、定位、处理和最终解决一个Bug的过程包括Bug报告、Bug评估和分配、Bug处理、Bug关闭等四个阶段：
1）测试工程师在测试过程中发现新的Bug后，应向项目组报告该Bug的位置、表现、当前状态等信息。项目组在Bug数据库中添加该Bug的记录。
2）开发经理对已发现的Bug进行集中讨论，根据Bug对软件产品的影响来评估Bug的优先级，制定Bug的修正策略。按照Bug的优先级顺序和开发人员的工作安排，开发经理将所有需要立即处理的Bug分配给相应的开发工程师。
3）开发工程师根据安排对特定的Bug进行处理，找出代码中的错误原因，修改代码，重新生成产品版本。
4）开发工程师处理了Bug之后，测试人员需要对处理后的结果进行验证，经过验证确认已正确处理的Bug被标记为关闭（Close）状态。测试工程师既需要验证Bug是否已经被修正，也需要确定开发人员有没有在修改代码的同时引入新的Bug。
话说回来，网上有很多自称专家的人在那里大谈特谈所谓的优先级标准，什么“系统死机是高级别，界面错误是低级别”之类。其实这些指的是缺陷的严重级别（Serverity）！
当然，一般来说缺陷的严重级别也不是tester“主观判断”决定的，如果公司比较规范的话，会由测试经理、项目经理等组织制订这么一份相关的标准文档，文档是关于对应缺陷严重级别的定义。Tester在测试的时候就根据这么一份文档来决定对应Bug的严重级别。
我下面粘贴某公司的一个《缺陷等级标准》的文档，大家可以看到其中的“E类——测试建议”正是我上课所说的Enhancement。
========================
缺陷严重级别定义:
o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急---事件非常重要,并且需要马上给予关注.
o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级---事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
更为详细的划分如下:
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
===============================
好了，关于缺陷优先级和严重级别我解释到这儿，我希望同学们在学习的过程中知其然更要知其所以然。流程的制定不是想当然的，更不是因为看到别的公司都这么做自己就跟着做的。项目管理、缺陷管理都需要有很深的技术管理知识作为支撑，否则是作不好的。 -
07年软件评测师考试心得
瑾瑾花园 发布于 2007-05-29 11:01:29
