鄙视国内现状，走测试分析之路

addvalue · 发表于 2005-1-25 20:21:32

手机软件测试单纯从MMI角度考虑，主要停留在系统测试中黑盒功能测试；若想进一步，则需要去学会分析定位问题。
举个例子来说明较为直接。“测试过程发现手机idle下掉网问题？”
测试验证过程：（便于问题分析与定位）
1.开机检查名片簿、sms是否可以正常读取?
2.通过手机工程模式或指令方式查看RxLev是否周期更新?
3.通过指令或工具方式手动使之Reset，检查是否可重新注册上网络？
测试理由：
1.为了确保SIM卡没有掉落或松滑。如果SIM卡掉落，肯定没有网络，而且读取电话簿和SMS错误；
2.检查RXlevel，确保手机周期性的对网络信号进行测量，并且向网络发送测量报告。如果没有变化，可能RF模块和控制RF模块的程序有逻辑错误导致死机；
3.手动reset，如果能正确重新注册原来网络，那么肯定是软件的原因。非硬件RF的原因。也就是说明原来的情况是由于程序溢出，导致底层不去检测RXlevel,不发RACH
最后通过logfile解码，结合代码实现进行问题定位：
......

skinapi · 发表于 2005-1-27 00:14:08

顶！！！

嘘garfield · 发表于 2005-1-27 14:49:02

renke · 发表于 2005-1-31 08:52:34

Ding

tigerzhang · 发表于 2005-1-31 09:03:19

addvalue · 发表于 2005-2-1 08:05:59

常规项目如PBS、sms、wap这些我们可以通过工具来配合，其余只好monkey test喽

liguihua1 · 发表于 2005-2-1 15:08:27

可以讲讲么？

addvalue · 发表于 2005-2-3 22:54:28

ms&BS simulator,pc端wap模拟器等

addvalue · 发表于 2005-3-17 23:14:04

比如，在哪些模块或功能业务实现上用户要求确保能在规定时间内完成任务？
终端本身支持容量和数据业务负载的能力？
优先级别高的关键任务期望的响应时间是多少？
系统功能不断扩展能否满足用户需要？（大容量电话簿、多媒体应用软件等）

hqy0921 · 发表于 2005-3-18 15:06:55

这个分析定位从测试员的角度简单来说，就是把bug复现的步骤以最简单最必然的方式来提交，测试员以某种盲目而又复杂的步骤发现了一个bug现象或偶然发现某个bug后，不用立即提交这个bug，最好不断的简化操作步骤来发掘bug再现的最简步骤。
当将这种经过简化的步骤提交给程序员时，程序员定位修改bug就相对容易多了，不过这种简化复杂步骤的事情我觉得是越少越好，我们应当把各种可能性都尽可能的考虑进测试用例中。
但是我有一个疑问阿
对于很有编程经验的测试员而言，他们究竟是否需要很详细的定位bug呢（不从测试员自身学习角度出发，纯粹从测试活动而言），譬如深究到代码中何处调用错误什么的
程序员担当着“解决bug”的职责，这个详细定位bug的问题是由程序员来做还是测试员来做呢？

luojingen100 · 发表于 2005-4-15 14:17:19

楼上所说的的确很普遍的。

发现一个问题再定为到问题的所在，那测试员的工作压力太大了，毕竟定位bug的工作特别消耗工作时间。可是简单的把问题提交到程序员那里，程序员又不知道你是如何出现该问题的。往往是需要你去再次操作使问题复现这样对整个进度又有影响。

大多数测试员对这个问题解决的方法是经全力找出问题重现的步骤，如果问题不能重现，那么也要写出该问题在10次或者20次测试中出现的概率。这样程序员定位该问题容易一些，测试人员也可以抛弃掉该问题的负担而进行下一个用例的测试。
这个是我的一点点感觉呵呵，说的不对，大家多多提出意见
另外，我对于问题的定位，我不怎么准确，不知道那位高人能够提拔提拔

hybird_h · 发表于 2005-4-15 16:45:34

