理想情况下完整的测试流程应该是怎样的

lsekfe

小公司如何规范测试流程，咱们可以“以大见小”。先了解下理想状态下的测试流程，然后抽离出可减少的环节。这个剩下的，不可减少的环节，就是小开发公司测试流程了。
　　在理想情况下，完整的项目流程如下图所示：

产品，红色马甲；测试，黄色马甲；开发，蓝色马甲
　此图清新展现了产品、开发、测试等主要角色，在项目不同阶段对应的工作内容。
　　1、需求阶段
　　在这个阶段中，由产品经理主导需求评审，测试跟开发积极参与。
　　在需求评审的过程中，开发和测试需要了解需求的细节和设计逻辑，同时对于有疑问的地方要向产品提出疑问，以达成对需求理解的一致。
　　需求评审结束后，开发先评估工时。测试则要根据需求文档，并结合开发的工作量，来完成测试工时的评估。
　　排期表规范：
　　包含角色：产品、设计、前后端、测试等（根据具体的项目来定）。
　　关键时间节点：
　　1.产品：需求串讲时间，项目上线时间
　　2.开发：开发起止时间，前后端联调时间
　　3.测试：提测时间，测试起止时间

　2、开发阶段
　　排期定好之后，就进入开发阶段了。
　　首先，开发同学会先出一个整体的技术设计方案，包含本次需求的设计思路和实现逻辑等。
　　这时一般会有技术评审的环节，该环节由开发主导，产品和测试参与。在技术评审的时候，测试人员可以对开发的技术设计提出疑问，从而获得更加全面的了解，了解越多，[url=]测试用例[/url]设计才会更全面。
　　技术评审结束之后，测试人员就要立即开始制定测试方案（测试范围、测试手段、测试时间等）。
　　接下来就进入到对于测试人员，非常重要的环节：编写测试用例。
　　编写测试用例可以用Excel，也可以用Xmind，在此，建议测试团队统一标准。


测试用例完成后，测试人员需要跟开发和产品拉会，进行用例评审。
　　用例评审的目的是找出遗漏点和逻辑理解不一致的地方，最终统一对预期效果的理解。
　　3、测试阶段
　　开发完成后，接下来就是提测。
　　在提测环节，建议制定测试准入（也称为提测规范）。
　　为什么要制定提测规范：为了规范开发的提测质量，加强前期质量控制，降低提测后因提测质量问题造成的风险。
　　测试准入标准（根据实际业务增减）：
　　1）开发人员按需求及原型图完成软件的业务流程及功能的开发
　　2）开发人员编码结束，并已完成单元测试，并提供自测功能报告
　　3）软件的基本业务流程可以运行通过（冒烟测试），功能操作正确，且符合需求
　　4）开发人员需提供软件的最新版本，并安装测试通过
　　5）开发人员需提供接口文档、部署文档、提测申请、提测功能列表
　　开发人员的提测质量，达标之后，测试人员就要正式上场了。
　　测试一般分为后端测试（接口测试）和前端测试，一般是后端测试通过之后再进行前端测试。
　　怎样才算合格的测试，同样也需要制定测试准出标准（测试完成标准）。
　　测试准出标准：
　　1）所有功能和业务流程都按需求实现
　　2）测试用例都已经执行完成，测试执行覆盖率为100%
　　3）测试发现的所有 BUG 问题中，致命、严重、都已被修复且被验证通过
　　4）允许遗留不影响业务流程的轻微bug，但是需要有解决方案及时间点
　　5）完成测试后，出具测试报告
　　四、发布阶段
　　测试完成后，就进入发布阶段。
　　发布规范包含以下几点：
　　1.发布时间：为了避免上线后有问题及时修复，发布日期建议避开周五及节假日前两天，上线时间避开用户活跃高峰期。
　　2.发布流量控制：为了避免线上问题影响到线上用户，建议小流量灰度发布，在线上回归没有问题后再逐步放量。
　　项目上线后，建议做一次项目复盘，看看那些地方做得不好，要分析原因并找到解决方案；那些地方做得好，以后继续保持。