软件测试的艺术

软件测试：
        软件测试，是一个过程或一系列过程．用来确认计算机代码完成了其应该完成的功能不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。更准确的说，“测试是为发现错误而执行程序的过程”。

软件测试的重要原则：

用于代码检查错误列表：

        主要有八种：数据引用错误、数据声明错误、数据运算错误、数据比较错误、控制流程错误、接口错误、输入输出错误、其他检查；        

测试方法：

        等价类划分：将程序所有可能的输入数据(有效的和无效的)划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,测试用例由有效等价类和无效等价类的代表组成,从而保证测试用例具有完整性和代表性。         边界值分析：是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

        因果图分析：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），可以通过因果图转换为定表，从而设计相应的测试用例。
        错误测试：指接到具体的程序之后，他们利用直觉和经验猜测出错的可能类型， 然后编写测试用例来暴露这些错误。

合理的测试策略：

        1. 如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。
        2. 在任何情况下都应使用边界值分析方法，边界值分析可以产生一系列补充的测试条件，但是，也正如“因果图分析”一节所述，多数甚至全部条件都可以被整合到因果图分析中。
        3. 应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
        4. 使用错误猜测技术增加更多的测试用例。
        5. 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增加足够数量的测试用例，以使覆盖准则得到满足。

        上述策略并不能保证可以发现所有的错误，但实践证明这是一个合理的折中方案。

好的测试计划应包括：

测试相关名词：

        black– box testing（黑盒测试）将程序视为一个整体、且忽略其内部结构的测试方法。单纯从软件的规格说明中获取测试数据。         bottom-up testing（自底向上的测试）增量模块测试的一种形式，首先测试底层模块，再测试调用模块等等。         boundary-value analysis（边界值分析），一种黑盒测试方法，重点在于程序输 t 入区间的边界区域。         branch coverage（分支覆盖）参见“判定覆盖”。         cause-effect graphing（因果图分析）使用简化的数字逻辑电路图（组合逻辑 络）辅助生成一组高效测试用例的技术。         code inspection（代码检查）一套供小组代码阅读的规程和错误检查枝术，作为检查错误的测试周期的一部分，通常使用一份常见错误的列表来对照代码。         condition coverage（条件覆盖）白盒测试的一项准则，要求编写足够数量的测试用例，确保将一个判断中的每个条件的所有可能的结果至少执行一次。         data-driven testing （数据驱动测试）参见“黑盒测试”。         decision/condition coverage （判定／条件覆盖）自盒测试的一项准则，要求编写足够数量的测试用例，确保将每个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。         decision coverage（判定覆盖）白盒测试的一项准则。要求编写足够数量的测试用例，确保每一个判断都至少有一个为真和为假的输出结果。         desk checking（桌面检查）一种将代码审查和走查技术结合起来，在用户桌面上执行程序的技术。         equivalence partitioning（等价类划分）一种黑盒测试技术，其中每个测试用例都必须体现尽可能多的不同的输入情况，以最大限度地减少全部用例的数量。应该尽量将程序输入范围划分为等价类，这样类中某个输入数据的测试结果等同于同类中所有输入数据的测试结果。         exhaustive input testing（穷举输入测试）黑盒测试的一项准则，通过将每个可能的输入条件都作为测试用例，尽量发现程序中的所有错误。         external specification（外部规格说明）从某个相关系统部件用户的角度对程序功能的精确描述。         facility testing（能力测试）系统测试的一种类型，判断目标文档提及的每一项能力（或功能）是否都实现了。不要混淆能力测试与功能测试。         function testing（功能测试）发现程序与其外部规格说明之间存在不一致的过程。         incremental testing（增量测试）模块测试的一种形式，将待测模块与已测模块组装在一起进行测试。         input/output testing（输入／输出测试）参见“，象盒泪 11 试”。         logical-driven testing（逻辑驱动测试）参见“白盒测试”。         multi-condition coverage（多重条件覆盖）白盒测试的一项准则，要求编写足够数量的测试用例，确保每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。         nonincremental testing（非增量测试）模块测试的一种形式，每个模块单独进行测试。         performance testing（性能测试）系统测试的一种形式，尽量证明程序不能满足特定的指标，如在特定负载和配置环境下的响应时间和吞吐率。         random-input testing（随机输入测试）在所有可能的输入值中随机选取一个子集来对程序进行测试的过程。
        security testing（安全性测试）系统测试的一种形式，用以考验程序或系统的安全保密机制。         stress testing（强度测试）系统测试的一种形式，使程序经受高负载或强度。高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。因特 应用系统通常需要进行强度测试，因为会有大量用户并发访问系统。         system testing（系统测试）高级测试的一种形式，将系统或程序与其初始目标进行比较。为了完成系统测试，需要一套书面的可度量的目标。         testing（测试）为了发现错误而执行程序（或具体的程序单元）的过程。top-down testing（自顶向下的测试）增量模块测试的一种形式，首先测试初始模块，再测试下一个子模块等等。         usability testing（易用性测试）系统测试的一种形式，测试程序的人机界面。通常要检查的部件包括界面布局、界面色彩、输出格式、输入字段、程序流程、拼写等等。         volume testing（容量测试）系统测试的一种形式，使用大容量的数据检验程序能否处理目标文档中规定数据容量。容量测试与强度测试并不相同。         walkthrough（走查）一套供小组代码阅读的规程和错误检查技术，作为检查错误的测试周期的一部分。通常一个小组的人起到“计算机”的作用，执行一个小的测试用例集。         white-box testing（白盒测试）一种检查程序内部结构的测试类型。