测试员最重要的素质是记忆力，进行任何操作之后都要能追溯到前5步操作甚至更前面。测试看起来是一个很随意的事情，其实做起来完全不是那样。

tianyuswtest · 发表于 2005-5-20 21:17:21

hqy0921、luojingen100：您好！
关于缺陷定位问题，（个人认为）从理论上将采用“重复测试”和“相近测试”，执行一定次数后一般能准确定位，这对于缺陷的快速解决肯定非常有利。但各公司测试资源是有限的，不可能执行“海量测试”，这种情况下建议分情况看待。
首先要看缺陷严重程度，非常严重的缺陷是值得多测试以求尽量定位；
其次要看缺陷的发生概率，发生概率高（估计30%以上）的，测试几次基本能精确定位，发生概率较小的（发生两次以上30%以下），建议测试10次到20次，不要超过50次，极少发生或测试中只发生了一次的，则可以采用统计学方法，主要统计历史测试中类似情况发生了多少次，然后再决定是否做专项测试。

另外，测试一定次数以后还是应该尽早把缺陷报告给开发人员，说不定开发人员一看就知道问题的所在了，这样避免了测试资源的浪费。

cshephy · 发表于 2005-9-14 14:38:23

两位老大同台演出，难得！有机会的话一定跟你们好好学习学习！

zmf111 · 发表于 2005-12-20 09:26:52

楼主说的基本无甚意义，这点做不到还做什么测试？？测试本身就内嵌分析能力

gubinger · 发表于 2006-1-5 16:12:14

你们怎么说的那么玄哦,好象定位一个问题就跟找可老婆一样,有那么麻烦吗?
我觉得问题定位的关键还是在TEST CASE,好的test case是在深入分析的基础上,充分考虑各种因素指定的,在执行某一test case失败后,查阅或者是回忆制定时的分析和考虑自然就能得出问题的定位,重显也很容易.
2位的看法是先发现问题,再去分析,我个人认为是不恰当的,这样可能会发现很多没主的bug.

晓仔 · 发表于 2006-1-8 14:18:04

有很多问题研究透彻以后，就感到做开发的是多么的无能了！

lorence810715 · 发表于 2006-1-17 13:43:22

关于手机测试谈谈我个人的一些想法
作为一名测试人员,首先要站在用户的角度去考虑,切忌单纯依据于测试式样书;我觉得这点是最为重要的!
的确优秀的测试人员需要具备对于BUG的分析能力,这点对于定位BUG,以及程序员解决BUG 起着不可忽视的作用;
但是我想说一些关于测试报告的一些想法.合格的测试人员必须能够准确的提交测试报告.书写一份好的测试报告,看起来很简单,但是却总会被大家忽视,其实它对于BUG的解决也起着至关重要的作用.
不好的测试报告,不能让程序员清楚问题的所在,久而久之,对于提交的BUG质量产生怀疑,对于测试人员也会失去信任,而BUG也会不能得到解决,进而影响到测试人员的干劲,从此陷入恶性循环!
我们在书写报告时,描述现象要清晰、要提供必要的测试数据、不要带有个人色彩的进行判断;尤其不要带有攻击性的词语;能够让程序员再现BUG,;报告无遗漏、无前后矛盾等等,当然如果测试人员能够对BUG进行正确的解析更好(这个解析同样需要体现在测试报告中)
这样程序员才会重视我们的测试结果及时解决BUG,我们也会觉得自己的付出有所回报!
我们的产品也会按时或者提前走向市场!!!

r7tobby · 发表于 2006-8-5 14:16:23

顶！

xiaoliuzis · 发表于 2006-8-7 04:40:07

恩，描述清楚很重要。。。

		自动登录	找回密码
密码			(注-册)加入51Testing

鄙视国内现状，走测试分析之路

相关帖子

顶

Ding

斑竹！你们一般怎么来做手机压力测试的呀？

分级别做

什么工具呢？

需要配合solution进行开发定制

性能测试和压力测试考虑情形将越来越多

关于分析定位角色的一个小疑问

评分

关于缺陷定位的一个看法

手机测试

站长推荐 /1