第1章 引言
1.1目的
简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。
测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。
1.2名词解释
列出本计划中使用的专用术语及其定义
列出本计划中使用的全部缩略语全称及其定义
1.3参考资料
列出本计划各处参考的经过核准的全部文档和主要文献。
1.4测试摘要
这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。
1.4.1 重点事项
列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在
1.4.2 争议事项
简要说明争议事项。
1.4.3 风险评估
通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试．
1.4.4 时间进度
简要说明测试开始时间与发布时间。
1.4.5 测试目标
简要说明测试发布的质量目标：
测试计划中所有测试方法和模块已经执行通过
所有的测试案例已经执行过
所有的重要等级为1/2的Bug已经解决并由测试验证
第2章 项目背景
2.1测试范围
说明本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。
（1）简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
（2）如果在编写此文档的过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。
（3）列出可能会影响测试设计、开发或实施的所有风险或意外事件。
（4）列出可能会影响测试设计、开发或实施的所有约束。
提示和技巧：
需要测试和特别注意测试那些部分？
测试是否专么针对与某些问题的解决?
哪些部分不需要测试，为什么？
哪些部分需要推迟测试,为什么?
是否要验证每个模块的稳定性？
测试的优先级和先后顺序
2.2测试目标
系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。
通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。
2.3联系方式
列出项目参与人员的职务、姓名、E-mail 和电话。
2.4风险及约束
列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。如：
由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束
由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对
只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。
2.5测试文档
列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生的文档。
2.5.1测试参考文档
第3章质量目标
描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。
质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的？
3.1产品质量目标
可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的`要求。
3.2测试质量目标
评价测试质量的目标可以有：
第4章 资源需求
4.1培训资料4.2测试环境
4.2.1硬件测试环境
描述建立测试环境所需要的设备、用途及软件部署计划。
“机型（配置）”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。
“用途及特殊说明”：此设备的用途，如数据库服务器，web服务器，后台开发等；如有特殊约束，如开放外部端口，封闭某端口，进行性能测试等，也写在此列；
“软件及版本”：详细说明每台设备上部署的自开发和第三方软件的名称和版本号，以便系统管理员按照此计划分配测试资源；
“预计空间”：说明第三方软件和应用程序的预计空间；
“环境约束说明”：建立此环境时的特殊约束。如需要开发外部访问端口，需要进行性能测试等。
4.2.2软件测试环境
4.3测试工具
此项目将列出测试使用的工具以及用途：
第5章 测试策略
5.1整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
使用里程碑技术在测试过程中验证每个模块，测试人员在需求阶段参与测试工作，进行需求review、设计review、测试案例设计和测试开发，在系统开发完成之后，正式执行测试。产品达到软件产品质量要求和测试要求后发布，并提交相关的测试文档。
5.2开始/中断/完成标准
说明中断/开始/完成测试的标准。
5.3测试类型
5.4测试技术
第6章 测试计划
6.1进度计划
在此章节，对各阶段的测试给出里程碑计划，包括阶段、里程碑、资源等。
6.1.1测试时间进度
6.1.2测试里程碑
6.2测试准备
6.2.1 测试环境准备
6.2.2安装测试
6.2.3烟雾测试
6.3 具体测试实施任务和时间人员安排
一、指导思想
我们的指导思想是：测试驱动开发，用例指导结果， 数据记录变化。
测试是国内企业面临的一个共同的问题，要么就是不重视，要么就是不彻底。我既然选择了测试，就会为此而执着地追求到底！
在产品开发过程中，或多或少的会留下一些问题。这很正常，如果问题到用户手里才发现，那似乎有点晚了，况且修复成本也增加了不少。我们的策略是：测试早介入，问题早发现。这样资源投入比以前要多一些，我觉得还是值得的。
在测试过程中，我们将加大用例设计力度，用科学的用例来发现BUG、用可靠的数据给来定位BUG、用合理的沟通技巧来跟进BUG，努力打造出一支能发现BUG的精良队伍。
二、工作重点
整体来说：提出“测试123计划”。
什么是测试123计划呢？我是这样想的：以泛华自研产品为中心，努力向同行业先进的测试团队看齐；坚持两手抓，一手抓执行力，一手抓BUG，两手同时发力，绝不手软；为了响应产品线的发展，我们组建了三条测试线：DAQ测试线、系统平台测试线和通信互连测试线。
接下来，分8个方面来讨论：
1. 提升团队凝聚力和战斗力
提倡以人为本。具体有如下举措：
自我认识，分工合作，充分发挥个人优势
为团队成员提供深造的机会，建设学习型测试团队
认真听取团队成员的见解和建议
鼓励团队成员的创造力
实施参与管理，有效授权
营造开放、信任和自由沟通的氛围
适当开展业余活动
2. 加强队伍建设
根据公司的战略规划，有重点、有步骤地组建测试团队。目前只考虑硬件测试，逐步培养软件测试和系统测试人员。
具体有如下举措：
PS-DAQ TestLine
现有3人，由常鹏坤牵头。计划发展到4～6人，其中多功能卡1人，同步卡1人，DSA卡2人。另VxWorks测试储备 1人。
业务范围：
（1）重点：研发测试。测试早介入，问题早发现。参与到研发过程中的各种测试，直到IPA结束。包括核心器件选型测试，单元测试，集成测试，系统测试，alpha和beta测试，用户验收测试等。并参与一系列研发评审活动，了解相关技术背景，为充分测试作准备。
（2）次要：小批量验证测试。包括测试环境搭建，生产测试程序设计与验证，生产测试规范编写与归档，小批量测试并触发质检入库。最后，编写小批量验证测试总结报告，并组织产品线进行会议评审。
（3）发展：自动化测试。开发低成本、高效可靠的智能程控开关和相关的适配器，搭建机柜式的自动化测试平台，并自主开发自动化测试程序。
（4）VxWorks测试储备，并逐步细化。
（5）配合DAQ产品线，适当做些市场应用性的验证测试。
PS-SP TestLine：
现有1人，光杆司令是韦忠品。计划发展到2～3人，其中机箱1人，控制器1人，EMC测试1人。
业务范围：
（1）重点：研发测试。包括核心器件选型测试，研发样品验收测试，IPA产品器件变更测试等。
（2）次要：小批量验证测试。包括测试环境搭建，生产测试规范编写与归档，小批量测试并触发质检入库。最后，编写小批量验证测试总结报告，并组织产品线进行会议评审。多关心转产后的生产测试，这也是泛华目前的一个薄弱环节，我们将派人去监督这个产线的生产测试。
（3）发展：EMC测试。先外包，学习和积累EMC测试经验，等时机成熟了，再考虑自己建设EMC实验室。
（4）配合系统平台（SP）产品线，适当做些市场应用性的验证测试。
PS-LINK TestLine：
现有1人，领头羊是许春亮。计划发展到1～2人，试行任务捆-绑，协同工作。包括DAQ产品之外的所有硬件板卡。
业务范围：
（1）重点：研发测试。测试早介入，问题早发现。参与到研发过程中的各种测试，直到IPA结束。包括核心器件选型测试，单元测试，集成测试，系统测试，alpha和beta测试，用户验收测试等。并参与一系列研发评审活动，了解相关技术背景，为充分测试作准备。
（2）次要：小批量验证测试。包括测试环境搭建，生产测试程序设计与验证，生产测试规范编写与归档，小批量测试并触发质检入库。最后，编写小批量验证测试总结报告，并组织产品线进行会议评审。
（3）配合Link产品线，适当做些市场应用性的验证测试。
总而言之，为了更好的完成测试任务，测试队伍在2015年将要翻一倍。
3. 测试环境建设
花点时间、花点资金来建设下测试环境，会给我们带来事半功倍的效果。
具体有如下需求：
（1）系统平台环境：目前有2套，9106+3031与9114+3030（机箱电源带负载能力比新机箱差些，插满板卡启动有问题）。计划再增加3套，分别是：宽温9108+3050、自研PXIe机箱+PXIe控制器、NI PXIe机箱+PXIe控制器(指标对比或参考用)。
（2）自研重点PXI板卡：各一块，用于各种发散性的测试。
（3）专业仪表：比如频率计、功率计等，资金计划在10～20万之内。
（4）测试易耗品：如各种测试线缆、接插件、连接器、端子等测试辅材，期望公司有高效的采购通道。
4. 建立规范的测试用例库
我们的测试管理平台支持测试用例库的管理，包括建立、修改、帅选、组合、导入、导出等操作，目前的测试用例放置在流程中，等规范化以后，可以随机加入专用的测试用例库。
具体按如下流程来操作:
首先，按测试线来编写测试用例设计规范。包括测试用例的常用设计方法，命名规则，内容、格式、附件等。
然后，按照规范来整理之前的测试用例，去粗取精，形成规范的、高效的测试用例。 接下来，我们组织评审团进行测试用例专题评审，合格的用例即可流入测试用例库。 我们要坚持做一件事情：不断向库中放测试用例，测试方案优先考虑用例库。
5. 规范BUG的评级依据
BUG管理一直是我们的重中之中。我们强制要求严重以上的BUG必须在IPA之前修复。自然，BUG的评级显得尤为重要。现在，有一些对BUG评级的定义，可能比较抽象，实际操作起来有些困难。为了弥补这些不足，我们将重点考虑如下几个问题：
（1）什么样的问题是BUG？
（2）如何对BUG进行量化评级？
（3）拿出具体实例。
准备整理成文档，贯彻执行。是P1的绝不判P0；发现了生产问题，绝不说成是设计BUG。
6. 提升测试技术
将硬件测试划分为：功能测试、性能测试、可靠性测试。现在覆盖比较多的是功能测试和性能指标测试。接下来，我们会提高可靠性测试方面的用例。
如何提升自研产品的测试技术呢？
具体有如下举措：
锁定目标为以上三类测试，有的放矢，并参考NI相关文档
参与研发过程中的概要设计、详细设计评审（学习）
产品需求细化
业务和实现逻辑分解
实现技术（算法）分解
选择合适的测试手段（工具应用及反推）
选择不同的测试角度
改变不同的用户场景
功能关联/依赖法
测试点反推法
bug反推法
从用户使用的角度去设计用例
结构性分析法
EMC
7. 全面推动自动化测试
自动化测试主要应用在DAQ与LINK产品线的批量测试上。为此，我们要设计一个实用的、高效的、稳定的自动化测试平台。
平台包括：
（1）机架式硬件测试平台，放在测试工位上（非ATE生产系统），我们作自动化程序调试和小批量验证用，生产测试环境直接复制即可。
（2）开发低成本的通用智能程控开关，实现多通道信号路由。
（3）设计通用的自动化测试软件平台，非LabVIEW编程环境。
（4）提供工厂模式和维护模式。
难点在于：智能程控开关和通用软件平台上。需要领导支持，一方面是资金投入；两一方面是人员安排，我们适当利用测试空隙时间来完成。
8. 培训与交流
具体有如下举措：
（1）每周五下午开展交流例会，主要是工作汇报和遗留问题讨论。如果时间允许的.话，可进行专题技术交流。
（2）4次以上外部技术培训，主要包括DAQ专题培训，反射内存技术、1553B系统技术和429系统技术培训，EMC专题培训，VxWorks培训等。
（3）参加市内重要的测试技术展会。
（4）2次以上业务活动。
三、考核目标
1. 建立标准的测试用例库
2. 测试用例数量增加30%
3. 测试BUG数量增加30%
4. 搭建一套自动化测试平台
5. 测试团队发展到中等规模（10～14人）
一 、工作职责：
1、协调好软件测试工程师与测试员之间的工作关系
2、对不同的项目进行优先评级，合理分配人力资源。
二 、目的：
更好的协助软件测试工程师，按时甚至时提前完成测试项目。
三、工作计划
一、协助测试员的导师，帮助刚入职的测试员进行工作环境和工作内容，工作规范，规章制度的熟悉。
二、帮助刚入职的测试员把测试时必须用的耳机， USB线，下载线，T卡，充电器，SIM卡，备齐。
三、分配测试项目
1、测试员分配测试项目的原则
（1）按照项目的优先等级进行分配
（2）按照测试能力进行分配
（3）按照对不同平台的熟悉程度进行分配
2、测试工程师提交协助测试项目的原则
（1）以书面形式，提前一天，特殊情况可提前半天，提交协助测试申请。内容包括：现在正在负责测试项目的个数，协助测试项目的进度安排，预计占用测试员的天数。
（2）以口头或者是书面的形式，告知测试项目的修改内容和测试重点。
（3）原则上测试员手上都有项目的话，将不在接手新项目，重点紧急项目可例外。
四、测试员的日常管理
1、与测试员进行交流与沟通，对工作中遇到的问题与困难能帮助解决的尽量帮助解决，自己不能解决的请教他人与于帮助解决。
2、监督测试员的日常工作，对工作中的错误与于指正。
3、每周提交周工作总结表（见附件），每月提交月工作总结表 原则上：周工作总结表，每周五五点半开始填写，六点之前上交 月工作总结表以前三周工作总结表为基础填写，每月第四周，周五五点半开始填写，六点之前上交