在职业生涯中的某个时候，程序员可能会遇到以下由同事，合伙人或决策者提出的论点：
显然，我的职业生涯达到了这一点，所以现在我需要辩论这个论点。 我决定成为一名优秀的互联网公民，并发表自己的想法。 因此，在这篇文章中，我将解构该论点，并从可以检查的每个角度将其删除。 我将使用易于被本学科以外的人处理的语言来这样做。
在提出该论点的特定公司中，存在一些针对产品，客户以及我们与他们之间的关系类型所特有的缓解因素，所有这些因素都使论点不像采用时那样听起来合理。你离题了。 即使考虑到这些因素，该论点仍然值得夸大其词，但我不会因该公司的具体情况而困扰读者，以确保该讨论总体上适用于软件开发。
以更完整的形式，该参数可能如下所示：
自动化软件测试对公司来说是一笔巨大的投资，公司内部的所有程序员都在花费大量时间，除了编写软件测试之外，什么也不做，但是这些测试不会给客户带来任何明显的好处。 相反，程序员应该通过仅花费一小部分时间来进行手动测试来确保软件能够正常工作，然后我们就可以花所有的时间保存这种方式，并将其投入到开发新功能和解决现有问题上。
简而言之，有人可能会说些类似的话：
我在自动化软件测试中看不到商业价值。
这句话是一堆神话，令人钦佩。 如此简单的解除武装很简单，以至于您可能一会儿就无所适从。 从哪里开始，真的。 我们需要一一看待神话。 它去了：
误解一：软件测试是一项巨大的投资。
不，不是。 也许可以，但是它的投资回报率很高，您绝对不想错过它。
如果您没有适当的软件测试，那么在我们行业中，已经确定的事实是，您将花费大量的时间来研究意外的应用程序行为，对代码进行故障排除以解释观察到的行为，发现错误，修复问题，以及经常在每个事件上重复此过程几次，因为对一个错误的修复通常会创建另一个错误，或者使先前存在的错误显现出来，并且常常会给客户带来往返的麻烦，因为“已修复”的软件在发现新引入的错误之前已发布。
确实，它的工作方式与教育相同。 引用著名的保险杠贴纸：
您认为教育昂贵吗？ 尝试无知！
此外，您选择手动软件测试还是自动软件测试对测试后需要进行的开发工作产生重大影响，以解决测试中发现的问题。 业界早已发现，漏洞发现越早，修复它的成本就越少。
最早的可能是在纠正错误时。 这就是为什么我们使用强类型编程语言以及集成开发环境来在我们键入代码时不断编译我们的代码的原因：这样，IDE会立即用红色下划线标记任何语法错误或类型冲突，因此我们可以看到它并修复它，然后继续键入下一行代码。 修复该错误的成本几乎为零。 (几乎所有脚本语言都绝对可怕的主要原因之一是，在这些语言中，即使是拼写错误也可能无法被发现并成为错误。)
如果在引入错误时仍无法捕获到该错误，那么下一个最佳捕获时间是在运行自动化测试时进行，这是在将更改提交到源代码存储库之前应该执行的操作。 如果这种情况没有发生，则将提交该错误，这已经代表了相当大的成本，您稍后必须为修复它付出代价。
下一个捕获该错误的最佳时间是通过运行自动测试作为持续构建系统的一部分。 这至少会告诉您最近的提交包含一个错误。 如果没有采用自动软件测试的持续构建，那么您将遭受另一笔陡峭的价格上涨，您必须为此付出最终修复该错误的费用。
当人们开始手动测试软件并发现错误时，可能已经对源代码存储库进行了更多提交。 这意味着，在发现该错误时，我们将不必知道是由哪些提交引起的，也不是由哪些程序员进行了相关的提交，即使我们这样做了，他们此时仍将继续从事其他工作，他们将必须暂时放弃，并使经常痛苦的心理环境切换回他们之前从事的工作。 自然地，从提交错误到开始修复错误，它花费的时间越长，它变得越糟。
在极端情况下，考虑在引入缺陷后几个月尝试尝试修复错误，这时没有人知道导致缺陷的更改，而做出这些更改的程序员甚至连公司都没有了。 为了解决此问题，必须有人熟悉该模块，考虑可能导致该错误的数十种不同提交，然后找到并修复。 修复该错误的成本可能超过程序员的月薪。
这就是为什么今天整个软件行业都以测试的名义发誓：它有助于尽早发现错误，并保持开发工作流不间断，因此最终节省了大量资金。
误解二：软件测试代表着一项投资。
不，甚至没有。 软件测试在我们的行业中被视为软件开发的组成部分，因此，将其视为与开发软件时已被认可的必要投资分开的投资是没有意义的。
提防无效的推理，即要实现某些功能，我们需要的是10条生产代码，这些代码成本100美元，而另外10条生产代码，则只能测试前10条代码，并且将花费额外的100块钱，是可选的。
取而代之的是，有效的推理是，要实现所述功能，我们将需要20行代码，这将花费200美元。 碰巧的是，这些行中的10行将驻留在源代码树的一个名为“生产”的子文件夹中，而其他10行将驻留在同一树的一个子文件夹中(称为“测试”)； 但是，每组线的精确位置是一项琐碎的技术性工作，与一组线相对于另一组线的“有用性”概念无关。 事实是，所有这些代码行中的所有20行对于实现期望的结果都是必不可少的。
这是因为没有相应测试代码的生产代码根本无法确定要实现任何功能。 关于无测试代码，唯一可以说的是，迄今为止，它已经成功地给人类观察者留下了印象，即其行为足以类似于某些所需的功能。 此外，只能说到目前为止它已被观察到是成功的，这意味着明天的新观察很可能会发现它在做一些不同的事情。
这与说“该软件确实实现了该功能”相差甚远。
误解三：软件测试只是草率的管理。
通常不会发声，而是暗示。 那么，为什么程序员不能在第一时间编写出正确的软件？ 到底为什么软件一旦编写就不能保持正确？
造成这种情况的原因有很多，最重要的原因与软件工程专业的成熟程度以及我们要求开发的软件的复杂性有关。
到期
软件开发不是像物理学和数学那样的硬科学。 您在大学里有一些纯粹的科学概念，但是它们很少适用于我们工作的日常现实。 在软件开发方面，通过通用法律，基本公理，已建立的通用惯例和规则，无处不在的符号，公式和程序的书，以及现成的商业化方法，对我们而言，向我们提供的帮助并不比其他学科多标准化的组件等。很难找到类似的基本科学技术概念，例如实验，测量和可重复性。 这就是为什么软件工程有时被描述为一门艺术而不是一门科学的原因，而且任何人都可以不必学习软件工程就可以成为程序员的事实无助于消除这种特征。
自动化软件测试是软件工程领域的其中一项发展，使之更像一门科学，而不是一门艺术。 通过测试，我们终于设法引入了软件工程中的实验，测量和可再现性的概念。 光靠可测性是否足以将我们的学科变成一门科学还是有争议的，但是如果没有测验，我们可以确定我们除了艺术之外什么也没做。
复杂
我们今天开发的软件系统非常复杂。 一个仅向用户显示4个连续的是/否选择的简单应用程序具有16个必须测试的不同执行路径。 将选择数量增加到7，将路径数量增加到128。在由20个步骤组成的真实应用程序中，使用稍长一些但完全符合实际的用例序列，路径总数超过一百万。 这非常复杂，到目前为止，我们仅在考虑是/否选择。 现在，想象每个步骤不仅包括是/否选择，还包括一个充满可点击按钮和可编辑字段的整个屏幕，它们相互交互。 这不是一个极端的情况，这是一个相当普遍的情况，其复杂性确实是天文数字。
有趣的是，硬件工程师喜欢将复杂性管理卸载到软件上。 机器完全由硬件组成，杠杆，齿轮，皮带和凸轮都经过精心对准以统一工作的时代已经一去不复返了，因此，转动曲柄的一端会使印刷和折叠的报纸从另一端出来。 如今，硬件组件之间往往不会相互影响，因为这太复杂了，很难更改。 取而代之的是，每个传感器和每个执行器都连接到中央面板，中央面板由软件负责并协调整个过程。
但是，软件并不是复杂性消失的神奇地方。 您不能期望为软件提供复杂的输入，期望复杂的输出，同时不能期望其内部只有纯粹和简单：系统的复杂性不能低于其执行功能固有的复杂性。
将复杂性从硬件转移到软件的价值在于，系统更易于更改，但是当我们说“更轻松”时，我们并不意味着“更简单”。 所有的复杂性仍然存在，必须加以解决。 当我们说“更容易改变”时，我们的意思是，为了进行改变，我们不必先向钢厂发送新的蓝图。 这就是通过将复杂性从硬件转移到软件而获得的：无需与物理世界进行混乱，耗时且昂贵的交互即可更改系统。
因此，即使我们已经消除了那些经过精心设计和精心布置的杠杆，齿轮，皮带和凸轮，但它们现在已经存在于软件中，您只是看不到它们，除非您是程序员，否则您将无法看到它们，正如对这种复杂性的物理机器进行最小的修改将是一场艰辛的苦难一样，对具有相同复杂度的软件系统进行的最小修改也将是一次艰苦的苦难。
如果操作正确，软件只能处理复杂性。 如果没有进行复杂的自动化软件测试，就无法开发复杂的软件，即使您进行开发，也无法对软件的正确性做出任何假设。 此外，即使它看起来可以正常工作，也不能对其进行任何改动，除非进行了自动软件测试，以确定更改后它仍然可以正常工作。 那是因为您根本无法以自动化以外的任何方式测试成千上万的可能执行路径。
误解四：测试对客户没有明显好处。
是的，它确实。 它被称为可靠，一致，正确运行的软件。 它也被称为软件，它会不断改进而不是因为担心打喷嚏而破裂而停滞不前。 这也称为接收新引入的功能，而又不会丢失曾经起作用但已被破坏的旧功能。 它甚至被称为在引入更新后立即接收更新，而不必等到几天之后可怜的灵魂点击了整个应用程序，以确保一切仍然正常进行。
误解五：手动测试可以确保软件正常运行。
不，它不能。 这是因为软件的复杂性通常远大于您可能希望手工进行的测试。 交互式应用程序不像一块织物，您可以对其进行视觉检查，并且可以肯定地说它没有缺陷。 您将需要以令人难以置信的多种不同方式与软件进行交互，以测试令人难以置信的多种可能的故障模式。
当我们进行手动测试时，为了节省时间(以及我们的理智)，我们仅关注软件功能的子集，该子集可能已受到对源代码所做的最新更改的影响。 但是，选择哪个子集进行测试必须基于我们对程序的哪些部分可能已受到我们的修改影响的估计和假设，以及对这些部分受到不利影响时的行为方式的猜测。 遗憾的是，这些估计，假设和猜测非常不可靠：通常是没人希望破坏的软件部分实际上破坏了，甚至可疑部分有时也以不同于任何人预期和计划破坏的方式破坏了。测试。
顾名思义，这是因为我们可以很容易地预见到所有失败模式，基于我们所做的修改，我们通常会在检查完修改并提交代码之前检查自己。
此外，在我们的行业中，众所周知，从事软件开发的人员通常不适合对其进行测试。 没有开发人员会像用户所愿那样鲁re和反复无常地使用该软件。 就像程序员的手有自己的想法一样，避免将鼠标指针发送到屏幕的不良区域，而正是这保证了用户的手可以发送它。 好像程序员的手指永远不会像用户的手指一样沉重地按下该鼠标按钮。 即使是专门的测试人员，在工作一段时间后也开始表现出像程序员一样的行为，因为只有人类才能在导航环境中运用已获得的有关环境的知识，并重用已建立的已知良好路径。 这是我们的本性。 您可以要求人们做违背他们本性的事情，他们可能会真诚地同意，甚至可能会尽力而为，但结果仍然会受到影响。
然后是重复性的运动疲劳，无论是身体上还是精神上的疲劳，都严重限制了任何种类的手动测试所具有的范围。
最后，还有效率问题。 当我们进行手动软件测试时，我们一定会在人工时进行测试，这与计算机执行相同任务的速度相比实在是太慢了。 一个人以每秒单击一次的速度测试排列，理论上可以在不少于2个工作月的时间内测试一百万个排列，计算机可以在几分钟内完成。 而计算机将完美地做到这一点，而相比之下，最有才干的人将做到这一点。 这就是效率低下的手动软件测试。
误解六：手动测试比编写测试花费的时间更少。
不，不是。 如果您想说您实际上是在进行一些值得一提的手动测试，而不是开玩笑，那么您将不得不花费大量的时间无所作为，而您将不得不继续重复一遍。每次修改软件。
相反，在进行软件测试时，您将花费一些时间来预先构建一些测试套件，然后您就可以在每次需要它们时重新执行它们，而只需付出相对较小的努力即可。 因此，您必须不断重复对某个软件进行手动测试，而为同一软件编写自动化测试套件则需要您一次执行，从那一刻起，它就一直为您带来回报。
这就是为什么说我们只是手动测试软件，然后节省时间会实现更多功能是谬论的原因：一旦您添加了一点新功能，就必须重复所有测试再次。 手动测试软件是一个永无止境的故事。
这种情况很像是租房还是买房：在租房时，每个月底时您的状况与月初时完全一样：房屋仍然完全不属于您，而是属于您房东，您现在必须全额支付新租金，才能再住一个月。 购买时，您需要预先支付很多钱，并且始终需要支付一些维护费用和税金，但是所支付的钱会变成有形的东西，并以房屋的形式变成您手中的价值现在拥有。
此外，通常会严重低估手动测试的相对效率。 为了进行正确的手动测试，您必须提出一个细致的测试计划，说明测试人员应该执行的操作以及每个操作的结果，以便测试人员可以判断软件是否根据是否达到要求。 但是，没有一个测试计划会像实际执行相同测试的代码那样明确，并且您对测试计划的努力越细致，获得的收益就越少，因为在某种程度上，开始编写测试计划与开始编写相应的自动化测试相当。 因此，您不妨先在代码中写下测试计划。
当然，一轮编写自动化软件测试套件将比几轮手动执行相同的测试花费更多的精力，因此，一种方法与另一种方法的合意性可能取决于您对盈亏平衡点的设想。 如果您认为收支平衡点已经相当快了，那么您已经看到了尽快实施自动化软件测试的好处。 如果您认为它将在IPO之后进行，那么您可能会认为最好推迟发行，但实际上，即使在这种情况下，您可能也不想这样做，以后再讨论。
好吧，让我告诉您：在软件行业中，已经建立的理解是，收支平衡点非常快。 就像很快在应用程序之前编写测试。 (一种称为测试驱动开发的实践。)
误解七：您无需进行软件测试就可以继续开发新功能并解决现有问题。
理论上可以，但实际上不能。 这是因为每当您触摸软件的任何部分时，有关该软件的所有信息现在都可能会损坏。 没有适当的自动化软件测试，您就是不知道。 对于杂乱编写的软件尤其如此，这反过来在从一开始就没有进行任何自动化软件测试的情况下尤其常见。 矛盾的是，自动化软件测试迫使软件设计具有某种结构，这种结构减少了故障，因此软件对测试的需求较少。
为了帮助减少变更引起的软件脆弱性，我们甚至设有专门的程序来控制错误的修复：发现错误后，我们并不总是继续进行修复。 取而代之的是，我们经常要做的是首先编写一个测试，该测试根据需求检查错误，而无需对可能导致错误的原因进行任何假设。 当然，由于该错误位于软件中，因此最初会观察到测试失败。 然后，我们会根据您的理论来修复导致问题的错误，然后测试应该会成功。 如果不是，则我们修复了错误的错误，或更可能的是，我们只是打破了以前很好的东西。 此外，其他所有更好的测试也可以继续保持成功，否则在修复此错误时，我们会破坏其他功能。 另外，新的测试现在成为测试套件的永久组成部分，因此，如果将来再次违反此特定行为，则此测试将抓住它。
如果您在没有解决诸如此类的测试机制的情况下解决“修复错误”，那么您并不是在真正地修复错误，而只是改组了错误。 这同样适用于功能：如果没有适当的必要测试机制就进行“添加功能”，那么根据定义，您没有添加功能，而是在添加错误。
误解八：软件测试没有商业价值。
是的，它确实。 我已经列出的论点应该清楚地表明确实如此，但是让我再提供一个论点，它表明自动化软件测试如何直接等同于业务价值。
对于几乎任何类型的业务而言，潜在的重要因素都是投资。 当投资者对软件业务感兴趣时，如果他们对自己的工作有丝毫的了解，他们很可能希望在进行投资之前先评估源代码。 评估是通过将软件项目的副本发送给独立的专业软件评估员来完成的。 评估人员检查软件，并给出投资建议。
评估者可以首先以普通用户的身份使用该软件，以确保它看起来像在做它打算做的事情，然后他们可以检查设计以确保它有意义，然后可以检查源代码以确保一切正常。看起来很正常，等等。在这些任务上花费了太多时间之后，评估者可能会继续进行测试。 软件测试在软件行业中如此普遍，以致于它被一致认为是决定软件质量的最重要的单个因素。
如果没有测试，这对于投资建议来说是个坏消息。
如果测试不通过，这也是一个坏消息。
如果测试成功，那么下一个问题是测试的彻底程度。
为此，评估人员可能会使用一个名为“代码覆盖率分析器”的工具。 该工具跟踪在程序运行时(或者更有可能在测试正在执行程序时)正在执行的代码行。 通过在代码覆盖率分析工具处于活动状态时运行测试，评估程序将因此获得软件的代码覆盖率度量。 这只是一个从0到100的数字，它是测试已执行的源代码行总数的百分比。 测试越彻底，这个数字就越高。
这是非常有用的度量标准，因为它以单个数字捕获了整个软件系统的客观，非常重要的质量度量标准。 它还往往与评估者最终给出的实际投资建议高度相关。 确切数字可能会因产品，评估人员，投资者，投资和其他情况而异，但大致分类如下：
低于50％表示“朝相反方向运行，这与埃博拉病毒一样好”。
50-60％表示“差”，
60–70％表示“体面”，
70–80％表示“好”，
80–90％表示“优秀”，
90–100％表示“例外”。
当然，所需的编程工作量与所获得的代码覆盖率的关系图是高度非线性的。 通过45％相对容易； 当您超过65％时，难度会越来越大； 越过85％的关卡，将变得异常困难。
以我的经验和理解，在一般商业软件业务中，有责任心的软件公司正在争取75％的成绩。 在他们只能实现大约65％的代码覆盖率的地方，他们认为这是可以接受的，但同时他们知道自己可以做得更好，或者他们的自尊心很低。 高危度软件(人类赖以生存或享有盛誉的国家/地区)可能具有100％的覆盖率，但是要实现这一目标需要付出巨大的努力。 无论如何，重要的不是开发人员的想法，而是评估者的想法。 评估者倾向于将行业的既定实践作为他们判断的标准。 既定的做法要求进行广泛的软件测试，因此，如果您不这样做，则您的评估效果会很差。
那么，软件测试是否具有商业价值？ 不论技术前景如何，仅投资前景就可以。 此外，软件评估可能是进行IPO的必要准备工作的一部分，因此，即使您认为IPO后自动测试与手动测试的收支平衡点仍然存在，仍然有充分的理由进行软件测试一切都在首次公开募股之前就处于完美的工作状态。
以上内容适用于专门从事软件开发的业务。 我不知道软件在哪些方面处于次要地位的公司可以在多大程度上获得并行性，但我怀疑这在很大程度上是不可行的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
