在开发过程中简单地运行代码是否意味着“测试”？

#1 楼

测试是实验。您有一个假设，通常由一个规范支配，例如“当我输入一个我知道是有效的用户名和密码并单击登录时，我就会越过登录屏幕并进入仪表板。”或“当我同时有10,000个用户登录该程序时，性能将不低于同时有1,000个用户的性能的95％”。

所有检验均始于该假设。假设的范围可能仅限于程序的一小部分，例如单个功能或组件。它可能涉及多个组件。它可能包含已知的好数据，已知的坏数据或随机数据。您可以将许多不同的东西推入这个假设。但是无论如何，该假设都来自产品规范的一部分。

测试的下一部分是实验本身。您执行操作并收集结果。这可能是Selenium或JUnit测试。这可能是人为点击的按钮。它可能是执行常规检查的批处理作业。但是有人必须执行该动作并收集观察结果。然后将观察结果与原始假设进行比较，以确定其是否通过。如果您无法确定它是否通过，则需要完善标准。这就是为什么很难测试“有趣”之类的原因。 '没有做测试。

作为一名前开发人员，我可以告诉你一个好的经验法则：


如果您要使其正常运行，您正在开发。如果要使其突破，就在测试。

#2 楼

这实际上取决于您的组织以及与利益相关者的关系。

在大多数情况下，测试只是一个没有具体含义的标签。最终目标是交付高质量的产品。 “测试”只是一种活动的标签，可以帮助您实现该目标。您可以根据需要定义该标签，但是您有责任交付满足质量目标的产品。规定应如何和/或何时进行测试。如果有这种安排，则需要使用这些规定来确定台式机上运行的软件是否符合其测试定义。

#3 楼

TLDR；可能描述他要求的特定术语是烟雾测试。

长版本：您正在与经理争论，而不是寻求解决方案。术语很重要，但沟通和完成工作也很重要。

您还没有完成单元或集成测试，您可能还没有完成任何性能或可用性测试，因此有各种各样测试您是否还没有做完-忘记所有这些内容。您的经理希望您至少记录一些您已验证的有关您所构建内容的信息。您验证了哪些内容可以有用地举报？而使用“ tested”一词会让您感到不舒服，然后使用另一个表示他想要的词。称其为已验证，已检查，已检查，已检查，已审查或已审核。无论哪种方法都能使您清楚，直到手疲倦之后才敲击键盘，然后再进行通话。

最后，无论是对整个项目还是对于他希望从您那里获得的文档，都要清楚地说明“完成”的含义。

#4 楼

如果不进行测试，您怎么会知道它正常工作？而且，如果它不一定能正常工作，为什么还要花资源呢？通过测试后，它的意思是“完成”-您需要同意“完成”的意思。我的浏览器中的测试文件没有崩溃”，并说“我们可以期望它会为我们任何客户的任何输入产生正确的结果”。代码可能对其他处理不同输入文件的人有用，也可能不起作用。测试（由其他人使用不同的输入以及可能不同的工作流）将确定代码是否“完成”。

多个完成级别-您需要找出老板的完成定义是什么。

好的测试会浪费资源和时间。如果您可以发布“测试版”，那么您的客户将为您进行测试，为您提供输入文件，这将打破您对输入的假设，等等（对老板来说是免费的），但是有代价：客户将看到失败的消息。您的代码。花费资源向客户展示更好的产品是否有意义，这是业务决策。即Windows的第一个可用版本是3.1，早期的版本对于beta测试人员来说是垃圾。查看产品并在“测试版”中进行尝试-如果他们对产品的运行没有期望，请提供有效的输入信息（例如“提早发布，经常发布”）。它使您可以在大量资源花在客户不关心的事情上之前满足客户的期望。与您的老板交谈，我们不知道他/她想要什么。

顺便提一下，我永远不会像这样两个小时与老板吵架。相反，我会要求超时来研究差异。可能是您对“完成”有不同的定义，而老板的定义可能对您使用的产品完全适用。接受一些有关“敏捷开发”的培训将对您有益-谷歌是您的朋友。

#5 楼

测试正在验证一组条件下的情况。在您的情况下，您可以验证它是否可以运行，可以说“我要测试它是否可以构建”。这意味着您正在实际测试某些东西。

从SDLC角度来看，您实际上只是在编码并检查您是否认为它有效并且足够好，这不是测试。测试实际上更加结构化，希望可以重复进行验证。除非它是测试驱动的开发或其他自动测试工作，否则这通常是生命周期中的另一个阶段，而这与开发代码并行进行。测试（案例）设计可以并行完成，但不能一个人完成。

