Question

软件测试中容易犯的测试错误？

Answer 1

虽然说我们在工作中一再要求大家要认真细心，但是对于许多的新手来说，依然会在不知不觉中犯错误。下面回龙观电脑培训就通过软件测试岗位做为分析案例，了解一下，一个软床测试新人都容易犯的测试错误都有哪些。

1.没有测试

我们很容易毫无原因地掉入这个陷阱。从现在开始，制定计划添加测试到你现在正在处理的代码中，并添加测试到将来的项目中。

2.没有从项目一开始就启动测试

我们很难再回过头去添加测试，并且可能需要改变架构才能添加测试，这样做终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期添加测试可以节省时间和精力。

3.编写失败的测试

TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创建测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试(红色表示)，但它可能会通过一个非决定性的或未实现的测试来表示。

4.担心未实现测试

软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你终想要实现的预期行为的测试，你将从测试中得到一定的价值，即使将怎么写测试目前还不得知。

5.没有很好地命名测试

命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的约定。无论你使用哪一种都没有关系，只要你能够一贯使用，并准确描述正在测试什么。

6.让测试做太多事情

又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。如果失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单处理系统输出，并确认输出中是否有一个单一项目以及它是否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创建一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。

7.没有实际测试代码

经常可以看到测试新手创建过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码是否正确，或者模拟代码是否和真正代码做相同的事情，或没有任何断言而只是执行代码。这样的“测试”都是白费力气，特别是如果它们的存在只是为了提高代码覆盖率水平的话。

8.担心代码覆盖率

代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但因为它不考虑正在执行代码的测试的质量，因此就变得没有意义。代码覆盖率在它数值非常高或非常低的时候，是挺博人眼球的。如果非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。因为这样模棱两可的意思，有的人就不知道单一片段的代码是否应该进行测试。我用一个简单的问题来明确这一点：代码是否包含重大的复杂性?如果包含，那么你需要一些测试。如果没有的话，你就不需要。测试属性访问器不过是浪费时间。如果它们失败的话，那么比起你正在写的代码，你的代码体系出现了一些更根本的问题。如果你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。如果我们在任意点重访代码，那么它就需要测试。如果在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。

9.着眼于一种类型的测试

一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件是否能够正确工作。你需要集成测试来确认不同组件是否能够协同工作。你需要自动化UI测试来验证软件是否可以如预期使用。后，你需要为任何不容易自动化的部分和探索性尝试进行手动测试。