分层测试_基本思想

按照V模型进行划分层次：

单元测试

模块测试又称组建测试，集成测试

系统测试

 

unit层的测试对象是函数或方法；

service层的测试对象是模块和接口；

UI层的主要测试对象是展示和交互

 

 

unit层的测试策略：

1、代码走查：开发人员自己检查自己的代码

2、代码评审code review：开发团队组织评审会，应避免走马观花，应注重效率

3、单元测试：自动化单元测试，编写测试代码或使用测试工具，缺点：入门门槛高，没有好的实践方法（覆盖率和编写标准），则可能无法推行，最终沦为鸡肋或是诟病。优点能今早的执行，降低测试成本，复用性好，可反复执行

 

 

service层的测试策略：

自动化的组件测试，

自动化的集成测试

自动化的API测试

与单元测试比较：运行速度慢，测试环境搭建困难，case数量较少，

 

 

UI层的测试策略：

手工测试：纯手工测试执行速度慢，无法重复使用

自动化测试：稳定模块

与其它层面的测试比较：自动化开发难度大，运行速度慢，测试环境搭建困难

 

对应自动化测试形式：

Automated Unit Tests代表的是unit层

Automated Component Tests(自动化组件测试)/Automated Integration Tests(自动集成测试）Automated API Test(自动化API测试)代表的是service层

Automated GUI Tests代表的是UI层

 

分层测试的优势：

单元测试尽量多做，UI级的测试可以少做一点；

UI测试难度相对较大；

UI测试更接近于真实用户；

手工UI测试只占据了塔顶一点点的位置，而大部分的测试工作是手工测试人员所难以介入的，这让只会手工测试的同学有一定的危机感；

开发人员是质量保障的最关键因素，因为测试金字塔的大部分测试工作都需要开发或者是具备开发技能的同学去完成；

正三角是稳固的，如果按照测试金字塔的模型去组织测试工作的话，在一切相对正常的情况下，产品/项目/系统的质量是处在可控的状态下的。

现实生活中能做到正三角的团队往往是少数，大部分测试同学接触到的团队应该是倒三角的，也就是没有或只有少量的单元测试，随心所欲的做一些接口测试，把大量的人力集中在UI测试。这样的产品质量往往难以控制或者需要花费大量的时间和人力成本才能控制。

前文也提到过伟大的产品刚横空出世的时候往往是没有单元测试和UI自动化测试的，但这些产品刚发布时的质量却是可以接受的或者甚至是优秀的，这是为什么呢？这是因为伟大的产品往往由天才的开发者创建或实现，天才的代码在不做单元测试的情况下也是质量可期的，这就等于是测试金字塔的最底层相当牢固，整个产品质量就自然由保障了；另外这些产品发布的初期规模也相对较小，也比较难出现一些在频繁协作过程中会出现的问题（比如修改了不是自己写的代码而造成了缺陷），规模小质量控制起来也相对容易些。

总而言之，如果你的产品/项目/系统的开发团队大部分人都不是天才而且需要进行频繁协作的话，按照测试金字塔模型去做可能是一个比较好的方式。另外很多伟大产品刚发布的时候也是没有测试人员的，这是不是说明没有专业的测试人员参与的情况下，产品的质量也是可以很好的控制的呢？我相信各位读者都有自己的答案。