技术起点

查看apache,nginx,php,mysql源码编译参数

作者：Lightning@小宝 发布时间：November 18, 2009 分类：概念&操作系统&中间件

查看apache编译参数：cat /usr/local/apache/build/config.nice

查看mysql编译参数：cat /usr/local/mysql/bin/mysqlbug | grep CONFIGURE_LINE

查看php编译参数：/usr/local/php/bin/php -i | grep configure 

查看nginx编译参数:  /usr/local/nginx/sbin/nginx -V

快速统计日志文件里点击量前十位的URL

作者：Lightning@小宝 发布时间：November 18, 2009 分类：概念&操作系统&中间件

作者：老王

关于shell命令，网上流传着很多奇技淫巧，比如说快速统计日志文件里点击量前十位的URL：

awk '{print $7}' /path/to/log | sort | uniq -c | sort -nr | head -n 10

附：这里假设日志文件是common格式的，如此一来，按空格分隔后，第七个字段就是URL

稍加思考，你会发现这里又是sort，又是uniq，存在重复操作，下面看看如何优化这条shell命令：

01 #!/bin/awk -f
02
03 {
04     url[$7]++
05 }
06
07 END {
08     for (key in url) {
09         print url[key], key | "sort -nr | head -n 10"
10     }
11 }

把上面代码（去掉行号）保存到demo.awk文件里，然后：chmod +x ./demo.awk，做这些就够了。

我找了一个7G的common格式日志文件来测试性能，视服务器性能结果会有差异，但相对值应该差不多：

time awk '{print $7}' /path/to/log | sort | uniq -c | sort -nr | head -n 10

real    1m57.150s
user    1m6.794s
sys     0m13.923s

time ./demo.awk /path/to/log

real    1m21.414s
user    0m32.799s
sys     0m22.556s

总体消耗的时间降低了四分之一，还是很明显的

Web应用中的轻量级消息队列

作者：Lightning@小宝 发布时间：November 10, 2009 分类：概念&操作系统&中间件

利用ffmpeg在linux下将mp3文件转换为wma

作者：Lightning@小宝 发布时间：October 19, 2009 分类：概念&操作系统&中间件

现在网络朝宽带网发展越来越快了，但服务器托管环境要变化还是要很多的￥，所以能节省一分就是一分。在网络上音频文件通常使用mp3格式存储，mp3格式音质可以压得比较好，但体积稍嫌有些大，而压低了音质的话就比较难听，而且也压得还不够小。wma文件在这点上相比mp3优化很多。经测试，使用24k码率下，5MB的mp3文件可压到1MB左右的wma，在我这样的烂耳朵下虽然分得出音质的胜负，但还尚能听。如果有朋友要做一个翻唱或乱录音的网站，那么把文件压成wma格式就合适不过了。

在网上搜了几十页，都是讲述如何将wma转换为mp3的，零星有几个mp3转wma的例子，可惜都是windows下的版本，有些还需要花钱。

于是干脆祭出ffmpeg，ffmpeg相信很多处理媒体文件的朋友都用过，是非常之强大，不但可以处理流行的flv等格式，我之前一直用来转换视频格式（asf、3gp、rm……）到wmv的，wmv既然能转，那么wma当然也一定能！

在网上搜寻一阵，找到了ffmpeg转wma的执行命令：

ffmpeg -y -ab 24 -ar 22050 -acodec wmav2 -i test.mp3 test.wma

其中-y参数是指直接覆盖存在文件而不用确认；-ab参数是码率；-ar参数采样率；-acodec是指定压缩格式；-i是指输入的文件；最后在敲上输出的文件就可以了。

对文件字节数影响最大的就是码率，wma文件最小的码率就是24k，不能再小了，唉，我还想用12k一试呢。

于是在命令行运行该命令，没有能成功，因为我两年前编译的这个ffmpeg并没有能支持wma。

于是到ffpeg的源码目录下（嘿嘿，这么多年了，这个源码目录居然还存在），忘了怎么编译？执行：

ffmpeg | head

就找回了原先的编译参数，是不是要加一个参数就能支持wma，难道还要装一个lame这样的东东么？敲上

./configure --help | grep wma

没有结果，仔细看了一遍help，也确实没有发现有关的东西。

于是在源码目录敲一下：

ss

请允许我有如此跳跃性的思维，其实我是没思路的时候，习惯性随手敲的，ss在我的机器上配置为svn up的快捷键。

这样一敲结果出现神奇现象，这个目录居然是一个svn拿下来的目录，而且，那么多年了，居然还能从这个svn地址check下东西，svn团队居然能把一个svn地址维护那么多年，一直没中断，实在是一大奇迹。

看一下这个传奇的svn地址：

svn://svn.mplayerhq.hu/ffmpeg/trunk

朋友们可以直接敲：

svn co svn://svn.mplayerhq.hu/ffmpeg/trunk

就可以拿下ffmpeg的所有东西了，我不知道ffmpeg现在有没有出tar.gz的包裹，前些年我就是直接从这个svn地址checkout下来的了。

多年没更新了，svn up的时间还比较长……

拿下最新的源码后，直接编译一下看看，我的编译参数是极简的：

./configure --enable-gpl --disable-debug --prefix=/data/ffmpeg --enable-libmp3lame --enable-pthreads --enable-nonfree

我用的系统是ubuntu，在ubuntu下有ffmpeg的apt，但当时安上去后发现没有声音，于是下载了ffmpeg的svn，并自己装上lame，才创出了声音。lame记得是用apt安装的，不很麻烦：

apt-get install lame liblame-dev

注意要安上liblame-dev的开发包，否则还是会不能支持mp3。

然后就是：

make; make install

无聊的过程。

装完后可以一测，嗯，这回能支持了。


总结（写到后面我总有点不耐烦）：

###############################
#系统是ubuntu6

apt-get install lame liblame-dev
svn co svn://svn.mplayerhq.hu/ffmpeg/trunk
cd trunk
./configure --enable-gpl --disable-debug --prefix=/data/ffmpeg --enable-libmp3lame --enable-pthreads --enable-nonfree
make -j10; make install

###

然后就可以用了：

/data/ffmpeg/ffmpeg -y -ab 24 -ar 22050 -acodec wmav2 -i test.mp3 test.wma

附带转wmv的，我怕不支持，也小测一把：

ffmpeg -y -acodec mp3 -vcodec wmv2 -i test.rm test.wmv
ffmpeg -y -acodec wmav2 -vcodec wmv2 -i test.rm test.wmv

都可以。

白盒测试&黑盒测试

作者：Lightning@小宝 发布时间：October 10, 2009 分类：概念&操作系统&中间件

白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（STatement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。
·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（DECision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（ConDItion Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是独立的。
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。

黑盒测试的优点
1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序CRASh了
2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点
1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的tEStcase造成的问题。这些在堆的问题中表现的更为突出。