模糊测试 对代码质量影响深远的技术

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了模糊测试 对代码质量影响深远的技术相关的知识,希望对你有一定的参考价值。

参考技术A

   年 月 日

    模糊测试(Fuzz testing )是一项对代码质量有着深远影响的简单技术 在本文中 Elliotte Rusty Harold 故意将随机的坏数据插入应用程序 以观察发生的结果 他也解释了如何使用如校验和 XML 数据存储及代码验证等防护性编码技术 来加固您的程序以抵制随机数据 他以一个练习进行总结 在练习中他以一个代码破坏者的角度进行思考 —— 这是一种用于防护代码的至关重要的技术

  多年来 我惊叹于有如此大量能够使 Microsoft Word 崩溃的坏文件 少数字节错位 会使整个应用程序毁于一旦 在旧式的 无内存保护的操作系统中 整个计算机通常就这样宕掉了 Word 为什么不能意识到它接收到了坏的数据 并发出一条错误信息呢?为什么它会仅仅因为少数字节被损坏就破坏自己的栈 堆呢?当然 Word 并不是惟一一个面对畸形文件时表现得如此糟糕的程序

  本文介绍了一种试图避免这种灾难的技术 在模糊测试中 用随机坏数据(也称做 fuzz)攻击一个程序 然后等著观察哪里遭到了破坏 模糊测试的技巧在于 它是不符合逻辑的 自动模糊测试不去猜测哪个数据会导致破坏(就像人工测试员那样) 而是将尽可能多的杂乱数据投入程序中 由这个测试验证过的失败模式通常对程序员来说是个彻底的震憾 因为任何按逻辑思考的人都不会想到这种失败

  模糊测试是一项简单的技术 但它却能揭示出程序中的重要 bug 它能够验证出现实世界中的错误模式并在您的软件发货前对潜在的应当被堵塞的攻击渠道进行提示

   模糊测试如何运行

  模糊测试的实现是一个非常简单的过程

    准备一份插入程序中的正确的文件 用随机数据替换该文件的某些部分 用程序打开文件 观察破坏了什么

  可以用任意多种方式改变该随机数据 例如 可以将整个文件打乱 而不是仅替换其中的一部分 也可以将该文件限制为 ASCII 文本或非零字节 不管用什么方式进行分割 关键是将大量随机数据放入应用程序并观察出故障的是什么

测试基于 C 的应用程序当字符串包含额外的零时 许多用 C 编写的程序都会出问题 —— 这类问题太过频繁以至于额外的零能够彻底隐藏代码中其他的问题 一旦验证出程序存在零字节问题 就可以移除它们 从而让其他的问题浮现出来

  可以手动进行初始化测试 但要想达到最佳的效果则确实需要采用自动化模糊测试 在这种情况下 当面临破坏输入时首先需要为应用程序定义适当的错误行为 (如果当输入数据被破坏时 您发现程序正常运行 且未定义发生的事件 那么这就是第一个 bug )随后将随机数据传递到程序中直到找到了一个文件 该文件不会触发适当的错误对话框 消息 异常 等等 存储并记录该文件 这样就能在稍后重现该问题 如此重复

  尽管模糊测试通常需要一些手动编码 但还有一些工具能提供帮助 例如 清单 显示了一个简单的 Java&# ; 类 该类随机更改文件的特定长度 我常愿意在开始的几个字节后面启动模糊测试 因为程序似乎更可能注意到早期的错误而不是后面的错误 (您的目的是想找到程序未检测到的错误 而不是寻找已经检测到的 )

清单 用随机数据替换文件部分的类

  import java io *; import java security SecureRandom; import java util Random; public class Fuzzer private Random random = new SecureRandom(); private int count = ; public File fuzz(File in int start int length) throws IOException byte[] data = new byte[(int) in length()]; DataInputStream din = new DataInputStream(new FileInputStream(in)); din readFully(data); fuzz(data start length); String name = fuzz_ + count + _ + in getName(); File fout = new File(name); FileOutputStream out = new FileOutputStream(fout); out write(data); out close(); din close(); count++; return fout; // Modifies byte array in place public void fuzz(byte[] in int start int length) byte[] fuzz = new byte[length]; random nextBytes(fuzz); System arraycopy(fuzz in start fuzz length);

