Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

功能、模块质量和非功能性测试

Posted on 03/09/201106/23/2019 by 四火

prj 但凡面向终端用户的产品,产品做大了以后,几乎都要涉及到基线能力和定制能力的划分。任何一个优秀的产品,都要经历从相对无序到有序的逐步成熟的过程。产品的发展总是要经历不断的阵痛,可是时间长了,我还是总免不了思考:好吧,就算产品最初匆忙和艰辛的时期已经过去,就算现在基线能力的建设已经迈入正轨,可是为什么我们的直接客户,定制团队还是那么辛苦?

 

有多少功能是真正值得去完成、真正被用户所需要的?

据一位定制的兄弟说,其实这个比例只有 8%,我相信数据也许是不准确的,但不管数据的有效性有多少,至少,大家都在问,产品的定位是一个厚实的门户,有太多的功能需要完成,可是真正给客户使用到了多少呢?也许没有一位普通的开发人员可以估摸出个一二。这是一个产品做大以后的问题,我们离最客户的核心价值越来越远,我们不知道客户真正需要什么,我们只知道 SE 的规格,SE 了解到一线的需求,一线才去倾听客户的声音。既然如此,其中会有多少信息走样?客户需要一个小小的草莓蛋糕,一线传达下来也许是一个大大的苹果派,到了 SE 那里,苹果派变成了一大盒各种口味的奶油蛋挞,最后,我们开发则做出了整整一冰箱的牛奶冰激凌。

 

功能不该有优先级吗?

我们的功能在开发和测试的眼中,大多是一视同仁的,开发要保证每一个功能的准确性,和一定程度上的可用性;测试要保证覆盖到所有的功能点。可是客户很单纯,他们不这么认为,他们要使用网站,这意味着网站中有他们所关心的核心价值,这也是用户量保证的最简单的原动力。比如说,在迅雷上可以看到免费的电影,在优酷上可以看到最新的视频新闻,在人人网上可以建设自己的主页,和朋友交流…… 那么这些功能,就是相应这些产品最有存在价值的地方,这些功能,无论从质量还是进度上,应当被优先保证。回过头说,我们的产品,核心竞争力是什么?如果这个思路不和辛苦工作的开发、测试们理清楚,不和努力赶工期、拼进度的基线、定制兄弟姐妹们达成一致,我们怎么能保证产品做下去的方向,走在最大限度地满足客户所需的道路上?

 

模块质量应该怎么保证?

我一直很担心,对于质量的认识,有许多兄弟姐妹似乎陷入了这样的思考中:我是开发,为了提高模块质量,那么我首要提高代码质量,我要仔细地过转测试的 CheckList,我要对每个问题单仔细地修改、认真地审核;我是测试,为了提高模块质量,那么我要仔细过测试用例,我要认真检查接口调用、业务逻辑是否正确,给每个提出的问题单写全面、写规范。

呵呵,大家都是好同志,可悲剧的事情就这样发生了。首先,这样的质量是客户需要的吗?客户最看重的质量,兴许和我们最看重的质量相距甚远。比如,如果我是视频用户的客户,那么这个网站对我的核心价值,就是可以在上面看视频,那么我最迫切要求的质量,大概是视频的种类、播放视频的流畅度和清晰度。也许我们应该做一做这样的分析和思考。

其次,好的软件是设计出来的,好的质量首先也是被设计出来的,而不是靠大面积问题单改出来的!迭代回溯会议上,需要见到更多对问题数量的回溯。在 SE 疲于奔命梳理繁多的需求的时候,开发和测试理应站出来和 SE、UCD,甚至一线的人扯一扯,毕竟从局部层面上看,只有我们才是最了解这一小块产品实现的人,也是最该被赋予设计上的话语权的人。

 

非功能性测试有多重要?

所有的测试用例,都是面对功能性测试而言的,对于自动化测试更是如此,对于非功能性测试,覆盖率只有零。可是,对于用户来说,能引起他兴趣的功能往往就只有那么一个或几个,能留住他的,却要靠大量用户体验的改善和满足。早些时候看到一则讲腾讯产品的胶片,QQ 影音在诞生阶段,功能做得很简单,那么它凭借什么去和那么多的播放器产品竞争?我所知道的是,它的用户体验一直站在一个核心的地位,比如胶片中所述的一个例子:在全屏播放的情况下,用户点击左键会暂停播放,可是当用户先点击右键,把右键菜单调出来的情况下,屏幕上点击左键,却是取消右键菜单,同时并不暂停播放。正是这样细致入微的考虑,把产品做实做细,产品才有了可靠的用户群。

我们以前是做彩铃的,正如一位主管所说,彩铃产品最直接是面向运营商的,彩铃有什么问题,也许运营商会抱怨,乃至会投诉,但兴许还是会用我们的产品,因为由于种种原因,他并不一定有很多替代品可供选择。但是做门户,做直接和终端用户交互的产品就不一样了,用户是没有耐心的,遇到糟糕的用户体验,会丢掉信任,没有怜悯也没有太多机会,也许用户就这样流失掉了。

 

产品质量的定位。

产品质量当然是越优秀越好。可惜的是,各方面都想得越完美的东西,越难以实现。尤其当项目进度压力袭来的时候,在功能没法砍掉的情况下,必然导致质量的牺牲,那么我们都现实一点,如果质量不可避免地被牺牲,哪一些模块的质量该被优先保证?质量应该被保证到哪个不同的级别上?

呵呵,其中能够说水分最大的、最容易被进度压垮的,不就是非功能性的软件质量吗?比如,用户体验和性能。

 

让合适的人,做合适的事。

这个扯得有点远了,也许它是优秀的管理者在思考的东西。俗话说,人尽其能,物尽其用。产品中少数模块已经渐渐培养起相应的长期耕耘的田主、少数技能的专家,希望后续这样的人员和角色能够不断丰富,真正在自己的领地上具备权威和话语权,一起把产品做好。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. EasyMock、EasyMock Class Extension 和 PowerMock
  2. Java 多线程程序的测试
  3. 一道随机数题目的求解
  4. 谈谈 Ops(汇总 + 最终篇):工具和实践
  5. 做实际的测试

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme