51Testing软件测试论坛

标题: 手工测试（黑盒测试）的高手是什么级别 [打印本页]

作者: rise1218 时间: 2010-10-13 17:55
标题: 手工测试（黑盒测试）的高手是什么级别
请问各位，手工测试（黑盒测试）能测到是哪个模块的错误吗，能测到具体的接口吗

作者: rise1218 时间: 2010-10-13 17:55
期待大家来讨论

作者: msnshow 时间: 2010-10-13 21:44
肯定能

作者: Jackc 时间: 2010-10-14 12:46
本帖最后由 Jackc 于 2010-10-14 12:49 编辑

LZ的问题，其实可以通过提升测试人员初步定位故障的能力来回答。
它主要依靠两方面：

1.针对发现的故障反复测试，精炼测试步骤。
比如：
手机测试中，测试人员发现在新建SIM卡联系人，使用最大字符长度的姓名、电话号码、邮箱地址进行存储时，出现crash.
如果就这样填写故障报告，显然是有所欠缺的，开发拿到故障后，还需要分析到底是姓名编辑框的问题，还是电话号码编辑框问题。
而这部分工作测试人员是完全可以代替的，只需要针对这个故障增加一些周边测试即可：
姓名最大字符长度测试；
号码最大字符长度测试；
邮箱最大字符长度测试；

这样可以进一步精确定位故障。而我们这样做就达到测试员的极限了么？
————————————
假如发现“号码最大字符长度测试”是导致故障的原因，那么，不是最大字符是否也能导致故障呢？所以又得增加测试点：
最大字符减1
最大字符减2
……
（注意：并不是说测试人员得一个一个递减去测试，初步测试时，测试数据可以间隔一定的区间。可以参考电视上的一个娱乐节目：看商品猜价格。至于区间间隔的取值，自己体会吧）

这样我们又会发现，当字符长度超过某个值，比如是20的时候就会导致故障。
——————————————————
当然，还可以继续。思考为什么是20就出故障？为什么只有存SIM卡联系才会导致故障？是否与SIM卡有关呢？
查找相关资料，发现测试SIM卡的号码编辑框限制就是20字符长度。
然后就可以换一张号码字符长度不是20的SIM卡，比如是30。然后分别测试30和31两个测试数据。
发现只有31测试数据会复现故障。

ok，最终该故障初步定位为：存储SIM卡联系，超过SIM卡电话号码限制
我们再返回来比较没做扩展测试前的初步定：存储SIM卡联系，最大字符长度的姓名、电话号码、邮箱地址

两者有明显区别。

2.善于运用你手中的工具。
1中提到的方法，只能针对逻辑比较简单的故障。
而对于逻辑复杂，关联模块较多或环境因素无法确定的故障，只能使用工具。

比如，我们在连接SIP服务器时，发现终端发送请求后，有时会成功注册，有时就直接crash了。

针对这样的故障，测试人员则需要工具辅助了。比如让开发人员build debug版本，抓取crash log；使用抓包工具，抓取SIP数据包，查看crash时，服务器返回的消息；挂载内存监控工具，查看进程运行情况等等。

综上：通过提升上述两点技能，黑盒手工自然也能测试并定位到指定的APP、API，甚至是code.

测试是实实在在的入门容易，提升难的职业。

作者: rise1218 时间: 2010-10-18 12:06
谢谢Jackc的回复，的确是有这种感觉，觉得很难提升，感觉一直徘徊在测试门外，只知道单纯的点点按钮来做测试，即便是自觉的QTP，也不知道如何运用，感觉很难提升。

作者: 清风无痕 时间: 2011-1-7 15:15
学习了

作者: zorovip 时间: 2011-1-8 12:22
对2楼学习了，对最后那句话也比较有体验，，，，而且，80%20%的说法真的很体验到了。

作者: 楠族开心果 时间: 2011-1-10 16:09
回复 4# Jackc

学习了，这个我也不懂呵呵谢谢JACKC的回答。。。
就如同JACKC所说的，入门简单，精通很难……

作者: Raynard 时间: 2011-1-12 17:21
回复 4# Jackc

受教了～

作者: cebio 时间: 2011-1-13 15:52
本帖最后由 cebio 于 2011-1-13 15:54 编辑

回复 4# Jackc

我觉得针对这个用例：所有字段都输入最大字符长度存储时就crash，如果能100%重现问题，就不需要在定位到具体是那个字段啦。试想，如果有20个字段呢，你需要逐个去试到底是那个字段超过长度，至少需要尝试20次吧，如果字段更多呢（比如人事基本信息啥模块），你的用例数会增加很多，但是如果采用调试，你只需要每个字符都输入最大值，很快就能在赋值时跟到是哪个字段超出导致抛出异常，从纯时间花费上来说，调试也许更经济，而且更有针对性。有时我觉得这种情况跟踪一下比逐个尝试来得更快。再举个例子，比如创建时间这个当我提交后总是不等于当前时间，而是一个其他什么时间，但是我不知道到底这个其他时间是怎么来的，这时候，其实我已经可以提交这个bug了，我可以100%重新问题了。实际在跟踪后你发现，这个创建时间是字段赋值错误，而这个其他时间根本不在当前页，你就算一一尝试也想不到是和当前页无关。
换句话说，这实际是个测试粒度的问题，如果我已经能100%重新，我还有必要定位到更细的粒度吗？再定位下去，我实际就进入调试领域啦。
再换个思维想想，其实这种字符长度问题，应该在单元测试阶段就检查出来，当到达更高的级别（集成测试、功能测试）我们其实应该更关注流程上的问题，业务流是否正确。而这种字符长度边界问题我觉得应该放在白盒更容易覆盖到而不会遗漏。

作者: Jackc 时间: 2011-1-14 17:01
回复 10# cebio

恩，说的有理。

但是这涉及到另一个问题：测试&开发的资源分布。
工作就摆在哪里，谁能做？谁有时间做？谁做成本低？

————————————————————————————

如果将测试理解为服务部门，我认为测试则应完成力所能及的工作。

其实缺陷的二次定位，其目的与“详细清晰描述缺陷”并无太多出入，也是一种减少开发资源浪费的手段罢了。

作者: zjshy2012 时间: 2011-1-26 17:11
二楼的说的很好，学习了，一直就这种感觉，但是表述不出来，学习了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)