2021系统分析师论文题目记忆

试题一：论面向对象的系统分析方法及应用

OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA的任务是“做什么”，OOD的任务是“怎么做”。

建立用例模型：

• 识别参与者：
  参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
  （1）其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。例如，对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者。
  （2）硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。例如，在开发集成电路（Integrated Circuit, IC）卡门禁系统时，IC卡读写器就是一个参与者。
  （3）时钟：当系统需要定时触发时，时钟就是一个参与者。例如，开发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
  要注意的是，参与者一定在系统之外，不是系统的一部分。可以通过下列问题来帮助系统分析师发现系统的参与者：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁关闭这个系统？哪些（其他的）系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事情自动在预计的时间发生？
  执行系统某项功能的参与者可能有多个，但这多个参与者在使用系统时会有不同的职责划分，根据职责的重要程度不同，有主要参与者和次要参与者之分。主要参与者是从系统中直接获得可度量价值的参与者，次要参与者的需求驱动了用例所表示的行为或功能，在用例中起支持作用，帮助主要参与者完成他们的工作，次要参与者不能脱离主要参与者而存在。开发用例的重点是要找到主要参与者。
• 合并需求获得用例
  将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。首先，要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏；其次，进行合并操作。在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作。合并后，将产生用例。将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架，如图11-10所示。
  图11-10　用例图示例
  在确定用例的过程中，需要注意以下问题：
  （1）用例命名。用例的命名应该注意采用“动词（短语）＋名词（短语）”的形式，例如，“开通课程”和“课程测试”等。而且，最好能够对用例进行编号，这也是实现需求跟踪管理的重要技巧，通过编号可以将用户的需求落实到特定的用例中去。
  （2）不能混淆用例和用例所包含的步骤。例如，“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
  （3）注意区分业务用例和系统用例。当针对整个业务领域建模时，需要使用业务用例，其中会涉及大量的人工活动，例如，在线教育平台系统中有一项重要工作是“编写教材”，这就是业务用例，是信息系统无法完成的。信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，因此，只需要识别出系统用例，而不需考虑业务用例。
• 细化用例描述
  用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，其他的还可以包括非功能需求和用例优先级等。
  一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时可以对用例进行分组。UML使用用例主题划分用例图，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
  用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于一些不重要的用例，可以留待以后再补充完成。用例描述通常包括以下几个部分：
  （1）用例名称。用例名称应该与用例图相符，并写上其相应的编号。
  （2）简要说明。对用例为参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。
  （3）事件流。事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。在编写时应注意使用简单的语法，主语明确，语义易于理解；明确写出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；从俯视的角度来编写，指出参与者的动作，以及系统的响应；描述用户意图和系统职责，而不叙述具体的行为和技术细节，特别是有关用户界面的细节。
  执行一个用例的事件流有多种可能的路线，其中主事件流（基本事件流）是指能够满足目标的典型的成功路径，主事件流通常不包括任何条件和分支，符合大多数人的期望，从而更容易理解和扩展；备选事件流（扩展事件流）也称为备选路径，是完成用例可能出现失败的情况、分支路径或扩展路径，为了不影响用例活动清晰的主线，将这些分支处理全部抽取出来作为备选事件流。例如，在“开通课程”用例执行的过程中，如果学员所交的费用多于所选修课程规定的费用，则需要把多余的费用转换为学习币；如果学员选修课程数量超出最大限额，则用例未达到期望目标而终止。在事件流的描述中，主事件流使用“确认”和“验证”等确定性语句，而不是“检查是否……”和“如果……，那么……，否则……”等条件语句，这些分支情况利用备选事件流来说明。
  另外，事件流的编写过程也是可以分阶段迭代进行的，对于优先级高的用例花更多的时间，更加的细化；对优先级低的用例可以先简略地将主事件流描述清楚，备选事件流留待以后处理。对于一些事件流较为复杂的，可以在用例描述中引用顺序图、状态图和通信图等手段进行描述。
  （4）非功能需求。因为用例所涉及的非功能需求通常很难在事件流中进行表达，因此单列为一小节进行描述。在非功能需求的描述方面，一定要注意使其可度量和可验证。否则，就容易流于形式，形同摆设。
  （5）前置条件和后置条件。前置条件是执行用例之前必须存在的系统状态，如果前置条件不满足，则用例无法启动。例如，“开通课程”用例的前置条件是客服人员已正确登录到系统中；后置条件是用例执行完毕系统可能处于的一组状态。一旦用例成功执行，可能会导致系统内部某些状态的变化，例如，成功地“开通课程”会使该课程的选修人数增加，会使学员的权限发生变化等。而某些用例也可能没有前置条件或后置条件，例如，“学员联络”用例没有后置条件，因为该用例执行后不会改变系统状态。如果在当前阶段不容易确定前置条件或后置条件，则可以在以后再细化。
  （6）扩展点。如果包括扩展（或包含）用例，则写出扩展（或包含）用例名，并说明在什么情况下使用。
  （7）优先级。说明用户对该用例的期望值，为以后的开发工作确定先后顺序。可以采用满意度/不满意度指标进行说明，例如，设置为1～5的数值。
