qq_41854911的博客

插桩和打桩是机载嵌入式软件测试中两种重要的技术。插桩技术主要用于覆盖测试、性能分析和故障调试等方面，而打桩技术则主要用于单元测试和集成测试中模拟外部依赖。在实际应用中，开发者需要根据具体的测试需求和测试环境选择合适的技术和工具来实现测试目标。插桩是指在源代码中插入额外的代码（桩代码），以收集信息（如覆盖率、性能数据等）、改变程序行为或进行调试。在机载嵌入式软件测试中，插桩技术常用于覆盖测试，以验证软件在特定条件下的执行路径和逻辑分支。

Automotive SPICE（Software Process Improvement and Capability Determination）是广泛认可的汽车行业软件开发过程评估国际标准。ASPICE 为软件开发过程的评估和改进提供了一个框架，并确保为汽车行业生产的软件质量符合要求的标准。该标准对于旨在生产高质量软件的汽车公司至关重要，因为它有助于识别和消除低效率、改善沟通并降低成本。ASPICE 框架涵盖整个软件开发生命周期，从需求管理到软件测试和维护，帮助组织确保其软件开发过程高效且有效。

为了确保汽车中安全攸关（safety critical）系统的安全性和可回溯性（Traceability），以及为了明确责任认定， 汽车软件行业如今普遍采用了ISO 26262和ASPICE等标准，作为软件开发的方法和流程。汽车行业的供应商们多数采用传统的“瀑布式流程”或“V型流程”来进行软件开发，并编制出大量的相关支持文档。这套流程不仅繁琐，而且越来越不适用于如今快速变化的市场需求。而开发汽车控制软件毫无疑问是一个“系统工程”。

所谓的软件开发模型，其实就是开发软件所经历的各个阶段 ，一般都会包括：需求->设计->编码-测试-运行维护。当然，不同的开发模型会稍有不同 ，每个模型都有其使用场景以及对应的公司使用 ，每个模型都有其优缺点 ，同时每个模型所解决问题的侧重点不同。

数据字典（data dictionary）是对于数据模型中的数据对象或者项目的描述的集合，这样做有利于程序员和其他需要参考的人。分析一个用户交换的对象系统的第一步就是去辨别每一个对象，以及它与其他对象之间的关系。这个过程称为数据建模，结果产生一个对象关系图。当每个数据对象和项目都给出了一个描述性的名字之后，它的关系再进行描述（或者是成为潜在描述关系的结构中的一部分），然后再描述数据的类型（例如文本还是图像，或者是二进制数值），列出所有可能预先定义的数值，以及提供简单的文字性描述。这个集合被组织成书。

​ 集成测试（Integration Testing），也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。​ 集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合为程序的更大部分。方法是测试片段的组合，并最终扩展成进程，将模块与其他组的模块一起测试。

系统工程与需求工程

已剪辑自: https://xie.infoq.cn/article/6ba589a35f3685b2ec86957ce本文我们主要盘点在不同项目情况下使用比较广泛的 10 大需求管理工具：1.Excel；2.在线文档；3.PingCode；4.Worktile；5.Doors；6.jira；7.Polarion；除介绍功能外，还将对比其优缺点。在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。

尤其是近期GPT-4模型的发布所引起的AI浪潮，未来的需求工程或许能够从动态数据中提取需求，包括从自然语言生成需求、从需求工程的过程中挖掘需求、基于主动学习和半监督机器学习的需求特征分析。通过开展组织内外的需求评审，以确定需求基线，并在需求发生变更时，重新进行需求的获取、分析、定义和验证评审。结合结构化思维的面向整体、自上而下分类分析、逐步求精的思想，针对需求分析自上向下整理系统需求、软件需求类型和需求元素（属性），建立结构化需求结构和模型，形成管理系统/软件需求的模板，用于需求分析。

首先回顾下ARP4754A中需求的定义：需求是功能规范的可识别要素，这种要素可以被确认，且其实现可被验证。功能的定义如下：功能是产品的一种行为，这种行为基于一系列与实现无关的需求。\1. 功能与需求的区别：功能不是需求，功能表示一系列需求的集合。2.功能与需求的联系：所有的需求都是对功能的描述，或者说所有的需求都是功能需求。3.功能与需求的研发顺序：先定义功能，再从功能分析需求。

首先，我们看看需求捕获是什么意思。可惜的是4754A并没有对需求捕获进行定义，但是从5.3节的内容可以看出，捕获的意思不是得出需求的方法和过程，而是描述/记录需求的方式，通俗的说就是需求怎么编写。也就是说4754A的需求管理不管需求是怎么来的，只管需求有了以后用什么方式写下来。如果使用文本的方式捕获需求，那就要定义需求文档的模板，如果使用模型的方式捕获需求，那就要建立需求建模规范。不管是文档还是模型，都是需求的描述，由于捕获这个词会引起误解，将这个活动称为定义需求描述规范。

