1.代码测试工具Fortify介绍及实操演示（下）
2.全面梳理：准确率,精确率,召回率,查准率,查全率,假阳性,真阳性,PRC,ROC,AUC,F1
3.iphone4如何升级越狱苹果4越狱教程
4.arm-linux-gcc 和 arm-elf-gcc 的区别

代码测试工具Fortify介绍及实操演示（下）

       Fortify是一款在代码审计中广泛应用的静态代码分析工具，尤其在金融等行业中受到青睐。它是软件开发组织及专业评测机构构建软件测试体系时的常用安全测试工具。在前面的文章中，我们已经介绍了Fortify的最新功能和通过“Audit Workbench”模式测试Java语言源代码的方法。接下来，做联盟的源码本文将继续介绍通过“Scan Wizard”模式和命令行进行测试的操作流程。

       通过“Scan Wizard”进行测试

       “Scan Wizard”支持多种语言或框架的源代码测试，包括Java、Python、C/C++、.Net、Go、PHP、Flex、Action Script、HTML、XML、JavaScript、TypeScript、Kotlin、SQL、spring源码规范ABAP、ColdFusion。

       （1）打开Scan Wizard

       （2）选择Python文件所在目录

       （3）确认测试工具自动识别内容

       （4）选择库文件

       （5）生成脚本文件

       （6）完成脚本文件生成

       （7）执行生成的脚本文件

       通过命令行进行测试

       命令行方式支持各语言源代码的测试。

       一、Linux项目测试

       以Linux下C/C++程序代码测试为例：

       1. 代码编译

       在代码测试执行前，首先需要进行C/C++程序代码的编译，如下面的示例：

       gcc -I. -o hello.o -c helloworld.c

       通过gcc编译器将代码进行编译。

       2. 代码测试

       在代码编译后，使用sourceanalyzer命令进行代码文件测试。

       sourceanalyzer -b gcc -I. -o hello.o -c helloworld.c

       3. 代码扫描结果文件生成

       在代码测试后，使用sourceanalyzer命令进行代码文件扫描及结果文件生成。

       sourceanalyzer -b -scan -f hello.fpr

       其中，本命令中的与第2步命令中的相同。成功生成结果文件后，可以基于该结果文件生成测试报告。

       4. 代码扫描结果文件生成

       二、iOS项目测试

        1. iOS项目测试条件

       （1） iOS项目需要使用non-fragile Objective-C runtime模式（ABI version 2或3）

       （2） 使用Apple “xcode-select command-line tool”设置Xcode path，同时供Fortify使用。

       （3） 确保项目相关依赖库文件已经包含在项目中。

       （4） 针对Swift代码，确保所有第三方模块都已经被包含，rabixtree源码分析包括Cocoapods。

       （5） 如果项目中包含二进制的属性列表文件，需要将它们转化为XML格式，通过Xcode的putil命令进行转换。

       （6） 针对Objective-C项目，需要保证头文件能够被获取。

       （7） 针对WatchKit应用，需要同时转化iPhone应用和WatchKit扩展目标。

       2. iOS代码测试执行

       sourceanalyzer -b xcodebuild []

       测试报告生成

       通过“Scan Wizard”生成测试报告

       通过“Scan Wizard”方式进行测试执行，会生成.fpr测试结果文件，然后通过命令行方式基于测试结果文件生成测试报告文件。

       通过命令行生成测试报告

       通过“Scan Wizard”方式或命令行方式生成测试结果文件后，可以基于“ReportGenerator”命令生成测试报告。

       下面示例中，基于.fpr结果文件生成PDF格式的测试报告。

       ReportGenerator -format pdf -f.pdf -source .fpr

       .pdf为命名的PDF格式测试报告名称，.fpr为测试结果文件名称。

       以上就是我们为大家介绍的Fortify不同模式下的使用操作流程，欢迎大家交流讨论。如需其他软件测试体系建设相关的内容可私信我交流。

       （谢绝转载，spark count源码更多内容可查看我的专栏）

       相关链接：

       @道普云 持续输出软件测试技术、软件测试团队建设、软件测评实验室认可等内容。不断更新中，欢迎交流探讨。

       我的专栏：

       性能测试 工具、方法、流程、诊断、调优......

       安全测试 app安全测试、web安全测试、渗透测试、代码测试

       软件测试CNAS认证 标准解读、政策分析、体系建设、测试方法、测试工具

       功能测试 功能自动化测试、自动化测试工具、测试用例、缺陷管理

       新兴技术测试 人工智能系统测试、大数据系统测试、番薯网源码自动化测试...

