赵星汉同学的博客

挺简单的一个错误，也应该是很常见的错误，但在企业的内部单元测试、配置项测试、系统测试中居然都没有测出来（集成测试在体系中被裁剪掉了），一直到联调的时候才被发现。个人感觉这个错误，即使是进行人工走查，也不容易看出来，因为在调用时，5个数的排序也会下意识的写5，特别是如果A、B函数写在不同的位置，那么审查到B的时候很可能忘了A的实现细节了。我觉得在联试期间能发现这个错误，应该还是比较幸运的，毕竟这种指针问题，到底会导致什么不可知的错误，是非常难预测的，也可能会隐藏的很隐秘，直到关键的时候再爆发出来。

这两天写论文，其中有张图需要将三个属性连接到一个序列上，本来想用面积表达第二，颜色表达第三个属性，又尝试了用三维图，发现效果都不好。今天早上被一只蚊子弄的睡不着了，凌晨四点忽然想到干嘛不用单横坐标多纵坐标的形式解决呢。于是马上爬起来查阅相关文档完成了这一方面的内容，记录如下：直接上代码吧。最终效果如下：...

最近在做一个研究课题，其中的工作之一就是将需求分析文档中的功能点按照GJB8000中的要求进行标注，通过功能点来进行软件的规模预测和软件缺陷的预测。在没做之前，觉得这个工作应该不是很复杂，毕竟有很明确的方法，问题应该不大，而且功能点的计算相对还是比较成熟的，国内国际上也有很多案例。做过以后才发现，这东西是真TMD麻烦。1、一个软件的需求，哪怕是不大的软件（几万行），其软件需求也有上百条，如果来上十几个软件配置项，如果靠人工，真的能算死。2、软件功能点，最终的加权系数，人与人之间的衡量差距还是很大的，

再次学习GJB8000的功能点计算方法，将笔记记一下什么是功能点估算方法功能点估算方法是从用户角度来估算软件规模，是基于客观的外部应用接口和主观的内部应用复杂度以及总体的系统性能特征，对软件功能规模进行间接定量估算。GJB8000的功能点是通过IFPUG功能点估算方法进行估计的。功能点估算步骤确定用户功能需求分解功能需求确定加权因子计算未调整功能点数确定调整因子计算交付功能点数流程图如下：#mermaid-svg-ODEfGibjMfLs4REE {font-family:"

步骤计算每种类型的函数数量计算未调整函数点（UFP）找到所有影响角度（TDI）计算矫正因子值（VAF）找到功能点数量（FPC）计算下边所列出的各个类型的数量：外部输入：进入系统的与数据相关的功能外部输出： 从系统出去的数据有关的功能外部查询： 从系统中检索数据，但不改变系统状态的功能内部文件： 系统内部维护的逻辑文件，此处不包括日志文件外部界面文件：提供给我们系统内的其他程序使用的逻辑文件计算未调整的功能点 (UFP)：根据其复杂性对五种功能类型中的每一种进行分类，例如简单、

首先，在这里感谢浙大和华为的相关同仁，给予我这次学术交流的机会，在这里表示感谢。但是，这次交流我也有很多感触，就在这里对国内软件工程学术圈吐槽一番，仅仅是个人发牢骚，只陈述现象，不针对个人。首先，感觉学术圈很多老师的选题的目的有点太偏重于发论文了。这可能和现在高校的职称评定有关系。但是毕竟也是浪费很多人力物力的研究项目，咱们能不能与实际工程贴合更紧密一些？报告的议题中，与华为合作的题目我认为都还是很不错的。但是有些老师的题目却明显超出我的认知了。我是真不明白用AI分析代码，让其自动生成Commit里边的

摘录自前一篇文章中介绍的梅老师的书。1.软件定型测评大纲按照《军用软件产品定型管理办法》以及《GJB6921-2009《《军用软件定型测评大纲编制要求》的规定,列举一个具体的审查内容和要求参考示例如下:a)是否列出了文档的标识、标题、所适用的被测软件的名称与版本,以及文档中采用的术语和缩略语。b)是否概述了文档的主要内容和用途。c)是否描述了此次定型测评任务委托方、被测软件承研单位及定型测评机构的名称、地址、联系人及联系电话。d)是否概述了被测软件的等级、使命任务、结构组成、信息流程使用环境、安

