2)QA不参与单测,RD依据需求纵向拆分功能点然后迭代提测,QA能提前一定时间介入测试:

  对照如下的流程示意图说明这个过程,实际上是传统瀑布模型做了拆分,变为了多个短期的“小瀑布模型”,这样的效果能使得项目周期长的产品,可提前介入测试以提前发现问题。

  在这样的迭代流程中,如何合理利用自动化手段来提高测试效率呢?一般来讲迭代周期不会很长,常规性的为3~5天一个周期,做太复杂的自动化投入成本较高。对于web系统来讲,为避免过多的自动化投入得不偿失,需要谨慎的判断web系统的特征适合哪种自动化模式。所以这里特别要关注的是分层自动化测试:

  如上图所述,web系统可以做几种功能测试:单元测试,集成测试,系统测试。大多数的产品QA不会太多介入单元测试,集中在集成测试和系统测试。结合上面提到的迭代排期,其实在一般项目中上层UI的开发往往比较滞后,赶工的结果也是提测质量不高。所以可推荐的一种模式是迭代周期内按照UI接口划分功能点做排期,UI的开发可以放在UI接口稳定之后提测。所以迭代周期内,面向UI接口的自动化是一个将测试前置,并且积累自动化case以待回归时代替手工操作的大好机会。

  着上面这个结论,再分析一下本节开头抛出的第二个问题:“系统级自动化测试的稳定性与可靠性”,先提出几个观点如下:

  1)有一些测试点,从系统级角度做自动化的性价比不高:

  第一:目前技术手段上还不具备低成本的实现手段的,比如flash、js实现的一些效果、不规范HTML标签、对浏览器运行版本环境考虑不周等引发的问题。导致开发成本高,运行的稳定性较低。

  第二:UI实现逻辑比较薄,比如只是查询DB一个字段然后显示在页面,把重点放在后端逻辑检查上性价比更高。

  2)系统级测试和集成测试的关注点不同:系统级测试关注的是用户从UI直接操作所能见到的结果,而集成测试关注的是UI接口数据的准确性。比如报表功能,页面上看到的是一个表格,而对UI接口来讲需要覆盖N种参数组合。

  上面两点说的是系统级测试和集成测试的区别之处,在自动化实施过程中,推荐分层的测试思路,既能够细化测试也能综合衡量自动化的投入成本,总的来讲是以下几点:

  1)传统瀑布项目,持续周期长,通过迭代模式可提前介入测试,而迭代周期内系统级功能可能不具备可测性,但是接口可以具备可测性。

  2)基于UI的自动化有利有弊,需要结合系统特征综合考虑分层测试的必要,分层后各有测试的侧重点,比如UI自动化重点关注UI的操作流程和显示,集成测试更关注UI接口的参数等价类覆盖和数据正确性。