发布新日志

  • Logcat过滤及常见用法整理

    2012-10-11 17:23:18

    转载http://hi.baidu.com/donghaozheng/item/efc72f200f716246479962fa
     

    Logcat过滤及常见用法整理

    Usage: logcat [options] [filterspecs]
    options include:
    -s              Set default filter to silent.
                      Like specifying filterspec '*:s'
    -f <filename>   Log to file. Default to stdout
    -r [<kbytes>]   Rotate log every kbytes. (16 if unspecified). Requires -f
    -n <count>      Sets max number of rotated logs to <count>, default 4
    -M <1,0>        Set enable copy(Move) the log to oms_log_path
    -v <format>     Sets the log print format, where <format> is one of:

                      brief process tag thread raw time threadtime long

    -c              clear (flush) the entire log and exit
    -d              dump the log and then exit (don't block)
    -g              get the size of the log's ring buffer and exit
    -b <buffer>     request alternate ring buffer
                      ('main' (default), 'radio', 'events')
    -B              output the log in binary

    filterspecs are a series of
    <tag>[:priority]

    where <tag> is a log component tag (or * for all) and priority is:
    V    Verbose
    D    Debug
    I    Info
    W    Warn
    E    Error
    F    Fatal
    S    Silent (supress all output)

    '*' means '*:d' and <tag> by itself means <tag>:v

    If not specified on the commandline, filterspec is set from ANDROID_LOG_TAGS.
    If no filterspec is found, filter defaults to '*:I'

    If not specified with -v, format is set from ANDROID_PRINTF_LOG
    or defaults to "brief"

    示例:

    1. 看radio log
      logcat -b radio

      I/RILC    (   46): 39 0d 0a
      I/RILC    (   46): AT[0]< +ECIND: 1,16,99
      I/RILC    (   46): AT[0]< +ECSQ: 16,99
      I/RILC    (   46): <<<< pCh[0]...
      I/RILC    (   46): 0d 0a 2b 45 43 49 4e 44 3a 20 31 2c 31 37 2c 39 39 0d 0a 0d 0a 2b 45 43 53 51 3a 20 31 37 2c 39
      I/RILC    (   46): 39 0d 0a
      I/RILC    (   46): AT[0]< +ECIND: 1,17,99
      I/RILC    (   46): AT[0]< +ECSQ: 17,99
    2. 查看warning以上的log
      logcat *:w

      E/SensorManager( 102): smjni------jni data_open
      E/        (   49): b433 6155
      E/        (   49): b433 6157
      E/gralloc ( 102): [unregister] handle 0x2debd0 still lock
      W/BatteryService( 102): get battery health[0] 'Charging'
      W/BatteryService( 102): get battery health='Good'
      W/BatteryService( 102): get battery health[0] 'Charging'
      W/BatteryService( 102): get battery health='Good'
    3. 过滤查看dalvikvm的log
      logcat -s dalvikvm 或者 logcat dalvikvm *:s

      D/dalvikvm( 257): GC freed 1191 objects / 343344 bytes in 65ms
      D/dalvikvm( 257): GC freed 1191 objects / 343400 bytes in 64ms
      D/dalvikvm( 257): GC freed 1191 objects / 343368 bytes in 65ms
      D/dalvikvm( 257): GC freed 1191 objects / 343416 bytes in 70ms
      D/dalvikvm( 257): GC freed 1191 objects / 343384 bytes in 64ms

      备注:logcat的过滤方式有点儿怪异,并不是直接指定要过滤的tag并指定priority就行,必须要设定所有的为silent,在此基础上设置的tag过滤才成功。
      所以,logcat appname:v 是不能成功过滤log的。
    4. 过滤多个app
      logcat -s dalvikvm vold

      D/vold    (   43): door_sock=10
      D/vold    (   43): fw_sock=7
      D/vold    (   43): uevent_sock=6
      D/dalvikvm( 257): GC freed 1191 objects / 343384 bytes in 76ms
      D/dalvikvm( 257): GC freed 1191 objects / 343368 bytes in 81ms
      D/dalvikvm( 257): GC freed 1191 objects / 343400 bytes in 64ms
      D/vold    (   43): select result=1
    5. log保存到文件
      logcat > 1.txt (">"是windows用的数据流导向符号)
  • Android测试方法

    2012-05-30 11:51:21

    http://wenku.baidu.com/view/7fc9b814f18583d048645906.html
  • android 测试中用到相关 !

    2012-05-30 11:49:56

  • android系统Logcat过滤及常见用法整理

    2012-05-15 16:13:28

    http://hi.baidu.com/xnjdyp/blog/item/d9426086f3cee6b06d811922.html
     
     
    http://blog.sina.com.cn/s/blog_406127500100sig1.html
  • linux busybox

    2012-05-14 13:55:28

    http://baike.baidu.com/view/1429588.htm
     
    http://zh.wikipedia.org/zh/BusyBox
  • linux下常用网络命令

    2012-05-02 16:46:12

    网络接口管理
    ifconfig//显示第一个网卡和环路信息
    其中:inet addr --Internet Address //IP地址
    Hwaddr --Hardware Address //硬件地址
    Bcast --BrodCast //广播地址
    Mask --Network Mask //网络掩码
    MTU --Maximum Transmission//最大传输单元
    RX/TX //分别代表Received和Transmitted,显示已接收和发送的数据包总数
    #ifconfig eth0 netmask 255.255.0.0 //修改子网掩码
    #ifconfig eth0 down //关闭网卡
    #ifconfig eth0 up //打开网卡
    #system-config-network 或 #redhat-config-network
    //开启图形化配置界面

    网络状况监控
    ping  //检查网络的联通性,用Ctrl+C中断
    netstat//查看网络链接,路由表和网络接口的信息
    nslookup//
     
     
    Linux网络命令详解
    http://www.upk8.com/Article/linux/200712/430_4.html
     
     
     
    http://www.upk8.com/Article/linux/200712/430.html
  • 终于记得51tesing的用户名和密码了

    2012-04-05 17:13:22

    一年半没写测试日志了,现在我又回来了。
    一年多变化好大呀。结婚生小孩了,当妈妈了。
    要勤写日记,每天都要进步哦
  • SPDIF

    2010-09-28 09:46:05

  • http各返回值的含义

    2010-09-26 16:43:58

    日志中的HTTP状态码都代表什么?

    作SEO时,我们经常会在日志上看到类似这样的代码:

    61.135.166.232 - - [31/Dec/2007:02:30:11 +0800] "GET /category21.html HTTP/1.1" 200 10968 "-" "Baiduspider+(+http://www.baidu.com/search/spider.htm)"

    66.249.70.172 - - [31/Dec/2007:03:36:10 +0800] "GET /32_10_zh.html HTTP/1.1" 200 18395 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

    这里面需要知道的,就是那个奇怪的数字“200”(另外那个数字表示抓取的文件大小)。
    “200”就是HTTP状态码

    SEO过程中最常见的HTTP状态码有:

    • 200 - 服务器成功返回网页
    • 404 - 请求的网页不存在
    • 503 - 服务器超时


    其他经常碰到的HTTP状态码列表如下:

    HTTP状态码        摘要说明

    成功2××          成功处理了请求的状态码。
    200                   服务器已成功处理了请求并提供了请求的网页。
    204                   服务器成功处理了请求,但没有返回任何内容。                        
    重定向3××       每次请求中使用重定向不要超过 5 次。
    301                   请求的网页已永久移动到新位置。当URLs发生变化时,使用301代码。搜索引擎索引中保存新的URL。
    302                   请求的网页临时移动到新位置。搜索引擎索引中保存原来的URL。
    304                   如果网页自请求者上次请求后没有更新,则用304代码告诉搜索引擎机器人,可节省带宽和开销。
    客户端错误4××  表示请求可能出错,妨碍了服务器的处理。
    400                    服务器不理解请求的语法。
    403                    服务器拒绝请求。
    404                    服务器找不到请求的网页。服务器上不存在的网页经常会返回此代码。
    410                    请求的资源永久删除后,服务器返回此响应。该代码与 404(未找到)代码相似,但在资源以前存在而现在不存在的情况下,有时用来替代404 代码。如果资源已永久删除,应当使用 301 指定资源的新位置。
    服务器错误5××   表示服务器在处理请求时发生内部错误。这些错误可能是服务器本身的错误,而不是请求出错。
    500                     服务器遇到错误,无法完成请求。
    503                     服务器目前无法使用(由于超载或停机维护)。通常,这只是暂时状态。

  • believe

    2010-09-24 17:55:25

    要相信自己能在测试中有很大发展,从工作中学习。

  • 日志 [2010年09月24日]

    2010-09-24 17:40:26

    一年多没进空间了,计划从今天开始要有规律的把自己生活和工作上的事情记录下来。

  • 生活小记

    2009-03-28 19:41:57

    今天星期六,看了一下午的电影。好累哦,计划又没完成。
  • 软件质量需求不断提高 小Bug蕴含测试大市场

    2007-08-05 21:43:53


    软件中的Bug 是指操作系统或应用软件程序的错误或缺陷。随着软件规模的扩大,软件的复杂程度也不断提高,软件Bug 的数量也成比例增加,由此产生的危害日益加剧。

    因此,从某种程度上说,软件产品的竞争已经不是技术的先进与否,而是软件的质量是否稳定,是否含有更少的Bug 的竞争。随着对软件质量需求的不断增强,研究软件Bug 的产生原因,从而有效地发现、修正和预防Bug 成为软件行业日益重视的课题。

    有一个美丽的传说

    IT界流传着关于软件Bug 的名称起源的多个版本,其中流传最广的是Grace Hopper在计算机的继电器中发现一只“飞蛾”导致计算机死机的传说。

    故事发生在1945年9月9日,下午3点。一个炎热的夏天,房间没有空调,所有窗户都敞开散热。Grace Hopper中尉正领着她的小组构造一个称为“MARK II”的计算机。这还不是一个完全的电子计算机,它使用了大量的继电器(一种电子机械装置)。Hopper的小组日以继夜地工作,机房是一间第一次世界大战时建造的老建筑。

    突然,MARK II死机了。技术人员试了很多办法,最后定位到板子F第70号继电器出错。Grace Hopper观察这个出错的继电器,发现一只飞蛾躺在中间,已经被继电器打死。她小心地用摄子将蛾子夹出来,用透明胶布帖到“事件记录本”中,并注明“第一个发现虫子的实例。”,然后计算机又恢复了正常。从此以后,人们将计算机错误戏称为虫子(Bug)或臭虫,而把找寻错误的工作称为“找臭虫”(Debug)。Grace Hopper的事件记录本,连同那个飞蛾,现在陈列在美国历史博物馆中。

    这个流传最广的版本,故事的真实性尚有待于进一步考证,但是Bug这一术语本身的简洁和恰当远比这个故事深刻。
    Bug 一词一般用来指代昆虫以及节肢动物,特别是指一些有害臭虫。在自然界,它们经常是人类的主要竞争者。科学家推测,如果人类灭绝,Bug将成为这个星球的主宰生命。据《圣经》所言,上帝降临埃及将犹太人从奴隶制度中解放出来时,带来了10种灾难。其中3种都是Bug,包括臭名昭著的蚊子、苍蝇和蝗虫,这些Bug叮咬我们的肉体,毁坏我们的房屋,吞噬我们的庄稼,并且将很多疾病传染给我们。

    与自然界的Bug具有特别类似特征的是软件中的Bug,从人类第一次开发软件开始,软件中的Bug一直以极其相似的方式折磨着人们。软件中的Bug如同自然界的Bug,它们无处不在,几乎所有的软件都有Bug。当我们遇到这些Bug时,它们同自然界中的Bug一样使我们惶惶不安,甚至陷入深深的痛苦之中。

    因此,如同自然界的害虫带来对人们的深深伤害一样,称软件的错误或缺陷为Bug,已经成为软件界倍感棘手的老大难问题,这可作为软件Bug名称来源的另一个版本。

    都是Bug惹的祸

    人们对软件Bug的心态是既敬畏又憎恨,主要是因为软件Bug经常潜藏于无形之中,而一旦发作轻则引起数据丢失,重则物毁人亡,造成生命和财产的巨大损失。且看一组近期发生的与软件Bug有关的真实事例。

    软件大佬比尔·盖茨遭遇软件Bug尴尬。大名鼎鼎的比尔·盖茨是何等显赫的人物,但是软件Bug从来六亲不认,根本不买他的账,使得软件大佬在演讲现场遭遇软件Bug引起计算机死机,真是“华佗无奈小虫何”。据外电报道,在CES 2005展会第一天,比尔介绍了微软的“无缝计算”战略,但就在演示的时候,可爱的Windows又出现了蓝屏,引起观众的哄笑。接下来在90分钟的演示中,一名产品经理演示了一款看起来属于用户友好的视频游戏Forza Motor Sport,游戏没有按照用户设置的要求进入赛车游戏,而是电脑显示器显示蓝屏死机和“系统内存溢出”的警告。实际上,硬件故障和软件Bug,已经在很大程度上浇灭了用户追求数字生活的激情。

    软件Bug引起北美地区大面积停电事故。著名安全机构SecurityFocus的数据表明,2003年8月14日发生的美国及加拿大部分地区史上最大停电事故是由软件错误所导致。SecurityFocus的数据表明,位于美国俄亥俄州的第一能源(FirstEnergy)公司下属的电力监测与控制管理系统“XA/21”出现软件错误,是北美大停电的罪魁祸首。根据第一能源公司发言人提供的数据,由于系统中重要的预警部分出现严重故障,负责预警服务的主服务器与备份服务器接连失控,使得错误没有得到及时通报和处理,最终多个重要设备出现故障导致大规模停电。

    导航软件Bug使俄罗斯飞船偏离降落地。2003年5月4日,搭乘俄罗斯“联盟—TMA1”载人飞船的国际空间站第七长期考察团的宇航员们返回了地球,但在返回途中,飞船偏离了降落目标地点约460公里。据来自美国国家航空航天局的消息称,这是由飞船的导航计算机软件设计中的错误引起的。

    其实,软件Bug造成重大事故的例子不胜枚举,由此造成的损失每年接近600亿美元。2002年6月28日,美国商务部的国立标准技术研究所(NIST:National Institute of Standards and Technology)发表了有关软件缺陷的损失调查报告。报告表示,“据推测,由于软件缺陷而引起的损失额每年高达595亿美元。这一数字相当于美国国内生产总值的0.6%”。
    软件Bug虽然仅是一只“小虫”,但说软件Bug猛于虎,确实千真万确。随着软件在社会生活中的不断渗透,特别是各种嵌入式软件在各种智能电器的应用,软件Bug造成的损失将会更大,对此,应该引起人们足够的警惕并采取一个可能措施,将损失降低到最小程度。警惕呀,软件Bug!

    软件Bug的丑恶嘴脸

    软件Bug是软件世界的“恐怖分子”,是最不招人喜欢的家伙。常听用户抱怨软件不好用,Bug太多,可是软件Bug外貌如何,却总是众说纷纭。

    经过对各种软件Bug特征的综合研究,人们对于软件Bug的丑恶嘴脸有了一些比较系统的认识。判断一个软件运行结果是否属于软件Bug可以从以下几个方面分析,凡是属于下列现象之一者,就是软件Bug。这些现象分别是:

    1. 软件未达到产品说明书标明的功能;
    2. 软件出现了产品说明书指明不会出现的错误;
    3. 软件功能超出产品说明书指明的范围;
    4. 软件未达到产品说明书虽未指出但应达到的目标;
    5. 软件测试人员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。

    在以上5条中,需要特别讨论后面的3条。第3条是说如果软件的功能和特征超出了软件的设计说明书的要求,那么也属于软件的缺陷;第4条是说如果测试者发现软件不正常,尽管设计说明书没有注明,但是根据测试者的工作经验和测试的尝试,也能判断出是否属于软件缺陷;第5条说明了软件测试的根据应该是软件设计说明文档和最终用户的要求。

    掌握软件Bug的这些特征,可以帮助人们采取各种软件测试手段,以便尽早、尽快地发现和报告软件质量问题,降低由于软件Bug造成的各种直接和间接损失。

    可怜的“替罪羊”

    显然,软件Bug都是人为造成的,但是在软件项目开发过程中,面对软件Bug带来的错误,一些软件开发人员却经常为自己的过失开脱责任,美其名曰“都是Bug搞的鬼,都是Bug惹的祸”。软件Bug沦为可怜的“替罪羊”,真是比窦娥还冤!
    “追求完美,根除Bug”是绝大多数软件开发人员追求的目标,但是尽管如此,软件Bug却还是屡见不鲜,原因何在?有些学者给出了软件Bug产生的一些原因:

    1. 开发人员不太了解软件需求,不清楚应该“做什么”和“不做什么”,常常做不合需求的事情,因此产生了Bug。
    2. 软件系统越来越复杂,开发人员不太可能精通所有的技术,如果不能正确地使用技术,将产生Bug。
    3. 软件设计文档不清楚,文档本身存在Bug,导致使用者产生更多的Bug。
    4. 软件需求、设计说明书、程序经常发生变更,每次变更都可能产生新的Bug。
    5. “人无完人”,任何人在编程时都可能犯错误,导致程序中的Bug。
    6. 软件项目由于时间或资源紧张,开发人员经常处于进度的压力之下,急忙之下容易产生Bug,尤其是在软件发布最后期限来临之际。
    7. 开发人员过于自信,喜欢说“没问题”,不真实的“没问题”将产生真正的问题,导致很多软件Bug。

    当然产生软件Bug的原因可能还有很多,例如,沟通上的问题,开发人员的态度问题,以及项目管理问题等。但是从根本上说,软件存在Bug有其必然性,这主要是由软件产品的生产方式和生产过程决定的。软件产品属于无形产品,不能一目了然的看清其“庐山真面目”,虽然靠人为努力可以在一定程度上发现和减少软件Bug,但却不能彻底消除软件中的全部Bug。

    爱恨交加Debug

    软件开发人员寻找软件Bug的产生原因,修正Bug的过程,称为“Debug”,即调试。前文描述了软件Bug的5类表现特征,对于具体的各个软件Bug而言,表现却是千变万化,由此给软件调试和修正错误带来了很大困难。

    通常情况下,软件调试和修正错误的难点不在于如何修正,而在于寻找和定位软件产生的位置困难。对于软件的界面布局错误或界面上的文字表达错误引起的软件Bug,开发人员可以很快地找出原因,在软件代码中迅速定位,然后容易地消除。实际上,任何软件开发人员都可以修正这类软件Bug,犹如快刀切瓜,探囊取物。

    但是要修正软件功能错误,就不总是那么容易了。实际上调试和修正软件功能错误,才是考验软件开发人员水平的真正标杆。某些软件功能错误,由于非常具有蒙蔽性,表面上看上去可能是常见的一些原因造成的,而实际上却往往是其他原因带来的。而且,这些软件Bug经常潜伏于软件代码的许多比较“阴暗”的角落,很难定位产生软件错误的代码准确位置。因此,修正某些软件Bug常常成为软件开发人员的“噩梦”,他们往往为了修正一个较难的软件Bug,需要绞尽脑汁,反复阅读和分析软件代码,设置程序断点,单步跟踪程序的运行结果,截获和分析程序的中间运行数据,试图找到修正错误的“蛛丝马迹”,为此甚至夜不能寐,百思不得其解,这是程序员的“地狱”。当然正确修正高难Bug后的成就感非常强烈,这是程序员的“天堂”,对于程序员而言,天堂和地狱的只有一个Bug那么远。

    需要注意的是软件的全部Bug并不是都需要修正的。在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制而无法有效、完整地修复所有的软件Bug。因此评估软件Bug的重要度、影响范围和市场因素,选择一个折中的方案,考虑软件Bug成为我们在面对软件Bug时一个必须直面的事实。另外,由于错误的关联性,某些软件Bug虽然能够得以修复,但在修复的过程中难免会引入新的软件Bug。很多软件Bug之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生,有时导致顾此失彼,得不偿失。

    由于市场和用户对软件质量的不断提高,软件行业的竞争逐渐加剧,而且寻找软件错误非常耗费时间和人力资源,所以现在越来越多的软件公司开始将软件测试外包出去,由第三方专业的测试公司进行测试,客观地寻找和报告软件Bug。由此促生了软件外包测试的兴起和迅速发展,产生了具有较大发展潜力的测试市场。

    软件外包是新兴的软件开发模式,我国是继印度之后具有较大竞争优势的软件外包服务提供国之一。在软件外包中,软件测试的门槛相对较低,是最可以先期进入的领域。这两年来,软件外包从软件测试外包做起,已经成为越来越多的软件业人士的共识。实际上,我国软件外包测试已经开始起步,且具有较广阔的市场发展潜力。

    国内已经出现了一些专门提供软件测试服务的公司。仅以软件本地化行业的公司而言,例如北京的一些由软件本地化公司转变而成的软件外包公司,他们正在为大型国际软件公司提供十多种语言的软件外包测试服务,采用到这些大型国际软件公司在中国的研发中心进行现场测试和软件外包公司内部成立测试部门测试相结合的服务方式。据了解,有些软件外包测试公司的测试人员数量已经达到数百人,而且未来两三年内仍将继续快速发展。

    小Bug蕴含大市场,随着软件外包在全球范围的不断深入,我国软件服务行业迎来了发展机遇,扩大软件外包市场先从软件外包测试做起,将成为推动我国软件行业发展的积极策略。


     
  • I am very happy!!

    2007-08-05 19:09:51

    想有自己的博客已经很久了,今天终于有了自已的博客了。以后要好好管理自己的博客。在博客里记下自己生活和工作的点点滴滴。
Open Toolbar