正常系统的可测试性通常在于是否能发现错误，而微服务系统架构通常是长期运营的分布式系统，而对于该系统来说，分布式会带来问题已发现但不易解决，因为消息链长且位于地理位置不同，架构不同的子系统上，发生错误后无法定位错误发生地点，如果在错误发生后有错误发生点向上提交错误信息的话会容易导致线路拥堵，且并不是所有的错误发生根本原因都在终点上。再者分布式系统会面临网络通信带来的问题，而无法单一的从错误反馈上看出究竟是哪一方发生的错误，例如用户发出请求后，系统返回连接超时，超时的原因并不一定是网络问题，也可能是接收节点进程死锁或其他原因导致无法反馈信息，这时即使测试程序反映出错误，我们也无法做出判断，而这两方面涉及的检查方向又不一样，贸然检查会导致成本上升以及有可能无功而返。因此对于微服务系统架构，定位错误并纠错显然更重要。
完备的日志系统可以将错误发生的轨迹可视化，我们可以在每个节点设置一个标志量，用于显式开启详细日志服务，当执行测试时会提醒每个节点开启日志服务，节点在记录日志后将日志和节点本身要传输的信息包装在一起，加上节点在所处架构的位置信息如位于哪一层等以便测试程序将日志分类管理以及时间戳等信息以便日志的排序，日志的跳数随着消息的传递递增，在包装后发送给测试程序，测试程序根据层数将日志分类，按时间戳进行排序，测试程序会根据日志的跳数来检查未成功发送日志的节点并要求其重新发送直到跳数连续为止。
测试程序需要为测试人员提供不同视图，例如网络方面排查时，严格按时间戳排序，并根据日志字段筛选出负责分组转发的节点呈现出来；数据库方面，根据系统元数据库中各个异构系统数据库数据的联系，将相关联的数据所在节点的日志聚集在一起，以便检查数据一致性。业务方面，将只留下有处理功能的节点的日志，并提供节点传输的信息以便测试人员分析流程中间值的变化来判断逻辑是否出错，以及涉及多个异构系统时，结果是否符合要求。