我是正在研究BE（CS）的学生，我的问题如下：

1. 是否需要在软件领域进行测试？
2. 如果我们非常谨慎地创建软件，那么为什么要进行测试？
3. 经过测试，我们是否可以确定已经实现了该目标（产品/软件按预期工作），因为我们已经对其进行了测试？可能吗？

我的问题：是否需要测试软件？

是。因为无论您多么出色，您都无法考虑所有事情。

• 您还将被要求使您的软件执行您从未打算做的事情。
• 您也永远不会有如此清晰的需求，以至于您将能够想到各种确保代码不会中断的需求。
• 您还将使用并非总是按预期方式工作的其他人的软件和api，但是您将假定这样做或应该导致“完美”案例中的缺陷。

是

出于同样的原因，厨师在烹饪时会品尝食物。

我与这样的人一起工作，他认为因为他是高级程序员，所以不再需要测试他的代码。该公司不了解这种态度有多危险，他们没有直接解雇他，而是雇用了更多的程序员来解决积压的bug。他们不知道这个积压来自何处，他们认为这是编程的全部内容。基本上，我们有3位程序员在这种模式下工作，并且有20个人组成的团队除了测试和修复这三个人创建的错误外，什么也不做。

缺席 的 PROPER测试KILLS。

因此，除非您是上帝或任何一个完美无缺的版本（我现在想知道），或者除非您主动希望很快被开除，否则我强烈建议您开始测试。

软件是人编写的。

人是不完美的，会犯错误。

随着任务的复杂性增加，错误，疏忽或遗忘的事物的潜在数量（和影响）也会增加-通常呈指数增长。

是的，需要测试。它带来平衡和远见。

您会乘坐运行您知道在笔记本电脑上使用过的操作系统并以自己喜欢的颜色显示死亡屏幕的航班吗？想一想。

没有编码器是完美的。远非如此。您需要测试，测试人员通常会引入开发人员所缺少的观点（也称为用例）。

搜索Google上最著名的软件错误，以了解我的意思。

在大学一级，请阅读一些有关测试驱动的开发，单元测试和敏捷实践的知识，以了解当前的情况。

对于任何实际使用的非琐碎（大小或功能）的应用程序，测试都是绝对必须的。您不会找到一个关心他/她的手艺的开发人员（通过访问此站点证明），他们会做出回应并说不需要进行测试。

除了已经发布的内容之外，在任何给定的应用程序上进行一整套的自动化单元测试将使您对将来的代码更改更有信心。这种较高的置信度（由于单元测试提供了BIG安全网），将导致对现有应用程序的代码更改速度更快（由于回溯/重复检查较少）

人文错误

没有没有错误的软件。

最熟练的开发人员使用错误编写代码。即使存在完美的开发人员，由于以下之间的差异，仍然会有错误：

• 用户需求和规格文件
• 规格和设计
• 预期和实际的硬件和软件环境
• 昨天和今天的真相：上面列出的所有内容都可能会在开发过程的每个步骤中发生变化，而变化未得到完全报告。

完美的开发人员只是整个过程的一部分。完美的开发者不存在。

大多数现实生活中的程序：

a）包含数百行或更多行的代码，分散在多个文件中；
b）由多个程序员开发；
c）在与开发人员环境不同的环境中使用

因此，如果您不检查程序在现实生活中的工作方式，那么它根本无法工作的机会将接近100％。

除了所有其他出色的答案之外，即使您知道它的完美和无缺陷，也请考虑将来需要处理您的代码的其他程序员。他们不会像您一样知道它，并且希望依靠您的测试来确保他们在进行更改后没有损坏任何东西。当然，这也适用于您一年没有看代码的情况！

是。

这是另一个尚未被涵盖的更微妙的观点：

永远不要低估“独立验证”的必要性。这就是为什么在提交大量作品供出版之前，让一些独立的编辑来检查您的工作是件好事的原因。不管您是多么出色的作家，您都偶尔会头脑不清-写下诸如“ in”之类的内容来代替“ it”之类的内容。如果您自己仔细地重新阅读它，您通常仍会错过它，因为您的大脑会自动接受您认为正确的思想流程，并掩盖错误。对于新的眼睛来说，这种错误通常很明显。

您在编程中会遇到同样的事情：进入一个流程很容易，在该流程中您的代码或您自己的代码的基本“开发测试”看起来都是正确的，因为您正在测试并以某种方式使用它。但是随后，当另一只手出现并以略有不同的方式或顺序单击事物时，一切都崩溃了。

