AICon 北京站 Keynote 亮点揭秘,想了解 Agent 智能体来就对了! 了解详情
写点什么

2012.3.6 微博热报:测试的价值 & 重构之惑

  • 2012-03-05
  • 本文字数:2229 字

    阅读完需:约 7 分钟

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;尝试尽量使用工具进行重构。

今日微博推荐

朴灵

推荐理由:Node.js 和Javascript 技术的热情实践者和布道师, EventProxy 库作者,主持 InfoQ 中文站《深入浅出Node.js 》专栏,在微博经常发布和讨论有关Javascript 前后端技术的最新发展和实践经验。

欢迎读者关注 @InfoQ ,推荐热门话题,可私信 @InfoQ ,同时请您说明推荐理由。

2012-03-05 08:572631
用户头像

发布了 501 篇内容, 共 271.7 次阅读, 收获喜欢 62 次。

关注

评论

发布
暂无评论
发现更多内容

Linux 的 IO 通信 以及 Reactor 线程模型详解

Linux服务器开发

reactor 后端 多线程 Linux服务器开发 网络io

想提升查询性能?openLooKeng新下推框架助您一臂之力

LooK

存储优化补充篇:Explain索引优化实操

Coder的技术之路

高并发 高并发系统设计 项目实战 数据库调优 索引优化

PHP文件包含小总结

Thrash

安全

技术探索系列 - 轻松带你掌握JMM(2)

码界西柚

JVM JMM 5月日更

消息队列架构设计文档

方堃

「技术人生」专题第1篇:什么是技术一号位?

阿里巴巴中间件

技术 程序人生 方法论 思维

架构实战营 - 模块三作业

Sun

中国式美好假期:用AI地图,抢先体验未来出行

脑极体

辞旧迎新岁岁新

Thomas

matlab

程序员应如何打破平庸,杜绝淘汰,避免内卷!【强烈建议收藏!】

程序员 ios开发

架构实战营 -- 模块三

永佳

架构实战营

消息队列详细架构设计

Lane

【得物技术】软件工程与PlantUML实战

得物技术

软件工程 UML PlantUML 实战 得物技术

基于 MySQL 的消息队列系统架构设计文档

小遵

AI英雄出少年!奔赴星辰,他们正在创造黄金时代

百度大脑

AI

分解的三要素,从经典中感悟

顿晓

5月日更 分解

惊呆了!阿里自爆2021年度九大Java技术合集,Github上已获赞98.3K

Java架构师迁哥

华仔架构训练营作业(模块三)

不听不听王八念晶

私域流量这件事,古代就有了……

白洞计划

数据架构:数据冷热分离实践思考

程序员架构进阶

数据架构 架构设计 28天写作 5月日更 冷热分离

模块1作业

圆心角

内卷

Jxin

如何做好用户画像?

石云升

创业 用户模型 5月日更

看了小姐姐的Spring SPI 总结,双非渣硕的我差点跳起来,被征服了

牛哄哄的java大师

Java

太好用了!斩获3个大厂Offer后,才发现学霸给的JVM笔记有多强大

飞飞JAva

Java

网络攻防学习笔记 Day7

穿过生命散发芬芳

5月日更 网络攻防

求求你别再用 MySQL offset 和 limit 分页了

xcbeyond

MySQL 5月日更

Nginx-代理服务器

进击的梦清

nginx Docker Linux Docker-compose 代理

架构实战营模块三作业

竹林七贤

基于OpenPAI细化部署 Hadoop 集群

Damon

hadoop 5月日更

2012.3.6 微博热报:测试的价值&重构之惑_架构_崔康_InfoQ精选文章