关于银行项目的软件测试_关于软件测试

关于银行项目的软件测试

At some point during his or her career, a programmer might come across the following argument, presented by some colleague, partner, or decision maker:

在他或她的职业生涯中的某个时候，程序员可能会遇到以下由同事，合伙人或决策者提出的论点：

Since we can always test our software by hand, we do not need to implement Automated Software Testing.

由于我们始终可以手动测试软件，因此我们无需实施自动化软件测试。

Apparently, I reached that point in my career, so now I need to debate this argument. I decided to be a good internet citizen and publish my thoughts. So, in this post I am going to be deconstructing that argument, and demolishing it from every angle that it can be examined. I will be doing so using language that is easy to process by people from outside of our discipline.

显然，我的职业生涯达到了这一点，所以现在我需要辩论这个论点。 我决定成为一名优秀的互联网公民，并发表自己的想法。 因此，在这篇文章中，我将解构该论点，并从可以检查的每个角度将其删除。 我将使用易于被本学科以外的人处理的语言来这样做。

In the particular company where that argument was brought forth, there exist mitigating factors which are specific to the product, the customers, and the type of relationship we have with them, all of which make the argument not as unreasonable as it may sound when taken out of context. Even in light of these factors, the argument still deserves to be blown out of the water, but I will not be bothering the reader with the specific situation of this company, so as to ensure that the discussion is applicable to software development in general.

在提出该论点的特定公司中，存在一些针对产品，客户以及我们与他们之间的关系类型所特有的缓解因素，所有这些因素都使论点不像采用时那样听起来合理。你离题了。 即使考虑到这些因素，该论点仍然值得夸大其词，但我不会因该公司的具体情况而困扰读者，以确保该讨论总体上适用于软件开发。

In its more complete form, the argument may go like this:

以更完整的形式，该参数可能如下所示：

Automated Software Testing represents a big investment for the company, where all the programmers in the house are spending copious amounts of time doing nothing but writing software tests, but these tests do not yield any visible benefit to the customers. Instead, the programmers should ensure that the software works by spending only a fraction of that time doing manual testing, and then we can take all the time that we save this way and invest it in developing new functionality and fixing existing issues.

自动化软件测试对公司来说是一笔巨大的投资，公司内部的所有程序员都在花费大量时间，除了编写软件测试之外，什么也不做，但是这些测试不会给客户带来任何明显的好处。 相反，程序员应该通过仅花费一小部分时间来进行手动测试来确保软件能够正常工作，然后我们就可以花所有的时间保存这种方式，并将其投入到开发新功能和解决现有问题上。

To put it more concisely, someone might say something along these lines:

简而言之，有人可能会说些类似的话：

I do not see the business value in Automated Software Testing.

我在自动化软件测试中看不到商业价值。

This statement is a bunch of myths rolled up into an admirably terse statement. It is so disarmingly simple, that for a moment you might be at loss of how to respond. Where to begin, really. We need to look at the myths one by one. Here it goes:

这句话是一堆神话，令人钦佩。 如此简单的解除武装很简单，以至于您可能一会儿就无所适从。 从哪里开始，真的。 我们需要一一看待神话。 它去了：

