整个项目流程中测试团队究竟该做哪些事情和承担了一个怎样的角色？

ゞ浴缸里的玫瑰 2022-12-06 04:09 94阅读 0赞

### 文章目录 ###

*  前言
 *  项目整个阶段
 *  一些规范说明

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70_pic_center]

# 前言 #

当前 IT 公司一般拥有四大角色

*  产品（业务）
 *  开发（Web，App）
 *  **测试**（测开，自动化，手工）
 *  运维

大型的 IT 企业拥有着强大 QA 团队和运维团队，小型的 IT 企业生存艰难，就简化了产品，并且舍去了**测试**和运维，**测试**和运维全部压在开发身上

随着 DevOps 持续集成持续交付的兴起，和敏捷开发方法论的流行，软件产品的快速迭代，国内**测试**团队越来越正规化，**测试**团队的在其中的作用又有了新的扩展，已经不再仅仅是满足简单的手工功能**测试**了

那么**测试**团队在整个敏捷开发中的工作内容是什么呢？下面我将结合我自己的工作经验来细细说明

# 项目整个阶段 #

整个项目采用敏捷开发的模式，两周一个迭代来进行开发，其中包含项目经理（PM），产品，开发，**测试**，运维

*  承接项目阶段（对于公司自研产品请忽略）
    
     *  对于私企来说就是通过产品的售前人员得公司产品和技术的销售）去推广自己公司的解决方案，然后项目- 需求讨论阶段
     *  需要人员和**测试**人员，产品是主导，**测试**提出自己的改进意见，TDD 风格有助于开发出更加安全可靠的产品
 *  需求宣讲阶段
    
     *  需要和**测试**和开发，产品做主导，宣讲的时候**测试**听取最终版本的需求说明，可以再次提出自己的疑问，开发也对需求的开发思考做出说明。不得不提的是**测试**人员需要对需求文档进行预习，否则容易造成需求文档不能一时理解的问题！
     *  需求宣讲完，**测试**人员就可以开始准备**测试**用例，可以在**测试**用例之前画个 xmind 思维导图方便理解被测点，当然如果时间够用的话
 *  设计讨论阶段
    
     *  需要和**测试**，**测试**提出自己的疑问和建议
 *  设计评审阶段
    
     *  需要**测试**，产品可以参与，看产品的时间，一般情况下，产品不用参与，**测试**可以再次提出疑问和思考
     *  宣讲完，**测试**可以开始维护修改**测试**用例，同时需要标出冒烟级别的**测试**用例
 *  用例评审阶段
    
     *  **测试**人员将写好的**测试**用例和思维导图进行评审，需要参与，产品和开发提出疑问，然后**测试**人员可能需要稍微调整**测试**用例
 *  开发阶段
    
     *  开发人员进行开发
     *  开发人员进行单元**测试**，编写提测文档
     *  环境协调自动部署，开发和运维介入
     *  **测试**人员开始**测试**执行
        
         *  sit 系统集成测试环境下，手工**测试**人员，手工执行**测试**用例
         *  sit 系统集成测试环境下，接口自动化**测试**人员，太前期的时候不必做所有接口的**测试**，由于系统还未稳定，可以做主要冒烟级别接口的**测试**工作，然后可以补上其他接口的**测试**
         *  sit 系统集成测试环境下，UI 自动化**测试**人员，前期时候不用做 UI **测试**，相较于接口，UI 变动性更大，所以 UI 自动化必须要在系统足够稳定，页面不会有太多的变动时候去做，并且只去做主要流程的 UI 自动化
         *  性能**测试**人员，压力**测试**需要在接口稳定之后去做，压力**测试**原则上是越早做越好，尽可能早的在项目初期发现性能上的问题，越早解决越好
         *  uat 验收测试环境下，进行兼容性的**测试**
 *  上线阶段
    
     *  两周一个迭代，上线阶段一般在半夜，需要提前先由产品和开发商量好，编写好上线清单
     *  开发和**测试**合作，检查环境，日志，计划等等内容
     *  开发按照清单进行上线
     *  上线后由**测试**进行**测试**执行，有问题需要及时反馈给开发和运维

# 一些规范说明 #

1.  不论是讨论阶段，还是宣讲阶段，建议采用半天时间，因为实际过程中开会时间很容易超时，导致项目进展缓慢，所以建议给项目设置一个要求尽量强制团队开会时间不能超过半天
2.  **测试**人员需要贯穿整个项目流程，不管是需求还是设计都需要**测试**人员参与，**测试**人员不仅要懂需求，还要懂技术，同时对于线上的**测试**，以及辅助开发和运维进行部署也是有意义的，**测试**人员基本可以说是一个全能的角色了
3.  实际过程中有一个问题就是需求和设计宣讲的太快，不容易听明白，特别是需求评审的时候，这时我们的解决办法，一个是在需求讨论时候多花点功夫，另一个就是可以在需求评审之前让**测试**团队先找产品拿到粗略的需求文档进行预习。之后在需求评审中需要各方大胆的提出自己的问题，不管这个问题是不是简单或者困难都是值得提出的
4.  现实中还有一个问题就是**测试**用例编写的细致程度，有时候一个需求写成用例，细致的写可以写上百条，也可以写成几十条，这需要按照整体项目的进度以及迭代周期和功能的重要程度和**测试**方法等诸多因素来考虑，一般采用等价类和边界值，这个等价类和边界值要细分到什么程度呢？这是一个比较灵活的点，需要总和考虑。当然对于**测试**而言越细越好
5.  开发进度缓慢，**测试**始终不能**测试**执行怎么办，**测试**团队可以每天进行任务汇报，按照一定的文本格式将每天的工作任务，**测试**被阻塞情况，**测试** bug 情况等内容及时在下班前反馈给 PM，形成一个固定的模式，当然除了**测试**团队外，其他团队也需要这样做，形成一个相互监督的体系
6.  开发进度缓慢容易导致的一个问题就是一个迭代周期快要结束了，可是**测试**用例还没有被执行完，全部都积压在了最后几天，这该怎么办？首先要明确不能因为要做完一件事而压缩质量，所以需要即使向 PM 反应完成多少**测试**用例的的工时是多少，这样 PM 会自动将超出工时的**测试**用例移至下周
7.  当**测试**发现 bug 时候需要即使向类似 jira 这样的平台提出 bug 单，同时向开发及时反馈，并协助开发解决
8.  敏捷开发的过程中，每天会有早会，要说明一下昨天今天和以后要做的事情，然后注意更新任务，这些是在 scrum 看板站会进行的
9.  建议每个迭代之后，开一个迭代会说明迭代的不足等其他事情
10. 开发人员提测之后需要更新一个提测表格，能够让**测试**及时看到，同时也需要提醒**测试**人员

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/909387315d424a95b488e63f8c3a97cc.png