从研发过程看，需求是架构、实施、集成、验证等研发活动的基础。整个研发过程中会不断对需求进行迭代或者产生新的需求，如果需求没有被记录，则最终无法保证最终研发出有用的产品。从完整过程角度，需求也是构型管理、安全性评估、过程保证和合格审定等完整过程活动的基础。而且在完整过程活动的过程中，需求也会产生变化，需要将需求记录下来才能管理好需求的变更。由于需求在整个项目全生命周期中非常关键，所以需要以一致的方式将需求记录下来，以便在项目进展过程中对需求进行管理。

已剪辑自: https://mp.weixin.qq.com/s?本文按照需求分类的四个维度对ARP4754A的需求分类进行梳理和分析。

已剪辑自: https://mp.weixin.qq.com/s?你可能见过多种需求分类方法，怎么选择适合你的呢？

已剪辑自: https://mp.weixin.qq.com/s?在策划需求管理的时候，最初始需要考虑的就是需求的分类。需求的分类可以从多个维度进行划分，包括类型维度、抽象级别维度、方案独立性维度、追溯性维度等。需求有时指原子的需求条目，有时指需求集合。有些维度只适用于需求条目，有些维度只适用于需求集合。

软件需求分析也称为系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。软件开发一般包括：可行性分析、需求分析、软件设计、软件开发、软件测试、软件实施、软件服务等步骤，需求分时软件开发的第一步骤。用户需求分析是指在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。

敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

PMI-ACP考试是由PMI于2011年推出一门敏捷项目管理的考试，全称Agile Certified Practitioner。PMI经过多年调查发现许多项目需求不断地变更，成员小于10人的团队，套用以往"先做计划再做事"的思维，项目根本推不动。因此，PMI提倡采用敏捷(Agile)的方法管理充满变动的项目，并从2011年开始正式推出PMI Agile Certified Practitioner(PMI-ACP)认证，是项目经理能够具备快速应变的能力。

软件测试是一种检查软件产品是否符合预期要求并确保软件产品质量的方法。它涉及使用手动或自动化工具执行软件/系统组件，以评估被测产品质量。软件测试的目的是识别与实际需求设计不一致的错误，差距或遗漏的需求。有些人更喜欢将软件测试称为“白盒测试”和“黑盒测试”。简而言之，软件测试是指对被测应用程序（AUT）的验证。什么是软件测试？为什么软件测试很重要？软件测试有什么好处？软件工程测试软件测试的类型软件工程中的测试策略程序测试测试不是独立的活动，它必须适合项目选择的开发模型。

这不仅需要知道组织所需要的优先事项，还需要深入了解每种项目需要的管理方法，以及每种管理方法对组织在成功的路上所产生的非良性影响的程度。CMMI提供了一个单一的集成化框架，目的是为了改进一个组织的弊端，新的集成模型框架也消除了各个模型的不一致性，避免了模型间的重复，这一环节也增加了透明度，从而建立了一个可扩展的，自动型框架，从整体上改进这一组织整体的质量和效率。在开发的最初阶段，软件项目被分成多个子项目，每个子项目开发出来的成果需要经过严格的检测，它们拥有可视化、集成性的特点。

项目是指在既定的资源和要求约束下，为实现某种目标而相互联系的一次性工作任务，或者是我们为完成一件独特的事情所做的全部努力。项目管理其实是一个管理学科的分支 ，指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。项目管理是有效整合资源、高效实现项目目标的一整套独特的管理理念、方法论体系。项目管理实质就是关于“在复杂多变的环境中，做好一件事情”的理念和技术。

项目管理是指项目管理者在有限的资源下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。更具体地说，在从项目的投资决策开始到项目结束的全过程中，进行计划、组织、指挥、协调、控制和评价，最终实现项目目标。项目管理在20世纪80年代仅限于建筑、国防、航天等行业，目前已经应用到计算机、电子通讯、金融甚至政府机关等众多领域，发展非常快速。进入新时期，项目管理的发展呈现出了全球化、多元化以及专业化的特点，发展速度也超出了人们想象。

自然语言并不是表达需求的完美的方式。然而，它仍然是目前唯一的能够涵盖各种所需概念的通用表达方式。已剪辑自: https://mp.weixin.qq.com/s/Z5VBTyV6j07JylDdOsFSxQ。这些其他的方法也不完善：模型尚未能覆盖概念所需要的范围，表格的呈现格式，追溯和管理也都存在问题。事实是，如果仅仅是为了补充其他的表达方式，则仍然需要文本化需求。一条需求要完整地描述需求本身的内容。需求是对利益相关者期望的正确表达。需求描述的内容在本质上是可行的。本指南仅指文本化需求的表达。

