目前为止,我们已经了解了软件质量保证是通过保证过程来保证最终产品的质量,并且简单了解了常用的软件开发模型,也就是我们说的“流水线”。在进行更深入的探索之前,我们先来了解下质量相关的几个概念:
软件错误/人为错误:软件错误指软件生命周期内出现的人为错误。人为错误将导致软件缺陷的产生。大虾还是喜欢使用“人为错误”这种表达方式,强调“人”的问题,而没有甩锅给“软件”。
软件缺陷:任何未满足与预期或者规定用途有关的要求。
软件故障:从系统角度看,指系统发生故障。
软件失效:从用户角度看,系统无法为用户提供某种正常的服务。失效可能由软件缺陷引起,也可能由人为因素,硬件故障等引起。
Bug:同缺陷。程序员常用来特指代码缺陷。
以上这些概念,可以用一句话来总结:人为错误将引入一个或者多个缺陷,缺陷在特定情况下被激活形成软件故障,如果未对软件故障进行有效隔离,影响用户使用,则导致软件失效。希望同学们能记住这句话,因为很多人都分不清这几个概念,偶尔装下X也是很好的嘛。
另外,再稍微扩展下,Bug会给人轻描淡写的感觉,而缺陷,故障,事故这几个描述给人严重性逐级加重的感觉。沟通的时候,选择合适的词汇非常重要,尤其是汇报的时候。比如:你会跟同事开玩笑说:我很擅长写Bug,大家听了都会会心一笑。而如果你说:我很擅长整点缺陷或者时不时搞个事故,大家可能会很震惊的看着你。汇报的时候更要注意,如果搞出个大事情,你的标题写着“针对某某Bug的分析”,我想领导肯定会认为:你没有深刻吸取教训,怀疑是不是处罚的力度还不够哈。这种场合“针对某某故障的分析”就比较合适,没有特殊原因一定不要特意使用“事故”这个词,本来领导没有那么当回事,一看报告写着“事故”,那就不得不认真对待了。当然你回头在项目组内部总结的时候,可以使用“事故”,先从气势上把大家镇住,然后臭骂一顿,让大家长长记性。如果只是使用“Bug”,我想也骂不出口吧,毕竟谁没写过Bug呢。
理清以上这些概念后,我们知道:为了提高质量,我们应该在软件交付前,应尽可能多的发现并修复缺陷。同学们做好准备哈,马上就要进入正题啦。
拒绝碎片化知识,订阅本专栏(免费)并关注大虾,系统化学习程序员需要掌握的质量知识,一起感受不同于技术的别样魅力,拓宽视野,为职业发展打好基础。