现在，当然，从理论上讲，您可以自己亲自正式验证代码中的每个可能性和逻辑分支，但是对于非平凡的软件而言，这比让其他人费力地花费更昂贵，更耗时。为您编写代码。而且您仍然可能会错过您从未想到的事情。

尚未触及的内容：即使您的代码完美，您仍然不安全。编译器具有一些错误，甚至可以使完美的代码在编译后无法正确运行。操作系统中的错误会导致完美的二进制文件在运行时无法正确运行。硬件具有可能导致问题的错误。

这就是为什么在一台机器上测试不足以用于商业产品的原因。他们需要在野外遇到的尽可能多的硬件和软件组合下进行测试。

编写航天飞机软件的团队负责人在每次发射前飞出，表明该软件不会损害航天飞机。

您认为他有信心这样做吗？

您只是通过编译和使用代码来不断测试它们。在某些IDE中，键入时会进行完整性检查。除非您从未真正运行过代码，否则您将在进行测试。

您测试多少实际上是这种问题的根源，而答案却是风险。从风险管理的角度进行测试，就可以进行尽可能多的测试。测试所有内容或什么都不做通常是不可能的。几乎一无所获的测试通常是不好的举动。介于两者之间的一切都是公平的游戏，具体取决于风险水平和可交付成果的暴露程度。

闻起来像一个作业问题。

是否需要在软件领域进行测试？

是。绝对。在所有级别。在一些专业领域之外，我们还没有一个阶段可以数学证明我们的代码针对特定的错误是正确的（至少在合理的时间范围内），因此我们必须认真研究一下是否哪里坏了。

如果我们非常谨慎地创建软件，那么为什么要进行测试？

测试不仅仅是寻找编码错误。这还与确保您满足所有要求以及整个系统按预期运行一样。如果我要求失败的事务必须返回特定的错误代码，则需要编写测试以验证该功能是否存在以及它是否正常工作。

而且所有这些假设均假定规范和设计完整，正确且内部一致，而事实并非如此。即使您符合字母的规格要求并遵循设计的最后一个点和分号，如果规格或设计不佳，集成时也会出现问题。通常，系统或集成测试是在您发现规范本身存在缺陷并且需要修订时（请参阅下面的战争故事）。

经过测试，我们是否可以确定已经实现了该目标（产品/软件按预期工作），因为我们已经对其进行了测试？可能吗？

不，不是100％。除了最简单的代码，我们无法测试任何可能的输入或执行路径组合。我们无法考虑所有环境因素。我们无法想象所有可能的故障模式。

我们可以测试到可以合理确定没有任何大问题的程度。同样，这就是为什么我们需要进行所有级别的测试。编写一组测试以确保您的代码正确处理了边缘条件（错误的输入，意外的结果，异常等）。进行单元测试，以验证您的代码是否符合其要求。系统测试以验证端到端处理。集成测试，以验证所有组件之间是否正确通话。进行可用性测试，以确保整个产品以客户不希望开枪的方式运作。

实际场景-我正在一个后端系统上工作，该系统偶尔将更新发送到GUI服务以显示在屏幕上的表格中。在项目期间，添加了一项要求以将过滤添加到显示中（例如，操作员可以选择在表中显示条目的子集）。设计错误＃1- 应当由GUI服务进行过滤（我有一个古朴，古怪的观念，显示管理功能应该由显示管理软件负责），但是由于政治因素以及我无法在问题出现之前就识别出问题问题，该要求放在了后端服务上。好吧，没问题，我可以做到。筛选器状态更改，我收到一条消息，然后发送以下内容的创建或删除消息表中的每一行，因为这就是界面的工作方式（设计错误＃2-无法在一条消息中将更新发送到多行；我们甚至无法发送一条“清除”或“删除”消息来清除整个表格）。

好吧，在开发过程中一切正常。单元，系统和集成测试表明，我发送了正确的信息并正确处理了过滤器更改。然后我们进行可用性测试，整个过程都很难解决，因为数据量很大。我的后端服务和GUI之间的网络延迟约为.15到.25秒。如果您只需要发送十几行左右的更新，那还不错。 致命的是您必须发送数百个更新。我们开始收到有关更改过滤器状态后GUI冻结的错误报告。好吧，不，发生了什么事，它要花几分钟的时间 之所以要更新显示内容，是因为骨头更新一次的消息协议无法处理现实情况。

请注意，如果我们事先不愿意做最基本的分析，那么从总承包商到小老我，所有人都应该并且已经预料到了所有这些。我要提供的唯一辩护是，我们正在关闭一个为期六个月的项目的第二年，该项目将在交付后几乎立即被淘汰，我们都迫切希望看到它的背后。

