黑盒测试比白盒测试更难，技术要求更高

seifer1754

原帖由 cleverman 于 2008-11-20 11:03 发表


一个变量占几个字节我们也有这种需求。你们的需求跟代码是非常同步的吗？你的产品的特点当然会要求比一般软件要高多了，只是想了解一下你们的需求一旦确定真的就不会变了吗？

需求肯定会变化的,能够控制的只是使需求的变化对代码的影响降到最低. 这就需要系统架构设计的非常完善,尽量使模块间的控制耦合降到最低.
而且,越底层的东西越不应该频繁变动,否则会使开发工作都产生极大的影响,这也是系统架构必须考虑的问题.(所以架构师一般是公司里面的超级大牛人物.)
这也需要测试人员设计的用例要尽量低耦合性,当代码变化时,设计的用例能够尽量复用.这也能体现出一个测试人员的水平.

我们肯定会挖掘客户的潜在需求,甚至在代码中会为以后的软件变更留下一些接口.但这些也是要有需求来对应的(或许这些需求是不提供给客户的),否则测试工作根本无法进行,因为你不知道代码在做什么,你当然无法去验证它.

代码一般都是 高内聚,低耦合. 这使得代码测试对需求的依赖非常高,白盒测试,一定要有明确的需求.

chech28

原帖由 cleverman 于 2008-11-20 10:42 发表
就我的经验来说，需求文档，设计文档及最后的代码是很不同步的。如果测试人员只是从需求文档，设计文档去设计测试用例或进行测试会产生不少误解。最好的办法就是去读代码进行有效的信息补充。当然，这不代表设计用例 ...

这么说吧，cleverman，你的工作其实已经包含了两个层次，即dev的测试和QA的测试。我有不少朋友在你们公司工作，所以我知道你们做的是比较特别的，事实上你们是把很多dev的测试工作剥离出来了。对普遍的QA来说，他们的职责就是保证所产品实现了需求，其他的不关心。当然QA有时候也参与代码级的debug,但如你所说，这基本上是一种补充，而不是主要职责。
另外关于代码变的问题，如果要变，不能离开你的需求，就是说一个接口内部随你怎么变，只要输入输出符合要求就可以了。如果dev改变了需求，那么 QA的测试就会发现这个改变，然后提交，如果这个改变获得批准，那么就要更新设计文档。文档的意义便在于此，它是非常碍手碍脚的，但是就是要逼迫人们走这个流程，对整个工程意义是极大的。

chech28

原帖由 cleverman 于 2008-11-20 10:57 发表


这主要是功能测试吧？很多测试跟用户的需求关系并不大。当然，满足用户的需求永远都是首位的。一个软件的设计也并不完全都是用户需求来驱动的，很多用户并不是真正了解自己的需求，所以我们的宗旨是帮助用户发挥 ...

自己定义的需求也是一样要文档化的，所以还是一样。

cleverman

原帖由 chech28 于 2008-11-20 11:29 发表

这么说吧，cleverman，你的工作其实已经包含了两个层次，即dev的测试和QA的测试。我有不少朋友在你们公司工作，所以我知道你们做的是比较特别的，事实上你们是把很多dev的测试工作剥离出来了。对普遍的QA来说，他们 ...

我们基本没人去很push文档的更新。就算你file一个bug，priority也不高，不定什么时候才会改呢。而且，代码变化总是会比文档变化更快，更频繁。测试人员等着文档更新，还不如直接去看代码呢。

cleverman

原帖由 chech28 于 2008-11-20 11:33 发表

自己定义的需求也是一样要文档化的，所以还是一样。

这个没错，我的意思就是说需求不一定都是客户的需求。我并不认为测试完全是按照需求来的，当然测试一定要首先满足需求。但是，很多测试，比如安全测试很多时候根本没什么需求可言。黑客哪个会按常理来出牌呢？

cleverman

原帖由 seifer1754 于 2008-11-20 11:19 发表