如果您想让管理人员真正减少测试工作量，请描述必须采取哪些步骤来发布功能在定义完成的生产环境中。此定义应包括它的构建以及执行功能的满意路径以验证其是否完整。我猜有些开发人员可以在不运行系统的情况下构建系统，但是打孔卡的时间远远不及我们。您可以跳过自动化，探索性或可用性测试之类的测试工作。

就完成的定义达成一致！现在将其最小化，并在遇到麻烦时将其扩展。

当您在评论中说出以下内容时，我会感觉到您正在制作原型：


该项目的重点是开发一些东西，看看它是否是可行的产品


请注意，由于您正在采取捷径（例如跳过测试），因此会造成技术负担。如果该产品可行，则可能需要进行干净且经过测试的重新实现，因为现在采用快捷方式通常会导致该产品长期无法维护。与您的利益相关者讨论技术债务，以便他们对未来持诚实的看法。通过将它们放在带有时间戳的表中来出售您的最小测试工作作为测试，这对您自己以及您的涉众和客户都是说谎的。将技术债务视为严重问题。被警告！ :)

#6 楼

TL; DR答案：否。

解释：在开发人员的机器上，在开发过程中运行代码仅是迭代开发。

在另一个系统（没有开发环境并且首先不编译代码的系统）上运行它可以被认为是冒烟测试。我建议您这样做，因为您的应用程序是概念验证试验（而我的经验是，令人苦恼的许多应用程序很快就变成了生产代码）： />执行其他任何操作之前，请询问您的经理他期望什么测试水平。您想确保两个人都使用相同的定义，否则您将互相交谈。在这一点上，定义的正确性比你们都在交流的意义要小（这是一个不好的位置，但这是生活）。最初的“无需测试，因为这是概念的证明”。这样可以使您更好地了解您的经理为什么要坚持要您记录某种形式的测试。建议您的测试证明应类似于以下内容：


列出安装版本（即您在另一台计算机上运行该应用程序）和执行的操作。称它为冒烟测试。
对于电子表格中的每个列表，输入覆盖的模块。因此，例如，您登录并添加了一个用户，然后注销并以该用户身份登录。您的冒烟测试涵盖了登录和用户管理。
单独列出了应用程序中的所有模块以及每个模块中的所有功能。是的，它可以工作，但是我怀疑您这里需要一定数量的解剖结构。
包括您未测试的内容以及原因的列表（在您的情况下，“为什么”将是“没有时间”）。该列表将涵盖您希望很少使用的功能，错误处理（冒烟测试超出范围），奇异的输入等。如果您正在使用类似于敏捷过程的任何东西，请确保明确地表明您的测试仅涵盖快乐路径或钢螺纹-使应用程序在正确输入下可行的最小功能集。
在文档中包括您不保证如果在快乐路径测试之外以任何方式使用该应用程序，将会发生什么。以我的经验，这样的注意事项会被忽略，但是它们对于指出何时开始指责是很有用的。最后，祝您好运。我在您的问题中看到的是，您的工作场所中的政治不是最好的。处理起来从来都不是一件有趣的事情。

#7 楼

您的问题非常简单，就是语义上的混乱。 “测试”一词太宽泛，因此可以有截然不同的解释。没有说出您的实际意思就谈论“测试”毫无意义。

有人提到“完成的定义”。这就是您要寻找的；它是您与客户之间的合同。国防部可以像您（和您的客户，即使是公司内部的）一样模糊或具体。 DoD的一部分是衡量软件何时被视为“正确”的度量标准。只要您和您的客户都同意它，并且您的代码实现了它，您就很清楚了。

在您的方案中，DoD的度量标准可能是：“可以在开发人员便携式计算机上输入很少的内容来手动启动编译的程序”。对于国防部，这是完全可以接受的。每个人都会知道，该软件在面对现实世界时可能会立即失效，但是对于原型/概念验证来说可能就很好。

#8 楼

根据我的经验，无需进行单元测试就可以进行开发，就像在不看发动机或任何其他组件的情况下进行二手车测试一样。是的，您可能会花很长的时间，没有遇到任何问题，但是您对这辆车值得花钱有足够的信心吗？在您的开发周期中，对于一个较小的项目，可能就足以涵盖大部分问题，而无需明确编写测试。但是，以我的经验来看，仅凭这一点还不足以确保作为开发人员可以确保的最低生产问题。 />