误解一：软件测试是一项巨大的投资。 (Myth #1: Software testing represents a big investment.)

No it doesn’t. Or maybe it does, but its ROI is so high that you absolutely don’t want to miss it.

不，不是。 也许可以，但是它的投资回报率很高，您绝对不想错过它。

If you do not have software testing in place, then it is an established fact in our industry that you will end up spending an inordinate amount of time researching unexpected application behavior, troubleshooting code to explain the observed behavior, discovering bugs, fixing them, and often repeating this process a few times on each incident because the fix for one bug often creates another bug, or causes pre-existing bugs to manifest, often with the embarrassment of an intervening round-trip to the customer, because the “fixed” software was released before the newly introduced bugs were discovered.

如果您没有适当的软件测试，那么在我们行业中，已经确定的事实是，您将花费大量的时间来研究意外的应用程序行为，对代码进行故障排除以解释观察到的行为，发现错误，修复问题，以及经常在每个事件上重复此过程几次，因为对一个错误的修复通常会创建另一个错误，或者使先前存在的错误显现出来，并且常常会给客户带来往返的麻烦，因为“已修复”的软件在发现新引入的错误之前已发布。

Really, it works the same way as education. To quote a famous bumper sticker:

确实，它的工作方式与教育相同。 引用著名的保险杠贴纸：

You think education is expensive? Try ignorance!

您认为教育昂贵吗？ 尝试无知！

Furthermore, your choice of Manual Software Testing vs. Automated Software Testing has a significant impact on the development effort required after the testing, to fix the issues that the testing discovers. It is a well established fact in the industry that the sooner a bug is discovered, the less it costs to fix it.

此外，您选择手动软件测试还是自动软件测试对测试后需要进行的开发工作产生重大影响，以解决测试中发现的问题。 业界早已发现，漏洞发现越早，修复它的成本就越少。

• The earliest time possible for fixing a mistake is when making it. That’s why we use strongly typed programming languages, together with Integrated Development Environments that continuously compile our code as we are typing it: this way, any syntax error or type violation is immediately flagged by the IDE with a red underline, so we can see it and fix it before proceeding to type the next line of code. The cost of fixing that bug is near zero. (And one of the main reasons why virtually all scripting languages are absolutely horrible is that in those languages, even a typo can go undetected and become a bug.)
  最早的可能是在纠正错误时。 这就是为什么我们使用强类型编程语言以及集成开发环境来在我们键入代码时不断编译我们的代码的原因：这样，IDE会立即用红色下划线标记任何语法错误或类型冲突，因此我们可以看到它并修复它，然后继续键入下一行代码。 修复该错误的成本几乎为零。 (几乎所有脚本语言都绝对可怕的主要原因之一是，在这些语言中，即使是拼写错误也可能无法被发现并成为错误。)
• If you can’t catch a bug at the moment you are introducing it, the next best time to catch it is when running automated tests, which is what you are supposed to do before committing your changes to the source code repository. If that doesn’t happen, then the bug will be committed, and this already represents a considerable cost that you will have to pay later for fixing it.
  如果在引入错误时仍无法捕获到该错误，那么下一个最佳捕获时间是在运行自动化测试时进行，这是在将更改提交到源代码存储库之前应该执行的操作。 如果这种情况没有发生，则将提交该错误，这已经代表了相当大的成本，您稍后必须为修复它付出代价。
• The next best time to catch the bug is by running automated tests as part of the Continuous Build System. This will at least tell you that the most recent commit contained a bug. If there is no Continuous Build with Automated Software Testing in place, then you suffer another steep increase in the price that you will have to pay for eventually fixing the bug.
  下一个捕获该错误的最佳时间是通过运行自动测试作为持续构建系统的一部分。 这至少会告诉您最近的提交包含一个错误。 如果没有采用自动软件测试的持续构建，那么您将遭受另一笔陡峭的价格上涨，您必须为此付出最终修复该错误的费用。
• By the time a human being gets around to manually testing the software and discovering the bug, many more commits may have been made to the source code repository. This means that by the time the bug is discovered, we will not necessarily know which commits contributed to it, nor which programmers made the relevant commits, and even if we do, they will at that moment be working on something else, which they will have to temporarily drop, and make an often painful mental context switch back to the task that they were working on earlier. Naturally, the more days pass between committing a bug and starting to fix it, the worse it gets.
  当人们开始手动测试软件并发现错误时，可能已经对源代码存储库进行了更多提交。 这意味着，在发现该错误时，我们将不必知道是由哪些提交引起的，也不是由哪些程序员进行了相关的提交，即使我们这样做了，他们此时仍将继续从事其他工作，他们将必须暂时放弃，并使经常痛苦的心理环境切换回他们之前从事的工作。 自然地，从提