工作中的测试员

一个重要的忽略 bug的特例情况是检查产品完成预期操作，但不检查它是否没有完成不应该完成的操作。举个例子，假设你有一个更新医疗机构的家庭记录数据库的程序。一个测试是在Dawn Marick的记录中添加第二个小孩。几乎所有的测试员都将在更新之后检查Dawn Marick现在有两个小孩了。部分测试员——那些聪明的、有经验的专家——将会检查Dawn Marick的配偶——Brian Marick，现在也有两个小孩了。相对较少的测试员将检查数据库中没有其他人添加了小孩。如果程序员将规则过分扩展，认为应当对所有的既是病人又是她的家庭成员的人都更新 “家庭信息”，给了Paul Marick（2岁）一个小孩，则这个 bug 就被忽略了。[Page]

  Ideally, every test should check that all data that should be modified has been modified and that all other data has been unchanged. With forethought, that can be built into automated tests. Complete checking may be impractical for manual tests, but occasional quick scans for data that might be corrupted can be valuable.

  理想情况中，每个测试都应检查需要修改的数据都被修改了，其他数据都没有。在经过仔细考虑后，可以将这个过程构建到自动化测试中。完全检查可能对于手工测试来说不切合实际的，但是偶尔地快速检查数据是否破坏可能是很有价值的。

  Testing should not be isolated work

  测试不应当是孤立的工作

  Here\'s another version of the test we\'ve been discussing:

  这里是我们讨论过的另一个版本：

  Design 3

  设计3

  Withdraw all with confirmation and normal check for 0.

  取出所有钱，需要确认，并检查余额为0。

  That means the same thing as Design 2 - but only to the original author. Test suites that are understandable only by their owners are ubiquitous. They cause many problems when their owners leave the company; sometimes many month\'s worth of work has to be thrown out.

  除了最初的作者，这与设计2是相同的。测试套件只有它们的作者才能理解是常见情况。当它们的拥有者离开公司后，会带来许多问题；有时候很多个月的工作就白费了。

  I should note that designs as detailed as Designs 1 or 2 often suffer a similar problem. Although they can be run by anyone, not everyone can update them when the product\'s interface changes. Because the tests do not list their purposes explicitly, updates can easily make them test a little less than they used to. (Consider, for example, a suite of tests in the Design 1 style: how hard will it be to make sure that all the user interface controls are touched in the revised tests? Will the tester even know that\'s a goal of the suite?) Over time, this leads to what I call \"test suite decay,\" in which a suite full of tests runs but no longer tests much of anything at all.

  我需要说明的是像设计1和2那样详细的设计也存在同样的问题。虽然他们可能由任何人运行，但不是每个人都能在产品界面变化后更新它们。因为测试不会显式地列出它们的目的，更新它们可能很容易使得比以前测试的少一点点。（例如，考虑一下，设计1风格中的测试套件：要确保所有用户界面控件在更改后的测试中被涉及是一件多么困难的事情？）长期以来，这导致了我称为“测试套件变质”的问题，完整的测试套件仍旧在运行，但什么也测试不了。

  Another classic mistake involves the boundary between the tester and programmer. Some products are mostly user interface; everything they do is visible on the screen. Other products are mostly internals; the user interface is a \"thin pipe\" that shows little of what happens inside. The problem is that testing has to use that thin pipe to discover failures. What if complicated internal processing produces only a \"yes or no\" answer? Any given test case could trigger many internal faults that, through sheer bad luck, don\'t produce the wrong answer.[Page]

  另一个典型错误是测试员与程序员的边界。某些产品主要是用户界面；他们做的所有操作在屏幕上都是可见的。其他产品主要是内部的；用户界面是一个“细管道”，很少显示内部发生什么。问题是测试必须使用那个细管道来发现错误。如果一个复杂的内部处理产生的只是“是或否”的答案，结果会怎么样呢？任何给定的测试用例都能触发很多内部错误，仅仅通过不坏的运气，才不会产生错误的答案。

  In such situations, testers sometimes rely solely on programmer (\"unit\") testing. In cases where that\'s not enough, testing only through the user-visible interface is a mistake. It is far better to get the programmers to add \"testability hooks\" or \"testpoints\" that reveal selected internal state. In essence, they convert a product like this:

  在这样的情况中，有时候测试员单独依赖于程序员（“单元”） 测试。在这不够充足的情况下，仅从用户可见的界面测试是一个错误。如果使程序员加上“可测试性钩子”或“测试点”以揭示所选择的内部状态的话，会好得多。本质上，他们将一个产品：





  to one like this:

  转化为：



 

文章来源于领测软件测试网 https://www.ltesting.net/