收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 其它管理相关 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

关于测试的问与答(下)

来源:互联网 日期:2014-01-24 11:30

  我问:什么测试才是良好的测试呢?

  神说,你觉得呢?

  我说,测试的目的是发现缺陷,所以发现的缺陷越多,那么测试越好。

  神说,然后呢?

  我说,我会告诉测试人员,啊哈,你们发现的缺陷越多,我就发给你们越多的奖金。

  神说,上帝啊,又是一个糟糕管理的绝佳范例。

  我说,恩,这样对测试人员来说,一个低劣的系统对他们的价值最高,他们会爱上那些糟糕的开发人员,引发办公室恋情。这和整个团队的目标-交付高质量的系统矛盾,并会在开发部门和测试部门之间引起矛盾和争执。还有,发现的缺陷会增加,但是获得信息的质量却降低了。

  神说,你混淆了测试的目的,测试的目的不是发现缺陷,而是获取我们所需要的信息。作为对比,如果你所有体检的项目都正常,你会觉得体检没有价值吗?

  神说,测试只是采样,所以良好的测试需要能够根据上下文覆盖系统中最重要的部分,而且又不能膨胀到不可管理的地步。另外,多样化样本发现的问题可能超过大样本发现的问题,同样,测试团队多样化也可能发现更多的问题。

  我说,想起来了,我们在体检的时候往往会有不同的检查套餐,例如针对白领的,会着重检查胃和颈椎;针对40岁以上人群的,会增加癌症因子筛查。也就是测试并不是一个孤立的行为,它需要根据不同的情况采取不同的策略。而且,我们总希望体检时不用花太多的钱。

  神说,“良好”并不是属于某个测试的属性,它只能是测试、实现、成本和应用场景四者之间关系的属性。作为比较,系统上线后用户的使用可以看做是测试的继续。

  我说,你的意思是我们可以对系统在使用中出现的缺陷加以追踪,然后进行统计和分析,例如测试比较典型的遗漏了哪种缺陷,而哪种测试实际上是没有太多必要的,因为用户根本都没有使用该功能。这样,以后我们就可以对测试加以改进。

  我问:那么,我们需要对所有缺陷都跟踪记录?

  神说,你们没有对所有缺陷都跟踪记录?

  我说,有些缺陷太小了,例如拼写错误,有些缺陷很容易就修复,所以测试人员就直接和我们说了,没有填写缺陷记录。

  神说,你怎么看?

  我说,我觉得还不错,没有一个开发人员愿意自己的程序里出现错误,我们往往把程序看成了自己的扩展,指出程序有错误就是在指出我有错误,所以,对于一些很小、由于疏忽引起的错误,测试人员直接和我说而不记录让我感觉好一些。

  神说,缺陷只有在系统交付后才成为错误。

  我说,好吧,可是报告我的程序出现缺陷会让我受到批评。

  神说,那是另外一个关于团队管理的问题了。如果一个人花在指责其他人上面的时间越多,那么解决该问题的可能性就越低。

  我说,可是,我们应该反对文档,文档阻碍了交流,实际上没有太大的价值。

  神说,文档在不使用的情况下才没有价值。一些人反对的不是文档,而是反对自己写文档。信息在文档化之后才能被追踪和统计,特别是作为项目信息一部分的缺陷信息,它反映了项目的状态,一定不能够被忽略,如果为了“节省时间”和“面子”而不记录缺陷,那么导致的结果就是项目状态的丢失,会给项目后续的判断带来影响,以后会浪费更多的时间和金钱。

  我问:好吧,如何避免测试困难呢?

  神说,你觉得是大的系统容易测试还是小的系统容易测试?

  我说,当然是小的系统容易测试。

  神说,那么,让系统尽可能的小。

  神说,第一,让需求受控。这是一项很重要的管理工作,如果没有很好的完成这项工作,那么就是管理上的失败。

  我说,这似乎很困难,因为客户总是在要求我们加功能。

  神说,如果在项目后期要求增加功能,而这项功能又是必需的,那么实际上是在告诉我们需求分析出现了问题,出现了需求遗漏。而一项功能如果最终因为各种原因其实不能使用,那么也是需求分析出现了问题,出现了需求幻想,脱离了实际情况。

  神说,要控制需求的增长,需要决策者、需求分析人员和客户来区分某件事对客户来说真的是必需的,需要价值驱动。

  神说,第二,不要试图在软件中处理所有的可能情况。

  我说,我们需要向新系统中导入遗留数据,如果在程序里包含对所有数据的处理,非常复杂,最后我们选择了手动处理部分数据。

  神说,第三,代码质量。最好的实现永远是最简洁的代码,要尽量减少代码的复杂性。两个具有相同物理规模的程序在内部复杂性上可能有极大的不同,而这最终会是决定测试工作难度的主要因素。

  我说,我们可以通过增量构建,不一次做所有事来控制代码的复杂性。

  神说,此外要注意组件之间的分离,特别是多团队协作的项目。

  我说,是这样的,很多项目会划分以模块为单位的小组开发,小组之间、模块之间要尽量减少依赖和不必要的沟通,因此代码可以有冗余,每个开发小组都要各自独立,有自己的分析人员、开发人员和测试人员。

  提到增量构建,我有了新的问题。

  我问:我们现在采用迭代式开发,那么每次迭代完成后对客户的演示能不能算是用户验收测试呢?

  神说,演示不是测试。

  我说,客户触摸到了真实的系统,直观了解到了系统的功能和使用方式,获取了系统信息,然后进行反馈,这可以看作是部分用户验收测试。

  神说,对客户来说,如果没有真正的使用该系统,那么就没有进行测试。此外,客户获取的信息难道不是你们准备好的吗?

  我说,演示之前我们会进行准备工作。

  神说,实际上是在准备客户能够获取的信息。

  我说,那么最理想的迭代开发应该是持续部署?

  神说,持续部署和持续增量使用。

  我叹了口气,说,额滴神啊,看起来测试真不是一件容易的事。

  神说,额滴上帝啊,测试就从来没有容易过。

相关链接:

关于测试的问与答(上)

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的! 友情链接:b2b电子商务
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号