关于代码我可以用很多种方式优化 清单 中的代码 例如 有着 java nio 的内存映射文件是一个相当不错的选择 我也能够改进这个错误处理及可配置性 因为不想让这些细节混淆这里所要说明的观点 所以我将代码保持了原样

  模糊测试文件很简单 将其传至应用程序通常不那么困难 如 AppleScript 或 Perl 脚本语言通常是编写模糊测试的最佳选择 对于 GUI 程序 最困难的部分是辨认出应用程序是否检测出正确的故障模式 有时 最简单的方法是让一个人坐在程序前将每一个测试通过或失败的结果都标记下来 一定要将所有生成的随机测试用例单独地命名并保存下来 这样就能够重现这个过程中检测到的任何故障

   防护性编码

  可靠的编码遵循了这样的基本原则 绝不会让程序中插入未经过一致性及合理性验证的外部数据

  如果从文件中读入一个数字并期望其为正数 那么 在使用其进行进一步处理前对其先验证一下 如果期望字符串只包含 ASCII 字母 请确定它确实是这样 如果认为文件包含一个四字节的整数倍的数据 请验证一下 一定不要假设任何外部提供的数据中的字符都会如您所料

  最常见的错误是做出这样的假设 因为程序将该数据写出 该程序就能不用验证再一次将该数据读回去 这是很危险的!因为该数据很可能已经被另一个程序在磁盘上复写过了 它也可能已经被一个故障磁盘或坏的网络传输所破坏了或已经被另一个带 bug 的程序更改过了 它甚至可能已经被故意更改过以破坏程序的安全性 所以不要假设任何事 要进行验证

  当然 错误处理及验证十分令人生厌 也很不方便 并被全世界程序员们所轻视 计算机的诞生已进入了六十个年头 我们仍旧没有检查基本的东西 如成功打开一个文件及内存分配是否成功 让程序员们在阅读一个文件时测试每一个字节和每一个不变量似乎是无望的 —— 但不这样做就会使程序易被模糊攻击 幸运的是 可以寻求帮助 恰当使用现代工具和技术能够显著减轻加固应用程序的痛苦 特别是如下三种技术更为突出

校验和 基于语法的格式 如 XML 验证过的代码如 Java

    

   用校验和进行的模糊试验

  能够保护程序抵御模糊攻击的最简单的方法是将一个检验和添加到数据中 例如 可以将文件中所有的字节都累加起来 然后取其除以 的余数 将得到的值存储到文件尾部的一个额外字节中 然后 在输入数据前 先验证检验和是否匹配 这项简单模式将未被发现的意外故障的风险降低到约 /

  健壮的校验和算法如 MD 和 SHA 并不仅仅取其除以 的余数 它完成的要多得多 在 Java 语言中 java security DigestInputStream 和 java security DigestOutputStream 类为将一个校验和附属到数据中提供了便捷的方式 使用这些校验和算法中的一种可以将程序遭受意外破坏的机率降低到少于十亿分之一(尽管故意攻击仍有可能)

   XML 存储及验证

  将数据以 XML 形式存储是一种避免数据损坏的好方法 XML 最初即着力于 Web 页面 书籍 诗歌 文章及相似文档 它几乎在每个领域都获取了巨大的成功 从金融数据到矢量图形到序列化对象等等

