前段时间写了一篇关于分层自动化测试的文章。有小伙伴感兴趣，今天刚好有些时间，便与他交流了一番。最大的收获在于“用例设计的分层”。前段时间评审用例的时候，受到特性树建设的启发，隐约中觉得我们的用例设计也需要像代码一样进行抽象层次的划分。当初有这样的想法大多源自于用例的复用，像写代码一样，减少用例中描述信息的重复度。大大精简和提升用例的复用度，保持用例的简单和有效。今天和小伙伴交流的时候，才发现原来这个就是“用例分层设计”的概念。从用例分层设计开始再考虑分层的自动化测试设计。结合我们的需求体系化，特性的抽象层次设计与用例的抽象层次设计可以相互参考，一一映射起来。最终实在整个体系化的特性的质量防护网。
以BS的架构来说，用例设计时至少可以分两层，一层是rest接口的用例，一层是UI的用例。两层用例可以独立的采用不同的自动化测试方案。
对于大型遗留系统来说，用例比较复杂。所以如果所有用例都位于同一个抽象层次上，必然导致用例的复杂度大大增加，各种排列组合场景，想要做到每一个用例的端到端自动化就变得非常困难。所以，可行的方案是化繁为简，把复杂的事情简单化，在不同的抽象层级去考虑较为简单的用例逻辑的自动化，也许是解决复杂场景下分层自动化测试的一个可能的解决方案。
这里在做用例设计的时候，如何去做分层？分为几层？与所在系统的业务复杂度有着极大的关系。一个很关键的点是，越靠近代码层级的用例反馈最快，但相对来说维护成本也较高，面向接口或用户也许需求的用例设计后期的变更可能性相对会小很多。
图片发自简书App
