收藏本站 收藏本站
积木网首页 - 技术学院 - 软件测试 - 网站黄页 - 常用手册 - 站长工具 - 技术社区
软件测试 > 业务知识 > 正文

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

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

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

热议:软件测试的价值&重构之惑

来源:互联网 日期:2013-12-14 16:00

  [Philonis高]在微博上发起了软件测试的价值体现在何处的讨论,[蛙蛙王子]则向大家提问:如何在实际工作中更好的重构

  软件测试的价值

  [Philonis高]在微博上表达了对软件测试价值取向的看法:

  很多人都说质量不是测出来的,这句话没错。不过,测试存在的意义其实有两点,创造价值和守护价值。质量要靠测试者来守护,而不是创造出来。“守护价值”存在于传统测试工作中;而“创造价值”,正是我们现在正在探索的。

  对于测试如何创造价值,或者说测试创造的价值是什么,很多人也有自己的看法。我预设的前提是,静态测试、需求评审等工作被划入“守护价值”,也就是将“创造价值”的范围缩小了,免得有哲学帝说一切工作都是创造价值。

  朱少民老师:

  守护价值和创造价值说得好!创造价值体现在基于客户的立场提出积极的质量反馈意见,以及对缺陷的分类、分析,总结出缺陷模式,回馈到前期过程,预防缺陷。

  原草莫莫:

  认同。我们现在搞的故障模式测试就是这样的一个实践。测试不依赖于开发的上游输入,通过反向验证推动产品质量改进。测试在产品也愈来愈有话语权。

  还有就是,当质量标准往往很难定义的时候,这个时候往往测试标准就成了产品潜在的质量标准。通过测试对产品质量作出诠释,这实际上也是一个引领开发、创造价值的过程。当然前提是测试对质量标准有足够的理解。

  Ang-Ani:

  测试当然创造价值。如在V model 中所谓的静态测试,review用户需求,及早发现需求中的defect,就是创造价值。如在敏捷测试中,测试结果反馈到下一个iteration,也是创造价值。再如测试驱动开发中,测试主导着开发过程,当然创造价值。

  质量就是测出来的。但是要知道何时测,测什么,如何测。不能把测试局限于后期的execution。从项目开始的最初,测试作为一个activity就应该存在,测试包括,静态的review 用户需求、技术文档及代码,动态的单元测试及非功能测试..如果脑海里只有waterfall模式:design code test,那么质量只能靠天收。

  梅万龙:

  “质量不是测出来的”——质量主要是靠设计的,有些产品还是得靠测试去发现,这也可以说质量是测出来的,而通过设计分析预防,测试维度分析预防成本更低,我们更乐于说,来通过预防来保证质量,而不是傻呼呼的都靠去测。

  “质量要靠测试者来守护”——质量是靠整个团队来守护,测试只是其中比较大的"发动机"。产品有比同行更好的质量,不就是要探索的价值吗?否则,不能从岗位角度看价值,得从人的职责和能力角度找价值了。

  Aullyxiao:

  这种情况也遇到不少,最后是项目经理确认某需求问题不找需求人员,而是找测试人员了,而测试人员直接找用例库,可想而知用例库的重要性和作用。这样思考之,探索式测试由于在事先没用例,事后补充的测试记录比较有限,也是一个限制。

  陈尚义:

  质量不是测出来的,这句话对传统产品是无可挑剔的正确,我见过纺织厂的质量检测人员,他们发现了错误就不能改,质量检测员当然不能提高质量。但对软件产品情形就不太一样,测试发现了问题马上就得到改正,这就提高了质量。另外,软件测试涵盖的范围很广,测试还可以建立对产品质量的信心。

  让测试飞起来:

  软件的历史是隐藏细节的历史。从routine到子程序,到procedure,到函数,到类(抽象类、接口)、到SOA,再到今天的云,无一不是将简单留给用户或后来的调用者,将细节隐藏。云计算将资源调度、管理、运维、安全保障、应用开发等细节隐藏,用户按需使用即可,一种到目前为止最高级别的细节隐藏。

  Frank-Lin:

  分析用户及其习惯,从用户角度进行测试和评估系统,从而,测试不仅仅是守护价值,推动了价值的创造。

  重构之惑

  [蛙蛙王子]在微博中向大家提问:

  看到代码中的坏味道,做到立刻重构,感觉太难了。书上说一个敏捷开发的人,从来不说稍后再重构,稍后等于永远不,他们不会看着软件走向腐化。认同是非常认同,实际中做的话,感觉哪儿都需要重构,坑太大了,而且还得先补测试,大家怎么来按部就班重构没测试的老系统的?

  乐淘网丁学:

  我一般是不会要求大家去做重构,但是会要求遵守童子军规则:永远保持离开时的露营地比你发现它时更整洁。

  软软的胖糖:

  如果是一个新系统,大家按照这个原则去做就不会有这个问题了。当然如果个别人做,坑太大了那也是没办法的事情。

  横刀天笑:

  除非你有一个非常能接受这种做法的团队,不然这种看见不爽就重构只会死的很惨。当然,如果你要染指某块代码,你可以乘机重构~

  wolvever:

  我们花了2年重构,边重构边开发新功能。所谓高速列车上换轮子,外科手术式重构。不分支,先易后难,影响小依赖少的优先,还要考虑业务发展,保证每次重构部分随时可以上线。时机很重要,不是看见就改,修改代码必须立项;不是一次改彻底,一定得容易可控周期短;不是纯技术问题,要与业务充分沟通。

  飞林沙:

  我觉得更现实的做法是当出现新需求时,如果原有代码无法适应需求,那么则为了适应这个需求重构。

  TW张逸:

  我认为重构必须把握几个原则:

  1、重构需要有测试的保护网,每次重构后必须跑一下测试;

  2、代码库的集体所有权;

  3、最好能有CI,至少保证频繁提交,避免因为重构引起的大量冲突;

  4、重构应随时进行;

  此外,还有一些比较好的实践,例如每日的Code Review;尝试尽量使用工具进行重构。

本周排行

别人正在浏览

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