深知概念的理解对于日常工作的意义不是很明显,但还是忍不住想琢磨概念,这是自己的思维模式与习惯。
所以,今天快速梳理下软件质量保证SQA的相关概念。
第一步,什么是软件?最本源的问题,它和人类创造的其他事物有何区别。
IEEE(电气电子工程师学会)对软件的定义为,软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据,其包含计算机程序、规程、文档和软件系统运行所必需的数据4个部分。
普适的定义往往比较抽象,仅能作为一个泛泛的概念。对比硬件的东西,软件数据逻辑产品而非物理产品,所以会有些特定的特征。
首先,软件是开发产生的,而不是用传统方法制造的,对于传统制造业而言,大量的人力物力都会投入到工厂里,而软件基本不存在这种标准化制造的概念,主要工作是集中在开发阶段,这也决定了软件领域和传统制造业领域完全不同的方法 论和模式。
其次,软件不会像物理硬件那样会有“浴盆曲线”表征的随时间变化的磨损失效规律,但软件会退化,这是因为软件在整个生命周期会不断经历变更,而在变更过程中会引入新的错误,在故障率恢复到之前稳定状态前,错误的修改又会引入新的错误,如此反复,软件的最小故障率开始提高,也就表现出所谓的退化。
插一句,说实话,对于这个软件退化理解得不是很明白,所谓Bug越修越多,为什么呢?
查了一些解释,还是没能很好说服自己。不过,自己大抵是这样理解的,任何设计,包括程序代码,在初期设计时,都是综合考虑了很多边界约束条件得到的一个平衡,各个参数间都会有依赖关系,正所谓,牵一发而动全身,在修Bug阶段,由于专家有限、时间压力、程序员偷懒等多方面因素,很难做到全面系统分析,所以统计数据下看到的是Bug越修越多。
最后,软件里的零件互换性和标准化还远不如电子硬件和机械结构领域,对于后者,构件复用已经是非常成熟和通用的了。
第二步,同样是很高层级的概念,什么是软件工程?
再次引用IEEE的定义,软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程,即将工程化应用于软件中,以及前述方法的研究。这个解释依然费解,换个角度讲,软件工程是一种过程、方法和工具的层次化技术,而支持软件工程的根基又在于对质量的关注,或者说为建造高质量的软件提供一个框架就是软件工程的目的。
过程层是是软件工程的基础层,它是凝聚力和实际体现,也是软件项目管理的基础,也即常规意义的流程;方法层是定义了如何实现,外企里常称为Knowhow,或者授之以渔的“渔”;而对于工具层呢,顾名思义,就是各类支持工具,就像没有CAD之前,绘图靠手绘,设计原则都是一样,只不过CAD能够更快捷和准确,不同的工具针对不同的需求,当工具被集成起来使得一个工具产生的信息可以被另一个工具使用时,一个计算机辅助软件工程系统就建立了,它集成了数据库和提供了软件工程环境。
步入到主题部分,软件质量。前面提到过软件工程的目标就是构造高质量的软件,那么怎么理解软件质量?克劳士比有这么一段回答:质量管理的问题不在于人们不知道什么是质量,问题在于人们认为他们自己知道什么。软件质量有这样的特征:每个人都需要它(当然,是在某种条件之下)。每个人都觉得自己理解它(尽管人们不愿意解释它)。每个人都认为实行它只需遵从自然的趋势(毕竟我们不管怎样都还做得不错)。当然,大多数人认为这一领域的问题都是由他人引起的(假设只要他们花了时间就能把事情做好)。
果然是大师,尽管翻译都有点拗口,但是很好地打到了质量的点,一定程度上,让自己对这个一直想不太清晰的概念触摸得更充分了些。
此外,软件质量可以从三个方面来看,1. 结构清晰,便于软件人员阅读,以及对用户有友好的人机界面;2. 能够按照要求工作,并满足特定标准的功能和性能指标;3. 符合开发标准,并且文档齐全。
还可以从另外的角度,即软件产品是如何生产出来的来间接地推断软件质量,称之为软件的过程质量,CMMI、ASPICE都是从过程角度来探讨软件质量和质量改进的。
那么,再进一步,什么是软件质量保证?它是一种应用于整个软件过程的保护性活动,包括一种质量管理方法、软件工程方法和工具、技术评审、测试策略、文档控制、流程符合以及度量和报告......
SQA(SW Qualify Assurance),它并不负责生产高质量的软件产品和制定质量计划,这些都是开发人员的工作,SQA是负责审计质量活动并鉴别活动中出现的偏差,主要包括SQA审计与评审、SQA报告和处理不符合问题。
有这么句话,SQA的主要作用是取得管理者(内部质量保证)或客户(外部质量保证)的信任。初看时,非常疑惑,QA和信任有什么关系。
为此,特意从网上摘抄了QA的各种定义,如下。
中国质量管理协会的定义是:“企业为用户在产品质量方面提供的担保,保证用户购得的产品在寿命期内质量可靠。” 美国质量管理协会(ASQC)的定义为:“QA是以保证各项质量管理工作实际地、有效地进行与完成为目的的活动体系”。 著名的质量管理权威、美国的质量管理专家朱兰(J.M.Juran)博士认为:“QA是对所有有关方面提供证据的活动,这些证据是为了确立信任所需要的,表明质量职能正在充分地贯彻着。” ISO8402:1994中的定义是“为了提供足够的信任表明实体能够满足品质要求,而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。
朱兰和ISO的定义都提到了信任,我们暂且往这个定义上理解QA,尽管经过了我的绞尽脑汁,但还是没想透。
姑且尝试下,外部QA似乎更容易理解些,如果作为供应商,要为客户提供相应的测试报告,目标当然就是为了赢得客户对其质量的信任,从而获取更多订单。那么,同理切换到内部,各类QA活动不也是为了证明做得够“好”吗,向谁证明呢?似乎也就是管理者了。这样一看,“信任说”貌似通了些。
点到为止,以后在更多的实际工作中去体会吧。
接下来看一下软件测试的方法。
从是否需要执行被测软件的角度,分为静态测试和动态测试,前者包括代码检查、静态结构分析、代码质量度量等,后者包括功能确认与接口测试、覆盖率分析、性能分析等。
从测试是否针对系统的内部结构和具体实现算法的角度,分为黑盒测试和白盒测试。黑盒测试也称功能测试或数据驱动测试,它不关心程序内部结构,测试者在程序接口进行测试,确认程序功能是否正常,是否能适当地接收输入数据产生正确的输出信息。白盒测试也称结构测试或逻辑驱动测试,测试者知道软件内部工作过程,通过测试确认软件内部动作是否按照要求进行,而不考虑功能是否正确。灰盒测试介于二者之间。
从软件开发阶段的角度,又可以分为需求测试、单元测试(人为定义的最小可测试单元,如函数)、集成测试(组装后的系统)、性能测试、压力测试(资源超负荷情况下)、容量测试(在超额数据情况下)、配置测试(不同软硬件环境下)、回归测试(确认变更)、安装测试(升级、安装、卸载)、安全性测试(非法授权的用户访问时)。
最后一个问题,质量保证和质量控制的区别?
质量保证和质量控制都是质量管理活动的一部分,两者都以满足质量要求为目的,但是,质量保证活动侧重于为满足质量要求提供使对方信任的证据,而质量控制活动侧重于如何满足质量要求。
因此,从某种意义上说质量保证和质量控制是为达到同一目的的两个方面。例如,对供方的评价选择是组织为了使采购产品满足要求的一种质量控制活动,而如果向顾客提供了组织对供方评价的记录,则可认为是一种质量保证活动。
后记:整体来看,这篇文章是不满意的,内容堆砌,而没能很好地融汇贯通,且留作一篇素材吧,留待日后使用。