This topic has been archived. It cannot be replied.
-
工作学习 / 事业工作 / 说一说了解DEV的Detail design对QA测试的帮助。
-tracyd(等待明天);
2021-10-29
{2600}
(#14074766@0)
+1
-
哈,看到最后,这为啥要质疑,这都是工作量呀,就像dev说我今天写了2万行代码,嘿嘿……
-guestagain(guest again);
2021-10-29
(#14074886@0)
-
对2万行,全是打印hello world。的确,那也叫代码。全是工作量啊。不应该质疑。;-)
-tracyd(等待明天);
2021-10-29
(#14075837@0)
-
QA 挺难的, 我一直不知道计算器是怎么测试的, 是不是在范围内都要比较一下结果。
光是 Check the addition of two integer numbers.我就不知道要写几个test cases.
-sxffff(lookingforjob);
2021-10-29
(#14074900@0)
+1
-
有很多combination。一般测试普通的计算器根本没有requirement,但是一定需要一个参照物来比较结果。例如有一些计算器1+2=3都是一样,但是有一些计算器1+2==就不一样。
测试计算器,是我大学毕业一样在国内第一份测试工作。那时候还不懂regression,程序员改完了code以后也不知道再重新测试一次。和一个老资格的DEV一起工作,教了我一些。说老资格也就是比我才大1-2岁,毕业早了点,在那家公司工作略久一些吧了。
那时候给台湾公司工作,他们给toshiba做硬件和软件产品,所以我们手头上都会有一个toshiba的计算器,作为测试标准。
有的时候你需要think out of box。例如需要不只是按1+2= 来得出结果,有时候需要再多按几个键,例如1++2=,1+2=。, 1+-2=,看看会不会死机,乱码,计算错误。
-tracyd(等待明天);
2021-10-29
{506}
(#14075827@0)
-
你当然可以这样做,但我不知道是不是对的,或者更有效的测法。这里当然不是去测硬件的bugs。
-sxffff(lookingforjob);
2021-10-29
(#14075840@0)
-
硬件的bug有时候也的测,不过我们那个时候基本上都是测软件的。程序是烧在一个地板上的,烧完了再测,有bug,改完了再烧,再测。我测过一次是关于太阳能电池的bug。经理给我一个计算器,让我找找问题,说有客户抱怨,计算器有时会down机,找不到任何原因。我就找了一段时间也没找到,就把计算器放抽屉里,时不时拿出来测一测。结果有一次真给我遇上了死机。然后回想所发生的一起,进行了n次的尝试,终于发现是当太阳能能量释放完毕以后会,不会自动切换到普通电池照成的。我把测试路径给台湾经理当场走了一遍。他连声说好。一个难找的bug终于找到了。
-tracyd(等待明天);
2021-10-29
{391}
(#14075858@0)
-
我的意思是,假如你测加法,测了1+1 =2, 5+5=10,都对,你还要测什么呢? 100+100? 1000+1000,这个好像无穷无尽,是不是要穷举呢?
-sxffff(lookingforjob);
2021-10-29
(#14075883@0)
-
所以前面说了,得测每一个路径么,例如,加法测10组,10以内的,100以内的,到几百上千,挑典型的出来测。还得测一测99999999+999999把屏幕全占满完了,看看有没有错,boundary测试。还有不同的键随意组合在一起测。
-tracyd(等待明天);
2021-10-29
(#14075995@0)
-
就是觉得测的不够。
-sxffff(lookingforjob);
2021-10-30
(#14076594@0)
-
这个就明显是需求文档没写清楚引起的bug。因为这个“太阳能电源不足切换普通电源”是基本要求,但没写下来,结果没人测试导致的。不关QA的事。或者算设计缺陷。有经验QA最多能做到的是写边缘测试情景来帮助找设计缺陷
-jedi_xie(Jedi);
2021-10-29
(#14075943@0)
-
我说过,没需求文档,给东芝提供的,一切按照东芝计算器来作为参照物评判对错。就有很多人把质量问题像你一样踢皮球踢来踢去,怪到别人身上。
-tracyd(等待明天);
2021-10-29
(#14075973@0)
-
问题来了,以东芝计算器作为参照物评判对错,作为参照物的计算器有太阳能板么?如果没有,那这个参照物就根本没用。因为无人知道没光时应该如何反应。你说的例子很明显就是你随机偶然发现的。即使你找Dev Lead,他也未必会知道必须有这个功能,也不可能告诉你要测试这个边缘情景。
-jedi_xie(Jedi);
2021-10-29
{250}
(#14076034@0)
-
就是因为你说的原因,所以没人测。到了客户那里发生问题报告回来以后让我测的。
-tracyd(等待明天);
2021-10-29
(#14076125@0)
-
要是计算器程序都不可靠,那未来的世界一定是doomed
-lzh0007(lzh0007);
2021-10-29
(#14076002@0)
-
楼主很聪明👍
-kw23(kw23);
2021-10-29
(#14075319@0)
-
看到前面xml给我写的几句关于code coverage的文字,突然想起还有这么一些事。就写给大家看看。时不时看到一个IT小白想一点没电脑和编程基础就要做QA赚大钱,又看到有人说做QA容易。所以写一些,给大家了解了解QA各种工作中发生的一些事情。
-tracyd(等待明天);
2021-10-29
(#14075836@0)
-
这只能是梦想。QA只需要把关business requirement就行了,如果需求文档(时髦叫法:user story,old school叫法: BRD)写得不好,不详细,出错了就不是QA的问题。白盒测试很难做,cost很高,不是高精端会死人的软件,一般不会花钱做。
-jedi_xie(Jedi);
2021-10-29
(#14075546@0)
+2
-
很多印度QA就你这种测法,上了production再被rollback。因为他们根本不懂,也不想懂。只是测requirement几乎和UAT没什么区别,只是工作量大一些而已。
-tracyd(等待明天);
2021-10-29
(#14075831@0)
-
不是印度QA的问题,而是无论任何人做QA都会这样,你想想一个3个月的项目必须有10个功能,开发设计测试在3个月内完成,你能做白盒测试?不可能的任务。这种情况在一般公司里很常见。TDD是很好的一个开发模式,为啥热乎了一两年就没了?因为要求资源太多,公司不会投入,编程人肯定不会干的。
-jedi_xie(Jedi);
2021-10-29
{251}
(#14075929@0)
-
你连白盒黑盒都没搞清楚。白盒需要在写程序里测的。这种顶多是一个灰盒,连code都看不到,只是测逻辑和每个路径而已。
-tracyd(等待明天);
2021-10-29
(#14075980@0)
-
随便你起啥名字都行,我的意思就是如果你要测development detail,花费巨大,不是一般公司会做的。简单举个例子,同样一条路径,两个CALL到不同backend取数据,单线程写法和多线程写法就会有很大的测试区别,如果QA做,花费很大,一般就之后只会控制输出结果,我管你如何写,1+1必须=2
你说的程序逻辑和路径就是需求文档里面写的。比如需求文档写了1+1=2, 1++1=3,那test case就必须覆盖这些,再加上一些边缘test case,这样的QA已经很好了。
-jedi_xie(Jedi);
2021-10-29
{392}
(#14076047@0)
-
一般都是给一个flow chart然后测。不用场景和路径都测一遍基本上都差不多了。不可能所有细节都测的。前面说的依据需求写出来的if else几个组合是很常见的flow.
-tracyd(等待明天);
2021-10-29
(#14076130@0)
-
这个是对的。实际上测试所有的case是不可能的,一般就是取正case,负case,邻界case, 然后根据code coverage指标来判定。白盒说的那么好听,实际上QA不可能懂代码,同一个功能也可能有几套代码
-gta_palace(呄 - 每天乃古);
2021-10-29
(#14075963@0)
-
你说的又让我想起那位home Depot经理的另外一个面试问题。就是如果数据库中有几千万几百万条记录,你需要做ETL,把数据清洗转换,从一个地方移到另外一个完全不一样类型的数据库中。你该怎么测,才能保证数据的迁移是正确的。
-tracyd(等待明天);
2021-10-29
{150}
(#14076017@0)
-
这个一般要写reconciliation report, 各个table的count,关键column的subtotal,跟QA关系不大
-sxffff(lookingforjob);
2021-10-30
(#14076585@0)
-
ETL数据需要全部清洗一遍再输出。重复数据需要删除,空的也得删。这count经常不管用。谁告诉你和QA关系不大。如果系统需要迁移,除了测front-end, 还需要一个懂ETL测试的QA。
-tracyd(等待明天);
2021-10-30
(#14078040@0)