• 调整用例模型
  在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。

建立分析模型：

• 定义概念类
  OOA的中心任务就是要找到系统中的对象或类，这些类将反映到系统设计中的软件类和系统实现中某个OOP语言声明的类。例如，在领域模型中，学员学习某门课程是一个事件，该事件记录了某个学员和某门课程在一定时期内的责任关系，表达的是领域概念；在系统设计模型中，学习记录就是一个软件类。虽然它们是不同的事物，但领域模型中的命名启发了后者的命名和定义，从而缩小了表示的差距。在整个系统开发过程中，要尽量使这些类或对象在不同阶段保持相同的名称。
  发现类的方法有很多种，其中应用最广泛的是名词短语法。它的主要规则是先识别有关问题域文本描述中的名词或名词短语，然后将它们作为候选的概念类或属性，其具体步骤如下：
  （1）阅读和理解需求文档或用例描述。
  （2）筛选出名词或名词短语，建立初始类清单（候选类）。
  （3）将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
  （4）舍弃明显无意义的类。
  （5）小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。
• 确定类之间的关系
  当完成了类的寻找工作之后，就需要理清这些类之间的关系，类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等，它们在UML中的表示方式如图11-14所示。
• 为类添加职责
  找到了反映问题域本质的主要概念类，而且还理清了它们之间的协作关系之后，系统分析师就可以为这些类添加其相应的职责。类的职责包括两个方面的内容，一个是类所维护的知识，即成员变量或属性；另一个是类能够执行的行为，即成员方法或责任。
  属性是描述类静态特征的一个数据项。系统分析师可以与用户进行交谈，提出问题来帮助寻找类的属性。从概念建模的角度来看，属性越简单越好。要保持属性的简单性，应该做到只定义与系统责任和系统目标有关的属性；使用简单数据类型来定义属性，不使用可由其他属性导出的属性（冗余属性）；不为类关联定义属性。最后，要对属性加以说明，包括名称、解释和数据类型，以及其他的一些要求。
  对于类的责任的确定，可以根据用例描述中的动词来进行判断，然后再进行筛选。这个过程与类的识别过程是类似的，此处不再赘述。系统分析师应该通用性地描述类的成员方法，例如，“交费”和“组卷”等。另外，根据封装性原则，信息和与其相关的行为应该存在同一个类中。关于一个事物的信息应该包含在单个类中，而不是分布在多个类中。但是，在适当的时候，可以在相关的类之间分享责任。
  要注意的是，为类添加职责与找到类之间的关系一样，这个阶段也只能找到那些主要的、明显的、与业务规则相关的部分。切忌在这个阶段不断地细化，甚至引入一些与具体实现相关的技术内容（例如，数据库和分布式对象之类的东西）。
• 建立交互图
  多个对象的行为通常采用对象交互来表示，UML 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同视点对行为有不同的表现能力，其中最常用的是顺序图，几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线，其中消息是顺序图的灵魂。当对象行为复杂并存在多种不同状态转换时，还要用到反映对象状态变化的状态图。

试题二：论静态测试方法及应用

静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查（DeskChecking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30％～70％的逻辑设计错误和编码错误。

