质量保证工程师如何测试计算？

#1 楼

所有工程师（应用程序和自动化）都通过提供已知输入和对预期输出的了解来测试算法，以执行验证。
验证值可以通过手动计算和/或不同算法来找到。

如果算法和手动计算方法未知，则另一种方法是BDD（行为驱动开发）。什么公式适用于“ 1”。然后是“ 2”。然后是“ 3”，依此类推。这确实是假设您至少可以手动计算那些值。在某个时候，您发出的呼叫看起来足够可靠，并且经过足够的测试。这是一种使用测试来发现设计的方法。
如果您无法确定给定简单输入即可得出的公式，例如“ 1”，则可能有其他问题。

#2 楼

我们不能依靠开发人员的代码来进行复杂的计算，即使QA开发了一种计算方法，我们又如何依靠它呢？
因为QA可能也会犯错。


您是否尝试过测试驱动开发？一次一次的计算行为？计算由多个步骤组成。例如，(1 + 2) / 3 = 1包含两个步骤，您可以分别对其进行测试。例如。分解计算并在较小的部分进行测试。进行一些端到端测试。

分步进行时很难出错。

#3 楼

您的问题明确假设质量保证必须100％可靠才能有用。这是不正确的，恐怕表明您严重误解了质量检查的目的。


，因为即使质量检查也可能会犯错误。


当然可以。优良作法是考虑将检查和测试同样容易出错。因此，您不会盲目地进行审核者提出的更改，也不会盲目地进行更改以使测试通过，因为两者都可能是错误的。

质量检查的目的是提供辩护深入。更多地关注问题，将更好地对其进行测试。最初的设计师通常对设计投入太多，无法在盒子外面看，并且倾向于根据他们所知道的功能进行测试，而独立工程师可以将其视为黑盒，并在没有先入为主的情况下针对要求进行测试。这也可能会暴露出含糊不清的要求问题，在这些问题中，设计人员和测试人员都可以“正确”地进行解释，但得出的结果仍然相互矛盾。

质量检查部门不可能保证存在在代码中没有错误。要清楚的是，这不仅不切实际，而且在数学上实际上是不可能的。 （如果需要证明，请阅读暂停问题。）QA可以做的是运行一组合理的测试，这些测试将在合理的操作条件范围内使用代码。测试越详细，就越有可能找到任何剩余的错误，而且花费也更多。根据软件的安全性，诸如DO-178B之类的开发标准通常要求进行所需的测试级别。

在1980年代和1990年代，学术界强烈使用正式规范，因为人们相信将设计转化为代码的过程是造成错误的重要原因。正式的规范语言/过程旨在允许生成明确无误的正确的测试用例，因此可以用来按照您想要的方式来验证可能有故障的代码。正如您可能看到的（但当时显然不是计算机科学的“专家”），正式的规范因此成为需求的第二种实现，因此同样容易在实现中包含错误。业界发现，实际上编码过程相对健壮，正常的质量检查过程很可能会遇到编码错误。事实证明，最严重的问题与不正确或模棱两可的要求有关，而这些要求固有地无法通过任何技术过程来解决。当时，从事正式规范领域的大多数人事后都认为这是死胡同。

作为超越质量保证的一步...一些与安全相关的系统使用冗余，其中两个（或多个） ）控制系统是由独立的非沟通团队制作的。从设计到质量检查的所有步骤均针对每个系统分别执行。尽管两个系统可能仍然包含错误，但它们极不可能都包含相同的错误，因此导致一个控制器行为异常的情况不会影响其他控制器。无论故障是由于编码错误还是对要求的不同解释，一个控制器仍将正确运行，并且整个系统旨在确保在发生这种情况时安全运行。这说明了安全工程的另一原理-假设将发生故障，并弄清楚如何在合理可能的范围内使系统整体上对该故障具有鲁棒性。

#4 楼

每种情况都不同，但是您可以测试以下几项：

正确的公式
首先要检查的是规范是否确实进行了正确的计算。在科学中，单位检查就是一个例子：将小时数除以米不会得到每秒的米数。同行评审是进行这些检查的好方法。

正确的答案
一种方法是在其他程序中使用输入->输出创建表，例如使用excel，然后进行比较反对这些价值观。使用典型输入值和非典型值。既要考虑算法本身，又要寻找实现，这是一个好主意，我倾向于称之为关键点，并围绕这些点进行额外的测试。一个非常接近零的除法就是一个例子。