作为公司代码委员会 golang 分会的理事，我 review 了很多代码，看了很多别人的 review 评论。发现不少同学 code review 与写出好代码的水平有待提高。在这里，想分享一下我的一些理念和思路。我这里先给一个我自己的总结：所谓架构师，就是掌握大量设计理念和原则、落地到各种语言及附带工具链（生态）下的实践方法、垂直行业模型理解，定制系统模型设计和工程实践规范细则。进而控制 30+万行代码项目的开发便利性、可维护性、可测试性、运营质量。

如何快速读懂开源代码？

原型图模板中师兄写了微信首页的需求文档，大家可以拿去参考，怎么写不重要，重要的是你要逻辑清晰，表述清楚，实际工作中多问问开发时如何看需求文档，他们有没有什么建议，就和我们做产品一样，多问问你的用户觉得你的产品如何。例如淘宝就有购买流程图，退货流程图，登录流程图等。说明本次开发要做的模块和功能，并对每个功能进行描述，让开发知道每个功能是干嘛的，更理解这个功能，功能多的时候就要对功能进行优先级排序。**边界：**这部分主要就是写一些特殊情况，例如无内容，名称过长显示不全，初始值，最大值，最小值，移动范围等。

• 编程不等于软件工程。软件工程是在时间、规模和权衡决策上的系统性工程；• 软件工程的三个特性：可持续性、规模性和复杂性；海勒姆定律和左移策略。

测试用例（Test Case）是为某个特殊目标而编制的 一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

已剪辑自: https://mp.weixin.qq.com/s/dbYmBOISjd7tzniVT2l_eg我们常常说，软件三分写七分调。实际开发中，确实也是这样子的。我工作这几年了，对这体会也越来越深。每当需求一下来，我代码很快就可以写完，但是，调试需要花很多时间。这里需要明确的是， 调试的目的不仅仅是调通整个功能需求。调通功能是最基本的要求，还需要进行优化、完善逻辑、完善异常处理。所以，需要非常长的时间。

需求是由个体在生理上或者心理上感到某种欠缺而力求获得满足的一种内心状态，它是个体进行各种活动的基本动力。需求理解的误区很多产品在讨论需求的时候，会流于表面，最常见的一个问题就是把解决方案当成了需求，对需求的理解挖掘一定要到心里状态这个程度。什么是产品所有的人造物都可以视为产品，为了满足人们特定的需求而生产出来。汽车是为了让你移动的更快；房子能为你遮风挡雨；衣服能为你保暖与遮羞；产品与需求的关系产品是为了满足人们的需求而被生产出来的，因为需求的驱动，才会使得用户需要产品。

已剪辑自:(, 1908-1970) 出生于纽约市布鲁克林区。美国社会心理学家、人格理论家和比较心理学家，的主要发起者和理论家,第三势力的领导人。1926年入，三年后转至攻读，在著名心理学家的指导下，1934年获得博士学位。之后，留校任教。1935年在任学习心理研究工作助理。1937年任纽约布鲁克林学院副教授。1951年被聘为布兰戴斯大学心理学教授兼系主任。1969年离任，成为加利福尼亚劳格林第一任常驻评议员。第二次世界大战后转到布兰戴斯大学任心理学教授兼系主任，开始对健康人格或者的心理特征进行研究。

电商所有模块中，订单系统是非常核心的一个子系统，决定了整个流程能不能顺畅的执行，起着承上启下的作用，其他模块都是围绕订单系统进行构建的。订单系统出问题，或者功能流程设计不完善、不准确，将会造成整个电商系统整体或局部业务流转不顺畅，甚至导致项目的失败。订单系统的作用是：管理订单类型、订单状态，收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作。订单系统业务的基本模型涉及用户、商品（库存）、订单、付款。

除了验证再加上芯片的各种测试，芯片的检查过程中的每个步骤目标和侧重点都是不一样的。因为越早发现问题越好解决，代价越小，前端验证发现问题最好改，越往后越难，到了测试阶段更难了，所以一般测试阶段发现问题就首先考虑的是使用时候怎么用软件规避过去，以及在下一版项目中改进的问题。测试针对的是“看得见摸得着的实体芯片”，所以检查不能光靠软件，需要搭建一个硬件电路系统，去让这个实体芯片“动起来”，才能对其进行检查、进行“测试”。，流片之后，“虚拟的”文件就变成了看得见摸得着的实体的芯片。”，这是很不专业的哦。

随着软件发布迭代的频率越来越高，传统的「瀑布型」（开发—测试—发布）模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。关于 DevOps 是什么，DevOps 的合著者 John Willis 写了一个非常好的帖子，在这里.

安全关键软件开发与审定之系统语境中的软件

软件工程化与机载软件适航审查实践之软件软件设计方法

软件工程化与机载软件适航审查实践之软件需求分析方法

《软件工程导论》之详细设计

《软件工程导论》之总体设计

剪辑与《软件工程导论 》