探索性测试 VS 精益测试

01 探索性测试

如何理解探索性测试

举个例子，为了7月底的这次经验交流会，ThoughtWorks计划专门为参会人员定制一款马克杯。供应商设计并研发好了样品，提供给我们验收。

对于这个例子，我们如何运用探索性测试验收呢p>

和传统测试一样，首先需要根据需求设计测试、然后逐一执行。然而，探索性测试到这里并没有结束。

• 在测试执行过程中，我们有了新的发现，进而引发出一些思考：

• • 现象：盛完茶水，杯子里好多茶渍

  • 思考：能不能刷干净p>

• 与此同时，我们忽然想到一些特殊的场景：

• • 上班的时候，我常常要端着杯子辗转于各个会议室，会一开就是一个多小时。250ml容量够不够盖子，水会不会容易撒出来p>

这些过程中想到的点都还没有得到验证，因此需要将其添加到测试用例中。与传统测试不同的是，设计用例的时候，我们并不一定清楚期待结果，而是要根据实际发生的结果去判断能否接受。比如，盛完茶水，杯子里好多茶渍，可是稍微一刷便焕然一新，那么就是可接受的结果。而如果，我使劲了浑身解数，茶渍依然纹丝不动，那这个马克杯只能当做一次性的了，着实可惜、不可接受。而对于第二个特殊场景，250ml容量的确不够，没有盖子，水也的确会容易洒出来。可它们真的是问题吗用户的特殊需求，换个容量大一点儿的、带盖子的杯子，或许才是解决问题的最佳选择。

相比之下，传统测试的过程是线性发生的，“先设计、再测试”，很多公司甚至要求在设计用例的时候就达到100%覆盖。而探索性测试是环状的，主张学习，强调同时展开测试设计、执行、并从结果中获得反馈，从而持续优化测试。

产品分解之后，究竟该如何测试呢p>

• 商业区：用户花钱买软件就是因为软件的特性使得他们的业务得以完成。商业区测试类型着重于测试软件的主要特性，因此，需要频繁地进行回归测试，以持续保证这些主要特性的可用性。由于具有很高的重复性，“商业区”的测试将是自动化测试关注的重点

• 旅游区：对于软件，有些特性对新用户更有吸引力。这一点也涉及到部分用户权限的测试

• 历史区：软件也一样具有前版本的历史遗留代码，这个区域的测试目的就是测试遗留代码和遗留缺陷。这一点在遗留系统改造项目中体现的尤为明显。”新开发特性不影响原有特性”将成为测试重点

• 旅馆区：当软件“休息”时，它实际上还是非常忙碌的。旅馆区模型关注的是一些辅助功能，比如软件后台运行等

• 娱乐区：对于软件，比如一个购物 站，商业区是搜索商品、加入购物车、生成订单、付款等，而其娱乐区就是指漂亮美观的UI、友好的用户界面等。这就需要关注到用户体验和兼容性测试

• 破旧区：不同于旅游，软件的破旧区可能存在严重的缺陷、安全及性能问题。这部分可能是软件的重灾区，需要关注异常测试、性能测试和安全测试

运用探索性测试指导自动化测试

自动化测试，是指将人为驱动的测试行为转化成机器、工具或者代码执行的一种测试方法。

我们通常将需求明确的、业务稳定的、需要重复回归测试的部分用自动化测试来实现；而将需求不明确、变动频繁的、无需重复测试的、或者需要日志等特殊形式验证结果的部分，配合探索性测试思路，通过手工测试来完成。

但自动化测试与手工测试并不是相互割裂的，而存在一个相互转化的过程。仍然以上面定制的马克杯为例：

02 精益测试

“精益测试”是ThoughtWorks 资深 QA 咨询师林冰玉提出的概念，她曾专门写过一篇博客《精益测试》，也讲过直播课程。

而我，不仅是知识的搬运工，更希望阐述一些自己对于“精益测试”的理解。

如何理解精益测试

“精益测试”的理念是将“精益生产”与“测试”相结合。

测试要做到精益，就是要减少测试中的浪费，不能一味的追求测试覆盖率，大而全的测试覆盖本身就是一种浪费。因此，精益测试并不是一种具体的测试方法，而是一种思维，其价值主要是为了帮助团队制定合适的测试策略，让测试更有效。

