关于测试人员需不需要懂代码-来自国外论坛的讨论
这个回帖主要谈了Advantage:Quote:
Testers will be looking at the application and it's behaviour and i don't think the tester need to through the code & try to understand the system. It doesn't work.
Actually when done properly it does work and those black box testers who have a high-level knowledge of the code behind what they are testing are generally better testers than those who don't understand any of the program internals.
In regards to test planning, understanding the high-level internals of the code + decision paths in the software is the only way a truly effective functional test plan can be created. What this knowledge also provides is the ability to reduce the test effort yet still obtain same coverage.
For instance let's say an app has both a thin and fat client. The thin client has a subset of the fat client's functionality. Not spending any time to investigate the code will result in duplication of testing because in reality all the functionality sits on the server side. Let's say the app has query operation. In a given week one would generally not want to execute the query test cases on both the thin and fat client because it's duplication of testing i.e. the same code on the server is being called. What would be much more efficient is to simply put the clients on a rotation i.e. one week test query functionality on thin client and next week test it on the fat client. And each week an acceptance test is run on both the thin and fat clients for added insurance + the fact there are of course differences in the "route" a query requests takes depending if it's initiated from a thin client vs. a fat client.
I know there are some who would disagree w/ this testing strategy but you have to take chances and risks during a project. I would say this would not be my strategy near key milestones...Beta and during the last few weeks prior to shipping but I'd feel comfortable with such guidelines for rest of the project. Without any knowledge of the code though I'd be totally uncomfortable with this and would simply request the test team to test everything every week.
This is how even a small amount of knowledge about the internals of the application can have a big impact on efficiency and quality.
这个回帖谈了Disadvantage:
I think the answer the original poster was looking for was "black box testing".
In your example, thekid, even someone with no knowledge of internals would be smart enough to test both a thin and thick client.
While I generally feel no knowledge is wasted, there are both advantages and disadvantages to having knowledge of internal code. Some of the diadvantages are exactly the same as for programmers. Just because you know what's there doesn't mean what's there is correct. Someone with this knowledge can focus too much on validating what's there instead of validating what is supposed to be there. I know plenty of programmers that reduce their testing coverage because they "know" what their stuff touches. It's amazing how many errors we find in their code .
I have people on my staff that are code-savvy and people who are not. There is little difference in terms of value to the organization, as they tend to "miss" different types of errors. The key in my organization has just been to deploy people according to the needs of the project and their skill sets.
有句话说的很好：
Just because you know what's there doesn't mean what's there is correct. Someone with this knowledge can focus too much on validating what's there instead of validating what is supposed to be there. 说的都有道理，
第一个的意思是你懂一点代码，至少可以避免一些重复劳动。
我觉得如果你懂一点代码，可以更加有效率的抓住一些bug，曾经我的一个developer跟我说过，对于计算机程序，有些你是可以trust，有些你不能，比如你要测一个函数，程序要先取来某些变量然后计算得出一个结果。最容易出问题的部分其实是他取的这些变量对不对，真正计算的过程倒是不容易出错的。我觉得很有道理。
第二个回帖给我的启发很大。因为我也是开发转测试，我也会习惯性的以开发的思维去测试，就象文中所说，focus too much on validating what's there。
一点感悟，欢迎讨论。 说的不错呵呵 好的
我的一点感觉
说的挺好的，就我自己而言，我感觉做测试还是懂代码比较好，至少能够看动代码，还有就是对代码要有感觉，当然也和经验有关系！ 做测试不需要用代码编程,但是最好能看的懂代码, 看得懂的确是有好处的sdlkfj2 能自己动手写些小工具更好:lol 测试对编程不用很精,但要能看懂.软件测试中有代码走读这一阶段如果看都看不懂就没法做了 :victory: 支持,最低限度要能看懂... 我认为了解代码就行了，不必要懂得很深。 测试最关键的是测试思路 和对程序的理解（包含站在用户角度上的理解和站在技术研发角度上的理解） 以及工作经验。。。
what is supposed to be there
这就是EXPECTED RESULT，不错不错！太偏向代码就变代码阅读器了。 这个要看情况的，因为我老师曾给我举了一个他朋友公司的例子：那个测试人员不用按时间上班，工资最高，为什么呐，因为软件的错误，它可以很快定位是什么错误，特别是系统级的bug，很多人很难找到，包括开发人员，而他却可以很快定位～～所以我感觉测试人员应该是软件行业里面最难做的，应该是个全才性质的～～～ 现在我做的也是黑盒测试,总是觉得自己不懂代码,有种心里不踏实的感觉.
不过上面的人说的好:最容易出问题的部分其实是他取的这些变量对不对，真正计算的过程倒是不容易出错的 看来要努力的学习代码，不过看懂是必要的。
回复 1# 的帖子
“太关注确认那是什么，而代替确认那应该是什么”这句话说的很好，我个人认为这是测试者很容易走入'太关注确认那是什么'的误区！ 说的不错，在我们日常的实际工作环境中，不同企业对测试有不同的要求，当你的测试能够接触到代码范围时，适当的去了解代码是应该的，那会是一个很有意思的事情 其实懂代码并不是坏事，可以更好的定位可能出错的地方并设计与之相关的用例，只是要时刻记住自己当前的角色，现在是测试人员，就不要去钻那些代码是什么意思。 我觉得还是懂的好````
页:
[1]
2