全面梳理：准确率,精确率,召回率,查准率,查全率,假阳性,真阳性,PRC,ROC,AUC,F1

       二分类问题的结果有四种：

       逻辑在于，你的预测是positive-1和negative-0，true和false描述你本次预测的对错

       true positive-TP：预测为1，预测正确即实际1

       false positive-FP：预测为1，预测错误即实际0

       true negative-TN：预测为0，预测正确即实际0

       false negative-FN：预测为0，预测错误即实际1

       混淆矩阵

       直观呈现以上四种情况的样本数

       准确率accuracy

       正确分类的样本/总样本：(TP+TN)/(ALL)

       在不平衡分类问题中难以准确度量：比如%的正样本只需全部预测为正即可获得%准确率

       精确率查准率precision

       TP/(TP+FP)：在你预测为1的样本中实际为1的概率

       查准率在检索系统中：检出的相关文献与检出的全部文献的百分比，衡量检索的信噪比

       召回率查全率recall

       TP/(TP+FN)：在实际为1的样本中你预测为1的概率

       查全率在检索系统中：检出的相关文献与全部相关文献的百分比，衡量检索的覆盖率

       实际的二分类中，positive-1标签可以代表健康也可以代表生病，但一般作为positive-1的指标指的是你更关注的样本表现，比如“是垃圾邮件”“是阳性肿瘤”“将要发生地震”。

       因此在肿瘤判断和地震预测等场景：

       要求模型有更高的召回率recall，是个地震你就都得给我揪出来不能放过

       在垃圾邮件判断等场景：

       要求模型有更高的精确率precision，你给我放进回收站里的可都得确定是垃圾，千万不能有正常邮件啊

       ROC

       常被用来评价一个二值分类器的优劣

       ROC曲线的横坐标为false positive rate（FPR）：FP/(FP+TN)

       假阳性率，即实际无病，但根据筛检被判为有病的百分比。

       在实际为0的样本中你预测为1的概率

       纵坐标为true positive rate（TPR）：TP/(TP+FN)

       真阳性率，即实际有病，但根据筛检被判为有病的百分比。

       在实际为1的样本中你预测为1的概率，此处即召回率查全率recall

       接下来我们考虑ROC曲线图中的四个点和一条线。

       第一个点，(0,1)，即FPR=0,TPR=1，这意味着无病的没有被误判，有病的都全部检测到，这是一个完美的分类器，它将所有的样本都正确分类。

       第二个点，(1,0)，即FPR=1，TPR=0，类似地分析可以发现这是一个最糟糕的分类器，因为它成功避开了所有的正确答案。

       第三个点，(0,0)，即FPR=TPR=0，即FP（false positive）=TP（true positive）=0，没病的没有被误判但有病的全都没被检测到，即全部选0

       类似的，第四个点（1,1），分类器实际上预测所有的样本都为1。

       经过以上的分析可得到：ROC曲线越接近左上角，该分类器的性能越好。

       ROC是如何画出来的

       分类器有概率输出，%常被作为阈值点，但基于不同的场景，可以通过控制概率输出的阈值来改变预测的标签，这样不同的阈值会得到不同的FPR和TPR。

       从0%-%之间选取任意细度的阈值分别获得FPR和TPR，对应在图中，得到的ROC曲线，阈值的细度控制了曲线的阶梯程度或平滑程度。

       一个没有过拟合的二分类器的ROC应该是梯度均匀的，如图紫线

       ROC曲线有个很好的特性：当测试集中的正负样本的分布变化的时候，ROC曲线能够保持不变。而Precision-Recall曲线会变化剧烈，故ROC经常被使用。

       AUC

       AUC（Area Under Curve）被定义为ROC曲线下的面积，完全随机的二分类器的AUC为0.5，虽然在不同的阈值下有不同的FPR和TPR，但相对面积更大，更靠近左上角的曲线代表着一个更加稳健的二分类器。

       同时针对每一个分类器的ROC曲线，又能找到一个最佳的概率切分点使得自己关注的指标达到最佳水平。

       AUC的排序本质

       大部分分类器的输出是概率输出，如果要计算准确率，需要先把概率转化成类别，就需要手动设置一个阈值，而这个超参数的确定会对优化指标的计算产生过于敏感的影响

       AUC从Mann–Whitney U statistic的角度来解释：随机从标签为1和标签为0的样本集中分别随机选择两个样本，同时分类器会输出两样本为1的概率，那么我们认为分类器对“标签1样本的预测概率>对标签0样本的预测概率 ”的概率等价于AUC。

       因而AUC反应的是分类器对样本的排序能力，这样也可以理解AUC对不平衡样本不敏感的原因了。

       作为优化目标的各类指标

       最常用的分类器优化及评价指标是AUC和logloss，最主要的原因是：不同于accuracy，precision等，这两个指标不需要将概率输出转化为类别，而是可以直接使用概率进行计算。

       顺便贴上logloss的公式

       F1

       F1兼顾了分类模型的准确率和召回率，可以看作是模型准确率和召回率的调和平均数，最大值是1，最小值是0。

       额外补充AUC为优化目标的模型融合手段rank_avg：

       在拍拍贷风控比赛中，印象中一个前排队伍基于AUC的排序本质，使用rank_avg融合了最后的几个基础模型。

       rank_avg这种融合方法适合排序评估指标，比如auc之类的

       其中weight_i为该模型权重，权重为1表示平均融合

       rank_i表示样本的升序排名 ，也就是越靠前的样本融合后也越靠前

       能较快的利用排名融合多个模型之间的差异，而不用去加权样本的概率值融合

       贴一段源码：

       M为正类样本的数目，N为负类样本的数目，rank为分类器给出的排名。

       可以发现整个计算过程中连直接的概率输出值都不需要，仅关心相对排名，所以只要保证submit的那一组输出的rank是有意义的即可，并不一定需要必须输出概率。

