张近东代表建议大数据也要“改革开放”

图1：改正问题的成本。

单元测试：开发人员在单独进行模块级测试时一般是编写存根代码(stub code)取代余下的系统软硬件。在开发周期的这个环节，测试主要侧重于代码的逻辑性能。

通常，开发人员会分别使用某些平均值、高值或低值、以及某些超出范围的值(以测试代码的异常处理功能)进行测试。但这些基于“黑匣子”的测试仅能对模块中整个代码的一部分进行测试。

回归测试：测试不应是一劳永逸的。每次修改程序后都应该重新进行测试，以确保这些更改不会无意中“误伤”某些不相关的行为。

称为回归测试的这类测试，一般是通过测试脚本自动进行的。比如，如果你设计了一组100个输入/输出(I/O)测试，回归测试脚本会自动执行这100个测试，然后将输出与一组“黄金标准”输出进行对比。每次对代码的任何部分进行修改时，都要对包含被修改代码的整个程序运行整套回归测试程序包，以确保修改过程中不会“误伤”其余代码。

测试什么

因为没有一个实际的测试集可以证明一个程序是正确的，因此关键问题变成了哪个测试子集最有可能检测到最多的错误。选择合适的测试例程的问题被称为测试例程设计。虽然存在数十种测试案例的设计方法，但它们通常可归为两种截然不同的方法：功能测试和覆盖测试。

功能测试(也称为黑匣子测试)选择可评估实现与需求规格符合程度的测试。覆盖测试(也称为白匣子测试)选择可执行代码某些部分的测试例程。(过后，将详细讨论这两种方法。)

这两种测试都是对嵌入式设计进行严格测试所必需的。其中，覆盖测试表示代码的稳定性，所以这种测试是用于已经完成或将近完成的产品的。另一方面，可在编写要求文档时，同时编写功能测试。

事实上，从功能测试开始入手，可以最大限度地降低重复劳动和重写测试案例的工作。因此，在我看来，要先考虑功能测试。

每个人都同意先编写功能测试这个观点，有人认为，功能测试在系统集成阶段(而不是在单元测试时)最有用。以下是整合功能测试和覆盖测试方法的一个简单处理流程：

1．找出哪些功能未被功能测试完全覆盖。

2．找出每个功能的哪些部分没被执行。

3．找出需要哪些额外的覆盖测试。

4．运行新增的额外测试。

5．重复以上步骤。

何时停止测试？

最通用的停止标准(按可靠性排序)如下：

1．老板命令停止测试

2．新的测试周期找到的新缺陷少于X个

3．在没有发现任何新缺陷的情况下已经满足了某个覆盖阀限

无论你多么彻底地测试了程序，都无法保证找出所有缺陷。这引发了另一个有趣的问题：你可容忍多少缺陷？假设在极端软件压力测试过程中，你发现系统每进行大约20小时的测试就会锁定。你仔细地检查程序，但是仍无法找出这个错误的根源。这个时候你应该交付产品吗？

多少测试才“足够好”？这个我说不好。但遵循一些久经时间考验的规则总是好的：“如果方法Z预估Y行代码中的缺陷少于X个，那么就可放心地发布程序了。”也许有一天会出现这种标准。编程行业仍然相对年轻，还达不到类似建筑业那样的成熟度。

许多厚厚的建筑手册和大本规范是多年经验的结晶，它们可为建筑师、土木工程师和结构工程师提供按工期在预算内、建造一栋安全建筑所需的全部信息。偶尔虽仍会有建筑倒塌，但毕竟很少见。在编程行业制定出类似标准前，“多少测试才足够？”就是个主观判断问题。