典型的测试错误有哪些?(11)

发表于:2014-12-08来源:uml.org.cn作者:不详点击数: 标签:典型测试错误
Some believe that programmers cant test their own code. On the face of it, this is false: programmers test their code all the time, and they do find bugs. Just not enough of them, which is why we need

  Some believe that programmers can't test their own code. On the face of it, this is false: programmers test their code all the time, and they do find bugs. Just not enough of them, which is why we need independent testers.

  有些人相信程序员不能测试他们自己的代码。这显然不对:程序员一直都在测试他们的代码,而且他们也的确能够发现 bug 。只是发现的 bug 还不够多,这也是为什么我们需要独立的测试员。

  But if independent testers are testing, and programmers are testing (and inspecting), isn't there a potential duplication of effort? And isn't that wasteful? I think the answer is yes. Ideally, programmers would concentrate on the types of bugs they can find adequately well, and independent testers would concentrate on the rest.

  但是如果独立测试员也在测试,程序员也在测试(并且也在走查代码),其中不存在潜在的重复工作吗?这不是一种浪费吗?我想答案是肯定的。理想情况中,程序员应当集中于他们能够充分发现的 bug 类型,而独立测试员应集中于其他部分。

  The bugs programmers can find well are those where their code does not do what they intended. For example, a reasonably trained, reasonably motivated programmer can do a perfectly fine job finding boundary conditions and checking whether each known equivalence class is handled. What programmers do poorly is discovering overlooked special cases (especially error cases), bugs due to the interaction of their code with other people's code (including system-wide properties like deadlocks and performance problems), and usability problems.

  程序员能够较好地发现的 bug 是那些与他们预期不符的代码。例如,一个接受过一定培训、有一定积极性的程序员可以很好地找到边界条件,并且检查每一个等价类是否都处理了。程序员做的不好的地方是不能发现被忽略的某些情况(尤其是错误情况),不能发现由于他们的代码与其他人的代码交互作用而产生的 bug ,以及易用性问题。

  Crudely put, good programmers do functional testing, and testers should do everything else. Recall that I earlier claimed an over-concentration on functional testing is a classic mistake. Decent programmer testing magnifies the damage it does.

  大致来说,好的程序员进行功能测试,测试员应该完成其他所有工作。回忆一下我前面曾说过,过分集中于功能测试是一个典型错误。合格的程序员测试夸大了它产生的破坏。

  Of course, decent programmer testing is relatively rare, because programmers are neither trained nor motivated to test. This is changing, gradually, as companies realize it's cheaper to have bugs found and fixed quickly by one person, instead of more slowly by two. Until then, testers must do both the testing that programmers can do and the testing only testers can do, but must take care not to let functional testing squeeze out the rest.

  当然,合格的程序员测试相对较少,因为程序员既没有接受过培训,对测试也没有热情。但是随着各个公司意识到由一个人发现并修复 bug 成本较低,这种情况也在逐步改变。在此之前,测试员不但必须完成程序员可以完成的测试,还要完成只有测试员才能完成的工作,还必须小心不要让功能测试挤占了其他测试。

  主题四:工作中的测试员

  When testing, you must decide how to exercise the program, then do it. The doing is ever so much more interesting than the deciding. A tester's itch to start breaking the program is as strong as a programmer's itch to start writing code - and it has the same effect: design work is skimped, and quality suffers. Paying more attention to running tests than to designing them is a classic mistake. A tester who is not systematic, who does not spend time laying out the possibilities in advance, will overlook special cases. They may be the same subtle ones that the programmers overlooked.

  在测试的时候,必须决定如何执行程序,然后完成它们。完成它们比决定它们要有趣的多。测试员渴望的是开始破坏程序,程序员渴望的是开始写代码——这导致相同结果:设计工作被忽略了,产品质量受到损害。将更多的注意力集中于运行测试而不是设计它们是一个典型错误。

  Concentration on execution also results in unreviewed test designs. Just like programmers, testers can benefit from a second pair of eyes. Reviews of test designs needn't be as elaborate as product design reviews, but a short check of the testing approach and the resulting tests can find significant omissions at low cost.

  集中于执行测试也导致未经审核的测试设计。就像程序员一样,测试员也得益于第二双眼睛的检查。测试设计的审核不必像产品审核那样严格,但是对测试方法和结果测试的快速检查可以低成本地找到重要的疏忽。

原文转自:http://www.uml.org.cn/Test/200709289.asp