软件质量标准_软件质量的思考
1.ISO9126软件质量模型（功能，可靠，易用，效率，可维护，可移植）
1.1ISO9126软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成，在工作中需要从这些特性和子特性去设计和实现一个软件。这个模型也是软件质量标准的核心，对于大部分的软件，都可以考虑从这几个方面着手进行测评。
2.软件质量铁三角（流程，技术，组合）
2.1流程：从计划到策略的实现，流程就是按照这种思维方式指导软件开发的，并且流程来源于成功的经验，可以指导项目少走弯路，从而提高软件质量，不仅如此，流程还对项目的成本和进度控制有很大的帮助 2.2技术：包括了分析技术、设计技术、编码技术、测试技术， -需求是项目的灵魂，良好的需求分析便是项目成功的关键所在，若是需求分析做不好不可避免的要出现返工； -设计，软件的质量是设计出来的，良好的设计基本上决定了软件产品的最终质量； -编码技术产生正确高效的代码； -测试是保证软件的一道防线。所以各种技术对质量来说都是很重要的 2.3组织：好的组织可以有效的促进流程的实施，同时提供员工的发展通道以吸引更多的人(技术的载体) 3.软件质量的思考 质量是设计出来的还是测试出来的？针对这个问题有这样一组讨论： A同学：我认为质量是设计出来的，在设计上考虑的各种功能和非功能质量数据，都会落地到代码中。设计的优化会不断的驱动系统质量的优化。 答：谋而后动的观点：无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析，都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。B同学：我认为质量是测试出来的，设计的东西可以避免已知的问题，但在实际测试的过程中，还是会发现其他未考虑到的问题，例如与软硬件兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动质量提升。 答：探索式测试的观点：无论是保证在设计变成代码的过程中是否100%的完成翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是希望所见即所得，想人之未想。B同学说得也对。 C同学：听完B同学的发言，我更坚信了质量是设计出来的。在不断的BUG驱动下，我们打补丁式做出来的系统，质量会更好吗？打补丁解一时之急，而后续系统性的设计、重构、升级，才是提升质量的关键点。 答：技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的升级，还是对基建能力进行优化，都是希望能够打好底盘，走的更远，走得更稳。C同学靠谱。
D同学：如果站到产品层面，我们会怎样去定义产品好不好？在我们定义产品好坏的质量模型里，很可能会包含软件研发相关的非功能质量属性(ISO9126)，可能会包括产品舆情、竞品对比中挖掘出的东西。例如，我们去定义一款内容推荐产品的好坏，除了“内容不重复”、“多样性”等维度外，“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准，新功能上线、满足需求，用户就会认为产品好。我们的认知会不断升级，“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈，让质量不断变好。 答：持续改进的观点：无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情，都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。 4.项目生命周期中的质量 需求阶段：检验质量的主要标准只有一个：满足使用者的实际需要。需要挖掘客户真实需求以及应用场景，做到用户常用爱用的功能或者功能点准确易用好用 设计阶段：在设计上正确理解客户的功能性需求，考虑的各种非功能需求以及异常场景的处理 开发阶段：选取合适的软件架构，做好代码审查，编写单元测试代码，进行单元测试、集成测试 测试阶段：依赖覆盖面充分的测试用例，注重系统测试、用户验收测试 运维阶段：及时收集、处理版本发布后客户反馈的市场缺陷，更新补丁，确保问题闭环，遵循PDCA循环持续改进 其实质量既是设计出来的，也是测试出来的，还是被逼出来的！
5 个常用的软件质量指标
在软件开发中，软件质量是衡量软件是否符合需求、标准的重要体现。除了 代码质量外，影响软件整体质量的因素还有很多。因此，要确保软件的整体质量，就需要在各个环节严格控制。 本文列出了衡量软件质量的5个最常用的指标。 1. SLOC（Source Lines of Code，源代码行） 计算代码行数可能是最简单的衡量指标，主要体现了软件的规模，并为项目增长和规划提供了相关数据。例如，如果每月统计一次代码的行数，就可以绘制一个项目发展概览图。当然，由于存在项目重构或是设计阶段等因素，这种方式并不太可靠，但是可以为项目的发展提供一个视角。 可以只统计逻辑代码行（Source Logical Line of Code，SLLOC），这样可以获得稍准确的信息。逻辑代码行不包含空行、单个括号行和注释行。可以使用 Metrics工具来统计。 代码行数不应该用来评估开发者的效率，否则，可能会产生重复、不可维护的或不专业的代码。 2. 每个代码段/模块/时间段中的bug数 要想实现更好的测试以及更高的可维护性，bug跟踪是必不可少的。每个代码段、模块或时间段（天、周、月等）内的bug可以很容易通过工具统计出来（如 Mantis）。这样，可以及早发现并及时修复。 Bug数可以作为评估开发者效率的指标之一，但必须注意，如果过分强调这种评估方法，软件开发者和测试者可能会成为敌人。在生产企业中，要保证员工彼此之间的凝聚力。 为了更好的实现评估，可以根据重要性和解决成本将bug划分为低、中、高三个级别。 3. 代码覆盖率 在单元测试阶段，代码覆盖率常常被拿来作为衡量测试好坏的指标，也用来考核测试任务完成情况。可以使用的工具也有很多，如 Cobertura等。 代码覆盖率并不能代表单元测试的整体质量，但可以提供一些测试覆盖率相关的信息，可以和其他一些测试指标一起来使用。 此外，在查看代码覆盖率时，还需注意单元测试代码、集成测试场景和结果等。 4. 设计/开发约束 软件开发中有很多设计约束和原则，其中包括： 类/方法的长度 一个类中方法/属性的个数 方法/构造函数参数的个数 代码文件中魔术数字、字符串的使用（魔术数字指直接写在代码中的具体数值，其他人难以理解数字的意义） 注释行比例等 代码的可维护性和可读性是很重要的，开发团队可以选择以上这些原则中的一个或全部，并通过一些自动化工具（如 maven pmd插件）来遵循这些原则，这将大大提高软件产品的质量。 5. 圈复杂度（Cyclomatic Complexity） 圈复杂度是用来衡量一个模块判定结构的复杂程度，已经成为评估软件质量的一个重要标准，能帮助开发者识别难于测试和维护的模块，在成本、进度和性能之间寻求平衡。圈复杂度可以使用 pmd工具来自动化计算。 圈复杂度数量上表现为独立路径的条数，即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护。 计算公式为：Cyclomatic Complexity = E - N + 2P E：边，代表节点间的程序流； N：节点，程序中代码的最小单元 P：出口节点
上图中共8条边，7个节点，因此圈复杂度为8 - 7 + 2*1＝3。可以看出，从最左边的节点到最右边的节点有3条不同的路径。在项目开发中，可以根据项目类型，来定义上限数（（6、8或10等）。
以上是最常用的5种软件质量度量指标，当然，还可以结合其他的指标，对项目有一个更清晰的认识。
https://blog.csdn.net/javady/article/details/84297184?spm=1001.2101.3001.6650.19&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-19-84297184-blog-117606822.235%5Ev28%5Epc_relevant_multi_platform_whitelistv3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-19-84297184-blog-117606822.235%5Ev28%5Epc_relevant_multi_platform_whitelistv3&utm_relevant_index=25
https://zhuanlan.zhihu.com/p/346958036
标签：代码,质量,测试,设计,软件,可以 From： https://www.cnblogs.com/sara20200116/p/17303953.html