测试用例的优先级程度

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

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

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

 

---

测试用例优先级	定义	执行频率与耗时	覆盖范围与用例数量	是否应该自动化
P0(BVT： Build Verification Test构建验证测试)	应用／进程的最基本功能，例如启动、运行/登陆、退出等 BVT测试失败，当天的日构建版本不值得做更多的测试	每一天的日构建版本均需执行BVT BVT用例需要控制在几分钟内完成（手工测试）		是
P0(DAT： Daily Acceptance Test每日验收测试)	最基础的端到端功能 如果P0用例不是100%通过，不应该允许发布版本上线	所有版本（外发版本、调试用版本、内测版本、补丁版本）都应该执行一次P0用例 用例应控制在１人１小时内手工执行完毕	每一个大的需求１至２个用例覆盖 P0用例数（BVT+DAT）建议不超过总用例数１０％	是
P1	每一个详细功能的深入测试 常见的用户行为 常见的异常操作 涉及到合作团队的需求 基本的安全测试 基本的性能测试	每一个外发版本（例如yy6.0、6.1等）需执行P1用例至少一次. 补丁版本只需要执行与补丁代码相关的P1用例，不需要执行所有P1用例	每一个需求细节需要有至少　1个用例覆盖 P1用例数建议占４０％－５０％的总用例数（可以调节到不超过70％。原则是P1比例越大，漏bug的概率越小，但是测试时间也越长）	非界面功能－是 ＵＩ相关 – 根据项目时间和可用的测试资源来决定
P2	异常场景（例如，不完全／无效的用户请求、内存紊乱、数据错误等） 基本的国际化功能 深入的边界条件测试 安全测试 回归用例（每一轮上线后发现的bug）	每一个大版本（例如yy3.0、4.0、5.0等）需执行一次P2用例 执行所有的P2用例会耗用非常长的测试时间	P0+P1+P2应达到70%以上的代码覆盖率	后台应用－是 客户端应用 – 否