测试小故事67：错误

  错误，指不正确、与客观事实不符。

  系统错误，指与系统需求描述或客户要求不一致。

  最近时常想一句关于系统错误的描述：系统错误有两种表现形式，明显找不到错误 和 找不到明显的错误。

  差别在哪？修饰，对错误的修饰：错误 和 明显的错误。

  最近一些项目的测试工作有点特别：部门新接手的维护型外包项目，项目本身没有完整的需求规格说明，变更内容不多，变更范围仅限于变更点的说明，要求测试人员对变更项进行测试。负责开发的人扔下一句话，测试简单点点没有错误就好了。

  什么叫“简单点点”？什么叫“没有错误”？

  添加的输入框可以正常输入和显示？更改的提交按钮可以正确提交？还是看看整个系统页面看起来一切正常？

  想来，这“简单点点”产生了“没有错误”的结论，是“没有明显的错误”，也就是所提到的“找不到明显的错误”。

  当然，仍可以认为是“找不到错误”，只是这里的错误在一系列特殊要求之下深埋在系统之中，显的并不是那么明显。

  系统错误的不明显可能由两个方面造成。

  1）系统功能开发者自身将错误埋的很深。

     这个问题可能是由于系统架构设计复杂、各功能部分接口定义和实现不清晰，使得系统错误深深的埋在了底层，发现起来相对较难；其次问题可能是由于开发者自身对于功能的理解不深、对实现的技术细节不能很好的掌握造成的，业务细节处理不到位，技术细节和异常处理不清晰。

     所有的这些都使得系统错误深深的埋藏于系统内部，无论是架构人员、开发人员、测试人员和业务人员都很难找到这些“不明显的错误”，看似一切正常，一但错误暴发就会引起系统大范围的异常（最常见的就是内存缓慢泄露）。

  2）系统功能测试者的测试工作做的不充分。

     这个问题可能是由于测试本身对于系统需求理解不充分、对于系统所涉及的专业领域知识不了解，因此测试深度不够，只是发现了表层的错误，使得系统看起来一切正常，没有明显的错误。

     或者说系统的可测试性不高。

  问题有了，如何解决？

  1）从设计做起，厘清关系，降低系统设计的复杂度（业务复杂并不代表设计也要复杂），高内聚低偶合；

  2）从开发做起，加强功能细节的了解，加强所需开发技能的理解，降低由于技术本身造成的内部错误；

  3）从测试做起，加强系统的业务学习，加强对测试设计、开发的产出物测试力度，增强测试的深度和广度，不仅仅是UI层的测试，更多的是做些底层的UNIT和集成测试，从最基础部分保证系统的正确性，减少系统隐患。

  质量不是某个人或是某些人的事，所有参与者的高质量意识才能最终合力生成高质量的产品。

  防患于未燃，如果做不到明显没有错误，那么就让错误从底层浮上来，让系统更易测，让错误显现出来，避免看似天下太平，实则危机四伏。