读梅老师主编的书，觉得评审意见模板很有参考价值和实用价值，帮梅老师安利一波，顺便记一下笔记。《系统/子系统规格说明》评审意见模板20XX年XX月XX日，XXX（主管机关）在XXX（会议地点）主持召开了“《XXX（产品名称）系统规格说明》评审会”。参加会议的有XXX机关，XXX院校，XXX研究所共XX名代表（名单见附件1），会议成立了评审组（名单见附件2），听取了XXX（单位）做的《XXXX报告》。经讨论质询，形成评审意见如下：系统规格说明对系统的研制目标和范围、工作状态、运行方式以及所要满足的能力需

这两天在读谷歌运维，感觉相关内容很有参考价值，在软件工程里也有很强的知道意义，所以在此记一下笔记。什么是琐事当前手动性的，重复性的，可以被自动化的，战术性的，没有持久价值的工作，琐事与代码（产品）规模呈线性关系。琐事的特性手动性：如脚本里的每一个步骤可以自动执行，但是执行脚本如果是手动的，那么就可以被认为是琐事。重复性的：不停反复做的工作。可以被自动化的：如果计算机可以很好的完成该任务，或者可以通过某种设计或流程优化彻底消除某项任务的需求，那么这项任务就可以被认为是琐事。战术性的：琐事是突然

软件测试大纲检查单 是否有项目负责人，测试人员，质量保证人员和配置管理人员 文中是否有必要、适用、明显等模糊性文字。 测试需求是否全面覆盖了软件需求规格说明 除显性需求外，是否还存在未包含的隐性需求，如强度测试、余量测试等 测试依据是否涵盖了软件测评任务书、合同、用户手册或其他等效文件 测试项的各个子类中，是否描述了测试的覆盖范围与程度（等价类、边界值、覆盖率等） 是否确定了测试的终止要求，包含正常和异常的终止 是否建立测试项与测试输入的追踪关系 若适用，是否包含了测试数据的生成与验证，

本文翻译自NextBigFuture网站原文地址，作者Brian Wang，发表于2018年12月。肯特·内伯格（Kent Nebergall）在macroinvent.com上撰文。肯特在第21届国际火星学会年度大会上发表了有关逆向工程SpaceX的演讲，因此我们可以像埃隆一样加速前进。他首先关注Elon生成产品的一般过程。这是视频中肯特演讲的摘要。我建议您观看嵌入式视频并观看肯特的完整演讲。但是，这是我从肯特演讲中获得的主要收获。注意：Elon并未发明全新的方法。Elon确实从计算机软件开发或其

原文地址：英文版地址，作者作者Jake Edge，发表于2013年3月6日。文中灰色背景的是我的一些不成熟的看法，部分数据和资料来源于网络和相关论文，由于是非正式发表，也就不标注来源了，有兴趣的朋友可以自行查证，欢迎留言讨论。在2013年嵌入式Linux大会的第二天，SpaceX的罗伯特·罗斯（Robert Rose）谈到了“从经验中学到的航天器开发软件”。在演讲中，他讨论了SpaceX如何开发其基于Linux的软件，以完成将航天器送入轨道甚至最终超越轨道所需的各种任务。他说，Linux在SpaceX.

第十章 概率与统计分析1 概述在这章中，我们将试图去描述和故障树相关的概率与统计概念中的基本元素。这些知识也是故障树量化的基础。在这方面基础好的读者可以直接跳过本章去阅读第十一章，在后边需要的时候再来回顾对应的内容。我们现在先来讨论概率分布理论。我们首先会讲解二项分布，接着学习常规的分布原理，并重点学习一些在系统分析中常用到的特殊分布。然后我们将具备统计评估的基础知识。我们的表示法或许不是...

第八章 压力罐的例子8.1 系统定义和故障树构建在本章和下一章里，我们将用两个简答的例子来定义非预期事件。读者将看到在第V章的帮助下，故障树是怎样一步一步的建立起来的。在故障树的建立过程中，可以得到一些比较浅显的结论，但是详细的评估过程将在第11章才会介绍。考虑图VIII-1的压力罐的例子，里边有一个管道马达装置和一些相关控制组件。首先我们先看系统功能，系统的功能模型如图VIII-2所示。...

