下载文档原格式
TPT 中脚本评估正确打开方式（上）：强大的内置函数库前言TPT 作为一款功能强大的嵌入式软件测试工具，覆盖MiL 、SiL 、PiL 、HiL 、ViL 等全阶段的测试过程，将测试执行到测试报告生成的所有步骤实现自动化，大大提高我们做软件测试的效率。
TPT 之所以在嵌入式测试中如此高效，少不了其脚本评估这个特色功能的支撑，今天我就带领大家来了解一下TPT 中脚本这个特性。
您将在本文及后续文章了解到的： • 通过TPT 脚本对任意时间的信号行为进行检查的方法 • TPT 脚本中对信号进行处理以及读写的方法 • 通过TPT 脚本对测试需求、测试报告等内容进行管理的方法 • TPT 脚本与Python 标准库、扩展库、MATLAB 、以及其它外部软件的交互方案 • TPT 脚本的封装、集成以及团队管理方案TPT 脚本评估的语法构成「PT ■脚本评估TPT 中的脚本由三个方面组成，分别是Python 基本语法、TPT 内置函数以及MATLAB 等其它程序的接口。
首先TPT 脚本的语法框架是基于Python2.7的，所以我们可以在TPT 中使用Python2.7中的绝大部分语法特性，比如说Python 中的选择语句、循环语句等流程控制语法，列表、元组、字典等数据结构，甚至我们还可以使用Python 中的函数、类等语法结构。
如下图所示，我们使用上述语法，对信号状态进行判断，同时建立了一个对信号图像进行设置的函数。
TPT 内置函数TPjK-et.;JLT.jH I section I er-BI?hic«T?TR€p ort.$ienalGr 型h"G f«sipial in sigju.1-5：班jiphiu 水H )apliic)除了基础的Python 语法框架，TPT 针对嵌入式软件测试的特点，提供了一套强大的函数库，覆盖到测试的方方面面。
从评估区间查找到信号行为检查，从测试需求管理到测试报告设置，我们都可以通过调用一两个函数去完成。
接口电路一般使用专用芯片，是否注意采用光器件或变压器进行隔离、传输匹配、过压过流保护、防雷击等措施。
芯片如有PGND引脚或要求接PGND时，在单板上是否设计了相应的PGND地，并在电源接口处与电源地相连，以防雷击并泄放一次保安单元剩余的电荷。
是否考虑到单板与RF模块接口的输入/输出信号的电平隔离及匹配。
高速并行总线接口是否统一采用推荐优选接口芯片单板上的调试串口是否采用RS232终端并联匹配电阻是否尽可能靠近接收电路，串联匹配电阻是否靠近始端。
输出信号应是否考虑有足够的驱动能力在设计中，正确使用数字地（DGND），模拟地（AGND），电源地（BGND），保护地（PGND）。
单板上电后能否进行自检，并进行一些必要的自环收发、内存读写、芯片测试等功能性的测试，如有异常，指示灯是否指示自检失败，否则开始正常运行。
单板自检故障时，能否将故障原因送主机及调试口在单板上是否有必要的测试点单独引出，以TP1、TP2···等来命名测试点是否包括电源、时钟等。
具有Boundary-Scan的器件，其测试访问端的四个管脚TDI、TDO、TMS 、TCK是否留有测试孔。
CPU的晶振应尽量排布在晶振输入引脚附近。
无源晶振要加几十皮法的电容；有源晶振可直接将信号引至CPU的晶振输入脚。
如果CPU内部自带Watchdog电路，则采用内部的Watchdog，对于系统来说更为安全可靠。
对于CPU的中断输入脚，无论使用与否，应接有上拉或下拉电阻，尽量不要悬空。
对于不用的输入脚，也应尽量照此处理。
专用芯片的应用是否参考了厂家资料给出的推荐电路。
在总线达到产生传输线效应的长度后，是否考虑了匹配关键信号是否引到接插件或预留了测试点PCB、单板软件的版本信息是否都在各自范围内设计，并可上报单板的关键芯片是否支持自测试功能单板、扣板的机械尺寸与信号位置设计是否统一考虑；单板上电后的芯片的初始状态是否固定单板上接插件的间距和位置是否参考同类成熟单板单板所有器件选型是否通过品质和商务清单评审。
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.客户标准及规格：对正在评估报价的项目料号取得客户标准，规范和要求。
Web软件测试Checklist应用系列简介：本文为系列文章"Web软件测试Checklit应用系列"中的第一篇。
该系列文章旨在阐述Checklit（检查清单）在Web软件产品测试中的应用，以帮助您了解如何利用Checklit这种重要的测试手段，更高效的寻找Web产品中的defect（缺陷）。
Checklit汇集了有经验的测试人员总结出来的最有效的测试想法，可以直接有效的指导测试工作，开阔测试人员的思路，能够快速的发现产品的缺陷并实现较好的测试覆盖，更重要的是该Checklit在不同的项目中具有很强的通用性。
回页首表格输入Checklit表1.表格输入Checklit总结1.1接收到非法输入时是否能恰当处理？一个好的软件，当接收到非法输入时，能够恰当的处理，不能给出不可预知的错误信息。
请看下面的例子。
Web产品页面上，输入域是必填项还是可选项需要进行验证。
有两个方面的验证需要完成:第一，必填输入域确实是必须填的，当没有输入时会有错误提示；可选输入域是可以不填的。
第二，确保必填输入域是确实必要的，而可选输入域是非必要的。
下面我们提供两个实例。
图2.可选项邮件地址未输入时报错图2的实例中，电子邮件地址为可选输入项，当用户没有填写该项时，产品提示需要输入邮件地址，而这与可选项的定义不符。
这是产品的一个缺陷。
图3.不合理的可选项输入设置图3的实例中显示为创建一个群组的窗口页面，该页面上唯一的输入即群组名称，而该群组名称作为群组的唯一标识，是应该为必填输入项的。
而这里，产品并未将该输入项作为必填项。
当用户不做任何输入，直接点击确定时，一个没有名字的群组将被创建。
这是不合理的，是产品的缺陷。
1.3输入超过允许长度的数据正常情况下，每个输入域对输入数据的长度需要进行约束，给出最小长度和最大长度限制。
如果用户输入的数据长度超过最大允许长度，程序需要做出恰当处理。
例如，测试人员可以创建一个1,000,000字节或者更长的字符串，将该字符串输入到输入区域内，并继续后续操作，比如保存或者运行，看程序是否能够给出错误提示或者对字符串长度进行自动截断处理等操作。
测试 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 的编写之后，需要进行评审。
Checklist的几大要素
Checklist的几个重要要素是：项目/任务、步骤、条件和标记（或勾选）方式。
1. 项目/任务：Checklist的首要要素是明确列出需要完成的项目或任务。
这些项目可以是工作任务、检查清单的事项、待办事项或需要遵循的步骤。
2. 步骤：每个项目或任务通常包含一系列需要执行的步骤。
步骤是指完成项目所需的行动或操作。
逐步明确列出这些步骤，可以确保在执行任务时不会遗漏关键细节。
3. 条件：Checklist的有效性还需考虑任务执行的条件。
条件是指完成项目或任务所需满足的先决条件、环境要求或其他相关情况。
在Checklist中包含适当的条件，有助于确保在适当的环境下执行任务。
4. 标记/勾选方式：Checklist的目的是跟踪任务完成情况。
为了实现这一目标，需要一种标记方式来记录已完成的步骤或任务。
常见的标记方式包括打勾、打对号、使用符号或颜色等方法。
这些要素的组合构成了一个完整的Checklist。
通过明确描述项目、步骤和条件，并使用适当的标记方式，Checklist 可以提供一个简单而有效的工具，帮助人们管理任务、确保重要步骤不被忽略，并提供一种可视化的方式来追踪任务的
进展。
| 2评论：图 2 的实例中，电子邮件地址为可选输入项，当用户没有填写该项时，产品提示需要输入邮件地址，而这与可选项的定义不符。
这是产品的一个缺陷。
图 3. 不合理的可选项输入设置图 3 的实例中显示为创建一个群组的窗口页面，该页面上唯一的输入即群组名称，而该群组名称作为群组的唯一标识，是应该为必填输入项的。
而这里，产品并未将该输 入项作为必填项。
当用户不做任何输入，直接点击确定时，一个没有名字的群组将被创建。
这是不合理的，是产品的缺陷。
1.3 输入超过允许长度的数据正 常情况下，每个输入域对输入数据的长度需要进行约束，给出最小长度和最大长度限制。
如果用户输入的数据长度超过最大允许长度，程序需要做出恰当处理。
例 如，测试人员可以创建一个 1,000,000 字节或者更长的字符串，将该字符串输入到输入区域内，并继续后续操作，比如保存或者运行，看程序是否能够给出错误提示或者对字符串长度进行自动截断处理等 操作。
1.4 页面装载或重装载后默认值当网页产品的页面装载完成以后，页面上显示的初 始默认值，需要满足一致性和准确性。
一致性是指，每次从不同的路径到达相同页面后，在做进一步操作之前，页面默认值需要保持一致。
准确性是指，页面上的默 认值需要布局合理，需要使能的按钮和操作都是可用的，需要被禁止的功能要确保不可用。
图 4. 初始加载页面图 4 显示的为打开一个用户配置文件页面，该页面打开后在不做任何更新的情况下，保存和取消按钮处于使能状态。
而实际上此时点击两图 5 的例子中，左侧图显示的是初始状态下组合框的列表内容，默认选择的是 Custom Group, 展开列表后可以看到 Search Results。
右如图 6 所示，在图中所示的表格中，不同组件的排列不齐，左边属性名称和右边的属性值输入域应该是水平对齐的。
这里是产品的一个缺如图 7 所示，注意红色圈内位置有一个未显示完全的按钮，其实下方还有其他更多内容，该部分内容已经超出显示区域的范围，应该在右如图 8 所示的例子中，当名字和姓氏都输入达到最大长度时，保存之后显示框中无法将两部分内容完整的呈现，并且没有水平滚动条辅助显示。
增1能否执行插入功能2默认值是否正确3必输项是否有红星标记，如果不输入提示是否跟相应的Label对应，提示的顺序是否跟Form输入域的排列次序一致4输入的特殊字符是否能正确处理：`~!@#$%^&*()_+-={}[]|\:;”’<>,./?5Form下拉菜单的值是否正确，下拉菜单的值通过维护后是否正确显示并可用；下拉菜单比如是机构编码，要到机构编码的维护界面查询一下是否Form列出的与其一致6要求唯一的数据（主键）是否可以重复添加7备注字段的超长检查8输入域的编辑状态是否正确（editable/uneditable）9输入结果是否被正确保存10插入页面为当前主页面的情况下，提交保存后能否转到合适的页面11插入页面为弹出新页面的情况下，提交保存后原来的列表页面是否会自动刷新12插入的数据在结果列表中是否正确排序13有唯一性要求的，连续提交，不能产生重复数据，或造成数据混乱、丢失改1能否执行修改功能2编辑页面中各输入域是否被正确的置成可编辑、不可编辑状态；可编辑数据项的检查，比如：数据在正式提交之前所有的属性都可以编辑，在提交之后，编号、状态等不能编辑，要根据业务来检查是否符合需求3编辑页面中可编辑的项目是否显示正确的默认值，包括form下拉菜单与文本框4涉及到下拉菜单的编辑修改Form，要检查在编辑和修改Form中，下拉菜单是否能正确显示当前值5Form提交后，要逐项检查输入的内容跟通过查询的结果一致6编辑权限的检查，比如：user1的数据user2不能编辑等7输入的数据是否被保存，Form提交后，要逐项检查输入的内容跟通过查询的结果一致8输入的数据是否保存为其它的值9如果输入的数据（主键）已经存在，是否可以保存10修改操作是否被当作插入处理，即在保存原有数据的基础上，插入了修改值11提交保存后能否转到合适的页面12修改的结果在结果列表中是否正确排序13有唯一性要求的，连续提交，不能产生重复数据，或造成数据混乱、丢失删1必须有“确认删除”的提示2能否执行删除功能3选定的数据是否被删除4是否错误的删除没有选择的数据5是否可以删除部分或全部数据6当设置自动编号时，能否处理删除后的空白7根据项目需求检查是软删除还是硬删除，来检查数据库中是否还存在该条记录8如果是软删除，用查询、统计界面检查该条记录能否被查询出来，数据是否被统计进去9是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成10是否有删除约束，如果有删除约束，要检查该记录是否被约束，如果被约束该记录不能被删除11检查因为业务约束不能删除的数据能否被保护不能手工删除，比如：流程中已经审批的文件不能被删除12跟删除相关的权限问题，比如：需求要求只有管理员和该记录的创建人能够删除该记录，那就以不同的用户和角色登录进去，执行删除操作，检查是否与需求匹配查1能否执行查询功能2对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等3是否可以设置查询条件4在不同部分查询统一信息，查询结果是否一致5查询结果是否包括符合条件的全部数据6是否存在重复出现相同数据的情况7查询结果中是否包括检索条件、可以判断正确与否8查询结果是否有明确的排列顺序9在插入/修改操作时，查询输入的值，结果是否正确10不设置查询条件时是否可以查到全部数据11根据项目需求是否支持模糊查询12根据项目需求查询关键字是否区分大小写13设置部分查询条件时查询结果是否正确14设置精确查询条件时查询结果是否正确15查询结果页面中是否保存查询条件16查询结果分页时，在点击下一页/上一页时查询条件是否能带过去，不能点击翻页时又重新查询17查询结果是否出现内容和合计数值不一致的情况18查询权限的检查，比如：user1不能查询到user2的数据等19当查询的数据量较大时系统性能如何20设置条件进行查询后清空查询条件，再次查询时是否仍然按照之前设置的条件进行查询21如输入%*?等通配符是否会导致查询错误22分页的统计数字是否正确，共X页，第N页，共X条记录等23对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确24查询结果有超链接的情况要检查超链接是否正确分页1总页数是否正确2当前页数是否正确3设置跳转的页数后能否直接跳转4首页/末页、上一页/下一页按钮的状态是否正确5点击首页/末页、上一页/下一页是否跳转到正确的页面上传/下载1是否能正确上传附件文件2检查上传的文件是否能正确下载并打开3上传文件时是否符合大小限制，若没有指定大小的限制，至少检查下列大小的文件能正确上传，0k,100k,1M,2M,4M,10M,20M等4上传文件时是否符合指定的类型限制，如果没有指定类型的限制，至少上传以下几种类型的文件能否正确上传并正确打开，类型有：.doc,.xls,.txt,.ppt,.htm,.gif,.jpg,.bmp,.tif,.avi等5同一个位置是否可以上传同名文件6在不同位置上传的同名文件，打开时是否出错7根据项目需求，中文名称的文件是否可以正确上传/下载。
检查表（checklist）的使⽤--测试检查表checklist很常见，各⾏各业都有，但是作为电信运营⽀撑系统这样⼤的软件系统的实施和开发，却。
检查项⽬并不是⼀成不变的，也不是随便想⼏个就可以的，否则会成为摆设。
⼀定得要有过程管理思想并深刻体会到其中的关键点进⾏监控。
每个团队、每个时期都是动态变化的，checklist是⼀种动态的⼯具。
除了过程，可以使⽤在其他⽅⾯，例如：各种评审。
checklist可以让⼯作标准化，但是快速发展的团队和⾼效⼯作似乎不需要标准化？错，这要看checklist的内容是什么。
总会有需要checklist的地⽅并且能起到真正的作⽤。
测试⽤例检查表是否每个⽤例测试⼀种单独的情况⽤例是否有测试数据⽤例是否有预期结果是否明确描述了测试数据的异常值、正常值、边界值预期结果是否可以再现测试⽤例是否分级展现是否有数据恢复脚本是否有优先级是否是可⽤状态（ready）每个⽤例是否覆盖了测试需求是否有设计时间(⽤例完成设计的时间)是否被评审过测试场景检查表场景是否由⽤例组成的场景是否有优先级是否每个场景中的⽤例已经run是否被评审过测试需求检查表涉及到数据库连接是否明确了连接个数和⽅式是否每个测试需求相对独⽴测试需求之间不应该存在因果关系测试需求中不应该存在模糊描述（⼤量、很多、长时间等等）测试需求的来源是否可靠（不会被随意改动）测试需求描述是否清晰⽆歧义是否被评审过是否设定了优先级测试需求是否包含了业务需求是否把复杂的业务需求分解了是否每个测试需求都有明确的输⼊输出，便于测试defect检查表是否描述清晰:出现问题的环境简要描述是否描述清晰:出现问题的操作过程描述是否描述清晰：问题现象描述清楚是否提出了⾃⼰的分析是否指定了解决⼈是否跟踪了每⼀个⾃⼰的bug是否有未关闭的bug是否提出bug之前检查了没有⼈已经提出来过（不重复）是否每个defect描述⼀个独⽴的问题是否及时修改了defect状态是否填写了应该填写的字段不能带有主观的对程序的评价bug描述中不能带有疑问句是否填写了优先级是否填写了严重程度测试计划检查表是否符合项⽬⾥程碑时间要求是否安排好了执⾏时间计划是否安排好了执⾏⼈计划计划安排是否粒度到天（周）是否有测试⼈员培训计划第⼀、描述了项⽬的⽬的第⼆、描述了项⽬的开发周期第四、描述了测试案例的设计周期第五、描述测试案例的执⾏周期第六、描述了测试过程中⽤到的⼯具或者技术第七、描述了测试过程中⽤到的资源情况每⼀部分测试计划时间安排是否有冲突是否有测试过程检查机制测试过程检查是否涉及到其他组是否取得了相关组的认可是否经过了有项⽬经理参加的评审是否有测试执⾏⽇报告机制是否有风险分析以及规避⽅法是否有测试环境描述是否有测试⼈员协作机制是否有测试⼈员考核点描述并且可⾏是否有其他组协作机制描述测试环境更新检查表是否是在确认了版本⽆误的情况下更新的是否有配置⽂件更新是否可执⾏程序权限正确是否记录了编译错误并报告更新后是否做了冒烟测试更新后是否记录了更新过程如果更新步骤或内容有变化是否同步更新了作业指导⽂档更新问题是否提交到CVS更新问题是否通知到相关⼈员是否记录了本次更新经验（版本更新⽇志）测试⽅案检查表是否描述了测试⽅法是否描述了测试参与⼈员是否描述了测试环境是否描述了⼈员协作办法是否相关⼈员已经通知到是否描述了测试内容测试内容时候细化到模块是否描述了测试时间安排是否描述了测试⼈员培训安排是否描写了测试说明章节是否进⾏了换位思考（别⼈能读得懂吗）是否有备份⽅案是否经过评审准备测试评审检查表是否提前给开发组和项⽬经理以及相关⼈员发送了评审材料是否预定了会议室和预约了合理的时间是否准备了与会材料和⼯具（投影机等）是否主讲者已经演练了⼀下是否最好了被推翻重来的准备是否做好了听取改进意见的准备是否做好了改变原有思路的准备是否做好了⼤家都没有意见的准备是否做好了需要⼆次评审的准备是否做好了由于各种原因评审会失败的准备是否检查过了被评审材料压⼒测试检查表是否已经清楚了实际业务的压⼒情况是否已经预估了业务发展趋势和量化了增长速度是否预估了产品的⽣命周期是否预估了产品⽣命周期内业务量可能的峰值是否统计了业务峰值时间段以及峰值业务量是否已经明确了⽣产系统的主机分布。
冠捷显示科技（武汉）有限公司文件编号：QI-MF8-001 版序：A00 文件名：塑胶制品品质管理细则编制部门: MFG-PP 分发:发布日期: 年月日文件管制:编制: 日期: 年月日审查: 日期: 年月日核准: 日期: 年月日本程序根据实际需要作如下更改,已经相关部门会签并呈报核准[更改申请单]由文件管理员保存。
1. 目的规范塑胶制品品质管理各方面的作业管理的细则。
2. 适用范围适用于塑胶制品品质管理各环节运作管理3. 定义无4. 职责4.1PP最高主管负责塑胶制品部日常管理事物；抽样方案审定；拒收通知单之结论签署；4.2PP品质课主管负责训练技术员及检验人员依指定程序作业；处理进料问题及生产线材料外观性问题，并与RD研讨SPEC及检验方法的适用性；进料检验拒收通知书的审查；制定并核准进料检验作业指导书；4.3PP品质课技术员协助组长训练检验员及处理上线材料外观性问题；制定[进料检验作业指导书]；[进料检验拒收通知书]的确认；掌握公司<<合格供应商评鉴及管理程序>>，主导供应商进行评鉴、年度稽核；负责供应商的日常品质管理、制程管理；零件量产中品质问题点的追踪；负责对塑胶壳外观样品确认、签核；负责对签核过的样品进行审核及保管；4.4PP品质课检验员掌握零件进料检验规范及零件规格书，并对料件检验；培训供应商检验员依 TPV 要求检验；改善对策导入状况追踪；与供应商 REVIEW 产品及制程品质，推动供应商持续改善；填写相关检验记录；5. 流程图及运作程序5.1塑胶供应商评鉴及管理细则5.1.1 流程图无5.1.2 运作程序：5.1.2.1具体运作程序按照《供应商评鉴及管理程序》进行；5.1.2.2补充说明：5.1.2.2.1PP每月对供应商的品质及服务进行考评，考评规则具体参见《塑胶供应商考评管理规则》；5.1.2.2.1针对每月对供应商综合考评,由供应商在次月15号之前完成上月问题点综合检讨，对上月的问题点进行综合检讨,导入相应的实施计划及对策,由驻厂PP进行追踪，在次月的检讨中将上月改善的对策及实施状况进行总结并不断完善。
