如何保证测试项目的质量

近期做了一个不算复杂的项目，第一版时bug数已经高达300个，才真正的警醒、反思。

一个项目的进行的是否顺畅，肯定不是一人之力能够推动的，有必要制定统一的规则，保持从产品到开发再到测试的步调一致，劲往一处使。

下面是此项目的心得，以此项目为戒：

 

• 1.需求阶段：

目前如果是常规小发布的话，一般是产品发出来简单的需求说明及上线时间点，在当面说一下，开发就开始coding了，这样对于有经验或者理解能力强的开发是OK的，但是，我们一般遇到的都不是这样的开发[捂脸]

所以我们的解决方法是：

不论大小的需求，都要把产品、开发、测试约在一起，产品对新需求做说明，然后开发复述自己对于需求的理解风格给产品和测试听，看是否理解正确

会议结束后，由产品将需求记入teambition

• 2.指定规划

彻底了解需求之后，开发评估这个需求的工作量，然后再说一下自己手头的工作是什么，把手头的工作和需求进行优先级排序，确定先做什么再做什么，给出具体提测时间点。

然后测试评估该提测时间是否合理

• 3.测试：

开发提交测试的代码需求自测通过

提测时间点是从开发自测通过时间开始算，如果提测的内容到测试之后其他主流程block的话，测试打回提测内容，此刻不算做提测时间，直到主流程通过（冒烟测试通过）才算是提测，该时间点才算是【提测时间】

提测的内容在teambition上及时将状态改为【测试中】（非测试中的问题将不列入测试范围）

若此次提测有老代码或者逻辑优化，但是在前端无感的话，需求同步到测试，测试同学会留意此部分功能

 

转载于:https://www.cnblogs.com/lybolg/p/9025656.html