输入超出范围
在计算机中，算法总是对输入值的可接受范围做出假设。您可以发送整数，但不接受负值（或非常大的值，...）。边界上和边界外的值（例如最大整数值）应始终进行测试。以我的经验，如果没有对允许范围的明确描述，计算很可能最终会失败。当值超出范围时，计算应以“设计的”方式进行。

所需的精度
在算法或计算中，除非非常小心，否则您很容易降低精度。也许您使用单精度浮点数进行计算，但实际上它需要两倍（或更多）才能给出正确的答案。有时可以猜到，例如将很小的值添加到很大的值时或除以接近bero的值时。

运行时间
Newton-Raphston说，某些算法应该收敛到一个值。但这绝对确定吗？是否存在算法无法收敛或收敛非常缓慢的情况？应该对此进行验证，并且实现应该对运行时行为有一定的保证。

#5 楼

质量保证通常采取尝试与被测功能执行相同操作的形式，但采取的方式不同。在硬接线或易于跟踪的情况下，简单的健全性检查通常会发现错误。从某种意义上说，这与确认实验结果是一回事：讲述相同故事的更多样本，不同偏倚的样本证实了这一结论并建立了信心。

拿几个玻璃纤维网状窗纱，每个有几个较大的孔，并将它们彼此重叠。接管随机的方向，并提供足够的屏幕，很可能会始终出现很少或没有孔或间隙。
将其视为像费马概率素数检验一样的筛子。错误随着每个新的正交问题呈指数下降。实际上，我们的偏见趋于一致，而不是完全不一样，因此投资回报率不及理论上的最大值。

自动化的一个例子可能是对一种算法，并针对解决同一问题的天真的实现生成的样本进行点测试。天真的实现尽管效率低下，但总是总是更简单，因此可以认为比优化实现的范围更可靠。

由于人为错误，不能保证凡人的质量保证计划是完美的，有或没有自动化。

#6 楼

2 + 2 =4。“保持愚蠢简单”。


无论使用哪种方法或计算的复杂程度，恕我直言，最简单，最有效的方法从外部文件读取输入和对应的输出作为硬编码值。

可以从数学角度考虑任何复杂的计算，这只是将一组输入值映射到输出值的功能。

我处在完全相同的情况下。一旦业务手动准备好并与所有主要复杂场景共享一个excel给整个Dev / qa团队，计算这些复杂值就不是一个挑战。真正的问题是在测试中就地计算它们代码可能会随着时间而改变和中断。

#7 楼

当然，您应该进行一些基本的检查，但是，即使没有准确指出错误的确切位置，通常也有很多更强大的测试可以揭示某个错误。

例如，迭代算法应该收敛以数学所预测的正确速度-“收敛速度快于预期”和“速度太慢”一样错误，除非您可以解释原因。

在我自己的固体力学和动力学领域，可以执行许多“自检”测试，因为计算机模型必须使用某些确定的坐标系来构建，但是要对物理对象进行建模对此一无所知。因此，如果结果取决于所使用的坐标系，则可以保证它们是错误的。

这样的测试非常强大，因为您可以创建一个完全“任意”的测试数据集，而在这里不可能手工检查结果或与发布的数据进行比较，并且然后以多种不同方式“随机”（自动）转换输入数据集，所有方式都应产生相同的结果。

当然，这种类型的测试并不一定会捕获重大错误（或恶意程序员），而创建一个函数，无论输入内容如何，​​该函数始终返回相同的值，等等-但是在这里进行代码审查而不是测试停止这种事情。

另一个重要的设计原则是使用可以测试的算法！这适用于系统设计和实施的所有级别。优秀的工程师在设计任何东西时，不仅要在计算机软件上都做到这一点。

这些只是非专业人员应该理解的一些例子-类似的数学算法测试方法可以比那些更深入地研究比较琐碎的例子。

#8 楼

对于诸如存储过程之类的东西，我将使用合同测试方法，这将智能地改变一组输入和输出对。您需要专注于测试过程的特定效果，而不是隐含SQL怪癖的方式。

对于诸如带有大量可变参数的函数之类的东西，应该使用属性测试，这是您尝试的地方运行所有有意义的输入组合，并观察某些属性（常量s或序列值）。例如。证明可接受的唯一性或熵。

一个好的测试计划应该包括多种方法，这些方法旨在在组合结果时增强对软件的信心。

#9 楼

使用算法/公式来计算结果不是问题，这被称为预言-可能具有不同的已知实现。您必须通过以下命令选择输入和输出：


等价类测试-具有相同输出的输入集
边界值分析-上面选择值的组，其中输出更改