软件质量的思考

​作为一个软件工程师,我们天天生产着代码。看着满天飞的软件技术。突然回过头来看看,感觉到迷茫的走了很多路,缺少了思考。

  1. ISO9126软件质量模型

ISO9126软件质量模型是评价软件质量的国际标准,由6个特性和27个子特性组成,在工作中需要从这些特性和子特性去设计和实现一个软件。这个模型也是软件质量标准的核心,对于大部分的软件,都可以考虑从这几个方面着手进行测评。

捕获2.JPG

  1. 软件质量铁三角

流程:从计划到策略的实现,流程就是按照这种思维方式指导软件开发的,并且流程来源于成功的经验,可以指导项目少走弯路,从而提高软件质量,不仅如此,流程还对项目的成本和进度控制有很大的帮助

技术:包括了分析技术、设计技术、编码技术、测试技术,需求是项目的灵魂,良好的需求分析便是项目成功的关键所在,若是需求分析做不好不可避免的要出现返工;设计,软件的质量是设计出来的,良好的设计基本上决定了软件产品的最终质量;编码技术产生正确高效的代码;测试是保证软件的一道防线。所以各种技术对质量来说都是很重要的

组织:好的组织可以有效的促进流程的实施,同时提供员工的发展通道以吸引更多的人(技术的载体)

  1. 软件质量的思考

质量是设计出来的还是测试出来的?针对这个问题有这样一组讨论:

A同学:我认为质量是设计出来的,在设计上考虑的各种功能和非功能质量数据,都会落地到代码中。设计的优化会不断的驱动系统质量的优化。

B同学:我认为质量是测试出来的,设计的东西可以避免已知的问题,但在实际测试的过程中,还是会发现其他未考虑到的问题,例如与软硬件兼容性问题,你能提前通过设计预防吗?所以测试发现问题,问题驱动质量提升。

C同学:听完B同学的发言,我更坚信了质量是设计出来的。在不断的BUG驱动下,我们打补丁式做出来的系统,质量会更好吗?打补丁解一时之急,而后续系统性的设计、重构、升级,才是提升质量的关键点。

D同学:如果站到产品层面,我们会怎样去定义产品好不好?在我们定义产品好坏的质量模型里,很可能会包含软件研发相关的非功能质量属性(ISO9126),可能会包括产品舆情、竞品对比中挖掘出的东西。例如,我们去定义一款内容推荐产品的好坏,除了“内容不重复”、“多样性”等维度外,“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准,新功能上线、满足需求,用户就会认为产品好。我们的认知会不断升级,“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈,让质量不断变好。

针对以上看法,其实是给出了针对软件质量的集中观点:

谋而后动的观点:无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析,都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。

探索式测试的观点:无论是保证在设计变成代码的过程中是否100%的完成翻译,还是在测试的过程中受到启发认为应该写下更多的逻辑代码,都是希望所见即所得,想人之未想。B同学说得也对。

技术债的观点:无论是对前段时间的补丁代码进行重构,还是对系统进行架构的升级,还是对基建能力进行优化,都是希望能够打好底盘,走的更远,走得更稳。C同学靠谱。

持续改进的观点:无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情,都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。

  1. 项目生命周期中的质量

需求阶段:检验质量的主要标准只有一个:满足使用者的实际需要。需要挖掘客户真实需求以及应用场景,做到用户常用爱用的功能或者功能点准确易用好用

设计阶段:在设计上正确理解客户的功能性需求,考虑的各种非功能需求以及异常场景的处理

开发阶段:选取合适的软件架构,做好代码审查,编写单元测试代码,进行单元测试、集成测试

测试阶段:依赖覆盖面充分的测试用例,注重系统测试、用户验收测试

运维阶段:及时收集、处理版本发布后客户反馈的市场缺陷,更新补丁,确保问题闭环,遵循PDCA循环持续改进

其实质量既是设计出来的,也是测试出来的,还是被逼出来的!

参考文章: https://zhuanlan.zhihu.com/p/40138584

欢迎关注【技术型项目经理】公众号。可获取软件行业动态、技术积累和项目管理理念文章分享。可在菜单中选择获取「PMP」、「高项」(信息系统项目管理师)、「CISSP」、「Python」、「GoLang」、「C++」学习资料。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章