需求肯定会变化的,能够控制的只是使需求的变化对代码的影响降到最低. 这就需要系统架构设计的非常完善,尽量使模块间的控制耦合降到最低.
而且,越底层的东西越不应该频繁变动,否则会使开发工作都产生极大的影响, ...

你们的测试就不会chanllenge需求？需求阶段的想法和最后的实现往往会有些脱节，测试人员如果发现有问题也是可以去要求改变需求的。比如你发现了需求没有考虑到的问题，如果这个问题严重，需求就是要改变。
我个人认为满足需求只是个基本测试，更多的测试是应该发现需求以外的问题。

chech28

原帖由 cleverman 于 2008-11-20 11:41 发表


我们基本没人去很push文档的更新。就算你file一个bug，priority也不高，不定什么时候才会改呢。而且，代码变化总是会比文档变化更快，更频繁。测试人员等着文档更新，还不如直接去看代码呢。

问题是在一般的QA体系中，即使你看了代码，提出了意见也没用，开发还是根据特定的优先级做的。

cleverman

原帖由 chech28 于 2008-11-20 12:55 发表


问题是在一般的QA体系中，即使你看了代码，提出了意见也没用，开发还是根据特定的优先级做的。

这就要看你是不是够strong了。跟开发去争论问题的确很hard。你要具备至少跟开发同样的水平才可能。所以，测试也是分级的，我们这里senior就一个，开发还没有senior呢，这个senior测试说什么，他们就得听。
当然还是会discuss了，但是他经验丰富，一般开发都争不过他。

猫猫的拖鞋

哪方面学会了都不难，都是测试领域的，没啥好对比的。

新手笑哈哈

现在只是新手还没有实践，不过看了帖子也有所收获。

chech28

原帖由 cleverman 于 2008-11-21 02:36 发表


这就要看你是不是够strong了。跟开发去争论问题的确很hard。你要具备至少跟开发同样的水平才可能。所以，测试也是分级的，我们这里senior就一个，开发还没有senior呢，这个senior测试说什么，他们就得听。
当然 ...

你提到了一个很有意思的问题，不过有一点我不同意，所谓的senior和principle和水平并不完全成正比，我们这里就有很多天才的junior，当然水平低的也有，但基本上都有自己的特长领域，因为我们的产品非常庞杂，没有一个人可以是所有的专家的。虽然开发对senior的意见可能会更重视些，但是一般QA可以escalate.你说服开发有时候也没有用，他们有自己的优先级，不是说服不说服的问题。我自己就不乏一层层，最后一直esclate到vp，然后解决的。
这个和企业文化也有关系，我问过我一个朋友在你们公司墨尔本工作的，发现他们非常依赖于人，而不是是流程，当然你们公司有这个资本，因为基本所有人都可以依赖的，这和我曾经在的第一个实验室非常像。所以我到了现在的部门后一开始非常不习惯，但是后来理解了，因为那种过多依赖人的方法是不可能广泛推广的。

cleverman

原帖由 chech28 于 2008-11-21 10:13 发表

你提到了一个很有意思的问题，不过有一点我不同意，所谓的senior和principle和水平并不完全成正比，我们这里就有很多天才的junior，当然水平低的也有，但基本上都有自己的特长领域，因为我们的产品非常庞杂，没有 ...

这个倒是。

cleverman

原帖由 猫猫的拖鞋 于 2008-11-21 09:20 发表
哪方面学会了都不难，都是测试领域的，没啥好对比的。

测试技术并不都是靠学习的，到了一定程度，自己的创新更重要。更何况测试的技术还是很不成熟的。

afeng

天马行空的问题没什么意义,实际实行根本没什么可行性,安心做好本职工作,想要牛必须付出代价,作人有时候也要学会适当的放弃,听听不同的声音,这对妮会很有好处

mingg

不错,顶了!~

heporen

study...

zz45509

libingyu135

敢问一下  文章在哪啊？

fengerapple

Thank you very much for sharing!The good man!The good life of peace!