当前位置:   article > 正文

测试用例的优先级程度_主流程用例比例

主流程用例比例

P1:专门深入验证每个产品特性功能的测试  所有功能点 
覆盖率(每个小功能点至少一个案例)

P2:无效的错误条件(错误导致意料之外的行为,比如,不完整的请求,内存损坏,数据丢失等等)  
运行所有的P2案例很大可能将花费非常长的时间 

P0:基本从头到尾每个功能的案例都要执行,必须确保P0的用例都是准备无误的,如果PO案例有运行失败的,那么产品就不能发布每个小版本的测试,应该在数小时内测试就可以了

 


测试用例优先级定义执行频率与耗时覆盖范围与用例数量是否应该自动化

P0(BVT:

Build Verification Test构建验证测试)
  • 应用/进程的最基本功能,例如启动、运行/登陆、退出等
BVT测试失败,当天的日构建版本不值得做更多的测试
  • 每一天的日构建版本均需执行BVT
  • BVT用例需要控制在几分钟内完成(手工测试)
 

P0(DAT:

Daily Acceptance Test每日验收测试)
  • 最基础的端到端功能
如果P0用例不是100%通过,不应该允许发布版本上线
  • 所有版本(外发版本、调试用版本、内测版本、补丁版本)都应该执行一次P0用例
  • 用例应控制在1人1小时内手工执行完毕
  • 每一个大的需求1至2个用例覆盖
  • P0用例数(BVT+DAT)建议不超过总用例数10%
P1
  • 每一个详细功能的深入测试
  • 常见的用户行为
  • 常见的异常操作
  • 涉及到合作团队的需求
  • 基本的安全测试
  • 基本的性能测试
  • 每一个外发版本(例如yy6.0、6.1等)需执行P1用例至少一次.
  • 补丁版本只需要执行与补丁代码相关的P1用例,不需要执行所有P1用例
  • 每一个需求细节需要有至少 1个用例覆盖
  • P1用例数建议占40%-50%的总用例数(可以调节到不超过70%。原则是P1比例越大,漏bug的概率越小,但是测试时间也越长)
  • 非界面功能-是
  • UI相关 – 根据项目时间和可用的测试资源来决定
P2
  • 异常场景(例如,不完全/无效的用户请求、内存紊乱、数据错误等)
  • 基本的国际化功能
  • 深入的边界条件测试
  • 安全测试
  • 回归用例(每一轮上线后发现的bug)
  • 每一个大版本(例如yy3.0、4.0、5.0等)需执行一次P2用例
  • 执行所有的P2用例会耗用非常长的测试时间
  • P0+P1+P2应达到70%以上的代码覆盖率
  • 后台应用-是
  • 客户端应用 – 否

 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/610238
推荐阅读
相关标签
  

闽ICP备14008679号