|
|
这个回帖主要谈了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. |
|
/1 
关于我们
发表于 2007-8-10 15:48:02
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
支持,最低限度要能看懂...