那么独立负责项目的测试上线，你需要做什么呢？ 测试计划标准
那么独立负责项目的测试上线，你需要做什么呢？
1、需求评审，确认研发计划。编写测试计划、测试方案。
2、先根据产品的需求文档+自己对当前行业的了解，拆分测试点。拆分测试点的过程中，把遇到的不清晰的需求（或者技术方面，不理解的知识点），通过问产品/开发/搜索引擎检索/查阅公司内部资料，搞定 。
根据自己梳理完成的最终测试点，开始设计测试用例、进行用例评审（或是测试点评审）。
3、测试执行过程中 ，问题提交Bug系统，对提交的bug进行跟进、回归。
4、关注风险/延期 ，以及 质量/进度的平衡，及时反馈。
5、完成测试，提交测试报告。
6、开始发布、上线（或有灰度发布流程。记得把上线的步骤，自己用文档，完整的记录下来，并模拟几次，确保无遗漏）。
7、进行生产环境测试
8、上线后，核心业务的日志、数据监控
9、上线后，线上问题反馈流程。
10、上线后的值班。
11、项目复盘（总结会）
《项目资料存档规范》
系统测试范围：功能、非功能
目标：需求的符合性、功能设计、用户满意度、系统稳定性；
阶段：计划（具体内容）-设计（系统测试方案）-实现（完成用例、脚本和规程）-执行（执行和发现问题）
计划先后：
管理文档：
项目经理：项目计划、里程碑
开发：开发计划
测试：软件验证和确认计划，是否做集成测试；
技术文档：系统测试、集成测试、单元测试计划；--开发评审+测试建议
测试计划：时间监控，按方案来设计用例、确认规程，执行用例、记录测试日志、写测试报告；--管理的角度规划；
内容：
组织形式：每人做什么，开发和测试员之间的协做；
测试对象：范围和范围详细分析（难），依赖于测试系统和需求的熟悉程度；
时间：给的时间；
目的：如找致命的BUG，在选取测试对象时找容易出错的地方；
常见目的：检测、证明、功能验证等；
工作任务分配：需求跟踪---表格、测试通过标准、挂起标准---测试部、应交付的测试产品；
模板：
目标、概述（项目背景、范围、组织形式、测试对象、需求跟踪表、工作任务分配、试通过标准、挂起标准---测试部、时间进度和安排、风险管控、应交付的测试产品、工作时间预估、资源分配）
制定的原则：
- 文档是对应系统测试具体的活动，具体步骤和时间点；
- 计划需要划分职责、让测试知道自己干什么；如何评估工作
- 计划需要根据实际修改，后续执行和计划脱离，就没有意义了；
内容补充：？
1.明确测试目标，确定测试需求。根据当前测试工作目标不同，测试需求的确定方式有所不同。如当前为新项目的测试工作，则测试需求可能为该项目能按时上线并按用户需求的功能正常使用等；而对于产品的阶段性测试，测试需求可以以列表形式展现，列表可以列出本次测试工作所需要测试的更新及影响的测试点等。
2.制定测试策略的时候，需要考虑：
根据测试项目特点，确定本次测试需要经历的测试阶段。确定测试阶段后，确考虑每个测试阶段的目标、进入条件及退出条件（完成标准）。
根据确定的测试阶段，分析每个测试阶段需要包含的各种测试类型，如是否需要性能测试、安装测试等。确定测试类型后，确定每种测试的测试目标、测试方法、完成标准及特殊事项考虑。
确定测试阶段、测试类型后，针对需要，确定测试方式及测试工具。
特别的：在考虑测试策略时，还应结合系统的特点及系统功能的优先级及难易程度，分析各项测试的重点及难点。另外，根据测试时间的长短不同，测试策略也需要有相应体现。
3.确定测试资源：测试资源的确定，需要充分调研，基本确定系统规模、功能复杂度、系统运行环境等，结合测试策略，考虑所需要的测试资源。确定测试资源，主要包括：
明确测试过程中角色分配。这点在测试计划阶段必须明确到人的是测试负责人这个角色。其他角色，如测试参与人员，可以不明确到具体的人员姓名。
明确测试人力资源及测试环境：考虑人力资源时，需要考虑所需人力资源的数量、各人力的知识或技能程度等。在测试计划阶段，测试负责人就可以开始协调测试资源，需要在该阶段就确定测试资源，包括人员资源及环境资源。有些项目可能测试资源比较紧张，测试计划制定者在制定计划时应该考虑最少测试资源与充足测试资源这两种条件下的测试策略调整。
4.测试里程碑设计：一般测试里程碑在模版上已经列示出来，测试计划制定者按照之前分析的测试需求、确定的测试策略及明确的测试资源，作相应的风险分析，从而确定测试里程碑及里程碑的起始时间。在制定里程碑起始时间时，可能出现项目留给测试的时间在当前实际下不足，则应及时与项目经理沟通或者重新考虑测试策略或者重新调配资源。
5.测试管理及任务的制定：这部分内容的计划，对顺利完成测试任务，保证计划执行有着重要意义。这部分内容，主要包括接收测试条件、测试时间（测试轮次）的设计、测试人员任务的分配、测试过程管理策略、测试完成标准确定及测试过程评审机制。这里，主要对测试时间、测试人员任务、测试过程管理作特别说明：
（1）测试时间设计和测试人员任务分配可以作为一体考虑。测试计划制定者需要有运筹的思想，根据当前测试资源的状况结合测试策略，确定测试需要经历多少轮次，各人员分别承担什么样的测试任务。测试计划制定者应该始终明确，成功的测试工作是用尽可能少的时间发现最多的缺陷。对于测试时间的评估，可以根据编写的文档页数、测试用例条数、执行测试用例数量及回归测试大约用时来衡量。但是目前工作中，除了上述标准，还应按项目实际情况和计划制定者的经验综合考虑。
测试轮次设计：设计测试轮次时，一般必须有回归测试环节。回归测试之前往往会经历多轮测试。但是建议不要设计太多轮次测试，以避免资源耗用过于频繁。每一轮测试都应有各自明确的目标与测试策略。如第一轮保证功能正确，第二轮保证流程顺畅，性能稳定等。最终应该设计回归测试环节，保证之前缺陷被正确修改，在该阶段还可以配合进行安装测试。如果系统庞大或测试工作复杂，对每一轮次测试，可以单独做小的测试计划，保证更好的测试效果。在测试时间控制上，应该略微预留一点时间，以控制突发事件。
在测试任务设计上，需要统筹分析考虑，合理安排人力资源。每个人测试什么任务，和谁一起承担，都应有特别的考虑；测试任务分配要均衡，避免出现一些任务特别紧张，一些任务很快完成的情况。
（2）测试过程管理设计中，需要考虑BUG管理流程，项目测试进度控制。
BUG管理中，需要考虑： BUG管理的工具是什么，BUG管理系统中各角色人员的权限是什么（测试准备一部分），研发人员解决BUG花费的时间限制，研发人员反馈BUG修改的规范、测试人员确认BUG的时间限制。总之，需要制定一个BUG管理流程，从一个BUG产生到BUG关闭这个流程中，所经历的过程规范。
测试过程管理规范的约定：如是否采用周报制度，对于项目较紧时是否采用日报的形式。对项目组成员可以要求进行日志形式提交测试情况等。
测试准备
（１） 测试准备：了解测试的背景，
（２） 向有经验的测试人员学习：利用师傅带徒弟的方式固化到流程中。
（３） 走读缺陷跟踪库中的问题报告单。
（４） 走读相关产品的历史测试用列
（５） 识别测试需求
（６） 加入开发小组邮件群组
（７） 测试用列的设计
（８） 加强测试用列的评审
（９） 测试用列的执行
（１０） 加强测试过程记录
（１１） 及时确认发现的问题
（１２） 了解测试模型（比如：Ｖ模型／螺旋模型／增量模型／快速模型等），掌握软件测试方法论。
测试计划
（１） 测试计划编写依据：项目计划／项目计划的评估状态以及业务的理解
（２） 测试计划编写时间：尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不是十分清楚和稳定的项目，测试计划也可以在总体设计完成后开始编写。
（３） 测试计划的编写与实施：测试计划应该由测试小组组长或最有经验的测试人员或环境的变动而变化，确保测试计划是最新的而且依据测试计划执行的测试工作。
（４） 测试计划的变更。
（５） 测试计划的优先级。
（６） 测试计划的评审
（７） 测试计划的管理
（８） 测试计划的原则
测试风险估算
对于一个软件过程中出现的风险，包括：人员中途的离去／测试过程中发现意料之外，需要延迟测试时间的ＢＵＧ，需求发生较大的变动，技术达不到顶期效果，测试环境搭建有问题，包括硬件和软件。
测试计划
（一） 软件测试设计流程：把软件分为５个阶段：计划阶段／设计阶段／执行阶段／评估阶段和验收阶段。
（二） 测试设计的基本方法
（１） 黑盒测试
（２） 等价类方法
（３） 边界值分析法
（４） 判定表法
（５） 因果图分析法