不切实际的限定如果真想要破坏一个 XML 解析器 有几种方法可以试试 例如 大多数 XML 解析器服从于特定的最大尺寸 如果一个元素名长度超过 亿字符(Java String 的最大尺寸) SAX 解析器将会失败 尽管如此 在实践中这些极限值如此之高 以至于在达到之前内存就已经耗尽

  使 XML 格式抵制模糊攻击的关键特征是一个对输入不做任何 假设的解析器 这就是真正想在一个健壮的文件格式中所获得的 设计 XML 解析器是为了让任何输入(格式良好的或无格式的 有效的或无效的)都以定义好的形式处理 XML 解析器能够处理任何 字节流 如果数据首先通过了 XML 解析器 则仅需要准备好接受解析器所能提供的东西 例如 不需要检查数据是否包含空字符 因为 XML 解析器绝不会传送一个空值 如果 XML 解析器在其输入中看到一个空字符 它就会发出异常并停止处理 当然还需要处理这个异常 但编写一个 catch 块来处理检测到的错误比起编写代码来检测所有可能的错误来说要简单得多

  为使程序更加安全 可以用 DTD 和/或模式来验证文档 这不仅检查了 XML 是否格式良好 而且至少与所预期更加接近 验证并不会告知关于文档所需了解的一切 但它却使编写大量简单检查变得很简单 用 XML 很明显能够将所接受的文档严格地限定为能够处理的格式

  尽管如此 还有多段代码不能用 DTD 或模式进行验证 例如 不能测试发票上商品的价格是否和数据库中库存商品的价格一致 当从客户接收到一份包含价格的订单文档时 不论其是 XML 格式或是其他格式 在提交前通常都会检查一下 以确保客户并未修改价格 可以用定制代码实现这些最后的检查

   基于语法的格式

  使 XML 能够对模糊攻击具有如此的抵御能力的是其使用巴科斯 诺尔范式(Backus Naur Form BNF)语法仔细且标准地定义的格式 许多解析器都是使用如 JavaCC 或 Bison 等解析器 生成器工具直接从此语法中构建的 这种工具的实质是阅读一个任意的输入流并确定其是否符合此语法

  如果 XML 并不适合于您的文件格式 您仍可以从基于解析器的解决方案的健壮性中获益 您必须为文件格式自行编写语法 随后开发自己的解析器来阅读它 相比使用唾手可得的 XML 解析器 开发自己的解析器需要更多的工作 然而它是一个更为健壮的解决方案 而不是不根据语法正式地进行验证就将数据简单地装载到内存中

   Java 代码验证

  由模糊测试导致的许多故障都是内存分配错误及缓冲器溢出的结果 用一种安全的垃圾收集语言(在如 Java 或 managed C# 等虚拟机上执行的)来编写应用程序避免了许多潜在问题 即使用 C 或 C++ 来编写代码 还是需要使用一个可靠的垃圾收集库 在 年 台式机程序员或服务器程序员不应该还需要管理内存

  Java 运行时对其自身的代码起到了额外保护层的作用 在将一个 class 文件装载到虚拟机之前 该文件要由一个字节符验证器或一个可选的 SecurityManager 进行验证 Java 并不假设创建 class 文件的编译器没有 bug 且运转正常 设计 Java 语言之初就是为了允许在一个安全沙箱中运行不信任的 潜在恶意的代码 它甚至不信任其自身编译过的代码 毕竟 也许有人已经用十六进制编辑器手工修改了字节符 试图触发缓冲器溢出 我们大家都应该对我们的程序也有对输入这样的偏执

   以敌人的角度思考

  之前介绍的每项技术都在阻止意外破坏方面造诣颇深 将它们综合起来恰当地实现 会将未被发现的非蓄意破坏发生的可能性几乎减少到零 (当然 并不会减少到零 但其发生的可能性就如同一束偏离轨道的宇宙射线将您 CPU 运算 + 的结果变为 的可能性一样微乎其微 )但不是所有的数据损坏都是非蓄意的 如果有人故意引入坏数据来破坏程序的安全性又该如何呢?以一个攻击者的角度进行思考是防护代码的下一个步骤

  转回到一个攻击者的角度进行思考 假设要攻击的应用程序是用 Java 编程语言编写的 使用非本地代码且将所有额外数据都以 XML(在接受前经过彻底验证)形式存储 还能成功攻击吗?是的 能 但用随机改变文件字节的低级方法显然不行 需要一种更为复杂的方法来说明程序自身的错误检测机制及路径

  当测试一个抵御模糊攻击的应用程序时 不可能做纯黑盒测试 但通过一些明显的修改 基本的想法还是可以应用的 例如 考虑校验和 如果文件格式包含一个校验和 在将文件传至应用程序前仅仅修改此校验和就可以使其同随机数据相匹配

  对于 XML 试着模糊单独的元素内容和属性值 而不是从文档中挑选一部分随机的字节进行替换 一定要用合法的 XML 字符替换数据 而不要用随机字节 因为即使一百字节的随机数据也一定是畸形的 也可以改变元素名称和属性名称 只要细心地确保得到的文档格式仍是正确的就可以了 如果该 XML 文档是由一个限制非常严格的模式进行检查的 还需要计算出该模式没有 检查什么 以决定在哪里进行有效的模糊

  一个结合了对剩余数据进行代码级验证的真正严格的模式也许不会留下可操纵的空间 这就是作为一个开发人员所需要追求的 应用程序应能够处理所发送的任何有意义的字节流 而不会因权利上( de jure ) 无效而拒绝

   结束语

  模糊测试能够说明 bug 在程序中的出现 并不证明不存在这样的 bug 而且 通过模糊测试会极大地提高您对应用程序的健壮性及抵御意外输入的安全性的自信心 如果您用 小时对程序进行模糊测试而其依然无事 那么随后同种类型的攻击就不大可能再危及到它 (并不是不可能 提醒您 只是可能性很小 )如果模糊测试揭示出程序中的 bug 就应该进行修正 而不是当 bug 随机出现时再对付它们 模糊测试通过明智地使用校验和 XML 垃圾收集和/或基于语法的文件格式 更有效地从根本上加固了文件格式

  模糊测试是一项用于验证程序中真实错误的重要工具 也是所有意识到安全性问题且着力于程序健壮性的程序员们的工具箱中所必备的工具

   关于作者

  

  

  Elliotte Rusty Harold 来自新奥尔良 现在他还定期回老家喝一碗美味的秋葵汤 不过目前 他和妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights 同住的还有他的猫咪 Charm(取自夸克)和 Marjorie(取自他岳母的名字) 他是 Polytechnic 大学计算机科学的副教授 他在该校讲授 Java 和面向对象编程 他的 Web 站点 Cafe au Lait 已经成为 Internet 上最流行的独立 Java 站点之一 它的姊妹站点 Cafe con Leche 已经成为最流行的 XML 站点之一 他的书包括 Effective XML Processing XML with Java Java Neork Programming 和 The XML Bible 他目前在从事处理 XML 的 XOM API Jaxen XPath 引擎和 Jester 测试覆盖率工具的开发工作

lishixinzhi/Article/program/Java/JSP/201311/19417

阿里巴巴java开发手册pdf

下载地址:网盘下载

 

 

 

      编辑推荐

规范了Java开发准则与代码编写习惯
将直接影响Java从业者、求职者和在校相关专业大学生等逾百万的计算机相关人群
以阿里的技术底蕴,以一个独特的视角地成为影响到世界的经典计算机图书
对Java教育教学产生深远影响
对社会贡献及深远影响不可估量
内容提要
《阿里巴巴Java开发手册》的愿景是码出高效,码出质量。它结合作者的开发经验和架构历程,提炼阿里巴巴集团技术团队的集体编程经验和软件设计智慧,浓缩成为立体的编程规范和最佳实践。众所周知,现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程相关的知识点,其他维度的知识点也会影响软件的最终交付质量,比如,数据库的表结构和索引设计缺陷可能带来软件的架构缺陷或性能风险;单元测试的失位导致集成测试困难;没有鉴权的漏洞代码易被黑客攻击等。所以,本手册以开发者为中心视角,划分为编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约七个维度,每个条目下有相应的扩展解释和说明,正例和反例,全面、立体、形象地帮助到开发者的成长和团队代码规约文化的形成。
从严格意义上讲,《阿里巴巴Java开发手册》超越了Java语言本身,明确作为一名合格开发者应该具备的基本素质,因此本手册适合计算机相关行业的管理者和研发人员、高等院校的计算机专业师生、求职者等阅读,希望成为大家如良师益友般的工作手册、工具字典和床头书。
目录
序 V
前言 XI
第1章 编程规约 1
1.1 命名风格 2
1.2 常量定义 7
1.3 代码格式 9
1.4 OOP规约 14
1.5 集合处理 21
1.6 并发处理 28
1.7 控制语句 33
1.8 注释规约 38
1.9 其他 41
第2章 异常日志 43
2.1 异常处理 44
2.2 日志规约 49
第3章 单元测试 53
第4章 安全规约 59
第5章 MySQL数据库 63
5.1 建表规约 64
5.2 索引规约 68
5.3 SQL语句 72
5.4 ORM映射 75
第6章 工程结构 79
6.1 应用分层 80
6.2 二方库依赖 83
6.3 服务器 87
第7章 设计规约 89
附 录 专有名词 94
作者简介
杨冠宝
花名孤尽,取自《笑傲江湖》中风清扬的“独孤九剑,破尽天下武功”之意,是《阿里巴巴Java开发手册》的主要作者。在阿里巴巴集团历任研发、架构师、技术主管等不同的角色,承担过双11、国际化、代码中心等大型项目,有着丰富的一线编程经验,目前是研发协同平台Aone代码中心负责人。乐于分享与总结,在阿里巴巴集团内部大型分享多达30余次,不懈地追求技术创新,勇于挑战技术难度,在大数据、高并发、研发效能领域均有较深的造诣。
媒体评论
“一个优秀的工程师和一个普通工程师的区别,不是满天飞的架构图,他的功底体现在所写的每一行代码上。”——毕玄
前言
别人都说我们是搬砖的码农,可我们知道自己是追求个性的艺术家。也许我们不会过多在意自己的外表和穿着,但在我们不羁的外表下,骨子里追求着代码的美、系统的美,代码规范其实就是一个对程序美的定义。但是这种美离程序员的生活有些遥远,尽管编码规范的价值在业内有着广泛的共识,在现实中却被否定得一塌糊涂。工程师曾经最引以为豪的代码,因为编码规范的缺失、命名的草率而全面地摧毁了彼此的信任,并严重地制约了相互的高效协同。工程师一边吐槽别人的代码,一边写着被吐槽的代码,频繁的系统重构和心惊胆战的维护似乎成了工作的主旋律。
那么如何走出这种怪圈呢?众所周知,互联网公司的优势在在于效率,是企业核心竞争力,体现在产品开发领域,就是沟通效率和研发效率。对于沟通效率的重要性,可以从程序员三大“编程理念之争”说起:
? 缩进采用空格键,还是Tab键。
? if单行语句需要大括号,还是不需要大括号。
? 左大括号不换行,还是单独另起一行。
在美剧《硅谷》中,你也许会记得这样一个经典镜头:主人公Richard与同为程序员的女友分手,理由是两人对缩进方式有着不同的习惯,互相拧巴地鄙视着对方的cody style。Tab键和空格键的争议在现实编程工作中确实存在。《阿里巴巴Java开发手册》(以下简称“《手册》”)明确地支持了4个空格的做法,如果一定要问理由,没有理由,因为能够想出来的理由,就像最坚固的盾一样,总有更加锋利的矛会戳破它。只想说,一致性很重要,无边无际争论的时间成本与最后的收益是成反比的。
? 缩进采用空格键,还是Tab键。
? if单行语句需要大括号,还是不需要大括号。
? 左大括号不换行,还是单独另起一行。
在美剧《硅谷》中,你也许会记得这样一个经典镜头:主人公Richard与同为程序员的女友分手,理由是两人对缩进方式有着不同的习惯,互相拧巴地鄙视着对方的cody style。Tab键和空格键的争议在现实编程工作中确实存在。《阿里巴巴Java开发手册》(以下简称“《手册》”)明确地支持了4个空格的做法,如果一定要问理由,没有理由,因为能够想出来的理由,就像最坚固的盾一样,总有更加锋利的矛会戳破它。只想说,一致性很重要,无边无际争论的时间成本与最后的收益是成反比的。
左大括号是否单独另起一行?因为Go语言的强制不换行,在这点上,“编程理念之争”的销烟味没有那么浓,如果一定要给一个理由,那么换行的代码可以增加一行,对于按代码行数考核工作量的公司员工,肯定倾向于左大括号前换行。《手册》明确左大括号不换行。
这些理念之争的本质就是自己多年代码习惯生的茧,不愿意对不一样的风格妥协,不愿意为了团队的整体效能提升而委屈自己。只想说,很多编程方式客观上没有对错之分,一致性很重要,可读性很重要,团队沟通效率很重要。有一个理论叫帕金森琐碎定律:一个组织中的成员往往会把过多的精力花费在一些琐碎的争论上。程序员天生需要团队协作,而协作的正能量要放在问题的有效沟通上。个性化应尽量表现在系统架构和算法效率的提升上,而不是在合作规范上进行纠缠不休的讨论、争论,最后没有结论。规范不一,就像下图中的小鸭子和小鸡对话一样,言语不通,一脸囧相。鸡同鸭讲也恰恰形容了人与人之间沟通的痛点,自说自话,达不成一致意见。再举个生活中的例子,交通规则靠左行还是靠右行,两者孰好孰坏并不重要,重要的是必须要在统一的方向上通行,表面上限制了自由,但实际上是保障了公众的人身安全。试想,如果没有规定靠右行驶,那样的路况肯定拥堵不堪,险象环生。同样,过分自由随意、天马行空的代码会严重地伤害系统的健康,影响到可扩展性及可维护性。
这些理念之争的本质就是自己多年代码习惯生的茧,不愿意对不一样的风格妥协,不愿意为了团队的整体效能提升而委屈自己。只想说,很多编程方式客观上没有对错之分,一致性很重要,可读性很重要,团队沟通效率很重要。有一个理论叫帕金森琐碎定律:一个组织中的成员往往会把过多的精力花费在一些琐碎的争论上。程序员天生需要团队协作,而协作的正能量要放在问题的有效沟通上。个性化应尽量表现在系统架构和算法效率的提升上,而不是在合作规范上进行纠缠不休的讨论、争论,最后没有结论。规范不一,就像下图中的小鸭子和小鸡对话一样,言语不通,一脸囧相。鸡同鸭讲也恰恰形容了人与人之间沟通的痛点,自说自话,达不成一致意见。再举个生活中的例子,交通规则靠左行还是靠右行,两者孰好孰坏并不重要,重要的是必须要在统一的方向上通行,表面上限制了自由,但实际上是保障了公众的人身安全。试想,如果没有规定靠右行驶,那样的路况肯定拥堵不堪,险象环生。同样,过分自由随意、天马行空的代码会严重地伤害系统的健康,影响到可扩展性及可维护性。
——孤尽
前言
《阿里巴巴Java开发手册》(以下简称“《手册》”)是阿里巴巴集团技术团队的集体智慧结晶和经验总结,经历了多次大规模一线实战的检验及不断的完善,系统化地被整理成册,回馈给广大开发者。
现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程知识点,其他维度的知识点也会影响软件的最终交付质量。比如,数据库的表结构和索引设计缺陷可能带来软件的架构缺陷或性能风险;单元测试的失位导致集成测试困难;没有鉴权的漏洞代码易被黑客攻击等。(与版权页介绍一致)所以,《手册》以Java开发者为中心视角,划分为编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约七个维度,再根据内容特征,细分成若干个二级子目录。
根据约束力强弱及故障敏感性,规约依次分为【强制】、【推荐】、【参考】三大类。在规约条目的延伸信息中,“说明”对内容做了适当扩展和解释,“正例”是提倡的编码和实现方式,“反例”是需要提防的雷区及真实的错误案例。
既然《手册》划分为前文所说的七大维度知识点,那么延伸的问题就是“为什么我们会提到这些看似与编码毫无关系的章节?”有人曾经质疑,扩展的知识体系本来就是十分庞大的规范文档,比如安全规约扩展开来可以是上百页的资料,与服务器维护相关的PE手册厚厚一叠,不知道写进《手册》中的意义何在?其实,《手册》主要关注的是与开发紧密相关的知识点,《手册》不是提倡大家成为安全专家、运维专家,而是关注与编码相关的生态知识,明确了作为一位合格的Java开发工程师应具备的基本技术素养。
设计规约部分是本手册独家首发,它根据阿里巴巴一线架构设计经验沉淀而成,旨在帮助研发人员准确度量是否需要定向地设计文档。近年来,敏捷开发的流行,在一定程度上弱化了设计的重要性,在《手册》中明确了软件设计底线,如果超过规定的阈值,则需要进行有针对性的软件设计与文档沉淀。
最后,《码出高效——阿里巴巴Java开发手册详解》即将出版。此书将详细说明规约的初衷和意义、编写和推广历程,每个条目背后的思考与详细的示例代码,以及相应的故障案例分析。拟定的主要章节如下:
第1章 从程序员的“编程理念之争”说起
第2章 编码规范与团队效能的辩证关系
第3章 Java编程规约剖析
第4章 异常日志与问题排查
第5章 兢兢业业的单元测试
第6章 安全无小事
第7章 MySQL数据库
第8章 规范化的工程
第9章 设计中体现艺术家的气质

 

 

 

 

下载地址:网盘下载

 


以上是关于模糊测试 对代码质量影响深远的技术的主要内容,如果未能解决你的问题,请参考以下文章

微软开源持续开发模糊测试工具OneFuzz

各类Fuzz软件

GO语言(二十九):模糊测试(下)-

两个测试模式“”集成测试“”“”模糊测试“”,你真会么

GO语言(十六):模糊测试入门(上)

[02]剑指安全之巅:知识普及之模糊测试的新生