1．桌前检查
由程序员检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析和检验，并补充相关的文档，目的是发现程序中的错误。检查项目包括检查变量的交叉引用表；检查标号的交叉引用表；检查子程序、宏、函数；等值性检查；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的规格说明，详细阅读源代码；补充文档。
由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多检查时间，但应避免主观片面性。
2．代码审查
代码审查是由若干程序员和测试人员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查的过程可以分为两个步骤：
（1）小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
（2）召开程序审查会。在会上，首先由程序员讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查是否存在错误。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
在会前，应当给会审小组每个成员准备一份常见错误的清单（通常称为检查单或检查表），把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的效率。检查单把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供会审时使用。
3．代码走查
代码走查与代码审查基本相同，其过程也分为两个步骤：
（1）把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
（2）开会的程序与代码会审不同，不是简单地读程序和对照错误检查单进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。
4．静态分析
在静态测试中，主要是对程序代码进行静态分析，包括控制流分析、数据流分析、接口分析和表达式分析。
（1）控制流分析。控制流分析是指使用控制流程图检查被测程序控制结构的过程。例如，可检查被测程序是否存在没有使用的语句或子程序、是否调用并不存在的子程序，以及是否存在无法达到的语句等。
（2）数据流分析。数据流分析是指使用控制流程图分析数据各种异常情况的过程，包括数据初始化、赋值或引用过程中的异常，例如，引用未定义的变量、对以前未使用的变量再次赋值等程序差错或异常情况。
（3）接口分析。接口分析主要包括模块之间接口的一致性分析、模块与外部数据库及其他软件配置项之间的一致性分析、子程序和函数之间的接口一致性分析等。例如，可以检查函数形参与实参的数量、顺序、类型和使用的一致性。
（4）表达式分析。表达式分析用于检查程序代码中的表达式错误，例如，括号不配对、数组引用越界、除数为零，以及浮点数变量比较时的误差等错误。

试题三：论富WEB技术及应用

