软件测试BUG分析.docx
《软件测试BUG分析.docx》由会员分享，可在线阅读，更多相关《软件测试BUG分析.docx（11页珍藏版）》请在冰点文库上搜索。
软件测试BUG分析
工作经验分享---BUG分析
V1.1
发布时间:
2014-03-18
文档修改记录
版本号
更新时间
更新人
主要内容或重大修改
V0.1
2014-02-12
戴旭峰
初稿
V0.2
2014-02-12
戴旭峰
修改文档格式以及部分文字错误
V1.0
2014-02-13
戴旭峰
定稿
V1.1
2014-03-18
戴旭峰
增加BUG分析案例
目录
1、我们为什么要对BUG进行分析？
4
2、我们怎么才能保证我们提交BUG的有效性?
4
2.1遇到以下情况时的一些建议（适用于以中间件开发的客户端）5
2.1.1当我们遇到以下情况时5
2.1.2系统提示进程未响应5
2.1.3客户端闪退、随机退出现象7
2.1.4Java异常导致的应用退出7
3.测试过程中遇到的一些问题分析和个人理解8
3.1安装包解析错误8
3.2不同系统平台下功能可能存在着差异或者删减9
3.3考虑同一个问题在类似场景下的表现9
3.4成功升级后，却发现应用还是老版本?
9
3.5利用中间件技术开发的应用被360、金山毒霸检测出病毒、木马等威胁？
10
1、我们为什么要对BUG进行分析？
测试的目的就是为了发现BUG，而至于BUG的原因，很多时候我们并不关心。
我们会认为这是开发人员的事情，其实这种想法是错误的。
因为通过分析BUG，可以有效提高我们对于软件的理解，进而能发现更深层次、严重等级更高的BUG。
通过对程序理解程度的提高，就能避免出现反复提交重复原因的BUG。
因为这样的BUG提交到开发同事那里，很快就会被关闭，它们毫无价值，反而会降低我们的有效BUG率。
2、我们怎么才能保证我们提交BUG的有效性?
我们在提交BUG时，一定要能够确定是程序本身出了问题，否则不要轻易提交BUG，但是我们又要如何确定这个BUG是程序的问题？
一、首先一定要能重现这个BUG，确定BUG出现的场景，也就是说我们的BUG描述一定要具体和准确。
确定BUG出现的场景是尤为重要的，因为它能够直接推导出BUG产生的原因。
举个例子，大家都一定都曾经遇到过，我们提交一个了BUG，在我们的机器上可以复现，但是到了开发人员那里就复现不了，或者根据你的BUG描述，开发人员无法重现问题。
这种情况在我们日常工作都遇到过，而出现这种情况的可能性有两种:
1）我们并没有明确BUG出现的场景，这就是我们的问题，我们的BUG描述中可能存在歧义或者不详尽的地方。
因此我们的复现路径一定要准确。
2）测试环境的问题，这就需要我们不断的排查从而缩小BUG出现的场景，如：
找找第3台机器试试，排除不是机器本身的问题，浏览器版本的问题，浏览器型号的问题，当前网络条件的问题，系统版本的问题等等。
这种分析工作不仅仅是开发人员的工作，同时也是我们测试人员的工作之一。
二、BUG本身是否与原有需求存在矛盾？
这种情况比第一种情况更容易判断，这属于业务层次的问题。
这同样也为我们带来了另外一个问题，那就是我们对于业务的熟悉程度。
对于测试人员而言，熟悉业务可能是我们最基本同样也是最重要的一项工作。
一个熟悉业务的测试人员，可以凭借自己对于软件熟悉程度来判断软件中哪部分的功能里可能存在严重问题。
2.1遇到以下情况时的一些建议（适用于以中间件开发的客户端）
2.1.1当我们遇到以下情况时
1）跳转页面时，页面始终处于loading状态
2）在播放视频时，视频长时间处于连接中、缓冲等等状态时
3）点击某个按钮无响应
首先我们需要排除客观因素，比如当时的网络条件。
网络是否联通，可以尝试使用手机浏览器访问网络，或者使用手机中其他应用，检测当前情况下，网络是否正常。
当最后确认非网络问题后，我们可以通过查看后台日志，从而判断是程序出错。
首先我们打开eclipse中的DDMS,使用WriteLogs过滤，重新复现一下当时的场景，如果存在无响应，那我们就在日志中搜索”error”,看看日志中是否存在报错信息，如果出现以下类似信息，说明当前代码在运行过程中存在报错，接下来就可以提交BUG，并附上报错相关日志，请开发同事具体定位问题了。
（类似这种报错一般都是业务代码有错或者模板报错）
2.1.2系统提示进程未响应
有些时候，在测试过程中偶尔会碰到客户端”假死”的情况，也就是我们说的程序无响应，ApplicationNoResponse（简称ANR）。
这种情况一般是因为客户端在某一个线程中处理时间超过5秒以后，系统便会弹出提示。
ANR问题
出现以上问题时，首先是将完整的日志抓取出来，此时就不需要过滤客户端的WriteLogs了，开发人员需要的是当时的系统Log来分析问题。
如果是ANR问题，那么就在日志中搜索“ANR”关键词，即可快速定位到关键事件信息。
上述日志是云之南社区测试过程中遇到的一次ANR问题，从日志可以看到以下信息。
ANRincom.wondertek.yninfo（com.wondertek.yninfo/com.wondertek.activity.AppActivity）
Reason:
keyDispatchingTimedOut
除了以上这份Log以外，我们还需要一份更详细的日志来辅助定位问题。
安卓系统在应用出现ANR问题时，会自动保存一份日志至/data/anr，我们就需要该目录下的traces.txt这个文件。
我们可以通过adb命令导出该文件，具体命令如下:
adbpull/data/anrC:
\Users\kay\Desktop（可以将后面的路径替换成你想要的路径）
通过以上的traces文件日志，开发就可以准确定位到具体是哪个代码文件的哪一行代码导致了此次的ANR问题。
2.1.3客户端闪退、随机退出现象
在我们的测试过程中，时不时的就会碰到一些意外情况。
比如在点击某个按钮或者页面跳转时，客户端就自动退出了。
这个时候我们需要做的就是及时的抓取当时的日志信息，这里需要的日志同样是完整的日志（包含系统Log和客户端的WriteLogs）。
对于中间件的项目我们可以通过搜索"#00"关键词来查看是否存在引擎的堆栈日志，类似如下日志输出:
通过日志我们可以看到，客户端最后是死在引擎的libapi.so这个库中，这样我们就可以将问题提交给引擎组的同事处理了。
但这里值得一提的是，上面日志中的这一行
#04pc00045499/data/data/com.cmcc.mobileaudio/lib2/WD/libapi.so（_WriteLogs+372）
由于我们客户端的WriteLogs这个函数存在字符限制，如果超过1024个字符输出，则会崩溃（部分节目的介绍信息可能超过了1024个字符），因此导致了退出问题。
但这个问题只存在于debug版本的安装包中，release版本中不会存在日志输入，所以就不会遇到这个问题，所以如果以后在测试遇到类似的日志输出时，我们可以先通过日志判断一下，再安装release版本复验一下，看是否还会出现以上问题。
2.1.4Java异常导致的应用退出
在我们测试过程中，还会遇到一种退出现象。
客户端闪退后，手机提示“XXX已停止”，此时便是应用在运行过程中遇到了Java异常。
同样的，我们需要做的第一件事还是及早的抓取相关日志（包含系统Log和客户端的WriteLogs）。
通过搜索“Fatal”或者“Exception”关键字来快速定位到关键事件信息。
从上述日志中我们可以看到这次的Java异常的原因是代码中存在一处空指针，这样我们就可以提交BUG并附上这段日志让开发同事进行代码走查来定位问题了。
3.测试过程中遇到的一些问题分析和个人理解
以下是我在测试手机视频过程中遇到过的一些比较具有代表性的问题，希望对其他项目也有警示作用:
3.1安装包解析错误
该问题经常会出现在客户端升级或者在客户端中下载第三方应用后调起系统安装程序时出现，出现的原因目前总结出两点:
1）安装包没有下载完全
这一点我们可以将单独从手机中把下载完成的安装包拿出来，然后手动安装一下（或者比对一下安装包大小），如果也不能安装，那么说明安装包本身可能存在问题。
2）安装包的下载在了手机内存中，即应用的安装路径内
如果程序将升级安装包的下载路径写在手机内存中就有可能发生这种问题。
原因是系统对内存中的文件夹缺少读写权限，由于部分机型对应用目录相关权限进行了管理，解析出错，就是因为权限问题。
修改建议，业务在下载新安装包时，应该将其放置在SD卡目录下面。
若SD卡不存在，还是放到应用目录下面，这种机器是否能安装成功就听天由命了（一般来说没SD卡的机型基本没对应用目录做权限限制）。
出现以上问题时，比较好的解决方案是将安装包的下载路径设置在手机存储卡中（内置或者外置存储卡），这样就可以规避第二种情况。
还遇到过一种情况是，如果手机已下载完成安装包，当你点击再次下载或者升级的时候，程序可能不会重新下载而是直接去调用手机中已下载的安装包。
这样就可能进入一个安装的死循环，永远都是“安装包解析错误”，那这个时候我建议在重新点击下载后，重新去下载安装包并将老的安装包删除以避免出现死循环。
3.2不同系统平台下功能可能存在着差异或者删减
我们测试的客户端可能常常会要求在不同手机平台上同时实现，那我们就需要考虑到，不同平台上功能可能存在的差异。
届于系统平台的差异，部分功能就需要单独修改，不能一概直接复用。
其中已知的功能有IOS的升级功能，消息推送，桌面小插件等。
还有非常重要的一点就是返回逻辑的设计，因为iphone手机没有物理返回键。
这些功能都需要我们在测试过程中着重注意的。
3.3考虑同一个问题在类似场景下的表现
以我测试的手机视频为例，很多功能都分本地代码和在线模板两部分。
其中本地代码在自构建打包过程中打进安装包内，而在线代码则通过OMS发布后，客户端访问相应页面时动态加载的。
就以播放功能为例，当我们发现在线播放页面中存在一个BUG时，与此同时我们应该再考虑一下是否会在本地播放中也存在同样的问题。
（根据我的历史经验来说，一般两个地方都会有问题）
3.4成功升级后，却发现应用还是老版本?
首先请确认对应升级安装包的版本号是否正确，公司客户端的升级是以老客户端覆盖新客户端的形式进行的。
在打包测试前，请先确认预打包的代码是否中版本号相关配置文件是否已正确无误。
版本号相关一般涉及以下代码文件（以手机视频为例）:
1）打开com_wondertek_mobilevideo3\release目录下的config文件，下图标记处显示的版本号对应客户端内使用帮助页面显示的版本号
2）打开Project目录下的AndroidManifest文件，下图标记处的android:
versionCode值:
该参数在第三方检测升级时会用到，现在很多安卓商城经常会提醒用户有哪些应用有版本更新，就是通过对比这个参数检测到的。
因此一定要保证该参数的正确性。
在每次发布版本时，请将其值与需要发布的版本号对应一致。
引擎会根据这个值来判断是否更新业务数据。
（重要）
android:
versionName值:
该参数对应手机应用管理中显示的程序版本号，在每次发布版本时，请将其值与需要发布的版本号对应一致，并保证版本号依次升高，因此一定要保证该参数的正确性。
（非常重要）
3）打开channelids文件，公司自构建对应不同的播放器需要对应修改不同的渠道号文件，channelids对应的是融创播放器版本，channelids_pe对应的是华为播放器版本。
途中前8位数字对应客户端版本号（打包前，请确认该文件中版本号的一致性），中间5位是业务标识，最后15位则是渠道号，图中显示的为主渠道版本，通常用作投放至各大开发市场（如360应用商城等）
（以上文件建议在开发同事发布TAG申请前检查，避免重复制作）
3.5利用中间件技术开发的应用被360、金山毒霸检测出病毒、木马等威胁？
经分析主要是应用中添加了短信监听、拦截功能。
如果相关项目没有此需求可以请开发同事将把此功能相关代码进行注释。
升级会员 