精华内容
下载资源
问答
  • 常见漏洞类型

    千次阅读 2020-09-30 10:52:07
    常见SRC漏洞类型 1. WEB漏洞 1.1. 反射型XSS 1.2. 存储型XSS 1.3. 命令注入 1.4. SQL注入 1.5. 上传漏洞 1.6. 信息泄露 1.7. CSRF 1.8. 文件包含 1.9. 逻辑漏洞 1.10. 权限绕过 1.11. URL跳转 1.12. XXE注入 1.13...

    常见漏洞类型

    1.    WEB漏洞
    1.1.    反射型XSS
    1.2.    存储型XSS
    1.3.    命令注入
    1.4.    SQL注入
    1.5.    上传漏洞
    1.6.    信息泄露
    1.7.    CSRF
    1.8.    文件包含
    1.9.    逻辑漏洞
    1.10.    权限绕过
    1.11.    URL跳转
    1.12.    XXE注入
    1.13.    文件读取
    1.14.    JSON劫持
    1.15.    命令执行
    1.16.    登陆爆破\认证缺陷
    1.17.    SSRF
    1.18.    反序列化
    1.19.    通用组件
    1.20.    目录遍历
    1.21.    管理后台对外
    1.22.    弱口令
    1.23.    CRLF
    1.24.    CORS劫持
    1.25.    后门
    1.26.    内容注入
    1.27.    代码执行
    1.28.    其它
    2.    PC客户端漏洞
    2.1.    任意代码执行
    2.2.    溢出
    2.3.    内核提取
    2.4.    其它
    3.    移动及IOT智能
    3.1.    智能设备
    3.2.    移动客户端
    3.3.    本地代码执行
    3.4.    组件拒绝服务漏洞
    3.5.    接口越权
    3.6.    本地文件权限设置不当
    3.7.    本地敏感数据明文存储
    3.8.    敏感数据明文传输
    3.9.    敏感信息泄露
    3.10.    android
    3.11.    小程序
    3.12.    其它
    4.    其它
    5.    业务情报
    5.1.    威胁组织
    5.2.    账号相关
    5.3.    违规营销
    5.4.    价格异常
    5.5.    资产/套现
    5.6.    第三方/合作厂商
    5.7.    网盘泄露
    5.8.    GitHub信息泄漏
    6.    技术情报
    6.1.    0day
    6.2.    入侵行为及事件
    6.3.    蠕虫/木马及病毒
    6.4.    新型利用方法
    6.5.    规则绕过
    6.6.    可利用工具
    6.7.    钓鱼事件
    6.8.    拒绝服务与劫持
    7.    服务器漏洞
    7.1.    远程代码执行
    7.2.    DOS
    7.3.    疑似入侵
    7.4.    系统弱口令
    7.5.    拒绝服务
    7.6.    配置缺陷
    7.7.    系统命令注入
    7.8.    其它

    一般SRC提交漏洞内容

    1. 发现方式:请尽量详细填写,流程/步骤/截图/重现方法等
    2. 漏洞证明:请在这里提供利用证明及POC
    3. 修复方案:您觉得靠谱的解决方案是什么?
    展开全文
  • 性能测试,是结合被测系统应用架构、业务场景和实现细节、逻辑,对软件响应时间、处理速率、容错能力等进行分析测试,...缺陷类型 缺陷描述 硬件 磁盘空间 CPU IO读写速率 内存 网络 带宽 网...

    性能测试,是结合被测系统应用架构、业务场景和实现细节、逻辑,对软件响应时间、处理速率、容错能力等进行分析测试,找到系统的性能瓶颈,并确认问题得到解决的过程

    由于工作需要,对性能测试缺陷分类进行了整理,这篇博客,聊聊常见的性能缺陷以及表现方式。。。

     

    性能测试缺陷分类

    缺陷类型 缺陷描述
    硬件 磁盘空间
    CPU
    IO读写速率
    内存
    网络 带宽
    网络波动
    CDN
    延时
    丢包
    应用 JVM
    代码逻辑
    配置 JDK版本
    底层配置
    参数配置
    数据库 索引
    表空间
    慢SQL
    数据量
    中间件 超时
    线程池
    缓存策略
    最大连接数
    通信实现方式
    负载均衡

     

    一、硬件

    磁盘空间:磁盘空间不足导致系统运行变慢,文件、日志等无法生成存放导致的性能瓶颈;

    CPU:CPU的核心功能是解释计算机指令以及处理数据,性能主要体现在其运行程序的速度上。影响运行速度的性能指标包括工作频率、Cache容量、指令系统和逻辑结构等参数;

    IO读写速率:即input和output,输入和输出,主要考虑数据处理时的读写速度,页交换等情况;

    内存:所有的程序都是运行在内存中的,其作用是用于暂时存放CPU中的运算数据,以及与外部存储器交换的数据,内存不足会限制程序的数据处理速度,因此这也是很重要的一项性能关注指标;

     

    二、网络

    带宽:高并发情况下,如果带宽不足,可能会导致网络资源竞争,超时等情况;

    网络波动:这里是从网络的稳定性来描述,即性能测试的环境,需要一个稳定的网络环境;

    CDN:即内容分发服务,有时候不同的CDN策略也会影响到“用户”感知到的系统性能表现;

    延时:延时的值越大,对系统性能表现影响越大(比如格斗类的PVP游戏),且性能测试的结果也存在更大的偏差;

    丢包:数据在网络上是以数据包的形式传输的,如果丢包,则可能造成报错或异常的情况;

     

    三、应用

    1、JVM

    堆内存分配:根据系统硬件条件来进行合理的堆内存分配,一般来说JVM的堆内存分配不要超过系统内存的25%较好;

    垃圾回收算法:JAVA的动态垃圾回收机制,是基于不同的几种回收算法来进行的,根据具体的情况,选择合适的垃圾回收策略;

    OOM:即内存溢出(out of memory),这个算是性能测试中很常见的一个问题,通常是由于代码问题造成的内存泄漏、GC不够彻底、内存被耗尽引起;

    2、代码逻辑

    常见的情况有不合理的线程引用和内存分配;

     

    四、配置

    版本:在性能测试过程中,一定要确保被测系统的版本和实际生产保持一致,否则由于版本不同带来的些许差异可能会对性能测试带来很大的偏差和影响;

    底层配置:涉及到操作系统、服务器等硬件的一些配置方式不合理,带来的性能瓶颈;

    参数配置:系统架构设计中,各个不同的参数配置带来的性能瓶颈;

     

    五、数据库

    索引:索引的存在就像一个标签目录一样,在执行数据库操作时提供更为快速的执行效率,减少磁盘IO操作和执行的数据库系统时间;

    :为了保证事务的原子性和隔离性,有了锁的存在,但有时候由于某些原因造成的表锁,也是性能瓶颈的一种表现;

    表空间:不合理的表空间设计,导致的数据库性能问题;

    慢SQL:慢SQL会导致数据库操作时间变长,增加IO读写以及引起一些列的资源竞争等问题,常见的慢SQL原因如下(以MySQL为例):

    数据量:对同一张表来说,1W条数据和1000W条数据,对其进行操作时的性能表现也是不同的,因此在性能测试时对于数据的正确性可用性,以及数据量也是需要重点关注的;

     

    六、中间件

    超时:设置合理的请求或响应超时时间,是很有必要的,这点要根据具体的业务场景和系统架构来考虑,具体的超时时间,建议进行配置测试来设定;

    线程池:之前的博客介绍过线程池的相关资料,线程池配置太小,很容易被使用完,太大的话又浪费资源,合理的线程池,建议进行配置测试来确定;

    缓存策略:缓存的优点是减少请求响应过程中的传输时间,但有时候在高并发情况下,缓存很容易失效而导致缓存穿透,瞬间对服务端带来很大的压力;

    最大连接数:关于连接数,之前的博客也介绍过,合理的连接数配置是很重要的,否则连接数太少容易导致队列等待、超时,连接数太多则浪费了系统资源;

    通信实现方式:同步(sync)和异步(Async);

    负载均衡策略:现在很多的系统都进行了服务集群,随之而来的就是负载均衡策略的实现,如果负载均衡不够“均衡”,在大数量的冲击下,容易导致某些服务的异常或者挂起;

    以上内容为整理出的常见的影响系统应用性能表现的常见缺陷,更详细的内容比如实现原理、处理逻辑等请自行查阅其他资料,内容仅供参考。。。

    转自:https://www.cnblogs.com/imyalost/

    展开全文
  • ODC,英文全称为Orthogonal Defect Classification,译作"正交缺陷分类",由IBM 的Waston中心推出。 当需要分析与开发者和测试人员相关、与开发阶段相关、与顾客的满意程度相关的产品质量的外部属性时,据IBM介绍...

    ODC,英文全称为Orthogonal Defect Classification,译作"正交缺陷分类",由IBM 的Waston中心推出。

    当需要分析与开发者和测试人员相关、与开发阶段相关、与顾客的满意程度相关的产品质量的外部属性时,据IBM介绍可以通过ODC分析这些属性的结果提高软件的质量。

    ODC技术对于以下3种情况特别适用:

    (1)开发生命周期相对来说是一个很漫长的过程,包括后续的改进工作。例如,这个项目包括多个软件版本或者一个版本有多次迭代。

    (2)潜在的缺陷数目是相当大的。缺陷数目越多,客观的分析结果也越多,对我们了解软件质量越有好处。

    (3)这个项目已经将"高质量"设定为它的主要目标之一。

    ODC技术将每一个缺陷按不同维度进行分类。当缺陷数量较多时,也可以对缺陷进行抽样分析。目前ODC技术的主要维度包括发现问题的活动(分为8类)、触发因素(分为36类)、结果影响(分为13类)、问题根源对象(分为6类)、缺陷类型(分为39类)、缺陷界定(分为3类)、责任来源(分为5类)、缺陷年龄(分为4类)8个,共114类。根据大量缺陷分类后产生的各类缺陷的统计数字,结合缺陷定位信息(所属子系统、模块、特性)进行多维度正交分析,就能准确确定产品主要质量问题区域,识别缺陷引入和去除过程的重点改进对象,实现对过程和产品的精确改进指导。将传统度量手段和ODC技术相结合,能实现对过程和产品的宏观评估和微观解剖。

    将一个缺陷在生命周期各环节的属性组织起来,从单维度、多维度来对缺陷进行分析,从不同角度得到各类缺陷的缺陷密度和缺陷比率,从而积累得到各类缺陷的基线值,用于评估测试活动、指导测试改进和整个研发流程的改进;同时根据各阶段缺陷分布得到缺陷去除过程特征模型,用于对测试活动进行评估和预测。7.7节中前面几个小节描述中涉及的缺陷分布、缺陷趋势等都属于这个方法中的一个角度而已。

    相关链接:
    http://www.research.ibm.com/softeng/ODC/DETODC.HTM

    其他缺陷分析方法:

    1、Gompertz分析:根据测试的累积投入时间和累积缺陷增长情况,拟合得到符合自己过程能力的缺陷增长Gompertz曲线,用来评估软件测试的充分性、预测软件极限缺陷数和退出测试所需时间、作为测试退出的判断依据、指导测试计划和策略的调整;

    2、Rayleigh分析:通过生命周期各阶段缺陷发现情况得到缺陷Rayleigh曲线,用于评估软件质量、预测软件现场质量;

    3、四象限分析:根据软件内部各模块、子系统、特性测试所累积时间和缺陷去除情况,和累积时间和缺陷去除情况的基线进行比较,得到各个模块、子系统、特性测试分别所位于的区间,从而判断哪些部分测试可以退出、哪些测试还需加强,用于指导测试计划和策略的调整;

    4、根本原因分析:利用鱼骨图、柏拉图等分析缺陷产生的根本原因,根据这些根本原因采取措施,改进开发和测试过程;

    5、缺陷注入分析:对被测软件注入一些缺陷,通过已有用例进行测试,根据这些刻意注入缺陷的发现情况,判断测试的有效性、充分性,预测软件残留缺陷数。在06年软件评测师考试中有一题就是考这个思路,参见这个帖子我的回复:http://bbs.51testing.com/thread-114979-1-1.html

    6、DRE/DRM分析:通过已有项目历史数据,得到软件生命周期各阶段缺陷注入和排除的模型,用于设定各阶段质量目标,评估测试活动.

    转载于:https://www.cnblogs.com/hncjp1989/archive/2012/03/02/2377157.html

    展开全文
  • JavaScript类型系统缺陷与解决方案

    千次阅读 2020-11-22 23:16:05
    学习资料:拉勾课程《大前端高薪训练营》 阅读建议:文章较长,搭配文章的侧边栏目录进行食用,体验会更佳哦! 内容说明:本文不做知识点的...强类型语言:程序运行时变量类型不允许任意的隐式类型转换(类型安全).

    学习资料:拉勾课程《大前端高薪训练营》
    阅读建议:文章较长,搭配文章的侧边栏目录进行食用,体验会更佳哦!
    内容说明:本文不做知识点的搬运工,文中只记录个人对该技术点的认识和理解。

    一:编程语言的类型系统

    1.强类型语言 与 弱类型语言

    语言类型的强弱之分,业界并没有权威的对比概念,所以网上有很多种不同的说法。但大部分说法的意思都在说明强类型语言有更强的类型约束,而弱类型中几乎没有什么约束。

    以下个人学习课程之后对强类型与弱类型的理解:

    • 强类型语言:程序运行时变量类型不允许任意的隐式类型转换类型安全)。
    • 弱类型语言:程序运行时变量类型允许任意的隐式类型转换类型不安全)。

    最简单的代码理解案例:

    // 强类型语言:java、python等
    100 - '50' //报语法错误
    
    // 弱类型语言:javaScript
    100 - '50' // 50
    

    2.静态类型语言 与 动态类型语言

    以下个人学习课程之后对静态类型类型与动态类型的理解:

    静态类型:程序开发时变量类型声明后,不允许再修改编译阶段检查类型)。
    动态类型:程序开发时变量类型声明后,可以随时发生变化运行阶段检查类型)。

    最简单的代码理解案例:

    // 静态类型语言:java
    int a = 100;
    a = '100';  // 报语法错误
    
    // 动态类型语言:javascript
    var a = 100;
    a = '100';  // typeof(a) 输出 'string'
    

    3.主流编程语言分类

    在这里插入图片描述

    二:Javascript类型系统缺陷

    1.程序健壮性差

    JavaScript语言本身是一种动态弱类型的解释型语言。在具体探讨它的类型缺陷之前,我们先看日常开发当中的几个JavaScript常见类型错误示例:

    let fn, name, age = 10, inputAge = '1';
    fn()			// 运行时报错,undefined不能当作函数对象不能调用
    const fn1 = fn; // 潜在错误:fn1并不是一个方法
    
    age = age + inputAge;// 运行不准确,但age计算不准确,同时类型转为string也是一个潜在错误
    <p> {name} </p> 	// 运行不准确,用户看到undefined
    

    从上述代码我们可以感觉到,我们平常写的JavaScript程序发生的很多错误其实都是类型错误,我们在找到这些错误并且调试解决它花了不少时间,尽管如此,程序中依然还有很多潜在的类型错误没有发现,下面思考一波发生这些错误的原因:

    • JavaScript是动态类型:意味着在程序开发阶段,开发者开发出的源代码没有经过类型检查就直接交给解释器执行。

    • JavaScript是弱类型:意味着程序在运行阶段碰到开发者造成的类型问题时,程序会自作主张的进行隐式类型转换,无法转换则报错,转换成功则返回运算结果(有时候不是开发者所期望的运行结果,即运行不准确)。

    • JavaScript既是动态类型又是弱类型,这使得JavaScript程序在运行期间很容易发生类型错误隐藏潜在错误、以及错误不被识别为错误导致程序运行不准确

    2.原始解决方案

    程序很容易发生类型错误隐藏潜在错误、以及错误不被识别为错误而运行不准确,一个好的开发者绝对无法认同这些事情的存在,所以我们在日常JavaScript开发中,经常会加上一些类型判断代码来避免错误的发生,如下代码示例:

    // 案例1
    const obj = {};
    // obj.foo();	// error
    if(obj.foo){	// 防错处理
    	obj.foo();
    } else {
      // xxx  
    }
    
    // 案例2
    function sum (a, b) {
       return a + b
    }
    function sum (a, b) {	// 防错处理
        if (!(typeOf(a)=== 'int' && typeOf(b)=== 'int')){
            throw new TypeError('arguments should be number');
        } 
       return a + b
    }
    

    在写JavaScript时,我们会经常有意的写这些代码来避免或者解决类型错误,但是我们分析一下这样解决类型问题的缺点:

    • 更大的开发成本:开发者除了需要编写代码的核心逻辑之外,还需要花费更多的时间精力去编写避免类型问题的代码,尤其在封装给别人使用时,这个问题尤其显著。
    • 只能解决部分问题:我们不可能在每次变量使用前都做一次类型判断,所以这种方案只能解决部分类型错误。
    • 大量类型判断代码:这种方案需要在程序中编写大量类型判断代码来避免错误,这容易导致代码量变大、核心业务代码被隐藏、代码不够清晰等问题。
    • 性能问题:在运行阶段需要运行这些类型判断逻辑代码,肯定需要消耗更多的运行时间。

    上述解决方案虽然比较丑陋,但是这就是我们平常写JavaScript代码避免类型问题的默选方案。

    先是讲到JavaScript的类型系统这么多缺陷,后是讲到原始解决方案还这么敷衍,有没有突然有一种用JavaScript语言编程好差劲的感觉,难怪往前这么多人称呼JavaScript为小丑语言,难堪大任!

    JavaScript在运行期间出现的这么多类型问题,其实都是源于JavaScript本身对变量类型没有约束,开发阶段无法进行类型检查,从而使得开发者编写出的JavaScript代码容易出现编程错误导致的。

    借鉴其它语言的做法,我们可能会想到,开发阶段的类型约束会是类型判断之外的解决JavaScript类型错误的另一种方案。实现上,这种思想现在有两种主流的解决方案,即Flow 和 Typescript。它们都是通过在源代码上加上类型声明来实现的类型约束和类型检查,然后通过编译得到一份类型严谨的JavaScript代码交给JavaScript解释器执行的方式来解决的类型问题,这主要涉及到开发、检查、编译三个过程:

    • 开发阶段:开发阶段根据规则为变量加上合适的类型声明。
    • 检查阶段:使用检查工具根据变量的类型声明和变量值进行匹配检查。分为开发时检查(代码提示)、开发后检查、编译时检查三种。
    • 编译阶段:使用编译工具为变量移除类型声明而后得到一份类型严谨的JavaScript代码。

    3.Flow解决方案

    Flow是JavaScript的静态类型检查工具,它定义了一套类型约束与检查规则,在检查通过之后可以编译出一套类型严谨也没有Flow类型声明的JavaScript代码,解决JavaScript类型问题。下面从开发、检查到编译三个阶段简单说明Flow提供的解决方案是如何解决JavaScript类型问题的,具体的使用细节查阅官方文档即可。

    1):开发阶段添加类型声明

    添加类型声明涉及到三个部分,即自己代码中的类型注解、环境下api(window / node)的类型注解以及第三方库(引入的lib)中的类型注解。环境下api以及第三方库的文件中缺乏类型注解时,我们通常会通过引入类型声明文件的方式来解决。

    下面是给自己代码中加上类型声明的案例:

    // @flow
    // test.js
    function sum(m: number, n: number): number {
    	return m + n
    }
    

    2):检查阶段进行类型匹配

    类型检查分为编码时检查、编码后检查、编译时检查三种,编码检查工具通常是IDE提供的插件,编码后以及编译时检查通常是使用官方提供的检查工具。

    Flow的开发时检查工具此处不做探讨,下面简单说明一下Flow开发后检查的工作流:

    • 安装检查工具flow-bin
    yarn add flow-bin --dev
    
    • 写入检查配置信息:.flowconifg
    # 生成.flowconifg配置文件,在这里可以配置检查源、检查规则、检查输出位置等
    yarn flow init
    
    • 读取配置执行检查
    yarn flow
    
    • 控制台输出检查结果
    • 根据检查报告修改代码中类型错误

    3):编译阶段移除类型声明

    Flow源代码中的类型注解并不符合JavaScript语法,直接丢给JavaScript解释器执行会报错,所以我们需要对源代码进行编译移除类型声明,得到能够被JavaScript解释器执行的JavaScript代码,解决JavaScript类型问题

    移除JavaScript文件中的Flow类型注解有两种方案:

    • 使用工具库flow-remove-types移除
    # 安装
    yarn add flow-remove-types --dev
    # 移除:命令参数,编译输入代码的位置、编译输出代码的位置
    yarn flow-remove-types src -d dist
    
    • 使用Babel插件@babel/preset-flow移除
    # 安装
    npm install --save-dev @babel/core @babel/cli @babel/preset-flow
    # 配置:.babelrc文件配置preset-flow插件
    {
      "presets": ["@babel/preset-flow"]
    }
    # 转换:命令参数,编译输入代码的位置、编译输出代码的位置
    yarn babel src -d dist
    

    三:Typescript终极解决方案

    和Flow一样,TypeScript也是JavaScript的类型检查器。不同的是,Typescript功能上更强大更完善,生态上也更加健全。在语法上,Typescript是Javascript的超集,它与JavaScript的关系如下图:
    在这里插入图片描述

    以下是除官话外,个人对Typescript的认识:

    Typescript这门语言其实并不能和C、C++、Java、JavaScript这些语言相谈并论,它只能算是JavaScript的切面语言,因为它的变量类型和语法规则只涉及到开发和编译阶段,在编译之后转换为JavaScript交给JavaScript解释器执行。这也意味着,我们在学习typescript这门语言的类型和语法时,完全不必要关注它的运行机制与存储规则,而是只需要理解它与JavaScript类型和语法的映射关系即可。

    下面我们从开发编译两个阶段简单说明Typescript提供的解决方案是如何解决JavaScript类型问题的,具体的使用细节查阅官方文档即可。

    1.开发阶段使用Typescript语法

    从上图我们也可以看到,Typescript除了支持静态类型之外,还支持ES6语法。接下来我们主要关注它是怎么解决JavaScript的类型问题的。
    与Flow一样,Typescript的类型声明也涉及到到三个部分,即自己代码中的类型注解、环境下api(window / node)的类型注解以及第三方库(引入的lib)中的类型注解。环境下api以及第三方库的文件中缺乏类型注解时,我们通常会通过引入类型声明文件的方式来解决。

    下面是给自己代码中加上类型声明的案例:

    // test.ts
    function sum(m: number, n: number): number {
    	return m + n
    }
    
    开发时检查

    typescript可以归属于静态语言,IDE对其代码具备很强的感知能力,所以IDE可以为开发者提供很强大的开发时检查、代码提示、错误提示等功能。

    2.编译阶段转换Typescript语法

    与Flow一样,Typescript源代码也不能直接交给JavaScript解释器执行。我们需要使用官方提供的tsc工具将typescript代码编译为JavaScript代码,解决Javascript的类型问题

    以下简要说明Typescript的编译工作流:

    • 安装typescript
    yarn add typescript --dev
    
    • 写入编译配置:tsconfig.json
    # 1.生成.flowconifg配置文件,在这里可以配置检查源、检查规则、检查输出位置等
    yarn tsc --init
    
    # 2.修改tyscript配置文件,主要涉及到编译输入文件位置、输出文件位置、编译规则等
    # xxx
    
    • 读取编译配置执行编译
    yarn tsc
    
    • 编译结束,成功得到JavaScript代码,失败则根据编译报错信息修改代码。

    3.Typescript类型系统

    这里简单提一提Typescript的类型系统,Typescript官网文档对它的类型划分为以下几类:

    类型 含义 示例
    basic Types 基本类型 number、Tuple、Void…
    Interfaces 接口类型 { x : ‘xx’ } / interface xxx { x ‘xx’}
    Unions and Intersection Types 并集、交集类型 object | null
    Literal Types 字面量类型 1 | 2 | 3
    Enums 枚举类型 Enum x { x ‘1’ }
    Functions 函数类型 function (m: number): Void { // xxx,no return }
    Classes 类类型 完整的java类,访问控制,单继承多实现
    Generics 泛型 值泛型:Array<number>,函数泛型、类泛型

    Typescript作为新出现的静态语言,它的类型系统吸收了很多其它语言中优秀的类型,尤其是Java。其实对于这些各种类型约束,我们也可以等同的使用原始解决方案为代码加上类型判断来解决类型问题。使用typescript虽然会造成初期开发增加,但是它可以让我们不用大量的类型判断就可以写的一手类型严谨、性能更好、维护性更好的JavaScript代码。如果想做一位JavaScript的优秀coder,不用我说也会拥抱Typescript吧!

    对于typescript的学习成本,其实它的学习成本很低,特别是对于有静态语言使用经验的开发者来说,因为它只涉及到开发和编译阶段,我们只需要理解它的各种类型含义并熟悉运用就可以写的一手好Typescript代码。

    本文结束,谢谢观看。
    如若认可,一键三连,每周一篇,后续更多精彩。

    展开全文
  • 常见问题一: 统一性不要在软件中使用中英文混合的提示,比如对于用户的操作提示,不要一会用“error”一会用“错误”;一会用“succeed”另一会用“成功”总之要统一。某局长使用心得:删除的时候提示Error,幸亏我...
  • 常见软件测试类型分类

    万次阅读 2018-09-20 09:48:05
    软件测试类型 1)回归测试 回归测试: (regression testing): 回归测试有两类:用例回归和错误回归;用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试,看看会重新发现问题。错误回归,就是在新...
  • 软件测试类型/缺陷分类的获取

    千次阅读 2017-07-10 10:03:00
    软件测试类型分析是进行细化测试用例条件的重要手段之一,通过测试类型的分类,软件测试人员可以将测试条件从不同的维度进行考虑,并发现不同的缺陷类型,从而提高测试的覆盖率。  测试类型并不是一个标准,它的...
  • 常见的网络攻击类型

    万次阅读 2019-02-20 12:23:46
    常见的网络攻击类型 一、拒绝服务攻击 1.拒绝服务攻击 Dos(Denial of Service)是一种利用合理的服务请求占用过多的服务资源,从而使合法用户无法得到服务响应的网络攻击行为。 被DOS攻击时的现象大致有: 被...
  • 五种常见的ASP.NET应用程序安全缺陷

    千次阅读 2013-12-23 14:35:14
    五种常见的ASP.NET应用程序安全缺陷 一、不能盲目相信用户输入  在Web应用开发中,开发者最大的失误往往是无条件地信任用户输入,假定用户(即使是恶意用户)总是受到浏览器的限制,总是通过浏览器和服务器交互,...
  • 提纲: 一、不能盲目相信用户输入 二、五种常见的ASP.NET安全缺陷 2.1 篡改参数 2.2 篡改参数之二 2.3 信息泄漏 2.4 SQL注入式攻击 2.5 跨站脚本执行 三、使用自动安全测试工具 正文: 保证应用程序的安全应当从编写...
  • 常见黑客攻击类型

    万次阅读 2006-11-19 14:23:00
     1.5.2 常见黑客攻击类型虽然黑客攻击的手法多种多样,但就目前来说,绝大多数中初级黑客们所采用的手法和工具仍具有许多共性。从大的方面来划分的话,归纳起来一般不外乎以下几种:1. 网络报文嗅探网络嗅探其实...
  • 五种常见的ASP.NET安全缺陷

    千次阅读 2004-07-08 15:30:00
    根据IBM的系统科学协会(Systems Sciences Institute)的研究,如果等到软件部署之后再来修补缺陷,其代价相当于开发期间检测和消除缺陷的15倍。 为了用最小的代价保障应用程序的安全,在代码本身的安全性、抗御攻击...
  • 本文讨论 Linux/UNIX 系统中最常见缺陷:缓冲区溢出。本文首先解释什么是缓冲区溢出,以及它们为何如此常见和如此危险。然后讨论广泛用于解决缓冲区溢出的新 Linux 和 UNIX 方法 ―― 以及为什么这些方法还不足够...
  • Windows编程 Win32API中常见的数据类型

    千次阅读 2015-12-31 15:20:28
    C\C++语言的数据类型有如下几个缺陷: 数据类型平台相关,在不同平台上,同一个数据类型可能占用不同的空间大小。典型的,在16位系统上,int类型和short int类型长度相同,但在32位平台上,则和long int类型长度...
  • 支付漏洞的三种常见类型

    万次阅读 2015-05-19 18:22:21
    一:支付过程中直接发送含有需支付金额的数据包(常见)  危害指数:星星星星星  这种案例非常常见,主要针对支付宝等需要第三方支付的案例。开发人员往往会为了方便,直接在支付的关键步骤数据包中直接传递...
  • 缺陷分析之缺陷预防的过程

    千次阅读 2019-11-01 10:50:21
    在研发过程中,使用缺陷预防的策略是一个很复杂的过程,关于缺陷预防的具体过程,如图所示。 整个缺陷预防策略的详细步骤说明如下: 第一步:项目进行研发,研发的过程主要包括需求管理、设计和编码三个阶段,这里...
  • MySQL常见的四个存储类型

    千次阅读 2018-11-25 08:36:34
    另外两种类型INNODB和BERKLEY(BDB),也常常可以使用。如果技术高超,还可以自己做一个引擎。 ISAM 一个定义明确且历经时间考验的数据表格管理方法,它在设计之时就考虑到数据库被查询的次数要远大于更...
  • 软件缺陷管理

    千次阅读 2016-06-28 11:21:53
    缺陷管理是软件开发及测试过程中对缺陷进行提交、沟通、修正、关闭、统计等一系列过程的总和,确保缺陷被跟踪管理,直到执行了缺陷管理的全生命周期。在整个缺陷管理周期,主要包括以下几部分:1、缺陷发现:通过...
  • Objective-C弱类型的一个大缺陷

    千次阅读 2012-07-03 15:04:36
    通常我们会想当然地认为,我们可以把任何想要的消息发送给代码中类型为“id”的变量,然后Objective-C的动态消息处理就会在运行时让这一调用正确地工作。但在某些罕见的情况下,这种假定是错误的。在本文中,我将...
  • 软件缺陷是什么以及缺陷的管理

    千次阅读 2020-06-01 10:18:00
    1软件测试缺陷软件缺陷的定义软件缺陷,通常又被叫做Bug或者defect,即为软件或程序中存在的某种破坏正常运行能力的问题、错误、其存在会导致软件产品在某种程度上不能满足用户的需求。软件...
  • 基于语义分割和生成对抗网络的缺陷检测算法

    千次阅读 热门讨论 2018-11-07 17:13:03
    一、缺陷类型 如下图所示,缺陷类型主要有缺损和裂纹两个类型。 二、语义分割网络 FCN网络 网上介绍FCN的教程很多,在这里不再详细讲述,具体请参考链接: https://www.cnblogs.com/gujianhan/p/6030639.html ...
  • 软件测试中的缺陷分析与管理

    千次阅读 2019-08-20 17:03:48
    缺陷的编号、缺陷的标题、缺陷的基本信息、测试的软件和硬件环境、测试的软件版本、缺陷类型缺陷的严重程度、缺陷的处理优先级、缺陷的复现步骤、缺陷的实际结果描述、期望的正确结果、截取的缺陷图像、注释文字...
  • BOOST_FOREACH缺陷

    千次阅读 2014-12-26 09:57:53
    本节描述 BOOST_FOREACH 中的一些常见缺陷。 带逗号的类型 由于 BOOST_FOREACH 是一个宏,它必须刚好有两个参数,并以一个逗号分隔它们。这并不总是很方便,尤其当循环变量的类型是一个模板的时候。考虑一下...
  • 表面缺陷检测数据集汇总及其相关项目推荐

    千次阅读 多人点赞 2020-06-27 00:00:00
    点击上方“3D视觉工坊”,选择“星标”干货第一时间送达最近,有许多朋友都在关注缺陷检测领域,今天来看看缺陷检测。目前, 基于机器视觉的表面 缺陷装备已经在各工业领域广泛替代人工肉眼检测,...
  • quality center包含的软件缺陷元素:缺陷标题、项目名称、所属模块、缺陷状态、缺陷等级、责任人、引入阶段、缺陷类型、优先级、能否重现、测试人员、发现日期、测试轮次、缺陷描述、预期结果、实际结果、重现步骤、...
  • halcon视觉缺陷检测系列(1)常用的6种方法

    千次阅读 多人点赞 2020-01-08 00:12:31
    首先常见缺陷:凹凸、污点瑕疵、划痕、裂缝、探伤等。常用的手法有六大金刚(在halcon中的ocv和印刷检测是针对印刷行业的检测,有对应算子封装): 1.blob+特征 2.blob+差分+特征 3.光度立体 4.特征训练 5.测量...
  • 不同于经典计算机视觉任务中的 ImageNet、PASCAL VOC2007/2012 和 COCO 等数据集,表面缺陷检测并没有一个统一的,大规模的数据集,不同的缺陷检测数据集,在 样本数量,正负样本比例,复杂度 等方面都有很大的不同...
  • 缺陷管理工具

    2010-04-12 08:51:00
    常见免费缺陷管理工具:Buggit http://www.pb-sys.com/Buggit 是一个十分小巧的C/S结构的Access应用软件,仅限于intranet,十分钟就可以配置完成,使用十分简单,查询简便,能满足基本的缺陷跟踪功能,还有十个用户...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 78,890
精华内容 31,556
关键字:

常见缺陷类型