这使我们有进行测试的最终原因-CYA。现实世界中的项目失败的原因有很多，其中许多是政治原因，并不是每当事情出错时，每个人都会真诚地行事。指责，指责被指责，最终，您需要能够指向记录，表明至少您的工作按预期工作。

测试将始终完成，并且将始终发现错误。只是测试将由您的团队在内部完成，或者最终用户将是测试人员。最终用户发现错误的成本比测试期间发现错误的成本高得多。

我建议参加一门好的容错计算课程。精心设计的软件只是实现软件产品健壮性的支柱之一。其他两个支柱是足够的测试和冗余设计。基本目的是容纳指数数量的未知故障条件，并优先处理某些已知故障条件：

1.）通过设计和适当的实施来消除尽可能多的故障2.）在设计阶段消除意外的故障，并通过各种形式的测试（单元，集成，随机）消除不正确的实施3.）通过冗余处理任何遗留的故障（时间=>重新计算，重试或空间=>保留副本，奇偶校验）

如果您省去了测试阶段，则只剩下设计和冗余阶段来解决故障。

同样，从产品的角度来看，您的利益相关者（例如，管理层，用户，投资者）将希望某种放心，以确保您的产品符合某些质量和安全规范，标准等。除了所有这些，您是否还没有测试过您构建只是为了进行“健全性检查”？所有这些原因使软件测试更具吸引力。

所有程序都有错误，至少要从头开始。

有一些研究表明，每五行未经测试的代码大约会聚集1个错误。

历史课：

早在1960年代，IBM需要一个“ NOP”程序，以便他们可以在JCL中执行某些功能而无需实际运行程序。开发人员提出了一个单行汇编程序，其中整个代码包含在其名称“ IEFBR14”中，实际代码为：

       BR 14 * brach to return address in register 14

在漫长的提升过程中，这一单行程序受到了2个错误报告和5个修订的约束。

当进行单元测试时，代码重构的速度确实更快。单元测试还向您展示了具体功能的简单用法，因此您有一点“ howto”，这在程序员不完全了解整个代码的大型项目中非常有用。

在使用TDD（测试驱动的开发）进行开发时，您没有不必要的getter / setter等。您只需创建所需的内容即可。

要回答问题的＃3：

是的，作为程序员和软件测试人员，您可以确定自己在测试期间符合软件的要求。

{戴上质量检查帽}

怎么样？您可以通过从测试代码到接受标准，从接受标准到要素以及从要素到需求的跟踪测试来做到这一点。如果您跟踪设计链中的每个测试并映射到一个或多个需求，则可以确保使用您的测试来确保代码满足其需求（尽管这会带来足够的测试覆盖率，另一个主题）。如果您无法跟踪设计链中的测试，那么您可能会测试不需要的东西，这是在浪费时间。验收标准还可以包括检查不良行为-您也可以测试不良行为，从而使您更接近质量发布。

{取消质量检查}

没有代码是没有错误的，只有在开发过程中花费更多的精力来评估其质量，随着时间的推移，成本才会降低。

我已经成为软件测试员已有3年了。最初，我本人对测试的必要性表示怀疑，因为我认为如果开发部门和项目管理人员做好工作，那么软件上就不会出现错误。

但事实并非如此。++++++++

错误经常发生，其中一些对于项目的运营至关重要。还有跨浏览器测试（这意味着要在不同的现有浏览器（例如SAFARI，FIREFOX，CHROME和Internet Explorer）上进行测试），而我从事的项目是在调查窗口上使用简单的界面按钮（例如YES和NO），而这些按钮在所有浏览器中均不起作用他们中的一些。

我从事互联网页面测试工作，当时正在测试简单的“文本更改”，并以为自己在世上不可能在这项简单的工作上存在缺陷，但没有发生。

我还看到，当新开发人员加入团队并获得现有复杂的Internet应用程序表单的更新工作时，该表单具有许多与外部页面的链接/调用，由于新旧开发人员之间缺乏沟通而发生了错误，由于各种原因（没有时间进行教育，没有意愿进行教育等等）。

是

假设您的软件只是一个逻辑函数AND（b1，b2），其中b1和b2只是位。这样，如果您的周围环境准确地提供了指定的用途，那么您需要4个测试用例来确保您的软件没有错误。

现在，您的系统由许多功能组成，其中最简单的功能要比该逻辑功能复杂得多。您如何确定它没有错误？

（未完待续）