对于“精益测试”的定义，我们应该这样理解：

对能体现业务价值的点，做到有效的测试覆盖，减少浪费，从而以尽量少的成本交付高质量的软件。

测试如何才能做到精益，如何才能避免浪费呢p>

这就不得不提到精益测试的核心原则，我们将其总结为TAT：适时（Time）、适量（Amount）、精准（Target）。

软件分层架构将软件分成若干个水平层，每一层都有清晰的分工，不需要知道其他层的细节。层与层之间通过接口通信。

• 表现层（Presentation Layer）：用户界面，负责视觉和用户互动

• 业务层（Business Layer）：实现业务逻辑

• 持久层（Persistence Layer）：提供数据，SQL 语句就放在这一层

• 数据库（Database Layer） ：保存数据

用户的请求依次通过这四层的处理，不能跳过其中任何一层。

软件分层架构为软件开发带来一定的好处，比如，不同技能的程序员可以独立分工，负责不同层的开发，这就是为什么我们会有前端开发和后端开发等多种开发角色；开发顺序也不受限制、只需要在各个层完成独立开发之后进行集成。

既然每一层可以独立开发，就必然能够独立测试。其他层的接口如果已经完成，可以直接与其集成进行测试；如果尚未完成，也可以通过模拟来解决，这就是测试分层。

• 适时：就是指我们在完成每一层的代码开发之后，立即开始这一层的测试，而在完成每一层的集成之后，立即开始集成测试或端到端测试

• 适量：从业务逻辑层到表现层，随着测试的依赖越来越多、逻辑和数据越来越复杂，测试的成本会逐渐增高，测试进度也相对滞后，因此要尽可能对较细颗粒度的测试进行更高程度的覆盖，而不是每一层都追求100%覆盖

• 精准：越往底层的测试越接近代码，测试成本更低、执行速度更快、定位问题也更准确，但是不能突显出完整的价值链；越往上层的测试越接近业务，更能反应业务价值，但有着不够稳定、执行速度慢、问题定位难等不足。因此，要明确每一层的特点和测试目标，避免各层之间对相同的点进行重复测试，产生冗余。比如，一个用来做除法的功能，我们在接口测试中进行了分母为0的异常测试，就没有必要在基于UI的端到端测试中重新测试一遍

虽然理想情况下，我们希望分层测试的覆盖情况呈金字塔结构，但随着技术架构、系统特点、质量要求、团队技能水平等因素的不同，每种测试的比例也不尽相同，它很有可能呈现出蜂巢等其它结构。因此，需要根据项目具体情况，来确定每层测试的比例。

03 总结

探索性测试和精益测试都可以被认为是一种测试思想，而并非某一种具体的测试项目或测试技术。既然是思想，就完全可以被应用于编写测试策略、设计自动化测试、或者进行功能测试、性能测试、兼容性测试等某一种具体的测试项中。

探索性测试帮助测试人员发散和拓展思路，发现更多关于产品的质量问题。而精益测试恰好帮助其进行有效收敛，将测试做到适时、适量和精准，让测试做到恰到好处从而减少浪费。两者相辅相成、起到良好的杠杆作用。

在我看来，对于To B类型的产品，系统用户只有几个人，他们更关心的是产品能不能帮助他完成业务、从而来带利润。他们对产品质量的容忍性高、对系统易用性的诉求也不够强烈。因此，运用精益测试，有助于更高效地交付产品。

而对于To C类的产品，用户往往千奇百怪，诉求也天马行空，产品中任何一个不太好用的点都可能让其失去一个用户。因此，To C类产品就是探索性测试大展身手的时候了。

对于探索性测试和精益测试，你怎么看呢留言给我！

延伸阅读：

• 《“探索性测试”在敏捷项目中的运用》

• 《精益测试》

• 《ThoughWorks敏捷测试第三讲：精益测试》(https://app.ma.scrmtech.com/meetings-api/sapIndex/SapSourceData_uid=7019_1254&sid=16238&source=2&pf_type=3&channel_id=779&channel_name=insights&tag_id=7066157a5b2dd0c0&appid=wx4bd00f95dd7c7ca1)

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92581 人正在系统学习中