第六章 概率理论：关于事件的数学描述6.1 概述通过学习前边的内容我们已经奠定了故障树的基础，我么几乎已经可以开始进入一些真实的故障树案例教学。但是，因为我们在第八章和第九章的例子中不仅有故障树的构建，还有故障树的评估，所以我们必须在第六章和第七章先把评估涉及的数学概念讲清楚。第六章讲解了定量评估故障树所涉及的基础的数学知识：概率理论。概率论是故障树分析的基础，因为它提供了对事件的分析处理，...

第四章 故障树的基本元素4.1 故障树的模式故障树分析可以简单的描述为一项分析技术，凭借一个特定系统的非期望状态（通常是一个安全方面的关键状态），该系统会根据环境和操作的上下文信息来找到非期望事件发生的所有可信途径。故障树本身是一种图形描述方式，这种图形方式描述了各类导致预定义的非期望事件发生的故障的并行和串行组合。（The fault tree itself is a graphic mod...

文章目录第二章 归纳法概论2.1 概述2.2 部件计数方法2.3 故障模式和效果分析（Failure Mode and Effect Analysis, FMEA）2.4 故障模式效果和关键性分析（Failure Mode Effect and Criticality Analysis, FMECA）2.5 预先危险性分析（Preliminary Hazard Analysis, PHA）2.6 ...

文章目录前言第一章 系统分析的基础概念1.1 系统分析的目的1.2 系统的定义1.3 分析方法1.3.1 归纳法(Inductive Approaches)1.3.2 演绎法(Deductive Approaches)1.4 风险与陷阱1.4.1 子系统接口1.4.2 规程接口本文原书为Fault Tree Handbook，所有者为美国核管理委员会（NUREG-0492)。当时学习的时候感觉...

测试实施实践持续集成什么是持续集成为什么要持续集成持续集成的优势减少风险任何时间任何地点生成可部署的软件增强项目的可见性建立团队对开发产品的信心原则TDDATDDBDD结对编程DevOps测试实施实践持续集成什么是持续集成持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每...

算法设计数据结构前边的常规数据结构树树二叉树堆图蛮力法什么叫蛮力法冒泡排序递归与分治法树与图中的一些递归问题二叉树的遍历分治法的基本思想动态规划法基本思想贪心算法基本思想可解决的问题回溯与分支限界基本思想状态空间状态空间树迭代改进算法计算复杂性与NP理论近似算法参数化算法随机算法随机算法的含义设计的一般

测试实施实践持续集成什么是持续集成为什么要持续集成持续集成的优势减少风险任何时间、任何地点生成可部署的软件增强项目的可见性建立团队对开发产品的信心原则TDDATDDBDD结对编程DevOps测试实施实践持续集成什么是持续集成持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意...

软件测试中的组合策略组合策略是一种测试用例的选取方法，该方法是采用将被测件的输入参数根据一些组合方式进行组合来生成测试用例。不同的组合策略，生成不同的测试用例生成技术。 软件测试用例的生成技术有如下两种形式：对测试输入进行建模分析，按照测试目标将测试输入分成不同的子集，同一个子集中的软件行为都是相似的。这种测试用例生成方式叫做分区测试（partition testing）,软件测试中常...

softmax学习笔记定义维基上的解释和公式是： “softmax function is a generalization of the logistic function that maps a length-p vector of real values to a length-K vector of values” σ(z)j=ezj∑k=1Kezk(1)(1)σ(z)j=...

定义边界以边界外的业务目标定义系统边界，就是将系统看成一个整体，暂时忽略系统内的业务期望。 采用业务模块的缺点就是模块之间的耦合可能比较复杂，不利于提炼清晰的需求。第一步讨论第一个讨论从业务目标得出的边界是有明确的理由的，在边界内可以得出的用力也是有明确的依据的。 假设一个涉众的工作职责有10个，而其中5个是与业务目标相关的，则系统边界内只容纳这5个，其他的还是要依靠涉众自己执行。第二个讨论从业