人们的应用需求永远是技术发展的驱动力。传统的Web系统允许用户填写表单，提交表单时就向Web服务器发送一个请求。服务器接收并处理传来的表单，然后返回一个新的网页。这种做法浪费了许多带宽，因为在前后两个页面中的大部分HTML代码往往是相同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间就依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。为了弥补B/S架构存在的一些不足，提高用户体验，富互联网应用（Rich Internet Application, RIA）技术应运而生。
RIA是一个用户接口，它比用HTML实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性，简化并改进了B/S架构的用户交互，这样，系统可以提供更丰富、更具有交互性的用户体验。
1．RIA的概念
针对B/S架构所存在的缺点，如果一味地提升服务器和网络的速度，既不现实又不经济，一种可行的技术方案就是采用高度互动性和局部智能型的客户端应用程序，这样，就可以在无需刷新全页或增加带宽需求的情况之下，迅速响应用户的输入并作出相应的处理。这种技术就是RIA。
RIA是B/S架构的一种演变，“富”的含义有两种，分别是丰富的数据模型和丰富的用户界面。丰富的数据意味着客户端的用户界面能表现和应对更多、更复杂的数据模式，这样才能处理客户端的运算，以及异步发送和接收数据。为了达到高度复杂的数据模式，客户端允许用户构建一个高响应、交互式的应用程序；HTML只能为用户的界面控制提供有限的功能，反之，RIA允许一些富有创造性的界面控制，巧妙地与数据模式相结合。传统的B/S架构是线性设计方式，用户唯一的选择就是用批处理方式提交页面到服务器。连续处理服务器请求和页面更新存在许多障碍，包括页面响应时间、网络带宽，以及满足会话或状态交叉连接而不断增长的日常开销。伴随着丰富的用户界面，用户可以从早期的服务器响应影响整个界面的运作模式，迁移到只对发出请求的特定区域进行改变的模式上来。
RIA具有C/S架构的特点，包括在消息确认和格式编排方面提供互动用户界面，在无刷新页面之下提供快捷的界面响应时间，提供通用的用户界面特性（例如，拖放操作、在线和离线操作能力等）；RIA也具有B/S架构的特点，包括立即布署、跨平台、采用逐步下载来检索内容和数据，以及可以充分利用广泛采纳的互联网标准。在RIA中，数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
2．客户端开发技术
一个新的技术是否能够被广泛应用，与该技术的支持平台的多少和平台功能是否强大、是否易用等因素密切相关。RIA技术一经推出，就得到了广泛应用，支持RIA的平台或工具主要有以下几个：
（1）Flex。Flex是一个表示服务器和应用程序框架，它可以运行于J2EE和．NET平台。Flex应用程序框架由MXML（Macromedia XML）、ActionScript和Flex类库构成。开发人员利用MXML定义应用程序用户界面元素，利用ActionScript定义客户逻辑与程序控制。Flex类库中包括Flex组件、管理器和行为等。应用程序由Flex服务器翻译成SWF格式的客户端应用程序，在Flash Player中运行。
（2）Bindows。Bindows是用Javascript和DHTML（Dynamic HTML，动态HTML）开发的Web窗口框架。JavaScript用于客户端界面的显示和处理，XML和HTTP用于客户端与服务器的信息传输。Bindows的一个主要缺点是，它采用一次性全部载入的方式来实现脚本库，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。另外，Bindows内部大量量利用了IE（Internet Explorer）技术，没有考虑到非IE的浏览器，限制了Bindows的流行。
（3）Java。一些相当复杂的系统都是用Java编写的，这说明可以用Java来建立几乎任何一个能够想象得到的RIA。使用Java建立RIA的主要缺陷是它的复杂性，例如，即使对简单的窗口和图形，也要求编写非常烦琐的代码。
（4）Laszlo。Laszlo是一个开源的RIA开发环境。使用Laszlo平台时，开发人员只需编写名为LZX的描述语言（其中整合了XML和JavaScript），运行在J2EE应用服务器上的Laszlo表示服务器会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说，Laszlo的本质和Flex是一样的。
（5）XUL（XML User Interface Language，基于XML的用户界面语言）。XUL可用于建立窗口应用系统，这些系统既可以在Mozilla浏览器上运行，也可以在其他描述引擎上运行。XUL描述引擎都非常小，它既可以使用XML数据，也可以生成XML数据。
（6）Avalon。Avalon是Vista的一部分，是一个图形和展示引擎，主耍由．NET框架中的一组类集合而成。Avalon定义了一个在Longhorn中使用的新标记语言，其代号为XAML（eXtensible Application Markup Language），即可扩展应用标记语言。可以使用XAML来定义文本、图像和控件的布局，程序代码可以直接嵌入到XAML中，也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是，基于Avalon的系统必须运行在Longhorn环境中，而Flex和Laszlo是不依赖于平台的，仅仅需要装有Flash播放器的浏览器即可。
3．异步JavaScript和XML
异步JavaScript和XML（Asynchronous JavaScript And XML, AJAX）是由几种蓬勃发展的技术以新的方式组合而成的，包括基于XHTML（eXtensible HyperText Markup Language，可扩展超文本标识语言）和CSS（Cascading Style Sheets，层叠样式表）标准的表示、使用DOM（Document Object Model，文档对象模型）进行动态显示和交互、使用XML和XSLT（eXtensible Stylesheet Language for Transformation，用于转换的可扩展样式表语言）进行数据交换及相关操作、使用XMLHttpRequest与服务器进行异步通信、使用JavaScript绑定一切。
（1）XML。XML是一套从SGML（Standard Generalized Markup Language，标准通用标记语言）中派生出来的定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，用于定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。XML的高扩展性、高灵活性特性，使得它可以描述各种不同种类的应用软件中的各种不同类型的数据，可以实现不同数据的集成。由于XML格式的标准化，许多浏览器软件都能够提供很好的支持，因此，只需简单地将XML格式的数据发送给客户端，客户端就可以自行对其进行编辑和处理，而不仅是显示。
（2）XHTML。XHTML是一个基于XML的标记语言，是一个扮演着类似HTML角色的XML，结合了部分XML的强大功能和大多数HTML的简单特性。建立XHTML的目的就是实现HTML向XML的过渡。
（3）JavaScript。JavaScript是一种粘合剂，使AJAX应用的各部分集成在一起。在AJAX中，JavaScript主要用来传递用户界面上的数据到服务端并返回结果。
（4）XMLHttpRequest。XMLHttpRequest对象用来响应通过HTTP传递的数据，一旦数据返回到客户端，就可以立刻使用DOM将数据显示在网页上。XMLHttpRequest对象在大部分浏览器中已经实现，而且拥有一个简单的接口，允许数据从客户端传递到服务端，但并不会打断用户当前的操作。使用XMLHttpRequest传送的数据可以是任何格式的。
（5）DOM。DOM为XML文档的已解析版本定义了一组接口。解析器读入整个文档，构建一个驻留内存的树结构，然后代码就可以使用DOM接口来操作这个树结构。
（6）XSLT。XSLT是一种将XML文档转换为XHTML文档或其他XML文档的语言，可以用在客户端和服务端，它能够减少大量的用JavaScript编写的应用逻辑。
（7）CSS。一个CSS样式单就是一组规则，样式再根据特定的一套规则级联起来。每个规则给出其所适用的元素名称，以及要应用于哪些元素的样式。CSS提供了从内容中分离应用样式和设计的机制。虽然CSS在AJAX应用中扮演至关重要的角色，但它也是构建跨浏览器应用的一大阻碍，因为不同的浏览器厂商支持各种不同的CSS级别。
借助于AJAX，可以在用户单击按钮时，使用JavaScript和DHTML立即更新用户界面，并向服务器发出异步请求，以执行更新或查询数据库。当请求返回时，就可以使用JavaScript和CSS来相应地更新用户界面，而不是刷新整个页面。最重要的是，用户甚至不知道浏览器正在与服务器通信，Web站点看起来是即时响应的。使用AJAX的最大优点，就是能在不更新整个页面的前提下维护数据，这使得Web系统更为迅捷地回应用户动作，并避免了在网络上发送那些没有改变过的信息。
使用AJAX的主要缺点是，它可能破坏浏览器“后退”按钮的正常行为。在动态更新页面的情况下，用户无法回到前一个页面状态，这是因为浏览器只能记下历史记录中的静态页面。用户通常都希望单击“后退”按钮，就能够取消他们的前一次操作，但在AJAX系统中，却无法做到这一点。解决这个问题的主要方法是，在用户单击“后退”按钮访问历史记录时，通过建立或使用一个隐藏的IFRAME来重现页面上的变更。例如，当用户在Google Maps中单击“后退”时，它在一个隐藏的IFRAME中进行搜索，然后将搜索结果反映到AJAX元素上，以便将系统恢复到当时的状态。另外，使用动态页面更新时，用户难以将某个特定的状态保存到收藏夹中。解决这个问题的主要方法是，使用URL（Uniform Resource Locator，统一资源定位符）片断标识符（通常被称为锚点，即URL中“＃”后面的部分）来保持跟踪，允许用户回到指定的某个系统状态。
进行AJAX开发时，需要慎重考虑网络延迟。不给予用户明确的回应，没有恰当的预读数据，或者对XMLHttpRequest的不恰当处理，都会使用户感到延迟，这是用户不希望看到的，也是他们无法理解的。通常的解决方案是，使用一个可视化的组件来告诉用户，系统正在进行后台操作并且正在读取数据和内容。

