测试部门日常工作要求规范
测试部门日常规范
文件更改摘要：
目录
1. 目的/方针 (2)
2. 工作范围 (3)
3. 工作职责 (3)
4. 主要流程图 (4)
5. 主要活动 (4)
5.1. 测试策划阶段 (4)
5.2. 模块/集成测试阶段 (5)
5.3. 确认测试阶段 (6)
5.4. 验收测试阶段 (7)
5.5. 性能测试阶段 (7)
6. 考核指标 (8)
7. 奖惩措施 (9)
7.1.加分指标 (9)
7.2.扣分指标 (9)
8. 模板 (10)
1.目的/方针
通过规范公司测试流程，确保测试工作的规范性和有效性，以验证软件产品的质量满足用户的需求。
测试作为质量控制的一种有效手段，运行测试用例找出软件中潜在的各种缺陷，通过协助开发人员修正缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患和降低质量成本。通过测试管理为产品与过程改进提供可靠的数据分析，起到缺陷预防的作用。
本过程的方针：
●实施测试策划活动
●根据测试策划所规定的要求编写测试需求与用例，实施相关的测试活动
●管理测试活动中发现的产品缺陷
2.工作范围
测试人员在软件开发过程中的任务：
1)参与评估软件需求，编写测试需求
2)根据用户需求，编写软件测试用例
3)在开发员完成单元测试后，进行模块测试，以期尽早发现bug。
4)根据软件测试用例，执行集成测试，寻找尽可能多的bug
5)对bug进行追踪与分析，保证bug及时得到修复
6)对软件性能进行衡量，并进行测试总结，提交软件测试报告书.
3.工作职责
4.主要流程图
图TTS000-1: 测试过程示意图
根据公司的开发模式以及人员情况，目前测试部门将测试工作分为下面4个阶段进行：
模块_集成测试阶段
确认测试阶段
缺陷管理阶段
验收测试阶段
5.主要活动
5.1. 测试策划阶段
5.2. 模块/集成测试阶段
模块/集成测试是在单元测试之后，验证所有开发模块能够在测试环境下满足设计要求。主要完成：?对模块和子系统的连接进行测试，确保各程序模块之间无错误连接；
?验证整个软件系统或子系统的输入/输出处理是否达到设计要求；
?验证软件系统或子系统正常处理能力和异常处理能力；
?验证是否达到产品需求，是否遵循系统设计。
5.3. 确认测试阶段
通过确认测试模拟用户真实环境，验证软件的功能和性能是否满足《软件需求规格说明书》的要求。确认测试包括：系统测试和发布测试。
测试人员职责：
5.4. 验收测试阶段
详细规定在产品发布后，由项目实施部门组织或配合客户进行验收测试的过程，确认发布的产品满足用户需求。验收测试是在客户环境或模拟客户环境下验证软件的功能和性能。
测试人员职责：
过。
5.5. 性能测试阶段
检查软件的平均响应时间或者吞吐量是否符合指定的标准。
6.考核指标
7.奖惩措施
为调动组内员工的工作积极性，组内特设立月度绩效工资，将以上考核指标作为绩效工资的评定标准。其中附加指标分将对表现突出或较差的员工进行（0，15）区间加减。
7.1.加分指标
1.工作认真负责，在测试项目中有优异表现。
2.发布的Q/A具有针对性、实质性。
3.提出建设性意见，并被公司采纳实施。
?提出的意见直接被公司采纳并实施的；
?提出的意见对公司的管理有很大的启迪作用，经修改后实施的；
?提出的意见对公司没有直接帮助，但有一定的建设性。
4.用户培训满意度在80分以上。
5.配合项目组加班加点，超额完成任务。
6.其他对公司有特殊贡献的表现（对公司的市场、产品改进、核心技术、关键问题解决等）。
7.2.扣分指标
1.不按工作流程执行工作或提交文档的。
2.用户培训满意度在60分以下。
3.其他由于工作疏忽导致重大责任事故（对公司的市场、业务、产品质量、公司信誉和形象造成不良
影响或一定损失）。
8.模板
Q/A反馈表
日期：反馈人：
(完整版)项目测试规范
项目测试规范 编 制 ： 审 核 ： 批 准 ： 文 件 编 号 : 版 本 号 : v1.0 秘 密 等 级 ：普通级 发 出 部 门 : 颁 发 日 期 : 年 月 日 发 送 至 ： 抄 送 ： 总 页 数 ： 页 附 件 ： 主 题 词 ：
文件更改历史更改日期版本号更改原因
目录 1编写目的 (4) 2测试团队构成 (4) 2.1职责 (4) 2.2角色划分 (4) 3工作流程及规范 (5) 3.1计划与设计阶段 (5) 3.1.1成立测试团队 (5) 3.1.2测试预通知 (5) 3.1.3召开测试启动会议 (5) 3.1.4编写测试计划文档 (6) 3.1.5设计测试用例 (6) 3.2实施测试阶段 (7) 3.2.1实施测试用例 (7) 3.2.2提交报告 (7) 3.2.3回归测试 (8) 3.3总结阶段 (8) 3.3.1编写测试报告 (8) 3.3.2测试工作总结 (9) 3.3.3测试验收 (9) 3.3.4测试归档 (10) 3.4缺陷跟踪 (10) 4缺陷类型定义 (11) 5测试标准 (12) 6争议处理 (12) 7标准文档 (12)
1编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： ?在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 ?编写合理的测试计划，并与项目整体计划有机地整合在一起。 ?编写覆盖率高的测试用例。 ?针对测试需求进行相关测试技术的研究。 ?认真仔细地实施测试工作，并提交测试报告供项目组参考。 ?进行缺陷跟踪与分析。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。
测试流程及规范
测试流程及规范标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
1目的 侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。 本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。 2概念与术语 在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示： 公司研发流程的实际情况，此测试也可由设计研发人员执行。 2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。一般采用自底向上或自顶向下的模块集成方法，逐步集成。在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。
3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试”的基本原则。 4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。 5）TD：全称Mercury TestDirector，一种测试管理工具。 6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。 3职责 组建测试小组 协调测试小组内外部的沟通
部门工作规范和要求细则
****处日常办公规范和要求细则 为加强部门建设，改进工作作风，提高工作效率，树立良好形象，营造教书育人，管理育人和服务育人的氛围，结合部门实际，制定本规范： 一、按时上、下班（上午8:20-12:00，下午14:10-17:30），如当天有特殊情况不能按时上、下班的需向分管和部门负责人请假，履行相关手续； 二、上班期间，待人接物要热情周到，不准面对来办事的教职工和学生用餐点，办公室来电、来访由老师负责接待，需送达到校内部门的材料，须由老师负责，树立服务意识； 三、上班期间，需中途离开办公室的，应将去向告知办公室其他同事，办公室老师一般不能同时离开，如确需同时离开，需向部门负责人报告，明确岗位职责； 四、上班期间，不做与工作、学习无关的事情(特别是观看影音视频)，通过网络QQ、飞信或邮件等发表言论或布置工作时要注意方式方法，校园内公共场所衣着打扮整洁，言行举止得体，树立师表风范； 五、工作中需由教学系配合完成的，应主动联系教学系学生工作负责人（系副书记），不直接针对辅导员老师或学生安排工作，讲求工作程序； 六、保持通信工具畅通，在未接到本部门办公电话或部门同事来电时，应在知晓后立即回电，及时沟通信息，特别是晚间或假期。 七、清扫办公室地面卫生、烧开水、买食品（含餐点）等与工作无直接关系的事项由老师自己处理，培养劳动观念； 八、上报、下发相关材料需经分管工作领导或部门负责人审核同意，要求参照部门文字材料排版须知妥细致、细心地处理好，维护部门形象； 九、每周四各科室将需要在学生工作例会上强调布置的工作内容报分管领导，以便统一安排部署，并由办公室综合干事汇总形成简要会议提纲在会前发放，学生工作例会纪要（提纲式）电子稿需在会议结束后当天发给各系学生工作书记，提高工作效率 十、妥善安排勤工助学同学的值班，一般每次由无上课任务的2名同学轮流当班，不得做与学习和工作无关的事情，处理工学关系； 十一、热心指导勤工助学同学，安排做一些力所能及的工作或整理基础材料，每项工作结束时需由安排的老师审核工作结果，严格质量把关； 十二、加强对办公室勤工助学同学的培养教育管理，勤工助学同学不得留有办公室钥匙，不准在没有老师在场的情况下（含节假日、周末、晚上等非上班时间）留守在办公室，不准在没有允许的情况下使用老师的电脑，明确工作要求。 十三、公章由综合干事专人管理并锁起，各科室使用公章要树立责任意识，做好登记和监管工作，尤其不得丢给学生帮忙代为使用。 请大家自觉遵守，相互监督，共同进步。 *****处二0**年十一月十二日
产品部工作规范及流程图
产品部工作规及工作流程 一、 产品团队组成 二、 产品周期流程 三、 产品设计流程 3.1 产品立项 产品小组开会讨论产品立项： 3.1.1 讨论产品需求并分析产品主要功能点。 3.1.2 讨论并拟定产品交互体验与产品视觉体验。 3.1.3 工作周期计划。 3.2 产品设计 使用Axure RP 对产品实现高保真的原型设计。 产品界面、功能不出现遗漏。 产品 立项 原型设计 原型确认 UI 设计 UI 确认 前端开发 前端确认 设计 周期 开发周期 测试周期 PRD 编写 产品经理 前端开发 UI 设计 测试 产品上线 阶段跟踪
原型交互体验应满足贴近真实产品90%的效果。 3.3 产品原型确认 3.3.1产品原型是否满足需求功能。 3.3.2产品原型交互体验评测。 3.3.3产品原型交互体验改进措施。 3.3.4讨论对产品UI设计。 3.4 产品UI设计与确认 3.4.1UI与产品原型是否相符 3.4.2视觉效果是否满意 3.5 产品前端设计与确认 3.5.1前端与原型保持一致性。。 3.5.2前端与UI保持一致性。 3.5.3前端不足改进措施。 3.6 产品PRD编写 通过产品原型图例对产品进行功能性描述。 四、产品开发进度跟踪流程 4.1产品开发沟通会议 4.1.1讲演产品：使用产品原型与PRD文档对产品进行讲演。 4.1.2需求沟通：对需求进行讨论。 4.2提交资料准备开发 产品部与技术部开完产品开发沟通会后，将前端文件（HTML），原型（Axure RP），开发需求文档（PRD）等文件提交到技术部。 4.3产品开发追踪 五、产品测试流程（参照产品测试规） 5.1产品测试 根据产品PRD文档与产品测试用例对产品进行功能点测试。 使用压力测试、兼容性测试等手段对产品进行性能测试。 5.2产品验收 产品通过功能测试及性能测试，测试人员给出总结报告，对该产品能否
测试规范及流程
xx公司 测试流程及规范 xx限公司 2017年9月
版本历史
目录 XX公司测试流程及规范 (1) 版本历史................................................................................................................... I 目录 ....................................................................................................................... I I 1.目的 (1) 2.测试流程介绍 (1) 产品验收前 (1) 产品验收后 (2) 3.编写测试用例的方法 (2) 等价类划分 (2) 边界值分析法 (3) 错误推测法 (3) 3.3.1.因果图分析 (3) 4.测试方法 (4) 黑盒测试（功能测试） (4) 用户界面测试-UI测试 (4) 随机测试 (4) 性能测试 (5) Β测试–此方法针对的是非程序员和测试 (5) 5.缺陷等级划分 (5) 产品验收前定义 (5) 产品验收后定义 (6) 6.缺陷报告.............................................................................. 错误!未定义书签。
1.目的 编写此文档是为了规范本公司的测试流程，为快速、高效和高质量软件测试提供基础流程框架。提高测试人员自身测试能力，使测试更加规范化和标准化。 2.测试流程介绍 产品验收前 需求分析书 提取测试需求 设计测试用例 搭建测试环境 进行功能点测试 提交BUG 进行系统测试 追踪BUG 回归测试 关闭BUG
部门日常管理制度
部门日常管理制度 为规范部门日常办公的管理，创造文明、整洁的办公环境，维护正常的办公秩序，树立良好的部门形象，提高办公效率，利于部门各项工作的开展，特制定本制度。 第一条、严格遵守考勤制度，准时上班按时下班，上下班时间按公司规定执行。 第二条、不得将可能影响办公环境的与工作无关的物品带入办公室。不得私自将部门财产带出。第三条、工作时间内不应无故离岗、串岗。外出或办私事，如确有需要须向部门领导请假告知批准，并在白板上留言去向后方可离开。 第四条、工作时间内必须穿公司统一下发的工作服及劳保鞋，着装整洁、得体，不得穿露出脚趾及后跟的凉鞋或其他不适宜的装束，不准佩戴夸张、异类、过大的饰物上班。 第五条、工作时间内不得大声喧哗、嬉戏打闹、聚堆聊天、玩游戏、浏览与工作无关网站；任何时候不得使用不文明语言和肢体动作，确保办公环境的安静有序。 第六条、工作期间不得饮酒，不得带有酒精状态上班。 第七条、下班后，必须关闭电脑、电器等耗电设备。把座椅摆放整齐，收拾好桌面办公用品，维持办公室清洁。最后一位离开办公室的人员应检查窗户是否关闭，关灯，锁门后方可离开。 第八条、开会时，将手机调至静音或振动状态，有重要电话必须接听须到会场外应答。 第九条、遵守保密纪律，保存好各种文件及技术资料，不得泄露公司机密。不得利用公司网络资源发布、转发任何形式的不当言论和垃圾邮件。 第十条、合理节约部门办公用品开支，降低低值易耗品如：笔、纸、电池、订书钉、胶水等的支出，严禁将办公用品带回家私用。 第十一条、所有办公室人员应妥善保管、爱护和使用各种设备、办公用品等，无故损坏办公设备等应按照原价予以赔偿。对各种设备应按规范要求操作、保养，降低消耗和费用，发现故障，应及时报请维修，以免影响正常工作。 第十二条、个人所属的桌椅、设备/工具、垃圾桶由各使用人自行清洁；部门所属的文件柜内部由指定专人负责整理和清洁；共用工器具做到随手清洁，及时归位； 第十三条、办公室值日每日轮流打扫，值日人员需提前到办公室做好办公室内的卫生工作，若发现忘记打扫卫生者，给予一周打扫卫生的处罚（注：垃圾桶不超过3/4满，水桶及塑料盆内不能存放污水）。 第十四条、办公室所有人员应互相检查、互相监督，共同创建安全、整洁、舒适的办公环境。 第十五条、本制度未涉及到的员工日常行为规范，严格按照公司下发的员工手册执行。 本制度适用于部门所有人员，自X年X月X日下发起实施。
测试部测试流程规范
测试部测试流程规范 目录 1目的 测试工作流程是开展测试工作的基础，本规范对测试流程中的关键环节点进行约定，明确测试时必需进行的工作项，所有的测试任务必须按照本规范的要求进行。 2规范的适用范围 测试部门执行的所有测试任务
3基本测试流程 PC/APP流程区别不在此处体现 4流程关键环节点说明 4.1测试准备 1.测试任务负责人在接受到测试任务后，必须对需求进行分析，完成测试需求的整理，评估工时与人员分工，制定测试策略，明确测试方法、测试范围。 2.根据项目级别（B级以上项目）需要有用例评审环节，避免在重要功能模块上与产品、开发产生歧义，降低项目在验收阶段需要返工的风险。 4.2准入测试 必须对开发提交的开发结果进行可测试性验证，准入测试结果需要告知任务相关人（测试主管、开发、产品经理、其他相关人员） 注：准入测试标准可以在测试需求分析阶段得出，经与任务相关人员共识后作为工作任务提交测试的标准； 4.3测试执行 必须按照共识的测试方法和测试范围对系统功能进行测试，测试完成后需要通知相关人员。 APP端测试执行阶段需要按照更加严格规范的checklist完成各环节测试。
4.4回归测试 系统测试完成且Bug得到解决后，必须对测试范围内的功能点和系统测试期间发现的Bug进行回归测试，保证没有遗漏或重新开放的Bug。测试完成后需要通知相关人员。补充：根据项目的排期情况UI验收并非强制需要在回归阶段执行，在系统相对稳定后即可通知UI人员对系统或app的UI设计进行验收测试，并要求UI人员提供测试报告。
4.5上线验证测试 生产环境部署上线包后，需通知相关产品构造线上数据，必须在生产环境对上线内容以及上线可能影响的内容进行测试，保证上线内容正确。测试完成后需要通知任务相关人员。
测试部门规划
测试部门规划与管理 1.引言 1.1测试部门现状 通过几天在公司的学习，观察，了解到我们公司现阶段的测试组的情况如下： 1）测试流程不规范； 2）测试文档不健全； 3）测试文档也没有控制和管理； 4）测试人员不参与需求分析； 5）被测软件没有版本控制； 6）测试部门人员多为行业的新人。 1.2编写规划目的 根据测试部门现状，以及公司领导对测试部们的重视与期望，该文档明确定义了测试部门岗位职能、测试流程、测试文档规范、日常项目工作、部门考评机制以及测试部门人员技能与业务的培训等方面，同时该文档将作为测试部门发展的一个指导，在后期的工作实践中由测试部门成员不断地改进优化，使得测试部门能够更好与其他部门成员做好产品的质量控制。 2.测试部门规划 2.1团队建设 1）岗位职能与技能：参考质量管理流程，测试人员分5各岗位,具体职能如下： a.测试部门经理：负责测试部门发展规划、协调测试部门资源配合公司各个项目的测试工作、 组织培养测试部门人员的技能和业务培训，指导测试人员技能提升与职业发展。 b.配置管理员：负责公司各个产品的软件版本控制，包括代码版本和文版本以及相关变更控 制，在项目的不同阶段输出相关的配置文档，如：配置管理计划、配置审计报告等 c.测试组负责人：负责项目测试环境搭建和bug管理库的维护、同时负责协调测试组所有事 宜，包括与开发、需求、设计人员的沟通，分配任务并指导团队测试人员做系统测试，在 项目的不同环节阶段输出相关的项目文档，如：测试计划、测试报告以及部分测试用例的 编写。 d.性能测试工程师：负责项目的性能测试工作，输出文档：性能测试计划、性能测试用例、 性能测试报告等。 e.功能测试工程师：负责项目的功能测试和流程测试，提出bug到bug管理库。输出文档： 功能测试用例、功能测试报告。 根据公司现状，测试部门目前暂时定位为：测试部门经理、测试组负责人、功能测试功能师3各岗位。配置管理的工作与项目人员沟通，配备专人参与，要求测试人员也要从中学习， 性能测试工程师工作由测试团队人员共同来做，必要时测试经理参与。 2）测试人员技能要求：测试岗位不同技能要求的程度也会有所不同，测试团队的成员应该对现市场上比较流行的各种测试软件都应有简单的了解，对于公司部门内部使用的测试工具能够灵活运用。以下测试技能和工具需要部门人员能够掌握到一定的程度： a.测试部目前选择testdirector做为部门的bug管理工具：要求测试部人员对于从测试需求 到bug列表管理的功能熟练使用，并能够做测试报告总结。对于测试组负责人和配置管理 员除了功能使用外系统管理员的常用功能使用熟练。对于市场上流行的Bugzilla、bugfree、 QC、mantis等都能够有一定的认识。 b.测试部门目前需要LoadRunner作为性能测试工具，性能测试人员能够熟练使用该工具，利 用该工具能够分析到系统的瓶颈提高系统的性能。对于测试团队的其他成员要求，了解 LoadRunner的工作原理，脚本处理中能够做到参数化和关联，针对测试结果做简单的分析。 对于市场上流行的自动化测试工具有了解。
测试流程及规范
1 2 3目的 侧重测试工作流程及规范的控制，明确产品研发的各阶段测试组应完成的工作。测试技术和策略等问题不在本文档描述范围内。 本规范作为所有测试组成员工作前必须掌握的工作规范，也供给其它部门其它组查阅参考，以便于组间的协调沟通，更好的合作完成产品的研发工作。 4概念与术语 在整个产品的研发过程中，测试类型按照先后顺序主要分为：单元测试、集成测试、系统测试及产品确认，整个过程如下面的W模型所示： 图1 有关的测试类型的概念如下： 1）单元测试：验证产品中的模块，测试依据主要为模块详细设计或模块的需求规格。能使问题及早暴露，也便于问题的定位解决，单元测试属于早期测试，因而错误发现后能明确知道是某一单元产生的，单元测试允许多个被测单元的测试工作同时开展。根据公司研发流程的实际情况，此测试也可由设计研发人员执行。 2）集成测试是验证模块间接口及匹配关系，测试依据主要为概要设计。一般采用自底向上或自顶向下的模块集成方法，逐步集成。在此环节中测试组还负责验收研发人员提供的转测试的材料，如果材料不完备，测试组可以拒绝接收。
3）系统测试是对系统的一系列的整体、有效性、可靠性的测试，测试依据主要为设计规格及产品需求规格。目的是确认产品与设计规格、需求、行业标准及公司标准的符合性，同时还要确认性能和系统的稳定性，与之前的集成测试应遵循“相同的被测对象不要做两遍相同的测试”的基本原则。 4）除单元测试、集成测试和系统测试之外，还应有“产品确认”环节，即在客户环境中或模拟客户环境测试与验证产品，在有限的试用客户中或模拟客户环境中发现产品问题并加以妥善处理，保证产品质量，提高客户满意度。确认与实验室内部测试的区别在于：实验室内部测试要尽可能多做，多发现问题；确认要在达到质量目标的情况下尽可能少做；两者要在质量和成本之间权衡、综合考虑。 5）TD：全称Mercury TestDirector，一种测试管理工具。 6）黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。 5职责 组建测试小组 协调测试小组内外部的沟通 组织编制测试大纲（含测试用例）和计划 组织测试准入检查 测试过程中的进度控制、风险管理 测试过程报告 编写测试报告 召集测试评审 识别测试需求 参与编制测试大纲（含测试用例）和计划 协助测试准入检查 执行测试用例，测试结果记录 测试缺陷记录与跟踪 协助测试评审
(完整word版)业务部日常工作流程及工作规范
业务部日常工作流程图及工作规范日常工作流程图
业务部日常工作规范 一、业务部工作规范目的 业务工作规范的目的在于提高的业务部各项工作的效率，使业务部运作规范化和标准化。保障销售人员日常销售的畅通，通过工作流程和工作规范提高业务部人员的风险意识和工作效率。 二、市场的信息收集整理与分配 1、市场信息收集特别是客户信息收集主要分为两类：网络信息和业务员直接获得的客户信 息； 2、业务员通自己努力直接得到客户信息，并建档跟踪的潜在客户由此业务员直接跟踪管理， 所产生的销售回款，划此业务员名下。 3、网络推广专员主根负责网上信息的的发布与收集，每天所得客户信息，整理后统一交业 务部经理分配。 4、网络客户信息的分配主要以公平、平等和业务员相关知识为原则。 5、新开客户跟踪以先建客户档案者负责跟踪的原则，特殊性情况由业务经理主持，协商解决。 三、市场价格 1、产品报价，常规产品按公司指导价格报价，详见产品指导价。定制产品或在指导价格表 上没有报价的产品，则按财务部提供指导价报价。 2、公司指导价格为含税价，客户不开增值税的可以在指导价上最多下浮6%。 3、如需要申请特价，则在指导价内每降1%，业务员提成降0.1%,最低销售不得低于指导价 X0.9%。 4、如需公关或其他费用（占销售价格x%）的,则销售价格：销售价格=指导价格/（1-x%）。 三、客户结算与服务 1、新开客户首次合作,原则上现款现货的形式，定制的产品必需交纳货款30%的定金。 2、公司统一实行送货上门服务，广州市内新客户单次进货1500元以上的，公司可以货到付 款；广州市以外的新客户原则上要求款到发货。 3、客户实行帐期结算的，客户单次进货超过2万元，必需经业务经理确认后方可发货。超 过5万元以上的经总经理确认后方可发货，新客户实行帐期结算的，2万元以上定单需业务经和总经理确认后方可发货。 4、客户开增值税发票的必需在5000元以上的，但可以开一般发票，不够5000元金额，客 户必需开增值税发票的，可以累计到5000元开增值税发票。 四、其他事项 1、常规型号产品对客户的发货周期承诺3~4天；定制产品按生产部门发货期回复。 2、国标内产品的报价格以指导价格为准，业务员可以根据客户情况决定报价。 3、不在指导价格内的非国标产品和线束产品的报价最长期限在24小之内。
测试部测试流程规范
测试部测试流程规范V1.2
目录 1目的 (3) 规范的适用范围2 (3) 基本测试流程 (33) 流程关键环节点说明 (44) 测试准备4.1 (4) 准入测试4.2 (5) 测试执行........................................................................................................................ 54.3 回归测试........................................................................................................................ 64.4 上线验证测试.4.5 (6) 1目的 测试工作流程是开展测试工作的基础，本规范对测试流程中的关键环节点进行约定，明确测试时必需进行的工作项，所有的测试任务必须按照本规范的要求进行。2规范的适用范围 测试部门执行的所有测试任务 3基本测试流程 流程区别不在此处体现PC/APP．
4流程关键环节点说明 4.1测试准备 1.测试任务负责人在接受到测试任务后，必须对需求进行分析，完成测试需求的整理，评估工时与人员分工，制定测试策略，明确测试方法、测试范围。 2.根据项目级别（B级以上项目）需要有用例评审环节，避免在重要功能模块上与产品、开发产生歧义，降低项目在验收阶段需要返工的风险。． 4.2准入测试 必须对开发提交的开发结果进行可测试性验证，准入测试结果需要告知任务相关人（测试主管、开发、产品经理、其他相关人员） 注：准入测试标准可以在测试需求分析阶段得出，经与任务相关人员共识后作为工作任务提交测试的标准； 4.3测试执行 必须按照共识的测试方法和测试范围对系统功能进行测试，测试完成后需要通知相关人员。 APP 端测试执行阶段需要按照更加严格规范的checklist完成各环节测试。 此时可加入产品验收与UI调整功能测试（二轮） 版本兼容测试 性能）/接口测试（功能 设备兼容测试穿插在功能测试一二轮当中设备兼容测试 部分体验性质的可穿插在测试二轮当中专项探索测试功能回归BUG回归 客户端安装测试 客户端升级测试 封板阶段：全量回归测 4.4回归测试 系统测试完成且Bug得到解决后，必须对测试范围内的功能点和系统测试期间
测试流程规范
一、项目立项 立项阶段的主要任务是确认立项的理由，提出立项建议，使立项建议成为正式项目。 二、软件开发 软件开发阶段分为：项目规划—需求分析—概要设计—详细设计—代码编写—代码实现—测试交接—实施测试—回归测试—同行审查—测试总结—项目发布、跟踪 项目确定后，需求人员设计详细需求文档及产品原型，并制定项目计划。项目计划是一个用来协调所有其他计划，以指导项目执行和控制的可操作文件。它体现了对需求的理解，是开展项目活动的基础，也是软件项目跟踪与监控的依据。开发人员根据需求文档及产品原型编写代码。在开发阶段如果需求发生变更时，应及时以文档形式说明。 三、软件测试 项目测试的目的是检查系统是否符合项目需求规定的要求。主要进行功能测试、健壮性测试、易用性测试、用户界面测试、性能测试等（根据项目要求选择不同测试方法）测试过程在测试环境中进行。 四、基本流程 立项 主要对项目的可行性进行分析，并且确定项目是否需要测试 需求评审 需求定义完成，开发人员和测试人员对需求中不清楚、不完整、太概括或存在疑义的地方提出问题，相关人员解答并确认。需求人员在对需求进行修改的同时，应以文档形式告知开发及测试人员。 测试工作启动 在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试人员可预先熟悉必要的项目（产品）资料。针对需求分析文档和项目开发计划文档测试完成后，测试组需要确定测试过程中的风险，并设计出合理的规避分险的策略，为后续的测试工作提供直接的指导。 否 是 需求 产品人员 开发人员 测试人员 发布 是否测试 产品人员确认
(工作规范)某公司各部门日常工作流程图(规范版)
江西某汽车销售有限公司 内 部 工 作 流 程 图 目录 人事招聘流程图 (2) 转正申请/考核流程图 (3)
员工内部培训管理流程图 (4) 员工离职管理流程图 (6) 绩效考核管理流程图 (7) 员工考勤管理流程图 (8) 员工竞争上岗管理流程图 (9) 晋升晋级管理流程图 (10) 人事调整管理流程图 (11) 工作奖罚管理流程图 (12) 工作目标管理流程图 (13) 员工薪酬管理流程图 (14) 员工福利管理流程图 (15) 员工激励管理流程图 (16) 人事档案管理流程图 (17) 保密管理流程图 (18) 劳动关系管理流程图 (19) 员工满意度管理流程图 (20) 员工职业生涯管理流程图 (21) 人力资源诊断管理流程图 (22) 人力资源成本管理流程图 (23) 人力资源危机管理流程图 (24) 人力资源战略管理流程图 (25) 人力资源计划管理流程图 (26) 职务分析管理流程图 (27) 人力资源改进管理流程图 (28) 文件管理流程图 (29) 办公用品采购及管理流程图 (30) 保安工作流程图 (31) 一般客户接待流程图 (32) 按揭客户接待流程图 (33) 进车流程图 (34) 展厅展车钥匙管理流程图 (35) 售后服务工作流程 (36) 人事招聘流程图
转正申请/考核流程图
员工内部培训管理流程图
● 填写好《培训申请表》时交由相关领导 审核最后由总经理审批。 ● 《培训申请表》经批准同意后将其交至 行政部，同时由行政部组织接受外部培训的相关人员签订外部培训协议书。 ● 由行政部组织并对外部培训进行监控工 作。 ● 所有经外部培训的考试成绩及证书原件 和相关资料必均需交由公司行政部进行保存和分发工作。 ● 接受完外部培训的相关人员在回到公司 将按内部培训程序执行转训工作。 ● 行政部要根据每次培训结果组织相关部 门经理进行效果评估。 ● 效果评估后作出相对应的措施并实施 （如再训，补考等工作的开展） 员工离职管理流程图 审批外部培训申请 外部培训实施 培训考试及证书和 相关资料 转 训 签订外部培训协议 培训效果评估及反馈
软件测试人员工作规范
周忠智 软件测试工作规范 版本记录: ］草稿 V］正式发布 ］正在修改
周忠智 1.编写目的 2.测试团队构成 2.1职责.. 2.2角色划分 3.工作流程及规范 3.1计划与设计阶段 3.1.1成立测试团队 3.1.2测试预通知 3.1.3召开测试启动会议 3.1.4编写测试计划文档 3.1.5设计测试用例 3.2实施测试阶段 3.2.1实施测试用例 3.2.2提交报告 3.2.3回归测试 3.3总结阶段 3.3.1编写测试报告 3.3.2测试工作总结 3.3.3测试验收 3.3.4测试归档 3.4缺陷跟踪 4缺陷类型定义 5测试标准..... 6问题争议处理 7测试标准文档10 10 11 12 12 12
周忠智1■编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2.测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任: A、在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 B、编写合理的测试计划，并与项目整体计划有机地整合在一起。 C、编写覆盖率高的测试用例。 D、针对测试需求进行相关测试技术的研究。 E认真仔细地实施测试工作，并提交测试报告以供项目组参考。 F、进行缺陷跟踪与分析。 2.2角色划分
周忠智
周忠智 3.工作流程及规范 3.1计划与设计阶段 3.1.1成立测试团队 3.1.2测试预通知 在正式测试任务下达前，开发团队应提前一周左右向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。测试负责人可视具体情况决定是否需要调整人力。测试人员可预先熟悉必要的背
测试工作总结编写规范
测试工作总结编写规范集团文件发布号：（9816-UATWW-MWUB-WUNN-INNUL-DQQTY-
软件测试工作总结编写规范 （版权所有，翻版必究） 1. 目的 2. 适用范围 3. 术语和缩略语 4. 规范要求 5. 引用文件 6. 质量记录 1. 目的 本文件规定了测试工作总结编写时应考虑的事项，通过测试工作总结来不断地积累测试经验，提高测试工作的整体水平。并对软件产品测试过程中发现的问题进行分析，为开发人员以后的修改、升级提供一个预防问题的依据。 2. 适用范围 本规范适用于软件项目与软件产品的功能测试与系统测试。
3.术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4.规范要求 4.1 测试小组在完成软件产品测试后，要对整个测试工作进行总结，分 析本次测试工作的得失，为以后的测试工作积累经验。 4.2 在测试工作总结中，全部测试人员在充分分析测试过程中发现问题 的基础上，完成《软件问题倾向分析表》，该表中指出该类型软件产 品容易导致问题的模块及操作。该表将用于该产品或该类产品的升 级、开发工作中为开发人员提供预防错误的依据。 5.引用文件 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 6.质量记录 （无） 附录：测试工作总结模版 项目名称（项目编号） （测试种类）测试工作总结 1. 引言…………………………………………………………………………………………… 3 2. 项目测试结果 (3) 2.1 软件产品 (3) 2.1.1软件产品名称及综合评价3
2.1.2 提交项目管理部门物品3 3. 测试工作评价3 4. 软件问题倾向 4.1 问题解决情况总结与分析 4.2 问题类型统计与分析 附录一：软件问题倾向分析表 附录二：测试结束检查表
软件测试流程规范
软件测试流程规范 一、通读项目需求设计文档 1.测试的准备阶段； 2.仔细阅读《软件需求规格说明书》； 3.根据测试手册，做前期的测试准备； 二、明确测试任务的范围 ⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试； ⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试； ⑾恢复测试；⑿文档测试；⒀可用性测试； 三、学习理解被测试软件 由开发人员组织讲解所要执行测试的软件或者产品，测试人员必须认真理解拿到手中待测试的软件或者产品。 四、制定测试计划 “工欲善其事，必先利其器”。软件测试必须以一个好的测试计划作为基础。作为测试的起始步骤和重要环节。测试计划应包括：产品基本情况调研、测试策略、测试大纲（功能模块的测试、详细测试、高级测试）、测试内容（界面测试、测试需求说明）、测试人力资源配置、测试计划的变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪报告、测试通过准则、测试计划的评审意见等。另外还包括测试计划的目的、测试对象信息、测试计划使用的范围及测试参考文档。 1.项目简介； 对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。 2.测试背景； 产品在那种情况下开始研发，执行测试，交待为何而测试产品的背景。 4.测试类型（方法）；（黑盒测试） ⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试； ⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试； ⑾恢复测试；⑿文档测试；⒀可用性测试； 5.测试资源；
6.测试策略\测试需求\测试任务\测试点； 针对测试需求定义测试类型、测试方法以及需求的测试工具等。 ①对于每种测试，都应提供测试说明，并解释其实施的原因。 ②制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。 ③下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已 知的、有控制的数据库来执行。 ④不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。 该测试本项目不适用”。 No工作内容开始时间结束时间责任人提交的结果备注 五、设计测试用例 测试用例的主要来源为：1）需求说明书及相关文档2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的UI（可以有针对性地补充一些用例） 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。 项目名称程序版本功能模块名用例编号编制人编制时间 论坛 功能特性 测试目的 参考信息 预置条件特殊规程说 明 参考信息 测试用例 基本流 序号名称说明1 2 备选流 序号名称说明1 2 相关的用例无 测试场景 序号名称说明
测试工作规范
测试工作规范 版本记录: 1编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。 编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告供项目组参考。 进行缺陷跟踪与分析。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。
3工作流程及规范 3.1计划与设计阶段 3.1.1成立测试团队 3.1.2测试预通知 在正式测试任务下达前，开发团队应提前一周左右向测试团队下达预通知，告之较为确 切的测试日期，提供当前最新的相关资料。测试部门经理可视具体情况决定是否需要调整人力。测试人员可预先熟悉必要的背景资料，协助测试经理编写《测试计划书》初稿。
图表 3.1.4编写测试计划文档 需求分析文档确立后，测试组需要编写测试计划文档，为后续的测试工作提供直接的指
3.1.5设计测试用例 在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。在用例的编写过程中，具体的任务和责任人如下： 3.2实施测试阶段 3.2.1实施测试用例 实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基 础上。 3.2.2提交报告
软件测试流程及规范V1.1
软件测试流程及规范V1.1
二、各阶段具体流程 1.需求分析阶段 立项 需求调研 编写/修改SRS 提交SRS SRS 审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS ，项目整体计划，设计、编写《测试计划》 和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告，即制订测试的标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程，并为每个测试过程选择 适当的测试用例。 进入概要设计阶段评审测试计划 和测试设计优化测试计划、 测试设计1.1步骤说明 1、需求定义基本完成，SRS 编写完成。 2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。 3、当评审未通过，直接打回，重新修改SRS ，问题解决后，重新提交评审。
4、当评审通过后，依据SRS，项目整体计划，设计、编写《测试计划》和《测试设计》，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出 输入：最新SRS、项目计划 输出：测试计划、测试设计 2、单元及集成测试流程
教练部日常管理规范
教练部日常管理规范 第一章总则 一、目的：为打造一支素质优良、有战斗力、团结协作、业务精通、积极进取的员工团队在教练部努力营造文明、和谐、严谨、高效的内在氛围，推动教练部文化建设及更好的服务会员，特制定以下日常规范。 二、实用范围：适用于游骑兵教练部全体员工（外聘教练） 第二章员工守则 第一条职业准则 一、基本原则 1.倡导诚实守信、勤奋敬业的职业道德，要求全体员工自觉遵守国家法律法规、方 2.员工一切行为要以公司利益为重，不得有损公司形象，对外诋毁公司 3.努力营造团结和谐、公正平等的人际和工作关系，员工之间应互相尊重、互助友爱、坦诚相待、和睦共处 4.认可公司文化，团队价值，不可我行我素，要当教练部为自己的家一样用心 5.所有人不得在公司以外进行私下交易，不得在未经公司及门店的同意下对外利用公司进行个人利益创收 二、禁止员工发生以下行为 1.禁止帮助竞争对手进行宣导 2.禁止对内部同事宣导竞争对手的优势，动摇人心 3.禁止向竞争对手泄露公司及门店的已知信息 4.禁止时常满嘴抱怨，推卸责任，不思进取 5.禁止教练对自己会员群体宣导公司不利信息 6.禁止教练利用家人和朋友做一切有损公司及门店形象的事情 第二条基本职责
1.遵守公司规章制度，服从部门日常管理 2.执行教练岗位的职责，遵守所属部门的日常规程 3.按照公司管理模式运作（POS流程、体验课流程、体测话术），确保业务流程和工作程序的顺畅高效 4.服从主管领导的安排，不得无故拒绝、违抗上级命令 5.依照岗位职责要求按时、按质、按量完成各项工作任务 6. 组织的各项培训、活动与考核 7.随时保持本岗位所辖范围和公共区域清洁卫生、遵 努力改善工作环境 8.根据公司需要及职责规定应积极配合其他同事开展工作、不得拖延、推诿和拒绝，对他人咨询不属自己职责范围内的事务，应就自己所知告诉咨询对象，不得置之不理 9.教练在上课期间不得玩手机和做与本课时无关的事情（包含教练以课带练），每天巡场教练值班期间必须保证有氧区随时有人巡场，固定器械区随时有人巡场，体测室随时有人轮值 10.教练上课期间必须将PT本随身携带并为会员做好锻炼记录，下课过后及时让会员签字确认，同时在私教系统和前台健身系统及时下课，整个过程必须保证签课本整洁有序，以及签课本、私教系统和前台健身系统下课保持一致 11.教练谈完POS、上完体验课过后必须让教练经理介入TO，同时每天体测必须按照公司流程严格执行 12.教练每天必须在21点至22点之间将当天工作量发送到PT工作群和及时更改数据白板和次日预约白板，若休息的第二天预约可请同事帮忙更改 13.每天晚班要负责及时提醒同事整理器械，同时负责当日拍照（白板、有氧区、私教区、自由力量区、固定器械区、体测室、教练岛）发放到PT群，查询小器械数量和归位情况做好登记。 14.教练每天上班过后不得做与工作无关的事情，如吃饭（每天只有一小时为吃饭时间）、看视频、玩手机、洗澡、化妆，聚众聊天等 15.教练部全员每天上班期间不得出现无故脱岗，请霸王假，随意调休换班，若出现
第三方检测工作管理办法
工程质量第三方检测工作管理办法 第一章总则 第一条为加强公司管内各铁路建设项目工程质量管理，规范公司管内铁路建设项目工程质量第三方质量检测工作，依据《关于开展隧道衬砌等铁路工程质量第三方检测的通知》（铁建设〔2011〕172号）、《中国铁路总公司关于进一步加强铁路隧道工程质量检测工作的通知》（铁总建设函〔2014〕637号）、现行检测技术规程规范、公司《工程质量管理办法》及相关文件，结合公司管内铁路建设项目工程质量第三方质量检测招标文件、合同文本，制定本办法。 第二条铁路建设项目工程质量第三方检测是指按照铁路总 公司有关规定，由公司通过独立招标程序确定委托的、依法持有工程质量检测资质的单位所从事的现场检测活动。 第三条铁路建设项目工程质量第三方检测活动应遵循科学、公正、准确、及时的原则。 第四条本办法适用于公司管内铁路建设项目桥梁桩基、路基及支挡结构、隧道衬砌、房建桩基、钢结构、通信铁塔等由公司委托第三方进行检测的工作范围。 第五条实行工程质量第三方检测后，施工单位按规定应实施的自检工作不变，施工质量责任不变；监理单位的质量管理责任不变。 第六条第三方检测单位不得参与本标段内施工单位的现场 检测自检项目。 第二章组织机构及工作职责 第七条组织机构
公司管内铁路建设项目工程质量第三方检测管理归口公司安 质部，建设指挥部负责管段内第三方检测的日常管理工作。 第八条工作职责 （一）安质部： 1．制定公司第三方检测管理办法。 2．指导现场指挥部召开第三方检测单位首次进场会议，每半年组织1次第三方检测单位履约情况检查，并对检查结果进行通报和考核。 3．配合上级有关部门开展实体质量抽检等工作。 4．审核第三方检测单位的验工计价及竣工结算。 5. 组织第三方检测招标工作。 6.每季度分析实体工程质量。对第三方开展评估 （二）工程部： 负责组织指挥部、设计、咨询、监理和施工单位研究质量存在较大问题或安全存在较大风险的不合格工程实体的处理方案，组织对处理方案落实情况的检查工作。 （三）建设指挥部： 1. 负责对第三方检测工作的日常管理，负责协调各施工、监理、检测单位的工作。 2．审批第三方检测单位编制的检测大纲和实施细则。 3．根据施工进度，编制下达月度检测计划，编制检测及缺陷整治月报。（建立台账），编制整治计划。每月召开检查工作例会。 4．督促施工、监理、第三方检测单位对存在问题的整改。 5. 组织建设、设计、施工、监理、第三方检测研究缺陷处理方案，重大质量缺陷处理方案初审意见报公司。