收录了 软件质量 频道下的 50 篇内容
最近,Chappell & Associates的负责人David Chappell发表两篇文章,讲述了软件质量的一些不同方面:功能、架构和流程;质量与用户、开发人员和投资者的关系;以及随着时间的推移,外部软件和内部软件的缺陷会造成的影响。
微软发布了一项研究成果报告,对传统的软件工程神话提出了质疑。代码覆盖率真能改善产品质量吗?TDD会花费更多时间吗?分布式开发会给软件质量带来什么影响?断言(assertion)有用吗?
软件质量的黄金准则:宁可在upstream (上游,接近问题的根源层面) 推送补丁,也不要在downstream (下游,远离问题根源的层面) 解决问题。
长时间的工作制度、最后期限和团队的压力会影响敏捷团队交付的软件质量。我们做些什么可以防止这种情况发生,使团队能够改善他们的软件质量呢?我们的建议是:把范围和最后期限安排得松一点、采用拉动式系统、让大家放慢节奏并得到充足的休息。
复杂度直接反映了软件的质量和成本:如果代码复杂度比较高,那么这段代码的质量就会比较低,而且它的维护成本也会比较高。复杂度度量可以用来评估开发和测试活动,决定应该对哪里进行重构以提升质量和预防问题。
刘彪是微软测试技术团队的一名软件设计工程师,他在自己的博客上分享了Facebook如何提高软件质量的原则、手段和背后的原因。
无知是福,但对于软件bug而言,这种态度触及了底线。那些能够揪出bug并改善软件质量的,将收获客户极大的信任,更高的报酬,更低廉的维护成本,并且难以被其竞争对手替代。Laila Lotfi在本文中介绍了自动化错误报告是如何帮助他处理软件bug的。
本文讲述了保利威在不断建设完善的产品矩阵中,QA团队是对质量是如何思考和落地的。
最近,资深软件工程师Cagdas Basaraner在博客中总结了软件开发实践过程中常用的几个衡量软件质量的指标,包括源代码行数、代码段/模块/时间段内的Bug数、代码覆盖率、设计/开发约束等。
最近,由The Reg reader发起的一项调查结果表明,被调查者认为,在分布式开发所面临的问题中,“各方之间参差的技能水平”是继“交流和协作”之后的第二大挑战.而“各方在实施过程与实践中的水平高下”也位列前五名之内。
在Empirical Software Engineering杂志上首次发表的一篇研究报告声称:“看来TDD可以应用在多个领域中,并显著降低软件的缺陷密度,同时也不会明显降低开发团队的工作效率。”研究对比了4个在微软和IBM执行的项目,这些项目使用了TDD方式开发,并与没有使用TDD开发的类似项目进行了对比。
如何在更短的时间内发现更多的Bug。
为什么 Motiff 团队不选择传统的分支发布 + 人工测试方案?
大数据、AI与无知
要从最基础的编码质量做起,视高质量代码为尊严和个人声誉。
软件质量可达到的水平反映了一个组织的经营决策。有许多因素影响这个决策,包括开发、构建和测试环境的有效性,资源和相关技能、诚信、积极性和经验水平、商业协议,以及采用的流程和产能工具。
本文讨论了什么是质量,定义质量的五种方法,卓越的质量、基于价值的质量、基于用户的质量、基于产品的质量、基于制造的质量,并讨论了整个团队都应该对质量负责。许多团队都在质量和时间之间做权衡,如果你们一开始认为速度最重要,不关注质量,那么就很有可能长期进行大量的返工,会出现很多不可维护的代码,质量将更进一步地下降。
在软件开发项目中,常见的争论之一是花费时间来提高软件质量,还是集中精力发布更有价值的功能。
不论软件产品应用的领域是什么,不论我们用怎样的方式构建它,质量都是所有软件产品最为关键的方面。Ben Linders发布了一本新书,名为《What Drives Quality》,他在书中提供了具体的例子和可执行的建议,帮助我们甄别和提高软件产品的质量。
软件测试的目的就是为了“验证产品质量是否满足用户的需求”。但是搞清楚,用户的需求并不是一件容易的事,因此在软件测试行业发展的漫长历史中,需要一种方式能够积累广大测试工程师的经验。这里的经验就是如何验证用户的需求。这也促使软件质量模型的诞生。