测试的本质是什么？

关于测试的本质是什么？

工作原因带过很多的软件项目，由于交付环节是最难的，所以，我也常常深夜思考的问题之一就是：到底测试的本质是什么？

我的浅薄理解

1、与客户需求严丝合缝

就算客户坚持他错误的需求观点，只要他愿意为此付出金钱、精力，那么软件测试标准就应该和客户的需求完全一致。尽管，我们在这个过程中可以提供很多合理化的建议。

2、固定的输入，就应该产生固定的输出结果

早些年，我还仅仅停留在了字面意思上。认为，这不就是天经地义的么？

当后来，项目引入了自动化测试，我稍微有些顿悟了。当项目产生需求变更，更改程序需要回归测试的时候，如何能够保证软件质量一如既往的不至于更差？简单有效的办法就是将所有正常的业务场景、业务流程全都回归测试一遍，但是，那需要耗费大量的人力物力。自动化测试就完美的诠释了固定输入-固定输出的理念，基于这一理念，我们有意识的在项目的每个阶段，都固定下来大量的测试用例，它们都有固定的业务场景、输入数据、输入条件、预期输出结果。这些测试用例借助自动化工具变成可以批量运行的任务，就能在程序变更时快速检测系统的犄角旮旯。

与固定输入不产生固定输出结果对应的其实是：往往每一轮软件测试，尽管测试细分场景完全一样，但是每个测试人员的输入不尽相同，导致输出结果需要人为去识别是否相同，但其实，这些类似的输入其实都应该成为一种标准的、固定的输入，节省下来的精力去设计更多的、更好的细分测试场景。

Tips：为什么说“自动化测试就完美的诠释了固定输入-固定输出的理念”

因为，如果没有自动化测试的出现，实际测试时无论如何要求测试人员，他们每一轮测试其实都不一样，完全只是沉淀了测试场景，而没有沉淀固定的输入-输出，尤其是：曾经某个软件阶段的输入-输出，历史阶段的输入-输出极其珍贵，因为当软件进入后期的时候，人们往往已经淡忘了历史阶段中的“诡异出错场景”，而仅仅会根据常识来设计测试用例，从而导致了深层次的软件缺陷被永久的留在了软件中。

3、软件测试就是要避免测试工作的产生

我对于这句话直接就蒙圈了，软件测试不就是测试工作吗，怎么还要避免产生？

随着软件建设越往后发展，测试工作量就会翻倍递增，但是真正对软件有产出的其实应该是开发人员（当然那只是理想情况，就是开发人员的软件写的足够完美，一个缺陷都没有），但是测试工作占所有工作的比重、人员投入越来越高（当然，不乏有只加工作量不加人的血汗工厂做法），意味着产出软件产品的就会下降，那么软件产出率就会变低。

假设，现在的软件测试工作，能够为将来减少大量的测试，或者最基本的，已经测试过的绝大部分业务场景、流程都不需要在未来进行测试了，那软件测试就做到了避免测试工作的产生。

这个假设，当然也要依赖架构、开发经验、市场等多方面的努力。

让软件做到，改哪里只测试哪里即可。才是测试要达到的目的，这样的话，软件测试的工作量几乎是恒定的，不会越往后，压力越大、工作量越重。