-
[转]文件压缩与解压缩
2010-06-20 12:25:57
对许多用户来说,在DOS和Windows环境下利用工具软件ARJ、Winzip等,压缩或解压文件是比较容易的事。但是,在Linux中如何对文件进行压缩与解压呢?本文基于Red Hat 6.0,介绍了压缩与解压文件的几种方法与技巧:
命令: compress
格式: compress 选项 文件列表
功能: 用Lempel-ziv压缩方法来压缩文件或压缩标准输入选项:
-r 递归操作,如果指定目录变元,则压缩该目录及其子目录中的所有文件。
-c 将压缩数据返回标准输出,而缺省情况下为压缩文件时将压缩数据返回文件。
-v 显示每个文件夹的压缩百分比。解释: 在用compress压缩文件时,将在原文件名之后加上扩展名.Z。如果不指定文件,则压缩标准输入,其结果返回标准输出。
实例: 目的:压缩/mnt/lgx/a1.doc文件
命令:#compress /mnt/lgx/a1.doc
结果:压缩后生成a1.doc.Z文件。命令: uncompress
格式: uncompress 选项 文件列表
功能: 解压缩用compress 程序压缩过的文件
选项: -c 它将压缩数据发往标准输出而不是改写旧的压缩文件
解释: 如果不指定文件,则解压缩标准输入。缺省-c时,为解压缩。
实例: 目的:解压缩/mnt/lgx/a1.doc.Z
命令:#uncompress /mnt/lgx/a1.doc.Z命令: gzip
格式: gzip 选项 文件目录列表
功能: 用Lempel-ziv编码压缩文件选项:
-c 压缩结果写入标准输出,原文件保持不变。缺省时gzip将原文件压缩为.gz文件,并删除原文件。
-v 输出处理信息。
-d 解压缩指定文件。
-t 测试压缩文件的完整性。解释: 值得一提的是,gzip比compress压缩更加有效。
实例: 目的:压缩/mnt/lgx/a1.doc
命令:#gzip -v /mnt/lgx/a1.doc
结果:产生a1.doc.gz的压缩文件命令: gunzip
格式: gunzip 选项 文件列表
功能: 解压缩用gzip命令(以及compress和zip命令)压缩过的文件选项:
-c 将输出写入标准输出,原文件保持不变。缺省时,gunzip将压缩文件变成解压缩文件。
-l 列出压缩文件中的文件而不解压缩。
-r 递归解压缩,深入目录结构中,解压缩命令行变元所指定目录中的所有子目录内的文件。实例: 目的:解压缩/mnt/lgx/a1.doc.gz
命令:#gunzip /mnt/lgx/a1.doc.gz命令: tar
格式: tar 选项 文件目录列表
功能: 对文件目录进行打包备份选项:
-c 建立新的归档文件
-r 向归档文件末尾追加文件
-x 从归档文件中解出文件
-O 将文件解开到标准输出
-v 处理过程中输出相关信息
-f 对普通文件操作
-z 调用gzip来压缩归档文件,与-x联用时调用gzip完成解压缩
-Z 调用compress来压缩归档文件,与-x联用时调用compress完成解压缩实例1: 目的:用tar打包一个目录下的文件
命令:#tar -cvf /mnt/lgx/a1.doc
结果:产生一个以.tar为扩展名的打包文件实例2: 目的:用tar解开打包文件
命令:#tar -xvf /mnt/lgx/a1.doc.tar
附加说明:在通常情况下,tar打包与gzip(压缩)经常联合使用,效果更好。方法是:
首先用tar打包,如:#tar -cvf /mnt/lgx/a1.doc (产生a1.doc.tar文件)
然后用gzip压缩a1.doc.tar文件,如:#gzip /mnt/lgx/a1.doc.tar (产生a1.doc.tar.gz文件)实例3: 目的:解压a1.doc.tar.gz文件
方法1:
#gzip -dc /mnt/lgx/a1.doc.tar.gz (产生a1.doc.tar文件)
#tar -xvf /mnt/lgx/a1.doc.tar (产生a1.doc文件)
这两次命令也可使用管道功能,把两个命令合二为一:
#gzip -dc /mnt/lgx/a1.doc.tar.gz | tar -xvf
方法2:使用tar提供的自动调用gzip解压缩功能
#tar -xzvf /mnt/lgx/a1.doc.tar.gz经过tar打包后,也可用compress命令压缩(注:gzip比compress压缩更加有效),产生一个以.tar.Z的文件,在解包时,可先用"uncompress 文件名"格式解压,然后用"tar -xvf 文件名"解包。也可直接调用"tar -Zxvf 文件名"解包。
-
面试时为啥问小孩儿是男孩儿、女孩儿?
2010-06-18 10:59:58
这阶段找工作,面试了好几家公司,有的技术面试完,到人事面试时,提到已经有小孩儿,都会问小孩儿多大了,男孩儿、女孩儿等等问题(绝对不是出于对小孩儿感兴趣),还有问和别人吵过架吗,问这些的意图是什么呢,该怎么回答才满意呢,我好像不太会面试,呵呵,笔试、技术面试我不怕,但是人事面试就不行了,不知道该如何回答人事提出的问题,
这阶段工作找的有点儿郁闷,难道有了小孩儿一定会影响到工作?我不这么认为,
-
Linux命令
2010-06-08 16:33:55
看到海盗船长的空间,整理的非常好,转载一下,使用起来比较方便,呵呵,谢谢啦!系统 # uname -a # 查看内核/操作系统/CPU信息
# head -n 1 /etc/issue # 查看操作系统版本
# cat /proc/cpuinfo # 查看CPU信息
# hostname # 查看计算机名
# lspci -tv # 列出所有PCI设备
# lsusb -tv # 列出所有USB设备
# lsmod # 列出加载的内核模块
# env # 查看环境变量资源
# free -m # 查看内存使用量和交换区使用量
# df -h # 查看各分区使用情况
# du -sh <目录名> # 查看指定目录的大小
# grep MemTotal /proc/meminfo # 查看内存总量
# grep MemFree /proc/meminfo # 查看空闲内存量
# uptime # 查看系统运行时间、用户数、负载
# cat /proc/loadavg # 查看系统负载磁盘和分区
# mount | column -t # 查看挂接的分区状态
# fdisk -l # 查看所有分区
# swapon -s # 查看所有交换分区
# hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备)
# dmesg | grep IDE # 查看启动时IDE设备检测状况网络
# ifconfig # 查看所有网络接口的属性
# iptables -L # 查看防火墙设置
# route -n # 查看路由表
# netstat -lntp # 查看所有监听端口
# netstat -antp # 查看所有已经建立的连接
# netstat -s # 查看网络统计信息进程
# ps -ef # 查看所有进程
# top # 实时显示进程状态用户
# w # 查看活动用户
# id <用户名> # 查看指定用户信息
# last # 查看用户登录日志
# cut -d: -f1 /etc/passwd # 查看系统所有用户
# cut -d: -f1 /etc/group # 查看系统所有组
# crontab -l # 查看当前用户的计划任务服务
# chkconfig --list # 列出所有系统服务
# chkconfig --list | grep on # 列出所有启动的系统服务程序
# rpm -qa # 查看所有安装的软件包 -
转载----软件回归测试及其实践
2010-05-27 10:17:53
在51testing上看到的好文章,转载一下。
一、 概述
在软件生命周期中的任何一个阶段,只要软件发生了改变,就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改,也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时,如果错误跟踪与管理系统不够完善,就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻,也可能导致所做的修改只修正了错误的外在表现,而没有修复错误本身,从而造成修改失败;修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题,使本来工作正常的功能产生错误。同样,在有新代码加入软件的时候,除了新加入的代码中有可能含有错误外,新代码还有可能对原有的代码带来影响。因此,每当软件发生变化时,我们就必须重新测试现有的功能,以便确定修改是否达到了预期的目的,检查修改是否损害了原有的正常功能。同时,还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试在软件生命周期中扮演着重要的角色,因忽视回归测试而造成严重后果的例子不计其数,导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。
回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
二、 回归测试策略
对于一个软件开发项目来说,项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中,并对其进行维护和管理。当得到一个软件的基线版本时,用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候,就可以根据所选择的回归测试策略,从基线测试用例库中提取合适的测试用例组成回归测试包,通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本,也有可能是测试用例的手工实现过程。
回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下,尽可能有效率和有效力地进行回归测试,需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
1、测试用例库的维护
为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变,软件的功能和应用接口以及软件的实现发生了演变,测试用例库中的一些测试用例可能会失去针对性和有效性,而另一些测试用例可能会变得过时,还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性,必须对测试用例库进行维护。同时,被修改的或新增添的软件功能,仅仅靠重新运行以前的测试用例并不足以揭示其中的问题,有必要追加新的测试用例来测试这些新的功能或特征。因此,测试用例库的维护工作还应包括开发新测试用例,这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。
测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面。
(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统,这些测试用例就会过时。例如,某个变量的界限发生了改变,原来针对边界值的测试就无法完成对新边界测试。所以,在软件的每次修改后都应进行相应的过时测试用例的删除。
(2)、改进不受控制的测试用例
随着软件项目的进展,测试用例库中的用例会不断增加,其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制,会影响回归测试的效率,需要进行改进,使其达到可重复和可控制的要求。
(3)、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试,那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库,并将冗余的用例删除掉。
(4)、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试,那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性,而且也提高了测试库的可信性,同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
2、回归测试包的选择
在软件生命周期中,即使一个得到良好维护的测试用例库也可能变得相当大,这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例,时间和成本约束可能阻碍运行这样一个测试,有时测试组不得不选择一个缩减的回归测试包来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会。然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括:
(1)、再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包,这是一种比较安全的方法,再测试全部用例具有最低的遗漏回归错误的风险,但测试成本最高。全部再测试几乎可以应用到任何情况下,基本上不需要进行分析和重新开发,但是,随着开发工作的进展,测试用例不断增多,重复原先所有的测试将带来很大的工作量,往往超出了我们的预算和进度。
(2)、基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试,而跳过那些非关键的、优先级别低的或者高稳定的测试用例,这些用例即便可能测试到缺陷,这些缺陷的严重性也仅有三级或四级。一般而言,测试从主要特征到次要特征。
(3)、基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的,测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定,回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性,但实施起来有一定的难度。
(4)、再测试修改的部分
当测试者对修改的局部化有足够的信心时,可以通过相依性分析识别软件的修改情况并分析修改的影响,将回归测试局限于被改变的模块和它的接口上。通常,一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下,回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略,但已经运行过许多次的回归测试不太可能揭示新的错误,而且很多时候,由于时间、人员、设备和经费的原因,不允许选择再测试全部用例的回归测试策略,此时,可以选择适当的策略进行缩减的回归测试。
3、回归测试的基本过程
有了测试用例库的维护方法和回归测试包的选择策略,回归测试可遵循下述基本过程进行:
(1). 识别出软件中被修改的部分;
(2). 从原基线测试用例库T中,排除所有不再适用的测试用例,确定那些对新的软件版本依然有效的测试用例,其结果是建立一个新的基线测试用例库T0。
(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。
(4). 如果必要,生成新的测试用例集T1,用于测试T0无法充分测试的软件部分。
(5). 用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能,第(4)和第(5)步测试验证 修改工作本身。
三、 回归测试实践
在实际工作中,回归测试需要反复进行,当测试者一次又一次地完成相同的测试时,这些回归测试将变得非常令人厌烦,而在大多数回归测试需要手工完成的时候尤其如此,因此,需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略,自动测试工具应该是通用的和灵活的,以便满足达到不同回归测试目标的要求。
在测试软件时,应用多种测试技术是常见的。当测试一个修改了的软件时,测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。
回归测试并不减少对系统新功能和特征的测试需求,回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求,必须补充新的测试用例使覆盖率达到规定的要求。
回归测试是重复性较多的活动,容易使测试者感到疲劳和厌倦,降低测试效率,在实际工作中可以采用一些策略减轻这些问题。例如,安排新的测试者完成手工回归测试,分配更有经验的测试者开发新的测试用例,编写和调试自动测试脚本,做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下,鼓励测试者创造性地执行测试用例,变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。
在实际工作中,可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题,而同时也可以揭示编码在回归方面的错误。 -
如何带领好一个测试团队
2010-05-20 10:36:40
最近想在测试技术兼测试管理方面有所发展,面试时被问到如何带领一个测试团队,虽然没有带领团队的经验,但自己总结了几点,写下来请大家多多指教:1. 首先了解这个团队里的每个人员,他们各自的优缺点分别是什么,能力分布情况。做到对你的团队里的每个人心里有数,只有很好的了解一个人,才能高效的发挥每个人的潜力。
2. 有针对性的做些技术培训。不断提高团队的技术能力。
3. 有效的与团队成员沟通,营造出团队的团结能力。
4. 制定团队人员的绩效考核标准,有奖有罚,起到激励团队的作用。
5. 做好和上面领导的沟通工作,这样才能有效的为自己的团队争取相应的利益。
6. 以身作责,敢于承担责任。 -
SQL 语句
2010-05-20 10:20:00
--数据操作SELECT --从数据库表中检索数据行和列
INSERT --向数据库表添加新数据行
DELETE --从数据库表中删除数据行
UPDATE --更新数据库表中的数据
--数据定义
CREATE TABLE --创建一个数据库表
DROP TABLE --从数据库中删除表
ALTER TABLE --修改数据库表结构
CREATE VIEW --创建一个视图
DROP VIEW --从数据库中删除视图
CREATE INDEX --为数据库表创建一个索引
DROP INDEX --从数据库中删除索引
CREATE PROCEDURE --创建一个存储过程
DROP PROCEDURE --从数据库中删除存储过程
CREATE TRIGGER --创建一个触发器
DROP TRIGGER --从数据库中删除触发器
CREATE SCHEMA --向数据库添加一个新模式
DROP SCHEMA --从数据库中删除一个模式
CREATE DOMAIN --创建一个数据值域
ALTER DOMAIN --改变域定义
DROP DOMAIN --从数据库中删除一个域
-
Linux下apache的安装部署详解
2010-05-20 10:11:28
1.下载apache的最新版本2.2.8并上传至要部署的服务器,打开上传文件所在的文件夹,解压apache安装包,执行下面的命令:
# tar zxvf httpd-2.2.8.tar.gz
2. 打开解压后文件夹, 执行命令:
# cd httpd-2.2.8
3. 编译并安装apache
集群方案部署执行命令:
#./configure --prefix=/usr/local/apache2.2.4 -enable-proxy -enable-proxy-html -enable-proxy-balancer -enable-rewrite -with-mpm=event
#make && make install
4. 编辑配置文件
用vi编辑器打开conf目录下的httpd.conf文件,在文件末尾加一行:
Include conf/balancer_sp.conf
在conf文件夹下新建一个名为balancer_sp.conf的文本文件,将其权限设置为可777。执行命令:
# chmod 777 balancer_sp.conf
balancer_sp.conf 文件内容为:
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
<Proxy balancer://myCluster>
BalancerMember http://172.17.8.231:8080
BalancerMember http://172.17.8.226:8080
BalancerMember http://172.17.8.239:8080
</Proxy>
<Location /spserver/>
ProxyPass balancer://myCluster/spserver/ lbmethod=byrequests
</Location>
其中, BalancerMember数量可以随应用服务器的多少而进行删减。
5. 运行apache
打开apache的bin文件夹,执行命令:
#./apachectl start # 启动apache服务
可以用ps命令检测apache服务是否已经启动。
#ps –ef
停止apache服务命令为:
#./apachectl stop
6. 检查集群配置信息
打开浏览器,输入地址:http://host:port/balancer-manager检查集群配置信息。
上述红色部分为需要修改设置部分,其余部分采用默认配置。修改配置文件,需要重新启动httpd才能生效,httpd.conf为apache的默认配置文件,%APACHE%\conf下,集群配置文件存放于相同的conf目录下,通过在httpd.conf 末尾处追加Include conf/***.conf形式进行导入。注意,依赖的mod_proxy_xxx.so文件是否存在已经设置正确轮竞。
标题搜索
我的存档
数据统计
- 访问量: 6539
- 日志数: 8
- 图片数: 2
- 建立时间: 2008-08-27
- 更新时间: 2010-06-20