试题四：论DevSecOps技术及应用

DevSecOps 对 DevOps 进行了改进，以确保安全性仍然是该过程的一个重要部分。

与 DevOps 一样，DevSecOps 是开发人员和 IT 运营团队在开发和部署软件应用程序时所遵循的一种思维方式或文化。它将主动和自动化的安全审计以及渗透测试集成到敏捷应用程序开发中。

要使用 DevSecOps，你需要：

从 SDLC 开始就引入安全性概念，以最大程度地减少软件代码中的漏洞。
确保每个人（包括开发人员和 IT 运营团队）共同承担在其任务中遵循安全实践的责任。
在 DevOps 工作流程开始时集成安全控件、工具和流程。这些将在软件交付的每个阶段启用自动安全检查。
DevOps 一直致力于在开发和发布过程中包括安全性以及质量保证（QA）、数据库管理和其他所有方面。然而，DevSecOps 是该过程的一个演进，以确保安全永远不会被遗忘，成为该过程的一个重要部分。

了解 DevSecOps 流程
典型的 DevOps 流程有不同的阶段；典型的 SDLC 流程包括计划、编码、构建、测试、发布和部署等阶段。在 DevSecOps 中，每个阶段都会应用特定的安全检查。

计划：执行安全性分析并创建测试计划，以确定在何处、如何以及何时进行测试的方案。
编码：部署整理工具和 Git 控件以保护密码和 API 密钥。
构建：在构建执行代码时，请结合使用静态应用程序安全测试（SAST）工具来跟踪代码中的缺陷，然后再部署到生产环境中。这些工具针对特定的编程语言。
测试：在运行时使用动态应用程序安全测试（DAST）工具来测试您的应用程序。 这些工具可以检测与用户身份验证，授权，SQL 注入以及与 API 相关的端点相关的错误。
发布：在发布应用程序之前，请使用安全分析工具来进行全面的渗透测试和漏洞扫描。
部署：在运行时完成上述测试后，将安全的版本发送到生产中以进行最终部署。

随着基于现代 IT 基础设施的企业安全威胁的复杂性增加，DevSecOps 将发挥更加关键的作用。然而，DevSecOps 流程将需要随着时间的推移而改进，而不是仅仅依靠同时实施所有安全更改即可。这将消除回溯或应用交付失败的可能性。

引用：你需要知道的DevSecOps流程及工具
《系统分析师教程》张友生著