iphone4如何升级越狱苹果4越狱教程

       iphone4如何升级越狱，苹果4越狱教程很多人还不知道，现在让我们一起来看看吧！

       1、iphone4越狱后如何安装软件？很多买了iphone4的朋友会越狱，但是越狱后会有一个问题：越狱后如何给iphone4安装软件？

       2、iphone4越狱后如何安装软件：

       3、一、iphone4越狱后安装软件，首先要安装AppSync补丁：

       4、安装补丁的方法非常简单。打开Cydia，点击下方的管理，然后点击右上角的编辑，再点击左侧的添加。这时会出现如下界面。输入monly used with uClinux. uC-libc and

       uClibc. They are quite different despite their similar names. Here is a

       quick overview of how they are different.

       ã€€ã€€uC-libc is the original library for uClinux. It was based on sources

       from the Linux- C library which was part of the ELKs project with m

       support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete

       libc implementation, however, some of the API's are a little non-standard

       and quite a few common libc routines are not present. Currently it has

       stable support for m, ColdFire and ARM (Non-MMU) architectures. It was

       primary design goal is to be small and light weight. It does try to conform

       to any standards, although its API tries to be compatible with most libcs,

       it is not always exactly the same.

       ã€€ã€€The uClinux distribution provides an environment that can compile using

       either uC-libc or uClibc depending on your needs. For m and Coldfire

       platforms it is generally better to chose uC-libc as it supports shared

       libraries and is the most commonly used libc for these CPUs. uClibc also

       works quite well with almost all platforms supported by the distribution.

       Which libc you choose to use will be decided by your requirements

       uClinux有两个经常使用的libc库：uC-libc和uClibc。虽然两者名字很相似，其实有差

       åˆ«ï¼Œä¸‹é¢å°±ç®€å•çš„介绍一下二者的不同之处。uC -libc是最早为uClinux开发的库，是

       Jeff Dionne和Kenneth Albanowski为在EKLs项目中支持m在Linux- C库源码

       ä¸Šç§»æ¤çš„。uC-libc是一个完全的libc实现，但其中有一些api是非标准的，有些libc的

       æ ‡å‡†ä¹Ÿæ²¡æœ‰å®žçŽ°ã€‚uC-libc稳定地支持 m，ColdFire和没有MMU的ARM。其主要设计

       ç›®æ ‡æ˜¯â€œå°â€ã€"è½»"，并尽量与标准一致，虽然它的API和很多libc兼容，但是似乎并

       ä¸åƒå®ƒæœŸæœ›çš„那样和所有标准一致。

       uClibc就是为了解决这个问题从uC-libc中发展出来的。它的所有API都是标准的(正确

       çš„返回类型，参数等等)，它弥补了uC-libc中没有实现的libc标准，现在已经被移植到

       å¤šç§æž¶æž„中。一般来讲，它尽量兼容glibc以便使应用程序用uClibc改写变的容易。

       uClibc能够在标准的 VM linux和uClinux上面使用。为了应用程序的简洁，它甚至可以

       åœ¨è®¸å¤šæ”¯æŒMMU的平台上被编译成共享库。Erik Anderson在uClibc背后做了很多的工

       ä½œã€‚uClibc支持许多系列的处理器：m，Coldfire，ARM，MIPS，v， x，

       i，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不断增加的平台支持显示uClibc

       èƒ½å¤Ÿå¾ˆå®¹æ˜“的适应新的架构。uClinux发行版提供了环境能够让你选择使用uC-libc或是

       uClibc编译。对于m和Coldfire平台来说，选择uC-libc还是稍微好一点，因为它

       æ”¯æŒå…±äº«åº“，而共享库是这些cpu经常使用的 libc.uClibc也几乎和所有的平台都能很

       å¥½çš„工作。选择哪种libc取决于你的需求。

       newlib 是一个用于嵌入式系统的开放源代码的C语言程序库，由libc和libm两个库组

       æˆï¼Œç‰¹ç‚¹æ˜¯è½»é‡çº§ï¼Œé€Ÿåº¦å¿«ï¼Œå¯ç§»æ¤åˆ°å¾ˆå¤šCPU结构上。newlib实现了许多复杂的功

       èƒ½ï¼ŒåŒ…括字符串支持，浮点运算，内存分配(如malloc)和I/O流函数(printf，fprinf()

       ç­‰ç­‰)。其中libc提供了c 语言库的实现，而libm提供了浮点运算支持。

       åœ¨ä¸ºARM交叉编译gcc编译器时，对gcc指定不同的配置选项时，使用的C语言库就不同，

       gcc编译器默认使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，当使用

       --with-newlib时，gcc编译器不使用Glibc。当没有交叉编译Glibc时，可以使用

       --with-newlib禁止连接Glibc而编译bootstrap gcc编译器。从gcc源目录下的

       config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影响gcc连接C语言

       åº“，t-linux(--target=arm-linux)默认使用Glibc，-arm-elf(--target=arm-elf)使用

       - Dinhibit_libc禁止连接Glibc，这时我们就可以使用newlib等其他C语言库编译GCCå·¥

       å…·é“¾ã€‚

       è™½ç„¶GCC工具链配置了不同的的C语言库，但由于这些C语言库都可以用来支持GCC，它们

       å¯¹æ ¸å¿ƒæ•°æ®çš„处理上不存在较大出入。因而arm-linux-* 和 arm-elf-*区别主要表现在

       C语言库的实现上，例如不同系统调用，不同的函数集实现，不同的ABI\启动代码以及

       ä¸åŒç³»ç»Ÿç‰¹æ€§ç­‰å¾®å°çš„差别。

       arm-linux-*和 arm-elf-*的使用没有一个绝对的标准，排除不同库实现的差异，gcc可

       ä»¥ç¼–译任何系统。arm-linux-*和 arm-elf-*都可以用来编译裸机程序和操作系统，只

       æ˜¯åœ¨éµå¾ªä¸‹é¢çš„描述时系统程序显得更加协调：

       arm-linux-*针对运行linux的ARM机器，其依赖于指定的C语言库Glibc，因为同样使用

       Glibc的linux而使得arm-linux-*在运行linux的ARM机器上编译显得更加和谐。

       arm-elf-*则是一个独立的编译体系，不依赖于指定的C语言库Glibc，可以使用newlib

       ç­‰å…¶ä»–C语言库，不要求操作系统支持，当其使用为嵌入式系统而设计的一些轻巧的C语

       è¨€åº“时编译裸机程序(没有linux等大型操作系统的程序)，如监控程序，bootloader等

       èƒ½ä½¿å¾—系统程序更加小巧快捷。

       Linaro prebuilt toolchain does support both hard and soft floating

       point. You can get it from /linaro-toolchain-binaries/+milestone/. try: ./arm-linux-gnueabihf-gcc -print-multi-lib

       The default configure is --with-arch=armv7-a --with-tune=cortex-a9

       --with-fpu=vfpv3-d --with-float=hard --with-mode=thumb

       To use soft floating, you need options: -marm -march=armv4t -mfloat-abi=soft.

       In your case, please try to change -march=armv5 to "-march=armv4t"

       If you want to change to configure to cortex-a8 and armv5. You need

       * Change cortex-a9 to cortex-a8 in

       samples/linaro-arm-linux-gnueabihf/crosstool.config

       * Change armv4t to armv5 in

       contrib/linaro/patches/gcc/linaro-4.7-./multilib.patch,

       Then follow the instructions to rebuild the toolchain

       (contrib/linaro/doc/README.txt)

       BTW: crosstool-ng-linaro does not support multilib for eglibc. It uses

       the prebuilt sysroot from Ubuntu Precise. If it does not work for you,

       please use the latest crosstool-ng from http://crosstool-ng.org/.