软件测试中，经常有一些表象会欺骗我们的判断，导致bug被遗漏，对个人和项目造成负面影响。我们需要避免这些陷阱，就需要深入测试。
测试用例的设计，加入正确验证步骤
关于测试用例，对于一条输入对应一条预期输出，作为测试员都能很好的理解，并考虑到。那么，一条用例执行完后，怎么去判断这条用例有执行成功呢？是根据前端的提示信息？如注册一个用户，当执行到最后提示注册成功，就说明注册通过？当然不是，往往界面上的提示信息，并不能说明问题。如笔者曾经做过的通信测试，当界面调用接口发送短信，返回信息提示短信发送成功，但实际用户根本没能收到。
在用例设计最后，加上一条正确的验证步骤判断用例是否执行通过，是判断一条用例设计是否有效的重要前提之一。通常验证步骤的设计可以遵循：
涉及数据操作的用例，应该增加一条数据执行结果的判断，即数据库中对应的表是否有执行该操作。如增、删、改操作。
涉及数据通信的用例，应该判断另一端是否有正确收到信息。如短信发送，邮件发送，接收者是否有正确收到信息。
涉及第三方接口或系统的用例，应该判断另一端是否有正确返回信息，系统并作出正确处理。如支付宝支付后，能正确执行回调程序，包括积分、金额、订单状态等的处理。
涉及集成多个子系统的系统业务操作，应该分别判断涉及每个子系统的信息是否有正确处理。如集成Ecshop商城，discuz论坛的综合商城，在其中一个子系统注册，其它子系统是否也能使用该注册账号登录。
能利用数据库，是我们深入测试的必备技能
可能一个软件在平时都能运行的很好，但当有一天需要做如数据迁移，过程中可能会出现各种各样的问题。如插入的数据，没有按照数据字典与数据库中的字段一一对应，或者数据库中使用了不存在于数据字典中的取值，最终导致数据迁移到另一张表中后，程序出现各种错误。又如CSDN安全门事件，如果测试员有去测试用户密码存放是否加密，然后指出安全风险，可能就会避免这样的重大事故。所以，要避免这些情况的发生，我们需要在测试中利用数据库，判断在执行插入等操作时，数据库中的数据是否有正确存放。
学会分析日志
前端看起来运行正确的功能或系统，现在应该认识到事实并不一定如此。而我们还应该学会查看分析日志，如tomcat日志、数据库日志或者程序打印的日志等，这样能更好的帮助我们深入判断。如笔者曾经在测一个软件时，发现在一定时间后MYSQL数据库会假死（即不会处理任何请求），只要重启则恢复正常。最后跟踪MySQL日志，发现因为订单做了缓存处理，但定时清理任务并没有生效，导致MySQL启用了大量的线程来处理这些缓存，直到挤满线程。
学会使用工具
孙悟空本领再高，也离不开金箍棒。同样，测试人员要深入测试也离不开工具的使用。如，我们发现Web页面运行似乎一切正常，但开启浏览器的开发调试工具的控制台（Console），可能就会发现各种js错误，或者请求错误，从而影响网页的加载速度。
测试需要有深度，这是很多研发组织提出的要求。但往往我们的测试人员可能会被一些表象所蒙蔽，最终导致bug的遗漏。所以要求我们要深入进去，更好的发现问题。