在编码时不进行单元测试（不一定是TDD，而是在编码时仅测试很小的代码块）有两个问题。

通过“运行和“看到发生了什么”，您将系统视为“黑匣子”，通过UI（或从程序中获得的任何结果）评估其质量。

也许您编写了一段代码，然后尝试构建，然后重复进行，直到您摆脱了所有语法错误。然后尝试一些输入，看起来很有希望。但是随后您尝试其他方法，却不起作用-是时候进行调试了！

根据您的技能，这可能很有趣，就像整天解决难题一样。因此，您在某个函数中发现的这个小bug恰好在适当的条件下显现出来，但是潜在的问题是，这个小函数无法实现应有的功能。在编写函数时捕获这些函数中的错误，即使在非常罕见的情况下很难引发这些错误，这也使您的经理和利益相关者对代码充满信心。

它也是有效的-使用几个快速测试可以很容易地证明函数正在执行应做的事情。它还促进编写易于测试的代码，该代码通常具有尽可能少的状态，并且具有尽可能纯的功能。这些功能易于测试，您可以放心，它们将在所有条件下都能正常工作。但是，如果不执行自动化的单元+集成测试，则意味着您可能会在提交中遇到回归错误，并使重构代码或安全地引入更改变得更加困难。每次提交，它们都是绿色的，这增加了您对代码的信心。

重构代码也容易得多。如果您知道有自动集成测试可以告诉您某些问题，那么不需要重写应用程序的一部分就不会那么害怕。


其他类型的测试（功能测试，例如测试）用户故事或性能测试）在我看来似乎很明显地处于开发的各个阶段，并且您几乎无法争辩说它们可以在编程时隐式完成。

#9 楼

我碰到这个确切的问题令人惊讶。业务各个角落的人模棱两可地使用诸如“数据”和“测试”之类的术语，而他们自己却并没有真正理解他们在说出这些术语时的要求。作为概念上的证明，我们的开发计划可能不包括任何时期的正式功能测试（因为没有必要），回归测试（因为没有可比较的先前版本）或编写回归测试（因为没有

但是当然，这并不意味着我们从未真正运行过代码。基本的开发人员级别的测试是编程的固有部分。如果您从不“测试”您编写的内容，那么您实际上是盲目的编程。在最极端的情况下，这种方法将意味着甚至不检查您的代码是否已编译，以我的经验，第一次进行编译非常罕见。因此，显然，在宣布代码可以工作并可以进行演示之前，您将要对其代码进行大量测试。

但是管理人员并不总是能够做到这一点。您的项目经理会说“您为什么花时间在测试上？我拒绝了。”然后，当您决定“好吧，我不会将其视为'测试'，因为这只是基本的开发健全性检查”时，您的直属经理就想知道为什么（以及如何）根本没有进行任何测试。 />
至此，我发现最好通过句子来限定“测试”一词。像这样的东西：


我们还没有进行正式的测试运行（并且因为它是概念验证而没有计划进行测试），但是我的基本开发级别的测试表明它可以正常工作明天的演示足够好。


值得注意的是，由于您的直属经理要求您提供测试结果电子表格，因此对我来说，您实际上应该进行一些正式测试。在这种情况下，他实际上与项目经理存在分歧，您应该互相推荐他们，以弄清他们希望您的团队做什么。概念证明总是最终演变成真实的产品。管理总是通过使事情发生而破坏事情。如今，即使在概念验证上，我也尽量不走捷径，因为这是在产品的第一版上给自己承担大量技术债务的最佳方法。

#10 楼

手动测试是一个很大的领域，我将其细分为：


单元测试
用户使用基本功能是否可以达到目的？测试
相关服务和数据存储区是否已正确更新和通信？
性能测试
反应需要多长时间？可以同时支持多少用户（负载）
探索性测试
系统从真实用户的角度来看是否起作用？测试可以是手动或自动化的，领域和需求是相似的。

#11 楼

问题是：运行代码是否等同于测试？

如果这意味着启动代码并观察其运行并加载页面或初始屏幕，是的，它将被视为一项测试-如果可以，则进行冒烟测试。 >但是测试不只是烟雾测试。正如其他人提到的那样，您可以通过执行其他类型的测试来对项目表示公正，例如功能测试，甚至是非功能测试。有UI或API测试。根据软件开发人员需求或用户故事进行测试将是一个好地方。

