项目文档Check List
checklist作文
checklist作文Checklists are important tools that help us stay organized and ensure that we don't forget important tasks. 使用清单是一个很好的方法,能够帮助我们保持组织,确保不会忘记重要的任务。
By breaking down complex tasks into smaller, manageable steps, checklists make it easier for us to stay focused and achieve our goals. 通过将复杂的任务分解成小、可管理的步骤,清单使我们更容易保持专注,实现我们的目标。
They provide a sense of accomplishment as we check off completed items, and serve as a visual reminder of what still needs to be done. 当我们完成一个项目时打勾,清单会给我们带来一种成就感,并作为还需完成的任务的视觉提醒。
One of the benefits of using checklists is that they can help reduce stress and anxiety by providing a structured approach to completing tasks. 使用清单的好处之一是,它们可以通过提供一个有结构的方法来完成任务,帮助减轻压力和焦虑。
Instead of trying to remember everything we need to do, we can simply refer to our checklist and follow the steps outlined. 不必试图记住所有需要做的事情,只需要查看我们的清单,按照列出的步骤进行操作。
新项目Checklist
New Product Development Tollgate Checklist Feasibility For Quote (stageⅠ)可行性阶段一Proto Type(stage Ⅱ)打样（阶段二）Pilot Run (stage Ⅲ)试生产（阶段三）Mass(1 Year review)（stage Ⅳ)量产（阶段四）RFQ No. Receive date/接收日期Customer Address/客户地址Customer/客户Required date/客户需求日期Q-1 ApprovedSupplier:通过质量认证的供应商Project name/项目名称Production use/产品用途Payment Term/付款条款Project Life/机种寿命Shippingrequirement/运输方式Delivery Term/送货条款Customer Importance/客户等级:high，middle，low Business form/贸易方式：直接/间接/当地Package Model/包装模式：循环/一次性Review Items评审项目ⅠⅡⅢⅣReview Result评审结果Comments评价注解1.Customer drawing, BOM(e.g.: Special Technical requirements)客户图纸，BOM（如：特殊技术要求）OK通过Can’t Meet不能通过Improvement 需改善N/A不适用2.Product’s Requirements: PPAP, Surface treatment, Color Sample, Packaging, Transportation, Method….产品的要求：如PPAP，表面处理，色样，包装，运输，方法等OK通过Can’t Meet不能通过Improvement需改善N/A不适用3.Supplier’s Risk(including appointed Suppliers)供应商风险含指定的供应商OK通过Can’t Meet不能通过Improvement需改善N/A不适用4. Material Risk(e.g.: Supplier by Customer)物料风险如客户指定的供应商OK通过Can’t Meet不能通过Improvement需改善N/A不适用5. Product Certification Requirements(e.g.: ROHS,GP,UL) 产品认证要求OK通过Can’t Meet不能通过Improvement 需改善N/A不适用Continue to Next Stage继续下阶段Another Review Required and Date需重新review及时间Terminate the Project终止该项目Notice to Client通知客户New Product Requirement Checklist Details新产品评审要求细则#1- Drawing / Print:Need to confirm the latest revision level drawings available. Require all assembly, sub-assembly and individual component drawings are provided from customer.图纸：需要确认并获得最新版本的图纸，要求客户提供所有组件，分部组件和子件的图纸#2- Critical Material: Need to identify material requirements for the project to confirm availability in China and available material substitutions; this should include any supplied material as well as the manufacturer (such as steel mill, paint manufacturer or OSP) of this material.关键材料：需要识别该项目的材料要求并确认在国内可购买以及有可用的替代材料，此要求除了制造商如钢厂，涂料厂商或外协厂商外，还需包含其它原材料及物料#3- Customer Standards & Specifications:Acquire all customer standards, specifications and requirements for the part numbers being considered for quoting purposes. Ask for the following customer documents: Supplier Quality Manual, Specifications listed on drawing / print, PPAP, Material Certificate Requirements or any third party test requirements.客户标准及规格：对正在评估报价的项目料号取得客户标准，规范和要求。
checklist方法
checklist方法Checklist是一种工具或方法，用于确保任务或项目的执行过程中的每个关键步骤和要求都得到满足。
它经常用于项目管理、质量控制和任务执行等领域。
使用Checklist可以帮助人们提高工作的效率、减少错误发生以及确保工作的准确和完整。
在本文中，我们将探讨Checklist的作用、好处以及如何创建和使用Checklist。
Checklist的作用和好处：1. 确保一致性和准确性：Checklist可以确保任务和项目的关键步骤都得到遵循和执行，从而确保一致性和准确性。
它可以帮助人们避免遗漏关键步骤或要求，以及减少错误发生的可能性。
2. 提高工作效率：通过使用Checklist，人们可以有条不紊地进行任务或项目的执行。
它可以帮助人们记录和跟踪每个步骤的完成情况，从而更好地组织和安排工作，并提高工作效率。
3. 降低错误发生率：通过将任务或项目的关键步骤和要求列入Checklist，人们可以避免疏忽和错误的发生。
通过反复检查Checklist，可以确保任务或项目的执行没有遗漏和错误，并及时发现和纠正问题。
4. 提高沟通和协作：Checklist可以作为沟通和协作的工具，帮助团队成员之间更好地理解任务和项目的要求，并确保每个人都按照相同的标准和步骤进行工作。
它可以促进团队之间的协作和配合，减少误解和冲突。
如何创建和使用Checklist：1.确定任务或项目的关键步骤和要求：首先，需要明确任务或项目的目标和要求。
然后，根据这些目标和要求，确定执行任务所需的关键步骤和要求。
2. 编写Checklist：将关键步骤和要求编写成Checklist的形式。
可以使用简单的列表形式，或者根据任务的复杂程度和要求的详细程度，使用更为详细和结构化的格式。
3. 测试Checklist的有效性：在使用Checklist之前，可以将其进行测试，以确保其有效性和可行性。
可以通过模拟执行任务或项目的过程，检查Checklist是否包含了所有关键步骤和要求，并是否易于理解和执行。
项目过程Checklist
项目过程Checklist工程过程序号检查点检查项审计级别检查结果问题描述检查时间输出或其它证明纠正结果纠正时间是否关闭1 需求分析是否进行功能需求（FRD ）确认高2 是否进行Demo 评审（如涉及Demo ）高3 是否进行UC 评审高4 UC 评审会上是否确定需求基线时间高5 UC 评审结束后是否形成《需求评审报告》，通知项目组各方成员确认，并纳入confluence 上项目文档库中6 UC 评审中发现的问题是否进行及时跟踪和验证，已妥善解决（SQA 抽查）高7 UC 评审通过后UC 文档是否按时入库基线1.基线时间在需求评审会议上项目组一致确定2.基线时间不能晚于设计完成时间3.基线时间的调整必须经项目组全体成员确认达成一致高8 设计是否形成系统设计文档,纳入confluence 上项目文档库高9 是否进行设计评审高10 技术评审结束后是否形成《设计评审报告》，通知项目组相关人员确认，并纳入confluence 上项目文档库中11 编码是否进行TC 评审高12 TC 评审后是否形成《TC 评审报告》，通知项目组相关人员确认，并纳入confluence 上项目文档库中13 提交测试前是否进行Codereview高14 Codereview 结束后是否形成《Codereview 记录》，通知项目组相关人员确认，并纳入confluence 上项目文档库中15 Codereview 发现的问题是否进行及时跟踪和验证，已妥善解决(PM 把关) 高16 提交测试前是否提交DBA 进行SQL 审核，并对审核出的问题进行改进与跟踪解决高17 提交测试前是否向SCM 申请测试分支合并代码并解决代码冲突（QA 配合检查）高18 提交测试前是否完成测试环境搭建高 19 是否填写《开发提交测试清单》，在转测试时提交给测试高20 测试发现的所有问题是否按规范录入QC 平台的项目缺陷库中高 21 是否按时发送《测试质量报告》高22 回归测试前是否全部closed 功能测试中发现的所有Bug （Deferred 除外）高23 回归测试前是否提交客户验收测试，并在QC 中记录验收测试发现的问题中回归测试前是否提交代码安全审核，并输出《代码安全审核报告》高回归测试之前，'代码安全审核报告'中所有'项目相关'安全漏洞已修补；若未修补的，已约定计划完成时间（在本项目内）；若未修补且无计划完成时间的，必须要有开发主管的确认邮件高24 进入预发布前，全部closed 测试中发现的所有Bug （Deferred 除外）高25 发布截止到项目发布前一周是否已制定完成发布计划（B 类项目截止在发布前三天完成）高26 截止在项目发布前三天已完成发布计划评审，并通知到项目组相关人员与会（PM,PD ，开发，测试，DBA,SCM,SQA ）高27 项目发布时间与小需求发布时间冲突时，是否进行发布时间协调尽量避免相同应用同一天发布项目和小需求（截止在项目发布前三天完成）高28正式发布前是否所有缺陷都已Closed(Deferred 除外）高30 正式发布是否出现二次发布或发布回高滚（SCM 统计）31 项目组相关成员是否对发布结果进行验证（SCM 把关）高29 发布后若有项目相关的Deffered 缺陷是否已安排好后期处理计划（正式发布后三天内）高32 项目发布后的两周是否对故障与Deferred 问题(项目范围内)进行跟踪与解决高33 项目发布后一月内是否已完成需求归档入产品文档库（SQA 抽查）中34 项目发布后两周内是否已完成TC 归档入公共用例库（SQA 抽查）中管理过程序号检查点检查项审计级别检查结果问题描述检查时间输出或其它证明纠正结果纠正时间是否关闭1 立项项目立项通知1.通知对象是否涉及所有相关方2.通知内容是否完整高2 项目Kickoff1.会议通知是否涉及所有相关方2.会议内容是否包含项目里程碑计划，项目风险识别高3项目Kickoff PPT 是否输出，及时上传文档库中4 计划项目里程碑计划是否输出高 5项目详细开发计划是否输出高6 项目测试计划是否输出高 7项目估算（开发、测试）是否输出高8 控制项目周报是否每周五下班前提交高9项目进度周会是否定期召开（Kickoff 约定沟通机中制）10 项目需求变更记录跟踪表是否输出，内容填写完整高11项目风险控制（周报中包含）高12 结项项目总结会是否召开高 13 项目总结报告是否输出高 14 项目过程度量数据表中15 资源统计项目组RPM 上每周按时项目相关工时填写高。
checklist模板实用
checklist模板实用在我们日常生活和工作中，我们经常需要处理各种各样的事情，有时候可能会让一些事情滑漏。
为了提高工作效率和避免疏忽，使用checklist模板是一个非常实用的方法。
checklist模板可以帮助我们把任务细化、整理和安排，确保我们完成所有必要的步骤。
本文将介绍一些常见的checklist模板以及它们的实用性。
1. 旅行checklist模板无论是商务差旅还是度假旅行，我们都需要做很多准备工作。
旅行checklist模板可以帮助我们列出需要带上的物品，如护照、钱包、手机、行李等。
除了物品清单，还可以列出办理机票、酒店预订、签证办理等的步骤。
这样，我们就可以避免在旅行前或旅途中忘记某些重要的东西。
2. 会议checklist模板参加会议时，我们需要做很多准备工作以确保会议顺利进行。
会议checklist模板可以帮助我们准备演示文稿、会议议程、会议资料等，并列出参会人员名单以避免遗漏。
此外，还可以添加准备会议室、检查会议设备等任务，以确保一切就绪。
3. 项目管理checklist模板项目管理是一个复杂而繁忙的任务。
使用项目管理checklist模板可以帮助我们更好地组织和管理项目。
这种模板可以包括各个项目阶段的任务、里程碑、交付物以及相关的计划和时间表。
通过使用这个模板，我们可以清晰地了解项目的进展情况，并确保按时完成各个阶段的任务。
4. 日常任务checklist模板我们每天都会面对大量的日常任务，例如回复邮件、安排会议、处理文件等。
使用日常任务checklist模板可以帮助我们更好地组织并优化这些任务。
这种模板可以帮助我们列出每天需要完成的任务，并按优先级进行排序。
通过使用这个模板，我们可以明确自己每天需要完成的任务，并及时跟进。
5. 事件筹备checklist模板筹备一个活动或者庆典是一个复杂且需要全面考虑的过程。
事件筹备checklist模板可以帮助我们规划并管理各个方面的任务。
测试check List
测试 Check List1. 引言测试 Check List 是测试过程中的一项重要工具，用于确保测试的全面性和准确性。
本文档将介绍如何编写和使用测试Check List。
2. 撰写测试 Check List 步骤2.1 确定测试范围在撰写测试 Check List 之前，首先需要明确测试的范围。
测试范围应该包括待测系统的功能、性能、安全性等方面。
2.2 列出待测功能点根据测试范围，列出待测的功能点。
每个功能点应该明确描述功能的预期行为。
示例：功能点预期行为用户登录登录成功后跳转到主页发布新文章成功发布后在文章列表中显示修改用户信息保存修改后，信息应更新到数据库删除评论删除后评论应从数据库中删除2.3 列出待测边界条件边界条件是指系统中的特殊情况，如极限值、异常值等。
列出待测边界条件可以帮助测试人员更全面地覆盖系统的各种情况。
示例：功能点边界条件发布新文章文章标题为空发布新文章文章内容超过最大长度修改用户信息用户名包含特殊字符删除评论评论ID不存在2.4 列出待测的关键功能点关键功能点是指对系统核心功能进行测试的功能。
列出待测的关键功能点，可以帮助测试人员重点关注系统的重要部分。
示例：•用户注册•支付功能•数据加密2.5 根据测试需求添加测试用例根据待测功能点和边界条件，为每个功能点编写相应的测试用例。
测试用例应包括输入、预期输出和实际输出。
示例：测试用例 1：功能点：用户登录输入：用户名、密码预期输出：登录成功实际输出：登录成功测试用例 2：功能点：发布新文章输入：文章标题、文章内容预期输出：文章成功发布实际输出：文章成功发布2.6 检查测试用例的覆盖范围在添加测试用例后，需要检查测试用例的覆盖范围。
确保所有待测功能点和边界条件都有相应的测试用例。
2.7 根据测试需求添加测试数据根据测试用例的输入要求，准备测试所需的测试数据。
确保测试数据覆盖了各种情况，包括正常情况和异常情况。
2.8 评审和修正测试 Check List在完成测试 Check List 的编写之后，需要进行评审。
obsidian checklist用法
obsidian checklist用法Obsidian 是一个支持 Markdown 的知识管理工具，它提供了一种 Checklist 的语法，允许你在文档中创建待办事项列表。
下面是如何使用 Obsidian 中的 Checklist 的基本用法：创建 Checklist 项在 Markdown 中，使用 - [ ] 或者 - [x] 来创建一个待办事项或已完成事项。
示例如下：- [ ] 完成任务 A- [x] 完成任务 B- [ ] 完成任务 C在编辑器中，你可以点击复选框来切换任务的完成状态。
嵌套 Checklist你还可以嵌套 Checklist 项，以创建更复杂的任务结构。
示例如下：- [ ] 完成主任务- [ ] 子任务 1- [ ] 子任务 2- [x] 子任务 2.1- [ ] 子任务 2.2- [ ] 完成其他任务列表中的 Checklist你还可以将 Checklist 项嵌套到有序或无序列表中，例如：1. 主要任务- [ ] 子任务 1- [ ] 子任务 22. 其他任务- [x] 完成 A- [ ] 完成 B使用快捷键在 Obsidian 中，你还可以使用快捷键来创建 Checklist 项：Windows/Linux: Ctrl + Shift + CmacOS: Cmd + Shift + C这将在光标位置插入一个新的 Checklist 项。
利用搜索和过滤Obsidian 还提供了搜索和过滤功能，你可以使用搜索功能查找所有未完成的任务或已完成的任务。
例如，你可以搜索- [ ] 来找到所有未完成的任务。
这是基本的 Obsidian Checklist 的用法。
你可以根据自己的需求和工作流程进行调整和扩展。
check list的几大要素
Checklist的几大要素
Checklist的几个重要要素是：项目/任务、步骤、条件和标记（或勾选）方式。
1. 项目/任务：Checklist的首要要素是明确列出需要完成的项目或任务。
这些项目可以是工作任务、检查清单的事项、待办事项或需要遵循的步骤。
2. 步骤：每个项目或任务通常包含一系列需要执行的步骤。
步骤是指完成项目所需的行动或操作。
逐步明确列出这些步骤，可以确保在执行任务时不会遗漏关键细节。
3. 条件：Checklist的有效性还需考虑任务执行的条件。
条件是指完成项目或任务所需满足的先决条件、环境要求或其他相关情况。
在Checklist中包含适当的条件，有助于确保在适当的环境下执行任务。
4. 标记/勾选方式：Checklist的目的是跟踪任务完成情况。
为了实现这一目标，需要一种标记方式来记录已完成的步骤或任务。
常见的标记方式包括打勾、打对号、使用符号或颜色等方法。
这些要素的组合构成了一个完整的Checklist。
通过明确描述项目、步骤和条件，并使用适当的标记方式，Checklist 可以提供一个简单而有效的工具，帮助人们管理任务、确保重要步骤不被忽略，并提供一种可视化的方式来追踪任务的
进展。
CK (项目名称)项目评审Checklist
R3.项目终验
从业务需求满足、架构、供 应商支持、IT服务、项目管 理规范性等方面，对项目做 最终验收。
评审纪要输出人 备案
项目评审指标（check-list)
A类：PMO B类：IT项目经理
PMO
《P2.立项阶段评审指标》
A类：PMO B类：IT项目经理
PMO
《P3.方案选型评审指标》
项目经理
PMO
1、业务:项目总监、业务项目经理、集 团对口职能部门 2、IT:专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、运维 1、集团管理部门:集经、集财 2、业务:项目总监、业务项目经理、集 团对口职能部门 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财
阶段
阶段评审目的
评审小组成员
1、集团管理部门:集经、集财 2、业务:项目总监、业务项目经理、集 团对口职能部门 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财 1、集团管理部门:集经、集财
P2.立项阶段
项目目标、需求明确、清晰 、可行
P3.方 2、业务:项目总监、业务项目经理、集 合美的IT架构要求，达到可 团对口职能部门 招标要求 3、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、IT财、商务 1、业务:项目总监、业务项目经理、集 需求经过充分调研，项目组 团对口职能部门 对业务需求理解清晰、准 确，得到业务的评审、确认 2、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 1、业务:项目总监、业务项目经理、集 团对口职能部门 总体方案能满足业务的需 2、IT:IT总监、专业系统部负责人、 PMO、IT项目经理、事业部IT经理、架 构师、运维
项目checklist模板doc资料
量产前的天线测试报告，是否为开模样品 。否则不予确认。只给针对样品的报告数 据
客户ID是否完成评审、备案。有否和其他 客户冲突接近
客户MD是否完成评审
是否告知客户我司的单机下载工具 是否告知客户我司的多串口下载工具 客户 相关 客户的供应商是否审核完整，包括屏，摄 像头，天线，电池厂家，FPC厂家。目前 要求这5类。大客户的话，喇叭也要求
分类分类项情况最后更新操作时间原因备注项目信息表是否及时更新原理图和摆件评审原理图评审时注意核对功能需求包括哪些资源是复用的而导致有些功能只能两选一等layout评审后续gerber文件的更新变更是否描述清楚是否写明了板子的内存种类拼板大小在文件名中bom归档后的差异料跟踪生产资料核对钢网的制作安排
客户第一次小批量装机的跟踪需要，和聂浅进行沟通。
若前期评审有错，以最后一次改进时间为准 。如果客户没有把改进的MD发来，此处留 空并且跟催。完成标志是必改项为0 保存校准参数的方法等。
需要签署封样的，例如中宝的，留有签署封 样的文件
生产资料核对，钢网的制作安排。有否因 为特殊机型需求，区别钢网，堵住某些开 孔等
过程 PR1试产前，软件的安排准备
PR1试产前，外围料安排准备，LCD，摄像 头，按键板等供调试用
样品要求器件上带有规格型号。
第一次发布正式版本前，对软件共性问题 的提前预防和监督。使得V001对测试部而 言有意义。
PCBA的调试结论是否给出，作为量产投板 依据
XY项目备忘
分类
分类项
情况
最后更新/操作时间
原因备注
项目信息表是否及时更新 原理图和摆件评审
原理图评审时注意核对功能需 求，包括哪些资源是复用的而导 致有些功能只能两选一等
项目进阶check list
13
系统兼容性、可靠性测试报告输出
Test
14
重量、尺寸、performance、battery life符合spec要求
15
所有严重等级1、2的issue已经解决，等级3的issue经客户同意
16
SE MP系统BOM整合完成
17
PM 更新key part list&EC level，关键部件至少2个source评测完成，满足供应需
32 产品经理 产品成本是否符合要求
33
TE 量产测试工装list、产线测试程序、preload image输出完成
33 策采 替代料按要求完DQE、质量管理部经理、PM、EE、EE经理、BIOS、EC、软件经理、散热、散热主管、系统兼容性测
Result DQA check Remark
、散热、散热主管、系统兼容性测试工程师、可靠 MPM、Driver工程师、WHQL工程师、认证工程师
list
Result DQA check Remark
热主管、测试工程师、测试工程部经理、PE、ME
参加人员
、ME经理、产品经理、MPM、SE、EMC工程师、CE主管
决策
Check Result
DQA check Remark
热、散热主管、测试工程师、测试经理或主管、PE 品经理、部件开发工程师
Result DQA check Remark
热、散热主管、系统兼容性测试工程师、可靠性测 主管、SE、EMC工程师、部件开发工程师、RF工程
5
RF 手板RF测试报告已经输出，issue有详细可行的解决方案
6
EMC EMI/ESD测试报告已输出，issue有详细可行的解决方案
7
QC品质管理中需要检查的项目check list
、 工 程……等 6〃决定查检表的格式。（图形或表格） 7〃决定查检记录的方式。如：正、++++、 △、√、○
四、制作的方法
1.
点检用查检表 A〃详列点检项目 B〃顺序 C〃层别 D〃可先用，如不符合再改善
2〃纪录用查检表
A〃列出所需的项目及所需要收集的数据 B〃决定格式 C〃决定记录的方式。如：正、++++、△ 、√、○。 D〃决定收集数据的方法
查检表(Check list)
一、目的：
1〃确认作业过程中,防止作业疏忽或遗漏
2〃利于资料的记录
二、种类
1〃点检用查检表:在设计时既已定义使用
的，只做是非、仪器保养维护的实 施状况或为预防事故发生，以确保使用时 的安全。此类检查表主要是确认检核作业 过程中的状况，以防止作业疏忽或漏洞。
五、制作要点
1〃如可以可先行参考他人的实例 2〃愈简单愈好 3〃一目了然
4〃以TEAM
WORK 方式进行，集思广益
六、实例说明
2〃记录用点检表：此类查检表是用来搜集
计划资料，应用于不良原因和不良项目的 纪录，作法是将数据分类为数个项目别， 以符号、划记或数字纪录的表格或图形。 由于常用于作业缺失，品质良莠等纪录， 故也称为改善用查检表。
三、制作检查表应注意的事项
1〃明了制作检查的目的 2〃决定查检的项目 3〃决定查检的频率 4〃决定查检的人员及方法 5〃相关条件之记录方式,如作业场所、日期
设计和项目checklist
项目周会 Check List（草案）
投模决策 模具制造
ESL1 ESL2
小批 pilot 量产
项目周会 Check List（草案）
市场调研、成本分析 项目研究计划表：设计工程师研究计划（样机研究，标准研究，功能结构评估） 专利搜索报告 标准研究计划表：品质工程师标准研究计划（标准释放，对比，解读，培训）、 测试资源评估清单：测试资源评估表准备（测试工装，仪器，设备，耗材） 可行性分析报告释放计划 意向书：明确 目标市场/目标成本/目标客户/主要性能参数/项目计划 客户流程确认（CPA，KFPS，各阶段样机需求计划） 实验大纲编制，讨论，释放计划
意向书 实验汇总表 拆机分析报告
ESL2物料到料清单：ESL2物料监控，到料测量确认 项目改进计划表更新：整机装配问题汇总，改善计划表更新执行监控 项目改进计划表更新：Artwork及ID参与确认相关外观及造型的问题点recheck. 装配工艺表：装配工装，检具，设备改善结果验证 测试设备清单：测试资源改善验证 ESL1品质评估报告：ESL1品质评估计划，测试情况监控跟踪（特别关注：使用，耐久，寿 命，温升,EMC） 项目改进计划表更新：ESL1阶段问题点改善结果确认 小批申请单释放 认证摸底，认证样机准备（特别关注：噪音，温升，耐久） FFU摸底，客户特殊测试要求摸底，FFU样机准备 小批检指，图纸发行计划，检具移交IQC计划 BOM进系统计划（物料清单爆炸图释放计划，商务档案释放计划） 试制完成2天内将包装样机安排寄出
PM
投模决策后5个工作日
包装 投模决策前5个工作日
RD
投模决策后5个工作日
RD
EOS后3个工作日
QA
项目上线自查文档(Check_list)
15UI、交互测试来自16产品原型、流程图、PRD
17
产品 上线通知
18
产品上线后检验
产品上线自查清单（Check_list）
详细内容
IOS：AppStore Android：小米、360、华为、oppo、应用宝.... 尺寸、logo、根据各个应用时长规格要求确定 闪现审核时要把苹果相关物品和宣传内容进行屏蔽 通用模板 通用模板 代码是否符合上线标准 部署服务器、域名解析等 各个发布渠道要有单独的渠道包 功能相关接口要先上线 确保版本号的连续性 数据统计、推送等服务 与产品需求保持一致 常用机型和系统 根据需求 UI设计师也要参与UI验收 所有文档都与线上功能保持一致 确定上线内容、通知对象等 产品经理自行检验、需求方检验反馈（检验内容：交互、逻辑等）
产品上线自查清单（Check_list）
序号 事项分类
事项说明
1
确定产品发布渠道
2 3
运营
应用商店介绍图 IOS版本的媒体内容管控
4
应用提交文案
5
新版本产品功能介绍
6
代码review
7
上线部署
8 9
技术
渠道包打包 接口上线确认
10
版本号管理
11
第三方服务确认
12
功能测试
13 14
测试
系统兼容测试 冒烟测试、回归测试
跟进人 张三
赵六 小红 小清
责任人 是否完成 张运营
赵技术 小白 小蓝
备注
检查表（checklist）的使用--测试
检查表（checklist）的使⽤--测试检查表checklist很常见，各⾏各业都有，但是作为电信运营⽀撑系统这样⼤的软件系统的实施和开发，却。
检查项⽬并不是⼀成不变的，也不是随便想⼏个就可以的，否则会成为摆设。
⼀定得要有过程管理思想并深刻体会到其中的关键点进⾏监控。
每个团队、每个时期都是动态变化的，checklist是⼀种动态的⼯具。
除了过程，可以使⽤在其他⽅⾯，例如：各种评审。
checklist可以让⼯作标准化，但是快速发展的团队和⾼效⼯作似乎不需要标准化？错，这要看checklist的内容是什么。
总会有需要checklist的地⽅并且能起到真正的作⽤。
测试⽤例检查表是否每个⽤例测试⼀种单独的情况⽤例是否有测试数据⽤例是否有预期结果是否明确描述了测试数据的异常值、正常值、边界值预期结果是否可以再现测试⽤例是否分级展现是否有数据恢复脚本是否有优先级是否是可⽤状态（ready）每个⽤例是否覆盖了测试需求是否有设计时间(⽤例完成设计的时间)是否被评审过测试场景检查表场景是否由⽤例组成的场景是否有优先级是否每个场景中的⽤例已经run是否被评审过测试需求检查表涉及到数据库连接是否明确了连接个数和⽅式是否每个测试需求相对独⽴测试需求之间不应该存在因果关系测试需求中不应该存在模糊描述（⼤量、很多、长时间等等）测试需求的来源是否可靠（不会被随意改动）测试需求描述是否清晰⽆歧义是否被评审过是否设定了优先级测试需求是否包含了业务需求是否把复杂的业务需求分解了是否每个测试需求都有明确的输⼊输出，便于测试defect检查表是否描述清晰:出现问题的环境简要描述是否描述清晰:出现问题的操作过程描述是否描述清晰：问题现象描述清楚是否提出了⾃⼰的分析是否指定了解决⼈是否跟踪了每⼀个⾃⼰的bug是否有未关闭的bug是否提出bug之前检查了没有⼈已经提出来过（不重复）是否每个defect描述⼀个独⽴的问题是否及时修改了defect状态是否填写了应该填写的字段不能带有主观的对程序的评价bug描述中不能带有疑问句是否填写了优先级是否填写了严重程度测试计划检查表是否符合项⽬⾥程碑时间要求是否安排好了执⾏时间计划是否安排好了执⾏⼈计划计划安排是否粒度到天（周）是否有测试⼈员培训计划第⼀、描述了项⽬的⽬的第⼆、描述了项⽬的开发周期第四、描述了测试案例的设计周期第五、描述测试案例的执⾏周期第六、描述了测试过程中⽤到的⼯具或者技术第七、描述了测试过程中⽤到的资源情况每⼀部分测试计划时间安排是否有冲突是否有测试过程检查机制测试过程检查是否涉及到其他组是否取得了相关组的认可是否经过了有项⽬经理参加的评审是否有测试执⾏⽇报告机制是否有风险分析以及规避⽅法是否有测试环境描述是否有测试⼈员协作机制是否有测试⼈员考核点描述并且可⾏是否有其他组协作机制描述测试环境更新检查表是否是在确认了版本⽆误的情况下更新的是否有配置⽂件更新是否可执⾏程序权限正确是否记录了编译错误并报告更新后是否做了冒烟测试更新后是否记录了更新过程如果更新步骤或内容有变化是否同步更新了作业指导⽂档更新问题是否提交到CVS更新问题是否通知到相关⼈员是否记录了本次更新经验（版本更新⽇志）测试⽅案检查表是否描述了测试⽅法是否描述了测试参与⼈员是否描述了测试环境是否描述了⼈员协作办法是否相关⼈员已经通知到是否描述了测试内容测试内容时候细化到模块是否描述了测试时间安排是否描述了测试⼈员培训安排是否描写了测试说明章节是否进⾏了换位思考（别⼈能读得懂吗）是否有备份⽅案是否经过评审准备测试评审检查表是否提前给开发组和项⽬经理以及相关⼈员发送了评审材料是否预定了会议室和预约了合理的时间是否准备了与会材料和⼯具（投影机等）是否主讲者已经演练了⼀下是否最好了被推翻重来的准备是否做好了听取改进意见的准备是否做好了改变原有思路的准备是否做好了⼤家都没有意见的准备是否做好了需要⼆次评审的准备是否做好了由于各种原因评审会失败的准备是否检查过了被评审材料压⼒测试检查表是否已经清楚了实际业务的压⼒情况是否已经预估了业务发展趋势和量化了增长速度是否预估了产品的⽣命周期是否预估了产品⽣命周期内业务量可能的峰值是否统计了业务峰值时间段以及峰值业务量是否已经明确了⽣产系统的主机分布。
项目测试管理CheckList_V1.0_xxx
项目测试管理CheckList Prepared by Date 2009-10-26
编制日期
Reviewed by Date
审核日期
Authorized by Date
批准日期
All rights reserved
版权所有违版必究
1、内容填写说明
A、项目基本信息由测试用例设计者填写。
B、自检，根据检查结果在自检结果“是、否、免”相应栏中作“V”标记；是：满足要求，否：不满足要求，免：内容不涉及此项目；在“否、免”栏作“V”标记，必须在自检说明中填写原因。
C、审查，确认自检结果是否正确，如与审查项目一致：在互检结果“是”栏作“V”标记，否则：在审核结果“否”栏作“V”标记，并在审核说明中填写原因。
D、“自检结论及问题说明”由测试用例设计者填写，在此栏说明该项目检视的要点，方便审核者检查。
“审核结论及问题说明”由审核者填写，在此栏列出审核结果中为“否”的所有问题。
E、最终QA将此文档提交给运作支持部，进行数据备份，整个过程由运作支持部跟踪。
项目管理之CP评审Checklist
必选
QA是否按照质量策划审视项目质量活动开展情况，并对质量目标、验收标准达成情 况做评估，交付件做审核，且结论为通过？
必选
SE是否组织需求澄清且输出需求列表\产品backlog、需求跟踪矩阵？需求澄清过程是 否有需求澄清记录表？最终符合SOW以及客户要求。
研发工具是否有相应规划？1、软硬件环境资源（服务器、TC&显示器、开发环境、 测试环境、持续集成环境等）2、研发工具：SVN、DTS、jira 、PDM、PIA等。--研
可选
PM
发工具类有规划即可，计划阶段不强行要求，需求阶段需到位。
质量策划：PM是否组织关键角色制定质量策划。
1、质量策划中包含如下内容：
期，里程碑时间点、验收要求、验收标准，版本计划、交付件列表（软硬件交付件， 工程文档），过程记录、需求列表等和客户达成一致。注：因项目形态选用需求列表\
必选
PM
产品backlog。 PM是否组织关键角色制定项目计划（包含CP评审，如果涉及阶段验收或迭代验收的
也必须列入）、评审计划（包含但不仅限于交付件评审和CP评审）、交付件清单、培 必选
必选
PM
可选
PM
TC是否组织测试，遗留问题\DI是否符合SOW要求？所有测试用例执行结论是否为通
过（预期结果和实际测试结果相同）？（不通过的，已和客户达成一致。）
必选
TC是否组织测试，遗留问题\DI是否符合SOW要求？脚本测试结论是否为100%通 过？（不通过的，已和客户达成一致。） TC是否输出测试报告，测试评估最终结论是否符合阶段验收或发布，且符合SOW要 求？ 项目组所有交付件已归档配置库，且符合上线/阶段验收要求？
遗留问题
cp2
遗留问题 \DI
文档报告类文件自检 CHECK LIST
2
3 4 5
签名
检 CHECK LIST——20140506
项目编号 自LIST——20140506
项目名称 项目 1 评审要素 项目编号 自检结果 是 否
文档标题、页眉、页脚是否和文档报告主题一致/文档内外标题是否一致/文档报 告目录与内容是否一致 如为PPT形式的报告：是否使用了标准的公司模板（有公司LOGO和名称落款做背景 的） 文档各级标题和排版格式是否统一、是否达到美观要求（标题分级分明，行距、 字体格式、字体大小、悬挂收缩等符合常规审美要求）。 文档报告是否描述清楚了“是什么——怎么做——做的结论” 文档内插入的图片是否必须/是否说明了文档报告主题/图片是否清晰/同类图片尺 寸大小是否一致
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
29
QA试产检查
30
QA外观、功能检查
31
QA结构评价
32
AM评价
33 34
项 目 检
ID评价 HW测试
35 36
测 与
PRT MFG试生产报告
37 评 QA汇总
38 价 PL评价
39
环境物质调查
完成后由QA汇总到《项目评价报告》中， 并按附件形式归CQS，
ISSUE由PM汇总到《ISSUE LIST》中
40
客户特殊要求评价
41
验证性评价
42
试用报告
43 部品 部品评价
44 附件 附件评价
45 评价 Spec认定
阶段
1）按《阶段目标评价》check list进行；2）每次试生产结束后
46 目标 阶段评价
的第2-3周内进行；3）完成后归CQS，4）ISSUE归《ISSUE
评价
LIST》
及时生成：1）PR1（EP1）试生产结束的第3天生成，2）每次
总结会：15个工作日内
DCC归档发布前确认是否评审（评审表有否），是否归CQS
细化的文件LIST
项目：
Owner:PM
标准要求
DP DR EP SP PP MP 备注
◎○●
◎●
◎●
◎●
◎●
●○○○
◎● ◎●
●○○ ● ● ● ◎● ◎● ◎◎●
◎● T1 T2
◎● T◎1 T●2 P1 P2 ◎● P1 P2 ◎◎◎●
试生产的2周内附件形式提交QMS-CQS，3）PR3（无PR3时
47
ISSUE LIST
PR2）（SP）开始每周更新，发布给项目组成员和各部门主管
以上人员；4）SA后和所有ISSUEClose后按最终版本（CQS输
ISSUE
48 管理 Root Cause Nhomakorabea49
Action
50
入的文件名中注明）以附件形式提交CQS 分析有效 制定有效 实施结果有效，有验证报告
PID layout
归DCC，同评审表
17
组装爆炸图
归CQS，H评审签字归档DCC，
18
2D图
归DCC，同评审表，发布
19
3D图
归DCC，同评审表，发布
20 项目 结构改进通知单
归CQS，H归DCC，ME发布
21 设计 HW设计输出文件包(Gerber归文D件C/CPC，B同la评yo审u表t/工，厂发文布件等系列文件 )
输出
22
HW改进通知单或新版设 计输出文件包
归DCC，同评审表，发布
23
各正式版软件
归DCC，发布
24
用户手册
评审OK后归CQS
25
维修手册
评审OK后归CQS
26
生产文件包（WI、测试文件评等审）OK后归CQS
27
BOM
从PR0、0开始归DCC
28
项目文件汇总， 外发FTP
依据关流程规定执行；通知客户
明）以附件形式提交CQS
54
Qualify
PP前第2周完成，DCC发布报告
55 SA SA CHECK
归CQS，ISSUE归《ISSUE LIST》
56 项目 项目总结会
SA后正式召开项目总结会
57 总结 提出改进计划
正式发布改进计划
58
分析完成：1周内
59 售后 售后质量分析
反馈：10个工作日内
60
6 设计 project schedule
归CQS
7 输入 外来文件
归CQS
8
项目联络表
归CQS
9
与客户确定标准
归CQS，发客户、OEM、供应商
10
项目特殊要求
归CQS，发相关方
11
客户需求变更
归CQS，发相关方
12
效果图
13
解析图
14
配色方案
归CQSH评审签字归档DCC，
15
3D Drawing
16
项目Check List ◎：初版、阶段版完成 ●：最终完成 ○：需要时的更新版 →：进行期
NO
检查项
要求
1
PD
经评审/归CQS/H归DCC
2
项目启动通知
归CQS/H归DCC
3
可行性研究
归CQS/H归DCC
4
UI Spec.
经客户签认/归CQS/H归DCC
5 项目 MENUTRE
经客户签认/归CQS/H归DCC
◎● ◎● ◎◎● ◎●○ ◎◎◎●
◎◎● ◎◎● ◎◎● ◎◎● ◎● ◎◎● ◎◎● ◎◎● ◎◎● ◎● ◎●
◎◎● ◎◎● ◎● ◎● ◎●
◎◎●
◎◎◎●
◎● ◎● ◎◎●
● ●
51
ISSUE 评审会
PM组织召开， 参加人员范围有效
52
ISSUE Close
所有ISSUE 要有效Close
1）PR2（EP2）试生产结束后的第二周开始建立，发布；2）
53 Qualify Qualify管理表
每周更新、发布给项目组成员和各部门主管以上人员；3）SA 后和所有ISSUEClose后按最终版本（CQS输入的文件名中注