本次主要学习了《软件测试》中的黑盒测试和代码检查。

黑盒测试

一、软件测试的两种基本方法（通过测试和失败测试）

   通过测试和失败测试的介绍
      通过测试实际上是确认软件至少能做什么，而失败测试可以测试出软件的上限。
      在设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。不必费力去区分它们，重要的是设法迫使指定的错误提示信息出现，设计迫使未提到的错误暴露出来。最终可以在通过测试和失败测试中都找到软件缺陷。

   思考：一个软件在发布之前首先应该保证的是通过测试，通过通过测试之后可以保证这个软件的基本功能是可以正常使用的。然后再进行失败测试，测试软件在极限数据等条件下的运行状态。我的观点同书上一致，无需特意去区分通过测试和失败测试，或许失败测试的前提条件就是通过测试。

二、等价分配

      1.在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组，这些组就是等价区间。
      2.如果为了减少测试案例的数量过度进行等价分配，测试时漏掉软件缺陷的风险就会增加。

   思考：不同测试人员对同一个复杂程序划分等价区间可能是不同的，只要他们划分的等价区间足以覆盖测试对象，这个等价区间的划分就是正确的。

三、数据测试

      1.软件由两个基本要素组成：数据和程序；其中数据包括键盘输入、鼠标点击、磁盘文件、打印输出等；程序是指可执行的流程、转换、逻辑和运算。
      2.边界值测试
             2.1 边界条件是指软件计划的操作界限所在的边缘条件。
             2.2 如果要选择在等价分配中包含哪些数据，就根据边界来选择。
             2.3 提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。
             2.4 在软件的每一个部分不断寻找边界是极为重要的，更多的边界将会被发现，从而找出更多软件缺陷。
             2.5 一定要考虑建立处理默认值、空白、空值、零值或者无输入等条件的等价区间。
      3.垃圾数据的测试，包括非法、错误、不正确和垃圾数据。

   思考：书中提到次边界值，也就是寻找除了普通边界条件的其他边界条件，我认为在测试时还是非常有必要的。换句话说，我想作者可能想告诉我们，在测试时不仅仅只依赖理论还要有自己的思考。还有最后的垃圾数据测试，也是在传递发挥软件测试人员创造力去测试的观点。

四、状态测试

      1.软件的状态是指软件当前所处的情况或者模式，软件测试人员比较测试程序的状态及其转换。
      2.测试软件的逻辑流程，在选项分支过多时，运用等价分配技术选择状态和分支。
      3.建立状态转换图，状态转换图如下

      4.减少要测试的状态及转换的数量。
             4.1 每种状态至少访问一次。
             4.2 测试看起来最常见最普遍的状态转换。
             4.3 测试状态之间最不常用的分支。
             4.4 测试所有错误状态及其返回值。
             4.5 测试随机状态转换。

   思考：我认为软件状态的测试工程量是巨大的，这个时候就需要发挥测试人员的智慧去减少不必要的状态测试

五、失败状态测试

      1.竞争条件和时序错乱。竞争条件测试难以设计，最好是首先仔细查看状态转换图的每一个状态，以找出哪些外部影响会中断该状态。
      2.重复、压迫和重负测试。时间也是一种重负测试；重复、压迫和重负测试应联合使用，同时进行。

   思考：书中将错误提示等状态归类于状态测试，而失败状态测试仅说明了竞争条件、时序错乱、重复、压迫和重负测试。因此我认为失败状态测试应该发生在保证软件功能正常的情况下。（大公司分功明确，当我没说哈）

六、其他黑盒测试

      1.像新（愚笨）用户那样去使用软件，尝试一些令人意想不到的操作。
      2.在已经找到软件缺陷的地方再找找，开发人员的代码也会收到心情等因素的印象，如果某一块地方 bug 较多，可能说明些这块代码时开发人员状态不佳，大概率影藏着其他的 bug。
      3.凭借经验、直觉和预感。

   思考：当测试人员出现一些令人意想不到的操作时，难免会被开发/产品说用户是不会这么做的，但是我觉得这是用户一定会做的，既然操作存在，那就必然会有一个用户去触发这个操作；对于经验这一方面，因为我来说目前还接触不到这个玄妙的境界，希望大佬可以说说 hh。

代码检查

一、静态白盒测试：检查设计和代码

      1.静态白盒测试的首要任务是尽早发现软件缺陷，以找出动态黑盒测试难以揭示或遇到的软件缺陷。
      2.静态白盒测试还可以为黑盒测试提供思路。

   思考：白盒测试在好多公司都没有展开，我想一个原因是目前测试行业的许多小伙伴没有阅读代码的能力，还有一个原因就是许多中小公司觉得白盒测试没有必要。

二、正式审查

      1.确定问题，确定问题并指出问题时，要保留个人情绪化，全部的批评应该直指代码，而不是其创建者。
      2.遵守规则，审查代码要遵守一套固定的规则。
      3.准备，每一个合作者都应该为审查做准备。
      4.编写报告，审查小组必须做出总结审查结果的书面报告，并使报告便于开发小组的成员使用。
      5.审查内容
             5.1 编码标准和规范。
             5.2 数据引用错误，使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录导致的软件缺陷。
             5.3 数据声明错误，不正确地声明或使用变量和常量。
             5.4 计算错误，计算无法得到预期结果。
             5.5 比较错误，比较和判断错误很可能是边界条件问题。
             5.6 控制流程错误，原因是编程语言中循环等控制结构未按预期方式工资。
             5.7 子程序参数错误，子程序不正确地传递数据。
             5.8 输入/输出错误，包括文件读取、接收键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
             5.9 其他检查，包括编码方式、兼容性、软件的警告和提示信息等内容。

   思考：白盒测试是一项需要大量准备工作才能有成效的任务，软件测试人员也需要提高自己的编程素养。

可能有些地方缺少深入思考，或者观点是错误的，望大佬指出！感激不尽！！！