从我收集的数据来看，该项目至少需要一位测试主管，snr测试分析师或更好的一位测试经理！然后，您将具有测试流程，缺陷管理，测试设计，测试分析，测试策略和测试结束。

#12 楼

您必须疯了才能配合“经理”的“测试”方法。我编写了许多复杂的代码，我当然可以推迟一段时间进行测试-在原型阶段，弄清需求，数据格式，类型规范等等，是对时间的更有效利用（可以说是）。测试不是万能的，它不能证明代码是经过精心设计或实施的，但是它确实达到了目的，尤其是在（例如）有多个项目追求类似问题空间，因此通过了大部分测试的情况下套件成为项目目标的目标（这是一种澄清哪些项目处于试验阶段，哪些接近可用）的方法。在设计自己的测试套件时（而不是使用预先建立的套件，例如将项目移植到新平台等），测试可以发送类似的信号-表示您的代码，类，类型，接口等足够清晰地建立起来，因此值得进行单元（和其他种类）测试。您的项目可能不在此阶段，可能是设计使然。在当前情况下，可能根本不需要进行测试。

但是，您不能使用英文单词“ testing”已超载这一事实来作为歪曲您的行为的借口。即使负责任的程序员有点适合“测试”一词，也没有专业的程序员会称其为“运行代码以确保其正常工作”。在软件开发环境中，没有人认为“测试”是指在学校参加测验。单词在上下文中具有含义，“测试”是指在使用上下文中特定的内容。如您所描述，将信息插入电子表格中是“测试”记录，这将是利用语言事故来达到邪恶或至少不负责任的目的，这在谈判和平时可能是必不可少的罪恶条约，但在计算机专业人员的绅士世界中却没有。 “利益相关者”不要改变词义。

作为一名程序员，我发现建议您“上一门课程”是令人反感的-如果有人需要进修课程，那就是您的经理。错误引用“ Come Out Ye Black and Tans”，“离开这里，带走您的血腥电子表格”。看来他在甩掉您自己的责任，以反击压力来证明测试已经完成。有一些专业标准比命令链更为重要，而您不能通过编造东西来避免它们。无论是您是经理人，还是他的老板，还是其他任何人，都必须说您作为开发人员必须遵守这些标准，没有人有权向您施加压力。我显然对您的工作场所知之甚少-您是否参加过工会等等-但您是在描述不容忍的虐待性治疗。

我希望您继续使用这样的论坛来描述情况，如果情况没有改善。越来越多的关于在专业环境中对程序员的不当对待的故事，通常是由主管提供的，这些主管在技术上没有足够的知识（我讨厌暗示这在某种程度上是失败的，但是缺乏必要的知识的确会引起问题。某人在权威位置上表现不合理）。这种事情掩盖了一个概念-不幸的是，因为它可能并不完全是错误的-IT世界是过度公民化和进步的。 （“任何时候有人打扰现状/所谓的自由主义者都会刺伤您的后背。”-黑色47 [感谢响应者观察到这些歌词的直接引述涉及令人反感的词- -在原始情况下是重点的一部分，但...]）作为程序员，我们需要更好的基础架构来承受这种待遇，而您的案例可以象征性地显示计算机专业人员社区越来越适应集体互助。支持，并且在要求理性，科学素养和尊重的工作场所方面更为激进。

“利益相关者”对他们（利润丰厚的）IT领域没有先验权利，而商业成功的特权是通过尊重编码人员和研究人员已获得的科学方法和知识而获得的。利益相关者（无论如何，在技术环境中）仅是因为开发人员同意生成代码而存在，而我们始终会临时这样做。听起来您正在和一些需要提醒的官僚打交道。

#13 楼

要添加所有答案和评论，我想向您展示有关Ad hoc测试的有趣文章。

#14 楼

当您使用诸如测试之类的非常笼统和通用的单词并尝试对其进行严格定义时，您将遇到那种“讨论”；）每个人的观点都值得尊重和考虑，并且通常有经验的基础。因此，向下移动以了解您是否在谈论以下内容：


测试正在编写的代码的代码
开发时进行手动测试
将单元测试编写为您开发了
写作集成测试
自动用户接受测试
手动用户接受测试

所有这些都可能是您的“测试”的一部分，但这取决于有关您的重要情况的详细信息，对您的公司有价值，并包含在当前的“测试”过程中。在同一页面上，并避免对[whatever]的定义进行假设和不必要的争论。