符合ISO26262标准的软件测试解决方案
随着汽车行业的迅速发展，汽车电子电器E/E系统在汽车中的作用不断提高，ECU开发所占用的时间和成本也越来越高。与此同时，越来越多的电子控制系统（例如车身稳定控制系统ESP，防抱死制动系统ABS，自适应前照明系统AFS等）具有与安全相关的功能，因此对ECU的安全要求也越来越高。为了减少产品的开发时间和成本，降低由于安全问题而导致的维护甚至召回的风险，越来越多的整车厂和供应商开始重视汽车领域的功能安全问题，ECU软件功能安全的问题也成为汽车行业迫切需要解决的问题，车辆功能安全标准ISO 26262就在这样的环境和需求下应运而生，并于2011年11月正式发布第一版本，该标准是当前汽车业中最流行、最复杂、也是最重要的一份标准。
ISO 26262的目标是通过避免汽车E/E 系统故障行为可能导致的危害来提高E/E系统的功能安全。ISO 26262采用车辆安全完整性等级（ASIL）来判断系统的功能安全程度，ASIL由ASIL A（最低）、ASIL B、ASIL C及ASIL D（最高）四个等级组成，ASIL等级越高表示系统的功能安全评估越严格,相应的表示系统正确执行安全功能，或者说的避免该功能出错的概率越高，即系统的安全可靠性越高。
ISO 26262标准的组成架构由十个规范和信息指导文件组成，其中ISO 26262—4/5/6阐述的是系统级/硬件级/软件级的产品开发，使用嵌套的V模型定义了每个开发阶段的过程以及相应的工作产品。本解决方案主要阐明了在软件级产品开发阶段如何去理解ISO 26262的要求，并且指出了在实际的软件开发过程中如何结合ISO 26262的软件测试生命周期，通过包括软件测试工作的执行以及过程控制等方面来确保ECU 软件质量满足ISO 26262软件级功能安全相应等级的要求。
基于V模式的ISO26262软件测试生命周期
如图所示，基于V模式的ISO 26262-6软件测试生命周期可以划分为五个阶段：
静态分析需求和功能需求：在软件级产品开发初始化阶段和软件安全需求规范制定阶段确定了一些基本的嵌入式软件静态分析需求和功能需求，这部分内容是以后设计和测试的基础；
架构验证：在软件架构设计阶段，我们可以使用人工分析的方式来验证和测试软件架构层的内容，但是有条件的话最好使用合适的架构设计工具，在设计的过程中同时进行架构验证；
静态测试：在软件单元设计和实现阶段同时进行静态测试，可以使用开发辅助工具来进行静态测试，这样不必因为静态测试的活动而改变开发流程。
动态测试：在软件单元测试阶段以及软件集成和测试阶段，使用合适的动态测试工具进行动态单元和集成测试，
功能验证：在软件安全需求验证阶段，要根据ISO 26262-6的要求进行功能验证，包括进行ECU网络环境测试和实车测试，必要的时候进行HIL测试。
因为在静态分析需求中所需要满足的方法基本上都是属于静态测试的范畴的，因此我们以ASIL A为例，将软件测试内容分为静态测试、动态测试和功能验证三部分（注：架构验证暂时未包含在内），见下表。
表中所列举的静态测试内容里面要求采取多种的测试方法，例如‘低复杂度的强制要求’一般需要通过满足一定的度量指标来实现，度量指标包括圈复杂度、嵌套深度等等，而‘使用语言的子集’在汽车行业一般选择MISRA-C，通过强制使用编码规范来排除未定义行为或者实现定义行为等危险用法，除此之外静态测试还要求一些其他的测试方法，例如如果要满足更高的安全完整性等级的话，静态测试内容还需要包括运行时错误检测等，一般需要使用可靠性测试性的测试。
ASIL A所要求的动态测试要求能够基于需求分析和设计测试用例，因此需要在开发过程中提供对需求管理的支持，同时要求能够针对函数或模块提供覆盖度分析等。如果是更高等级的ASIL的话可能还需要进行不同环境的测试，例如模型在环测试（MIL）和软件在环测试（SIL），并在必要的情况下进行MIL和SIL 的对比测试。
软件安全需求的测试环境需要根据ASIL等级来进行选取，并且至少要在一个以上不同环境内执行测试。ASIL A所要求的ECU网络测试包括了网络中各ECU之间的相互作用，目的是确保ECU之间没有引起功能故障的相互干扰，而实车测试则是在真正的ECU软件运行环境中进行测试的方式，根据功能安全需求规范来进行，可以最直观地反映出ECU软件是否能够满足定义的功能安全需求。当然在必要的时候还需要进行硬件在环测试（HIL），通过仿真控制系统中传感器和执行器的硬件(Hardware)电气特性，为嵌入式控制器构建起一个控制回路 (Loop)，从而可以方便的在其中模拟被控对象的工作环境，对ECU的算法进行功能验证和测试。
针对前面划分的ISO 26262所关注的静态测试、动态测试和功能验证的要求，下面我们就来看一下解决方案中如何来满足这些需求。
符合ISO26262标准的静态测试
在静态测试中，静态分析主要包括规则检测和质量度量；可靠性测试主要进行运行时错误的检测。
上面提到ASIL A中针对编码准则的需求以及其他ASIL等级所强烈推荐的例如使用风格指南等需求都是不需要运行源程序来检测，因此都属于静态分析的范畴，虽然这些需求也可以通过人工检查的方式实现，但一个好的静态分析工具几乎可以自动化地执行表1中所有的要求，通过静态分析工具来帮助我们检查和满足这些规定可以明显地帮助组织更有效率地实现ISO 26262静态分析的相关需求。
针对静态分析的需求，我们提供DAC这样一个工具，它的主要功能包括：可以自动化地地执行C代码及汇编代码的静态分析，支持包括MISRA-C1998和2004的规则检测；提供项目、文件和函数质量度量；
提供方便快捷的代码结构生成，高亮显示代码结构并生成报告文档等。
在静态测试中，除了规则检测和质量度量以外，还有一类错误我们称之为运行时错误，例如数组越界、标量溢出等。运行时错误顾名思义是程序运行的时候才会出现的错误，针对这样的错误，使用传统的测试方式只有在动态地运行测试用例的时候才有可能发现，但是现在的测试工具可以使用先进的代码分析技术，不需要真正去执行源代码，而是使用数学方法分析源代码，发现代码中在运行的时候可能会出现错误的地方，从而实现通过静态测试的方式来达到一定的动态测试的效果。因为运行时错误会直接影响的程序执行的可靠性，所以针对这类错误的测试我们也可以称之为可靠性测试。
针对可靠性测试的需求，我们提供澳大利亚的一个运行时错误监测工具Goanna。其模型检测技术可以对所有函数提供高效的路径覆盖，检查超过90种运行时错误，包括空指针引用、危险的指针运算、未初始化/未使用变量、冗余/不需要的代码、除零、内存泄露、缓冲区溢出、释放后使用、不一致的释放、滥用的虚拟成员调用、算术错误、32/64位兼容性等。
符合ISO26262标准的软件代码SIL测试
在准备和设计阶段，大部分都是属于静态测试的工作，它在确认设计或实现的不足时非常高效，但它
不能证明功能正确。而依ISO 26262-6标准开发的软件根据需达到的车辆安全完整性等级（ASIL）不同，还需要经过各种动态测试，动态测试可以验证软件功能，因此是对静态测试的有效补充。
以前的动态测试大部分是通过人工的方式实现，但是由于动态测试巨大的工作量，以及测试用例难以重用，测试覆盖率无法计算的困难，因此在测试解决方案中还是需要选择合适的动态测试工具来执行软件单元测试。又因为ISO 26262对需求和测试有可追溯性的要求，所以最好测试工具可以和相关需求管理工具集成，例如能够从需求管理工具中将需求导入，再将测试用例和需求链接起来，并且实现数据的双向同步。
针对软件代码SIL测试，我们提供德国的代码级动态测试工具Tessy。它的基本功能包括：全自动地测试执行和评估；多种方式确定测试用例；基于需求的测试跟踪；不需要用户介入的回归测试；代码覆盖率；自动生成测试报告等。
在Tessy中，测试用例的设计不仅可以基于需求覆盖来进行，包括进行需求管理、需求跟踪、需求覆盖度统计等，也可以基于代码覆盖进行测试用例设计，并且非常方便地达到MC/DC覆盖的等级。
符合ISO26262标准的MIL测试
在汽车领域的嵌入式控制系统开发中，基于模型的开发(Model-Based Development)的设计方法以其直观、快速、高效等优势已经得到广泛的应用。但是由于系统的复杂性，建立起来的仿真模型也越来越复杂，根据自动生成代码的测试结果再来改进模型的测试方式也变得越来越困难，并且根据ISO 26262标准ASIL C和D的要求，必须对模型和对应的代码分别进行单元测试并且比较结果，因此，如果是使用模型自动生成代码的设计方式的话，我们需要在建立了仿真模型之后就对模型进行测试，在确保模型功能正确的基础之上来自动生成代码再进行代码测试。
针对MIL测试，我们提供德国的分时段测试工具TPT，实现对控制系统以及闭环控制系统模型的MIL 测试。TPT软件由于首创地使用分时段测试（Time Partition Testing），使得控制系统的软件测试技术得以极大提升；同时由于TPT软件支持众多业内主流的工具平台和测试环境，能够更好地利用客户已有的投资，实现各种异构环境下的自动化测试；针对MATLAB/Simulink/Stateflow以及TargetLink，TPT专门设计了完美的接口构建功能模型，然后在TPT中创建测试用例模型，通过TPT的MATLAB接口保证测试的高效率执行。提供了全方位的支持进行模型测试。
同时，在TPT中可以满足ISO 26262基于功能设计测试用例的需求，包括分析建立场景、定义测试用例组件、确定场景组合、生成测试用例等。
符合ISO26262标准的网络测试和HIL测试
不论是AUTOSAR还是OSEK，都把网络作为整个软件结构的基础，因此对网络的验证放在功能验证之前进行，ISO 26262也在最低功能安全等级ASIL A里面就提出了网络环境测试的需求。
网络测试是功能测试的基础，在上面有应用层的时候，在做应用层验证之前，先进行网络验证。
现在网络已经越来越复杂，CAN、LIN，一般都有三四十个节点，汽车里面有很多总线的环境，最底下是物理层（CAN-驱动），在CAN的物理层之上有很多应用层的协议栈，利用Vector的HIL测试系统——VT，再基于Vector另一个工具CANoe的优势可以很好的进行协议栈的仿真，实现网络测试的需求。
HIL测试一般可以分为两种情况，一是基于真实负载的测试，另一种是在极端情况下或者说在自动化环境下更常用的是实用方针负载进行测试。不论是真实负载还是仿真负载，最重要的一点就是构建自动化的仿真环境出来，Vector的VT系统能够提供模块化的测试接口设备，为供电环境、总线接口、传感器激励和仿真负载等提供相应的模块来搭建测试环境。CANoe基于它先天的网路仿真的测试功能，再加上VT系统可以帮助我们简化测试平台的搭建以及测试执行的过程，并将测试能力扩展到HIL和功能测试。
符合ISO26262标准的实车测试
不论是代码测试、模型测试还是网络测试或者HIL测试，基本都是偏研发的测试，除此之外在研发后期还需要实车测试。传统实车测试需要专门驾驶员和一些测试人员到现场进行测试并采集数据，而现在比较流行的远程测试则是通过在车上加装一些远程监控设备，将测试系统在测试过程中产生的数据通过远程传输的方式发送到数据后台，并且在测试过程中不仅可以记录测试数据，还能根据测试的要求远程下载测试任务，例如更新需要采集的数据等，我们提供的德国CarMediaLab公司的产品Flea就可以实现这种功能。
车辆实时采集的数据主要是总线信息，需要在分析过程中和工况结合起来，而在进行离线分析时还可以与TPT结合起来。
北汇信息能够提供的服务和技术支持
上海北汇信息科技有限公司在汽车行业具有丰富的嵌入式软件开发和测试的经验，对于ISO 26262标准中过程控制和测试相关内容有深刻理解和实践经验。北汇信息可以为客户提供ISO26262标准的培训，帮助客户理解标准；并且与合作伙伴一起，提供ISO26262标准的实施咨询服务，真正在客户具体的项目中帮助客户全流程满足ISO26262标准；在软件测试方面，提供了完整的软件测试工具链，并提供相应的技术支持和服务。
以满足ISO 26262软件级测试需求为例，北汇信息可以根据客户嵌入式软件开发和测试的业务现状以及客户现有或者将要有的嵌入式软件测试工具，针对汽车行业道路车辆功能安全标准ISO 26262软件级测试的要求构建嵌入式软件测试解决方案。针对ISO 26262的嵌入式软件测试解决方案的本质是从嵌入式软件功能安全的角度来支持公司嵌入式软件开发项目的开展，不仅要分析ISO 26262对于嵌入式软件测试的需求，针对需求搭建相应的软件测试工具链，实现对于测试需求的满足和覆盖，同时必须制定相关软件测试的流程和测试模板，从而保证各阶段测试的有序进行以及能够产生相应的工作产品。
主要分为以下五部分的内容：
1、现状/需求调研：通过前期现状调研，了解客户当前嵌入式软件测试状况和需求，对当前工程过程和ISO 26262软件级开发测试要求进行差距分析，提出可行性改进建议；
2、建立流程：对测试过程进行优化或者重定义一个合适的过程架构，创建嵌入式软件测试过程的描述文档以及相关文档的模板；
3、能力建设：分析和介绍相关的现有或者将有的嵌入式软件测试工具，对工程师进行功能安全相关的软件测试和工具应用的相关培训，将软件测试工具嵌入到软件测试流程中，并使测试人员了解不同的测试工具在嵌入式软件测试生命周期中的位置和作用；
4、测试项目执行：指导用户根据新制定的测试流程，应用嵌入式软件测试工具链开展一个软件测试项目，帮助用户驾驭和优化过程，生成相关工作产品和测试报告；
5、对上述所有活动的规划，监测和报告。
软件测试方法 β测试_Beta测试 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。 α测试_Alpha测试 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 可移植性测试 可移植性测试，英文是Portability testing。又称兼容性测试。 可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试-UI测试 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息(Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入
软件测试标准 前言 前一版的《软件测试标准》，在测试工作中发挥了很好的指导作用。本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 2．2黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 2．3测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2．4预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 2．5测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型，实现测试与软件开发的同步进行。
2.7等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比 概要设计审核概要设计，从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划 审核测试用例 执行测试 测试总结 集成测试阶段验收测试阶段 补充测试用例资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试 测试总结 复测测试报告复测测试用例复测 三、开发—测试流程
软件测试规 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下容：
?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足
XX项目 软件测试方案 编号：XX XX公司 2017年XX月
目录 1 文档说明..................................................错误!未定义书签。 文档信息............................................错误!未定义书签。 文档控制............................................错误!未定义书签。 变更记录......................................错误!未定义书签。 审阅记录......................................错误!未定义书签。 2 引言......................................................错误!未定义书签。 编写目的............................................错误!未定义书签。 读者对象............................................错误!未定义书签。 项目背景............................................错误!未定义书签。 测试目标............................................错误!未定义书签。 测试参考文档和测试提交文档..........................错误!未定义书签。 测试参考文档..................................错误!未定义书签。 测试提交文档..................................错误!未定义书签。 术语和缩略语........................................错误!未定义书签。 3 测试要求..................................................错误!未定义书签。 测试配置要求........................................错误!未定义书签。 硬件环境......................................错误!未定义书签。 软件环境......................................错误!未定义书签。 测试手段............................................错误!未定义书签。 测试方法......................................错误!未定义书签。 测试数据............................................错误!未定义书签。 测试策略............................................错误!未定义书签。 单元测试......................................错误!未定义书签。 集成测试......................................错误!未定义书签。 系统测试......................................错误!未定义书签。 验收测试......................................错误!未定义书签。 测试资源............................................错误!未定义书签。 测试阶段及范围......................................错误!未定义书签。 通过测试的标准......................................错误!未定义书签。 4 软件结构介绍..............................................错误!未定义书签。 概述................................................错误!未定义书签。 5 用例表格..................................................错误!未定义书签。 6 关注点....................................................错误!未定义书签。 文本输入框..........................................错误!未定义书签。 下拉列表............................................错误!未定义书签。 增加数据............................................错误!未定义书签。 修改数据............................................错误!未定义书签。 删除数据............................................错误!未定义书签。 查询数据............................................错误!未定义书签。 数据导入导出........................................错误!未定义书签。 数据接入与处理......................................错误!未定义书签。 其他................................................错误!未定义书签。
测试方案模板 Edit by LJ. 1 概述 1.1 编写目的 [说明编写本测试方案的目的是为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师提供关于**系统整体系统功能和性能的测试指导。] 1.2 读者对象 [本测试方案可能的合法读者对象为软件开发项目管理者、软件工程师、测试组、系统维护工程师] 1.3 项目背景 [可以如下那样简单说明，根据项目的具体情况，方案编写者也可以进行详细说明 项目名称：*** 简称：*** 项目代号：*** 委托单位：*** 开发单位：*** 主管部分：***] 1.4 测试目标 [说明进行项目测试的目标或所要达到的目的] 1.5 参考资料 [列出编写本测试方案时参考的资料和文献]
2 测试配置要求 2.1 网络环境 [在此说明应用系统的网络环境，如果应用系统是网络版的，必须具有本节内容。] 2.1.1 网络硬件 [此处给出网络硬件的拓扑图、名称、规格、数量、配置等信息。] 2.1.2 网络软件 [此处给出网络软件的名称、协议、通讯和连接方式等信息。] 2.2 服务器环境 2.2.1 服务器硬件 [此处给出服务器硬件的名称、规格、数量、配置等信息。] 2.2.2 服务器软件 [此处给出服务器软件名称、协议和版本等信息。] 2.3 工作站环境 2.3.1 工作站硬件 [此处给出工作站硬件的拓扑图、名称、规格、数量、配置等信息。] 2.3.2 工作站软件 [此处给出工作站软件的名称、协议和版本等信息。] 2.4 测试手段 [在此参照《测试计划》说明测试方法和工具，注明执行测试时，必须同时填写《测试记录表》]
2.5 测试数据 [在此简要说明测试数据的形成，如以客户单位具体的业务规则和《***系统需求分析说明书》，参考《***系统概要设计说明书》、《***系统详细设计说明书》和《数据规格说明书》中规定的运行限制，设计测试用例，作为整个**系统的测试数据。] 2.6 测试策略 [在此说明测试策略，可以如下这样说明： 测试过程按三个步骤进行，即单元测试、组装、系统测试，根据不同阶段测试的侧重点不同，分别介绍测试策略： A）单元测试 首先按照系统、子系统和模块进行划分，但最终的单元必须是功能模块，或面向对象过程中的若干个类。单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面： 1）模块接口：对所测模块的数据流进行测试。 2）局部数据结构：检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。 3）路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。 4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。 5）边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。 B）集成测试 集成测试也叫组装测试或联合测试。通常，在单元测试的基础上需要将所有的模块按照设计要求组装成系统，这时需要考虑的问题： 1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。
中国涂装作业安全相关国家标准一览 1、前言 涂装是产品表面保护和装饰所采用的最基本的技术手段，涂装作业遍及国民经济的各个部门。当前我国涂装危害恶性发展趋势有所遏制，但职业危害依然严峻，火灾事故十分严重，环境污染严重。涂装技术有了长足进步，但落后工艺还有相当比例；防护工程技术有了较大进步，但整体安全水平急待提高。涂装职业危害应当引起有关部门的高度重视，采取必要的措施，予以关注。 80年代以来，我国启动了涂装安全标准化工作。现已颁布的标准有：GB/T14441《术语》、GB7691《劳动安全和劳动卫生管理》（已修订，正在报批中），GB7692《涂漆前处理工艺安全及其通风净化》（己修订，将GB7692、7693合并），GB6514《涂漆工艺安全及其通风净化》（已修订，将GB6514、6515合并），GB12367《静电喷漆工艺安全》，GB15607《粉末静电喷涂工艺安全》，GB17750《浸漆工艺安全》，GB14444《喷漆室安全技术规定》，GB14443《涂层烘干室安全技术规定》，GB14773《静电喷枪及其辅助装置安全技术条件》，GB12942《有限空间作业安全技术要求》等11项国家标准。现将标准体系的基本要点作如下概述。 2、限制、淘汰严重危害人民安全健康的涂料产品和涂装工艺
--积极推广有利于人类安全健康的涂料和涂装工艺； --禁止使用含苯的涂料、稀释剂和溶剂；禁止使用含铅白的涂料；限制使用含红丹的涂料；禁止使用含苯、汞、砷、铅、镉、锑和铬酸盐的车间底漆； --严禁在前处理工艺中使用苯；禁止使用火焰法除旧漆；禁止在大面积除油和除旧漆中使用甲苯、二甲苯和汽油；严格限制使用干喷砂除锈。 修订GB7691时，将进一步提高和扩大限制、淘汰的范围： --将含铅白的涂料由禁止提高到严禁使用；将干喷砂除锈由限制提高到禁止使用；新增限制使用含二氯乙烷的清洗液；限制使用含铬酸盐的清洗液； 3、对涂料、金属清洗液、化学处理淮实施化学品管理 --对涂装作业使用的化学品，实施国际劳工组织《1990年化学品公约》管理。 --涂料及有关化学品生产单位应注册登记，评价确定化学品危害性。--涂料及有关化学品，必须提供符合规定的标签、包装和安全技术说明书。 --所有的（生产、经营、运输、贮存、使用）的经济部门都要遵守有关规定。 --进口的涂料及有关化学品必须提供中文安全技术说明书，加贴中文
软件测试标准规范 1目的 为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护 记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容： ?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
软件测试方案设计 编写20xx 年xx 月xx 日审核年月日批准年月日
版本控制 注：（A-添加，M-修改，D-删除）
目录 1 概述 (4) 1.1 编写目的 (4) 1.2 读者对象 (4) 1.3 项目背景 (4) 1.4 测试目标 (4) 1.5 参考资料 (4) 2 测试配置要 (4) 2.1 测试手段 (4) 2.2 测试数据 (5) 2.3 测试策略 (5) 2.4. 测试通过准则 (6) 3 软件结构介绍 (6) 3.1 概述 (6) 3.2 整体功能模块介绍 (6) 3.3 整体功能模块关系图 (6) 3.4 系统外部接口功能模块关系图 (7) 3.5 系统内部接口功能模块关系图 (7) 4 系统测试用例 (7) 4.1 XX系统 (7) 4.1.1 用户界面 (7) 4.1.2 功能测试 (8) 7 附录 (8) 7.1 附录1 审批记录表 (8) 角色 (8) 签名 (8) 日期 (8) 备注 (8)
说明：蓝色说明文字，文档编写完成后，请删除。 1 概述 1.1 编写目的 编写本测试方案的目的是为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师提供关于**系统整体系统功能和性能的测试指导。 1.2 读者对象 本测试方案可能的合法读者对象为软件开发项目管理者、软件工程师、测试组、系统维护工程师 1.3 项目背景 简单说明，根据项目的具体情况，方案编写者也可以进行详细说明 1.4 测试目标 说明进行项目测试的目标或所要达到的目的 1.5 参考资料 列出编写本测试方案时参考的资料和文献 2 测试配置要 2.1 测试手段 在此参照《测试计划》说明测试方法和工具，注明执行测试时，必须同时填写《测试记录表》
测试工作规范版本记录： 文件状态：[√] 草稿[ ] 正式发布[ ] 正在修改当前版本：1.1 作者：** 完成日期：2004-9-15签收人： 签收日期： 1编写目的 本文档是测试团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试团队应完成的工作。测试技术和策略等问题不在本文档描述范围内。 2测试团队构成 2.1职责 测试是软件开发过程中的重要组成部分，肩负着如下责任： 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。 编写合理的测试计划，并与项目整体计划有机地整合在一起。
编写覆盖率高的测试用例。 针对测试需求进行相关测试技术的研究。 认真仔细地实施测试工作，并提交测试报告供项目组参考。 进行缺陷跟踪与分析。 2.2角色划分 在人力资源有限的情况下，一个团队成员可能会同时承担多个角色。角色名称相关主要责任 测试经理组建测试组 协调测试组内部的沟通 代表测试组与其他角色组进行沟通编写测试计划 测试报告分析 测试用例设计工程师编写测试用例{可以由测试经理兼任}测试实施工程师实施测试用例，执行测试 技术支持工程师为测试工作提供技术支持 3工作流程及规范
3.1计划与设计阶段 在项目组成立的同时，测试组也将同时成立。团队成立的工作与责任如下：
图表 2
划。测试计划中应该至少包括以下关键内容： 测试需求——需要测试组测试的范围，估算出测试所花费的人力资源和各个测试需求的测试优先级 测试方案——整体测试的测试方法和每个测试需求的测试方法 测试资源——本次测试所需要用到的人力、硬件、软件、技术的资源 测试组角色——明确测试组内各个成员的角色和相关责任 里程碑——明确标准项目过程中测试组应该关注的里程碑 可交付工件——在测试组的工作中必须向项目组提交的产物，包括测试计划、测试报告等等 风险管理——列举出测试工作所可能出现的风险 测试计划编写完毕后，必须提交给项目组全体成员，并由项目组组中各个角色组联合评审。 测试计划由项目组评审通过. 在项目开发过程中，要适时的对测试计划进行跟踪，以评估此计划的完整性、可行性，在项目结束时还要最后
软件测试完成标准 目录 1.简介 (2) 1.1目的 (2) 1.2范围 (2) 1.3文档结构 (2) 1.4词汇表 (2) 2.软件测试完成标准 (3) 2.1软件测试暂停、完成标准 (3) 2.2单元测试停止标准 (3) 2.3集成测试停止标准 (3) 2.4确认测试停止标准 (3) 2.5系统测试停止标准 (4) 2.6安装测试停止标准 (4) 2.8验收测试停止标准 (4) 2.9缺陷修复率标准 (5) 2.10覆盖率标准 (5) 2.11缺陷等级分类 (5)
1.简介 1.1目的 本文档的目的是为软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试提供停止标准。 1.2范围 本文档适用于虹信软件股份有限公司所有项目及产品的测试活动。 1.3文档结构 第一部分： 简介，介绍软件停止标准的目的，本标准的适用范围，以及在本文档中使用的词汇的解释。 第二部分： 描述软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试停止标准。 第三部分： 列出本标准使用的参考文献。 第四部分： 附录 1.4词汇表 缺陷（Defect）：缺陷是对软件产品预期属性的偏离现象。 覆盖率（Coverage rate）：语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。
2. 软件测试完成标准 2.1 软件测试暂停、完成标准 1)软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现紧急错误 大于等于严重级别错误暂停测试返回开发。 2)软件系统经过单元、集成、确认、系统、安装、验收测试，分别达到单元、集 成、确认、系统、安装、验收测试停止标准。 3)软件系统通过验收测试，并已得出验收测试结论。 4)软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。 5)软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测 试应随之暂停或终止，并备份暂停或终止点数据。 2.2 单元测试完成标准 1)按照单元测试计划完成了所有规定单元的测试 2)达到了测试计划中关于单元测试所规定的覆盖率的要求 3)软件单元功能与设计一致 4)在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.3 集成测试完成标准 1)按照集成构件计划及增量集成策略完成了整个系统的集成测试 2)达到了测试计划中关于集成测试所规定的覆盖率的要求 3)被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误） 4)集成工作版本满足设计定义的各项功能、性能要求 5)在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.4 功能测试完成标准 1)功能测试用例设计已经通过评审 2)按照功能测试计划完成了功能测试 3)达到了功能测试计划中关于功能测试所规定的覆盖率的要求 4)系统达到详细设计定义的各项功能，性能
食品包装相关国家标准 序号标准号名称 1 GB/T 330 2 - 2009 日用陶瓷器包装、标志、运输、贮存规则 2 GB/T 3532 - 2009 日用瓷器 3 GB/T 4456 - 2008 包装用聚乙烯吹塑薄膜 4 GB 4544 - 1996 啤酒瓶 5 GB/T 4768 - 2008 防霉包装 6 GB 4803-94 食品容器、包装材料用聚氯乙烯树脂卫生标准 7 GB 4804-84 搪瓷食具容器卫生标准 8 GB 4805-84 食品罐头内壁环氧酚醛涂料卫生标准 9 GB 4806.1-94 食品用橡胶制品卫生标准 10 GB 4806.2-94 橡胶奶嘴卫生标准 11 GB 4808 食品用高压锅密封圈卫生标准 12 GB/T 4879 - 1999 防锈包装 13 GB 5369 - 2008 船用饮水舱涂料通用技术条件 14 GB/T 5737-1995 食品塑料周转箱 15 GB/T 5738-1995 瓶装酒、饮料塑料周转箱 16 GB 7105-86 食品容器过氯乙烯内壁涂料卫生标准 17 GB 7189-1994 食品用石蜡 18 GB 8058-2008 陶瓷烹调器铅镉溶出量允许极限和检测方法 19 GB/T 8946-1998 塑料编织袋 20 GB/T 8947-1998 复合塑料编织袋
21 GB 9106-2001 包装容器铝易开盖两片罐 22 GB 9680-1988 食品容器漆酚涂料卫生标准 23 GB 9681-1988 食品包装用聚氯乙烯成型品卫生标准 24 GB 9682-1988 食品罐头内壁脱膜涂料卫生标准 25 GB 9683-1988 复合食品包装袋卫生标准 26 GB 9684-1988 不锈钢食具容器卫生标准 27 GB 9685-2008 食品容器、包装材料用添加剂使用卫生标准 28 GB 9686-1988 食品容器内壁聚酰胺环氧树脂涂料卫生标准 29 GB 9687-1988 食品包装用聚乙烯成型品卫生标准 30 GB 9688-1988 食品包装用聚丙烯成型品卫生标准 31 GB 9689-1988 食品包装用聚苯乙烯成型品卫生标准 32 GB 9690-2009 食品容器，包装材料用三聚氰胺-甲醛成型品卫生标准 33 GB 9691-1988 食品包装用聚乙烯树脂卫生标准 34 GB 9692-1988 食品包装用聚苯乙烯树脂卫生标准 35 GB 9693-1988 食品包装用聚丙烯树脂卫生标准 36 GB/T 10002.1-2006 给水用硬聚氯乙烯(PVC-U)管材 37 GB/T 10002.2-2006 给水用硬聚氯乙烯(PVC-U)管件 38 GB/T10003-2008 普通用途双向拉伸聚丙烯薄膜 39 GB/T10004-2008 包装用塑料复合膜、袋干法复合、挤出复合 40 GB/T 10440-2008 圆柱形复合罐
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
XX项目 软件测试方案 编号:XX XX公司 2017年XX月
目录 1 文档说明 (1) 1.1 文档信息 (1) 1.2 文档控制 (1) 1.2.1 变更记录 (1) 1.2.2 审阅记录 (1) 2 引言 (2) 2.1 编写目的 (2) 2.2 读者对象 (2) 2.3 项目背景 (2) 2.4 测试目标 (2) 2.5 测试参考文档和测试提交文档 (2) 2.5.1 测试参考文档 (2) 2.5.2 测试提交文档 (3) 2.6 术语和缩略语 (3) 3 测试要求 (5) 3.1 测试配置要求 (5) 3.1.1 硬件环境 (5) 3.1.2 软件环境 (5) 3.2 测试手段 (6) 3.2.1 测试方法 (6) 3.3 测试数据 (6) 3.4 测试策略 (6) 3.4.1 单元测试 (6) 3.4.2 集成测试 (7) 3.4.3 系统测试 (7) 3.4.4 验收测试 (11) 3.5 测试资源 (11) 3.6 测试阶段及范围 (11) 3.7 通过测试的标准 (11) 4 软件结构介绍 (12) 4.1 概述 (12) 5 用例表格 (14) 6 关注点 (14) 6.1 文本输入框 (14) 6.2 下拉列表 (15) 6.3 增加数据 (15) 6.4 修改数据 (15) 6.5 删除数据 (15) 6.6 查询数据 (16) 6.7 数据导入导出 (16) 6.8 数据接入与处理 (16)
6.9 其他 (16) 7 附录 (16) 7.1 附录1审批记录表 (16)
1文档说明 1.1文档信息 文档基本信息参看表1-1文档信息表。 1.2文档控制 1.2.1变更记录 文档变更记录在表1-2文档变更记录表中详细记录。 1.2.2审阅记录 表1-3审阅记录表中详细记录了审阅记录。
上海兴汉科技公司软件测试规范
目录
一.概述 本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。
1.什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 2.软件测试的目标 下面这些规则也可以看作是测试的目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。 由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。
软件测试方案 一、软件测试目的 1、论证软件的有用性及数据处理的准确性 2、总结一套基于软件的成本控制工作方法 二、软件测试涉及的人员及其任务 1、施工员：开工前，负责拟定施工方案、临时工程的施工图设计、编制进度计划、并据此配置由总承包企业（本企业）自行采购的生产工人、施工机械和周转材料，形成需求计划（直方图）；施工过程中，根据新的条件随时变更施工方案、临时工程的施工图设计、进度计划以及生产工人、施工机械和周转材料的需求计划（直方图）。 2、预算员：开工前，负责编制拟建工程的工程量清单计价文件、临时工程的工程量计算；施工过程中，根据拟建工程设计变更随时计算增减工程量、按期提供现行预算价格资料、根据变更后的临时工程设计随时计算临时工程的增减工程量、定期统计实际进度（实际完成的定额工程量）、随时记录实体材料的供应信息（包括每批次的供应日期、供应商、供应量、价格）、控制期末实体材料库存量的盘点、随时记录施工机械和周转材料的进退场信息（包括每批次的进退场日期、供应商、进退场数量、价格）、如果使用了本企业的生产工人则还需要负责要对他们进行考勤。 3、料具员：开工前，负责预测和提供估算施工项目成本所需的人工、材料和机械的价格；施工过程中，负责向预算员提供每批次材料（机械、周材）的实际价格。
4、项目经理：开工前，负责拟定分包方案、选择分包商和确定分包合同造价、根据项目经理部的人员构成估算现场管理费和其他相关的费用开支；施工过程中，负责确定各个控制期内分包工程的实际进度款支付额、现场管理费和其他相关费用的实际支付额。 5、软件测试人员：总的来讲，负责全面、全过程施工项目成本计划和控制的决策支持信息的提供。具体地讲，开工前，负责估算施工项目的计划成本（包括成本汇总、成本项目和量价明细等三个层次）、进行施工项目预期收支情况的对比分析；施工过程中，负责定期核算对应于实际进度的实际成本、分析控制期成本差异、计算控制期末成本动态差异、负责动态的施工项目收支对比分析。 三、软件测试的工作流程
测试计划
目录 1.概述............................................................................................................................................ (1) 1.1产品简介1 1.2范围1 1.3限制条件1 1.4参考文档1 2.约定2 2.1测试目标2 2.2接收规范2 2.3资源和工具2 2.3.1资源2 2.3.2工具2 2.4送测要求2 2.5编号规则2 3.测试种类及测试规范3 3.1测试种类3 3.2测试方法及规范3 3.2.1功能测试3 3.2.2业务测试3 3.2.3压力测试3 3.2.4安装测试3 3.2.5验收测试3 4.测试重点及顺序4 4.1预测风险4 4.2测试重点4 4.2.1功能测试4 4.2.2业务测试4 5.暂停规范和再启动要求5 6.测试任务和进度6 7.测试提交物7
1.概述 1.1产品简介 本次开发是在销售助手一期的基础上进行的后续开发，包括新增客服功能模块、解决一期遗留的售前部分问题、完成必要的库房经管功能。二期结束后产品就成为一个比较完整的销售经管软件。 1.2范围 本测试计划是针对<销售助手二期概要设计说明书>中规定内容的测试计划，包括：?改进后的报价书 ?改进后的客户关怀 ?销售机会中新增加的客户反馈 ?销售机会中新增加的客户组织分析 ?销售机会中改进的竞争经管（待定） ?销售机会中改进的联系人 ?改进后的产品和价格配制器 ?新增的销售知识库 ?新增的联系活动经管 ?新增的客户请求模块 ?新增的客服活动模块 ?新增的客服合同模块 ?新增的客服计划模块 ?新增的客服知识库模块 ?新增的完成关联任务模块 ?公共部分新加或改进的日历浏览数据 ?公共部分新加或改进的报表功能 ?公共部分新加或改进的个人事务中心 1.3限制条件 本测试计划受限于产品开发人员提交测试的内容和时间的事实。根据开发人员提交模块的实际情况，本计划会做出相应修改。 1.4参考文档
防静电相关国家标准及其它标准 GB1410-89《固体电工绝缘材料绝缘电阻、体积电阻系数和表面电阻试验方法》GB1692-81《硫化橡胶绝缘电阻率的测定方法》西北橡胶工业制品研究所 GB2439-81《导电和抗静电橡胶电阻率(系数)的测定方法》沈阳第四橡胶厂GB3684-83《运输带导电性规范和试验方法》青岛橡胶工业研究所 GB4386-84《防静电胶底鞋、导电胶底鞋电阻值测量方法》 GB4385-84《防静电胶底鞋、导电胶底鞋安全技术条件》北京市劳保所 GB4655-84《橡胶工业静电安全规程》GB6950-86《轻质油品安全静止电导率》GB6539-86《轻质石油产品电导率测定法》石化研究院, GB6951-86《轻质油品装油安全油面电位值》 GB6650-86《计算机房用活动地板技术条件》 GB6833.3-87《电子测量仪器电磁兼容性试验规范静电放电敏感度试验》GB9572-88《橡胶、塑料软管和软管组合件电阻的测定》沈阳橡胶所 GB10715-89《抗静电环形V带导性规定值和试验方法》 GB12014-89《防静电工作服》 GB11210-89《硫化橡胶抗静电和导电制品电阻的测定》 GB12158-90《防止静电事故通用导则》 GB/T 12582-90 《液态烃类电导率测定方法》石化研究院
GB 12367-90 《涂装作业安全规程静电喷漆工艺安全 GB/T12582-90 《液态烃类电导率测定方法(精密静电计法)》 GB/T12703-91《纺织品静电性能测试方法》北京理工大学 GB 13348-92 液体石油产品静电安全规程江苏省劳动保护科学技术研究所GB/T14288-93《可燃气体与易燃液体蒸汽最小静电点火能测定方法》 GB 14773-93 涂装作业安全规程静电喷枪及其辅助装置安全技术条件 GB/T 1447-93《塑料薄膜静电性能测试方法半衰期法》 GB/T 50174-93《电子计算机房设计规范》 GB/T14342-93《合成短纤维试验方法比电阻》 GB/T 15463-1995 《静电安全术语》劳动部劳保所 GB 15607-1995 《涂装作业安全规程粉末静电喷涂工艺安全》 GB 15599-1995 《石油与石油设施雷电安全规范》 GB/T15662-1995 《导电、防静电塑料体积电阻率测试方法》 GB/T 15738-1995 《导电和抗静电纤维增强塑料电阻率试验方法》 GB/T 16801-1997 《织物调理剂抗静电性能的测定》中国日用化学工业研究所