为什么需要做单元黑盒测试？

   单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。
   那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。
   国内的测试通常现状:
    1) 没有详细规格说明书
    2）没有概要规格说明书
    3）甚至可以没有单元测试
    4) 就算有单元测试，达不到高质量的单元测试
       a.开发充分使用了白盒测试的测试用例设计方法（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖）吗？
       b.开发的单元测试代码写的正确吗？
       c.开发的式样理解正确吗？
    靠集成测试解决可行吗？不管怎样，集成测试将会抓住所有的Bug。这个论点不成立的原因在于规模越大的代码集成意味着复杂性就越高。如果软件的单元没有事先进行充分的测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。一旦软件可以运行了，开发人员又要面对这样的问题：在考虑软件全局复杂性的前提下对每个单元进行全面的测试。这是一件非常困难的事情，甚至在创造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。在软件集成阶段，对单元功能全面测试的复杂程度远远的超过独立进行的单元测试过程。最后的结果是测试将无法达到它所应该有的全面性。一些缺陷将被遗漏，并且很多Bug将被忽略过去。
    后果：一个特定的开发组织或软件应用系统的测试水平取决于对那些未发现的Bug的潜在后果的重视程度。这种后果的严重程度可以从一个Bug引起的小小的不便到发生多次的死机的情况。这种后果可能常常会被软件的开发人员所忽视（但是用户可不会这样），这种情况会长期的损害这些向用户提交带有Bug的软件的开发组织的信誉，并且会导致对未来的市场产生负面的影响。相反地，一个可靠的软件系统的良好的声誉将有助于一个开发组织获取未来的市场。在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。Bug发现的越晚，修改它所需的费用就越高，所以单元测试很重要。
    怎么办？是否可以在测试人员进行集成测试之前，做一下单元黑盒测试，我看了下定义，和灰盒测试最接近。
    灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。灰盒测试能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的黑盒。
    灰盒测试的灰度是按照整体特性信息和内部具体实现信息所占的比例来确定的,如果只能看到整体特性就变成黑盒测试,如果可以看到具体的内部就是白盒测试.趋于前者就深些,趋于后者就浅些.主要用于集成测试.
    好的灰盒测试同样需要有高质量的规格说明，好的详细设计书会帮你程序分析好，你只需要找出设计的错误和漏掉，再补充一些测试点就可以了。而没有详细设计书，我们测试可以将程序看作一个必须从外面进行分析的黑盒，考虑数据的抓取，考虑检查，考虑排他，考虑数据库处理等，开发人员能在没有详细设计的情况下写出代码，我想测试人员同样有能力在没有详细设计的情况下将程序的内部逻辑考虑清楚，写出针对的单元的测试用例。在整个系统的式样理解方面，往往很多有经验的测试人员比开发人员理解的更加深入，分析数据库比开发人员更加透彻。
    为什么很多公司不愿意写详细设计，现在很少公司愿意在写代码之前花时间和成本在写详细设计书上(之前非开发人员写详细设计，系统的质量会更有保证)，一般或者没有详细设计书，或者是开发写好代码，补写详细设计书。（补写的详细设计书实际上是开发人员将自己写代码的思路写下来，能很快翻译成伪代码，这样的详细设计书如果经过评审过对测试人员更有价值，但不管是否评审过，通常测试人员光看详细设计书就可能找出很多程序上的BUG）
    单元黑盒测试是使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法来书写测试用例，然后视情况需要使用白盒测试方法来设计补充测试用例。

    单元黑盒测试可能会有的测试点（以设计书为准）：
3.1 画面进入的前置画面有哪些。
3.2 画面进入时是否做了权限检查。如何做权限检查。
3.3 画面进入时做了哪些数据处理。（新增、修改、删除、查询都有可能。查询是最常见的，需要考虑DB异常的情况）
比如一览的数据怎么抓，DROPDOWNLIST中数据怎么抓，将SQL文写出来，包括抓取顺序。
3.4 画面进入后，初期化判定是否正确。（关注各项目的初期值、列表值、显示顺序、操作制御）
3.5 点击画面上各按钮、链接等可操作控件后，有哪些业务或数据处理。
  通常点“登录”或“修改”按钮，需要关注：
画面项目哪些需要做必须入力、类型检查、位数检查、关联项目检查等。
“登录”或“修改”时是否需要弹出确认对话框。
“登录”或“修改”时是否需要做同名判断、存在性判断等判断。
“修改”时是否需要做排他检查，修改的数据已经被其他人修改或其他人删除各是怎样的处理。
“登录”或“修改”时的数据处理是否正确。（新增、修改、删除、查询都有可能。此处新增、修改是最常见的，需要考虑DB异常的情况）。
“登录”或“修改”完后画面的处理。如跳转到某画面，向该画面传的参数是否正确。点该画面的“返回”按钮，是否能正常返回到本画面，并保持本画面的信息等。
“登录”或“修改”完后是否向服务器端删除、生成或修改某些文件。
  注意：我们除了应该判断插入值，更新值，删除数据是否正确，还应该判断更新条件、删除条件是否正确，不应该更新的数据和字段是否更新了，不应该删除的数据是否删除了。有些人会说，不需要看数据库，做完某操作，可以再看画面上的值是否正确，可是有很多数据库的值在当前画面是不表示的。
3.6  用例中不仅关注错误信息，也要关注弹出的确认信息。
3.7 有些画面字段间会有连动处理。这也是关注点。
3.8 点击画面上“查询”按钮，具体的查询条件需判断。
例如：我们会写“输入查询条件员工号，且该员工存在于数据库中，对应的员工信息结果出现在页面底部列表中。”
以上写法的问题，有些取得条件中的语句和画面上的输入值不对应。比如只能抓用户状态为0：正常、审核状态为1：审核通过的数据，按照该写法是没有写明的，也许就作为BUG流出了。
   如果是个首页画面，各一览信息是从数据库中取得，你不清楚具体的取得条件，不写或者就通过简单的语言描述，就能使测试清楚数据是怎么取得吗？这些地方都很有可能存在BUG的。
3.9 有些功能模块没有画面，是一个批处理程序实现的。通常关注业务或数据处理。用例写法和画面上点击某按钮、链接类似。
3.10 关注数据库处理的时间点.如果我们每一个操作，数据库做了什么处理都能够做判断，就不会出现因数据库处理的时间点不对，留出的BUG.

举例说明：

1）订购流程画面输入优惠券，点“使用”按钮，再点“确定支付”按钮，检查优惠券是否已经被使用，什么时候做？
      如点“使用”按钮时，做优惠券是否已经被使用的检查，点“确定支付”按钮不做，由于点“使用”和点“确定支付”有时间差，所以已经被使用的检查没有被封住，应该2个地方都做。
2）****网可以使用金币优惠购买商品。比如扣除7金币，可以用20元的价格买原价98元的包。
在购买流程中，第一步扣了7金币，下一步下一步过程中，出现浏览器打不开等异常情况，没有买成。但是7金币已经被扣了。浏览器打不开等异常情况解除后，因为剩余的金币不够7金币，我的商品没有购买成。
问题是扣7金币得时间点不对，应该在购买成功的同时，做扣7金币的操作。
3）点“删除“等按钮，弹出确认对话框，到底是确认对话框时做排他检查还是确认对话框点“确定”按钮时，做排他检查。显然确认对话框点“确定”按钮时，做排他检查比较合适。如果弹出确认对话框时做，弹出确认对话框和确认对话框点“确定”按钮有时间差，达不到排他的目的。