2.重点车测试方案

第6页共17页版本：V1.0“重点车辆运行体征及精细化管理”应用场景功能升级软件迭代开发项目测试方案项目承建单位：成都交投智能交通技术服务有限公司编制日期：2022年8月

文件建立/修改记录序号版本建立或修改建立/修改人日期审核人日期批准人日期1V1.0新建2022-8-15袁海龙2022-8-16

目录1 概述 51.1 适用对象和范围 51.2 术语表 51.2.1. 系统测试 51.2.2. 黑盒测试（功能测试） 51.2.3. 白盒测试 51.2.4. 灰盒测试 51.2.5. 健壮性测试（容错能力/恢复能力测试） 51.2.6. 接口测试 61.2.7. 强度测试 61.2.8. 压力测试 61.2.9. 性能测试 61.2.10. 安全测试 61.2.11. 可靠性测试 61.2.12. 文档测试 62 测试工作流程 72.1 测试管理总流程 72.2 制定测试计划工作流程 72.3 测试工作总体流程 82.4 功能测试工作流程 92.5 集成测试工作流程 102.6 BUG修复和管理流程 113 测试参考文档和测试提交文档 123.1. 测试参考文档 123.2. 测试提交文档 124 测试团队 134.1. 人员、角色、职责 134.2. 测试环境 135 测试方法和方式 146 通过测试的标准 147 测试中断与开始的标准 148 测试策略 158.1. 数据和数据库完整性测试 158.2. 接口测试 158.3. 集成测试 158.4. 功能测试 168.5. 用户界面测试 168.6. 性能评测 178.7. 安全性和访问控制测试 179 测试任务 1810 测试用例编写方案及相关约定 1910.1. 编写原则 1910.2. 衡量测试用例设计的质量标准 1911 测试用例 2111.1 公共预置条件 2111.2 业务场景 2111.2.1 运行体征 2111.2.2 运行监测 2211.2.3 精细管理 2211.2.4 研判分析 2411.2.5 GPS异常 2411.2.6 配置管理 2512 实施建议 2713 附录一缺陷分类 2714 附录二缺陷严重程度 2815 附录三优先级 2916 附录四测试计划审批意见 30

概述本文档主要针对”重点车辆运行体征及精细化管理”应用场景功能升级软件迭代开发项目测试用例并指导测试，并展示测试情况。采用黑盒测试，主要按照功能需求和期望效果，依照测试操作流程步骤进行操作，对测试过程中发现问题进行上报，阶段性测试完成后由开发人员统一进行bug修复，待所有已知问题为修复完成状态后，由测试人员进行下一轮测试。测试终端主要为Andriod、IOS和PC。适用对象和范围本文档可提供给”重点车辆运行体征及精细化管理”应用场景功能升级软件迭代开发项目组的测试人员、研发人员、项目实施人员阅读和使用。术语表系统测试系统测试是通过与系统的需求规格作比较，发现软件与系统需求规格不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统进行的测试。黑盒测试（功能测试）黑盒测试是基于系统需求规格，在不知道系统或组件的内部结构的情况下进行的测试。通常又将黑盒测试叫做：基于规格的测试、输入输出测试、功能测试或数据驱动测试。是基于用户观点出发的测试。主要是验证功能是否符合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。白盒测试白盒测试也叫结构测试、逻辑驱动测试或给予程序的测试。主要是分析程序的内部构造，并根据内部构造设计测试用例。灰盒测试可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间,对软件内部有所了解,但不见得到了如指掌的程度,却可以结合这些了解做些比黑盒多点的测试。健壮性测试（容错能力/恢复能力测试）侧重于程序容错能力的测试。本测试在单元测试阶段和系统测试阶段都要进行。如数据边界测试、非法数据测试、异常中断测试等等，主要是验证程序对各种异常情况是否进行正确处理。接口测试程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。建议由开发人员进行。强度测试强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。压力测试对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如，测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。性能测试在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试有密切关系。所以压力和强度测试应该于性能测试一同进行。安全测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。可靠性测试这里是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行一个统计，在实际工作中如果没有条件可以不必特意去做。重点做好与之紧密相关的功能测试、健壮性测试就可以了。文档测试主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。测试工作流程测试管理总流程制定测试计划制定测试计划设计测试用例执行测试用例BUG修复和管理审批审批迭代制定测试计划工作流程确定阶段的测试范围和任务确定阶段的测试范围和任务确定测试方法和方式确定测试环境与辅助工具确定测试完成准则确定测试人员与任务表确定测试相关规范和约定输入需求规格说明书输入项目计划书测试计划测试工作总体流程设计阶段设计阶段编码及单元白盒测试阶单元黑盒测试阶段段集成测试阶段验收测试阶段总结阶段功能测试工作流程详细设计详细设计编码及白盒测试测试用例编码审核测试用例审核单元测试总结测试报告提交Bug报告循环达到测试要求进入集成测试集成测试工作流程单元测试审核单元测试审核集成测试测试用例接上一阶段测试用例审核提交Bug报告达到集成测试要求测试总结报告进入验收测试BUG修复和管理流程测试人员发现测试人员发现bug由项目经理或测试组长确认是否为bugbug状态为打开开发人员修复bugbug关闭否是测试员回归测试测试人员或项目经理再次确认是否为bug是否测试参考文档和测试提交文档测试参考文档下表列出了制定测试计划时所使用的文档，并标明了各文档的可用性：文档（版本/日期）已创建或可用已被接收或已经过复审作者或来源备注软件需求规格说明书是[]否[]是[]否[]软件概要设计是[]否[]是[]否[]软件详细设计是[]否[]是[]否[]测试计划及方案是[]否[]是[]否[]测试报告是[]否[]是[]否[]用户操作手册是[]否[]是[]否[]测试提交文档文档已创建或可用已被接收或已经过复审作者或来源备注测试计划及方案是[]否[]是[]否[]测试用例是[]否[]是[]否[]测试报告是[]否[]是[]否[]测试团队人员、角色、职责人员角色职责、任务备注袁海龙项目经理项目总体管理与协调张诗雅测试小组长、测试设计员质量控制冉勇均测试设计员测试员质量控制杨沛东测试设计员测试员质量控制阮宇、冉红涛、杨柠宾开发人员负责指导软件开发，解决疑难问题，软件开发与深化设计测试环境下表列出了测试的系统环境软件环境（相关软件、操作系统等）开发软件IntelliJIDEA2019.3.3x64、NavicatPremium12、RedisDesktopManager、PLSQLDeveloper13(64bit)、Postman、Xshell5、Xftp5运行支撑软件Nginx、tomcat、mysql、oracle系统软件windowsserver2009、windows10、linux-centos7.6硬件环境（网络、设备等）客户端Android、PC服务端请参照附件安装配置报告.docx服务端列表网络备注具体参照需求规格说明书需求约定、概要设计说明书设计约定。测试方法和方式测试方式主要以手工测试为主，在条件允许的情况下使用自动化测试工具进行测试。测试方法测试覆盖率执行人员描述黑盒测试100%测试人员功能测试或数据驱动测试灰盒测试10~20%测试或开发人员静态的白盒测试或动态的黑盒测试白盒测试5%开发人员结构测试或逻辑驱动测试说明：黑盒测试是依据用户能看到的规格说明，即针对命令、信息、报表等用户界面及体现他们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。主要由测试小组人员完成执行黑盒测试。通过测试的标准一般有“基于测试用例”和“基于缺陷密度”两种评比准则，在这里我们采用前者。准则如下：（1）功能性测试用例通过率达到100％；（2）非功能性测试用例通过率达到95％；（3）沒有高于优先级3以上的问题。备选通过办法：根据实际情况由软件开发部门的经理、项目经理和测试负责人等共同讨论确定本阶段是否结束。测试中断与开始的标准当优先级1的问题超过总体问题的1/3时当优先级2的问题超过总体问题的1/2时当优先级3的问题超过总体问题的3/4时测试重新开始时的回归测试项目。测试策略数据和数据库完整性测试测试目标：[确保数据库访问方法和进程正常运行，数据不会遭到损坏]测试范围：技术：[调用各个数据库访问方法和进程，并在其中填充有效的和无效的数据（或对数据的请求）。检查数据库，确保数据已按预期的方式填充，并且所有的数据库事件已正常发生；或者检查所返回的数据，确保正当的理由检索到了正确的数据]开始标准：完成标准：[所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭到损坏。]测试重点和优先级：需考虑的特殊事项：[测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。接口测试测试目标确保接口调用的正确性 测试范围：所有软件、硬件接口，记录输入输出数据技术：开始标准：完成标准：测试重点和优先级：需考虑的特殊事项：接口的限制条件集成测试测试目标检测需求中业务流程，数据流的正确性测试范围：需求中明确的业务流程，或组合不同功能模块而形成一个大的功能。技术：[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]开始标准：在完成某个集成测试时必须达到标准各模块接口都已完成编码完成标准：[所计划的测试已全部执行。所发现的缺陷已全部解决。]测试重点和优先级：测试重点指在测试过程中需着重测试的地方，优先级可以根据需求及严重来定需考虑的特殊事项：[确定或说明那些将对功能测试的实施和执行造成影响的事项或因素（内部的或外部的）]功能测试测试目标[确保测试的功能正常，其中包括，数据输入，信息发送、转发、接收，处理和检索等功能。]测试范围：[“重点车辆运行体征及精细化管理”应用场景功能升级软件迭代开发项目各个客户端模块功能、后台管理各模块功能]技术：[利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容：在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]开始标准：[各功能项都已完成开发]完成标准：[具体参照本文通过测试的标准。]测试重点和优先级：需考虑的特殊事项：1）功能是否符合需求2）功能是否完整3）功能是否有作用4）功能是否无错误用户界面测试测试目标[核实以下内容：通过测试进行的浏览可正确反映业务的功能和需求。界面特征（例如，菜单、大小、位置、状态）都符合标准。]测试范围：技术：[为每个界面创建或修改测试，以核实各个应用程序和对象都可正确地进行浏览，并处于正常的状态。]开始标准：完成标准：[成功地核实出各个操作界面都与基准版本保持一致，或符合可接受标准]测试重点和优先级：需考虑的特殊事项：[并不是所有定制或第三方对象的特征都可访问。]性能评测测试目标[核实所指定的事务或业务功能在以下情况下的性能行为：正常的预期工作量预期的最繁重工作量]测试范围：技术：[使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代数量。]开始标准：完成标准：[单个事务或单个用户：在每个事务所预期时间范围内成功地完成测试，没有发生任何故障。][多个事务或多个用户：在可接受的时间范围内成功地完成测试，没有发生任何故障。]测试重点和优先级：需考虑的特殊事项：需考虑的特殊事项：[负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。]安全性和访问控制测试安全性和访问控制测试侧重于安全性的两个关键方面：应用程序级别的安全性，包括对数据或业务功能的访问。系统级别的安全性，包括对系统的登录或远程访问。测试目标[应用程序级别的安全]测试范围：技术：应用程序级别的安全性：[确定并列出各用户类型及其被授权访问的功能或数据。][为各用户类型创建测试，并通过创建各用户类型所特有的事务来核实其权限。][修改用户类型并为相同的用户重新运行测试。对于每种用户类型，确保正确地提供或拒绝了这些附加的功能或数据。]开始标准：完成标准：[所有事务都按照预期的方式运行，并在先前的应用程序功能测试中运行了所有的事务。]测试重点和优先级：需考虑的特殊事项：测试任务本次测试主要包括单元测试、集成测试、系统测试。单元测试由开发人员互检为主，测试人员提供相应的工具。集成测试和系统测试由开发人员同测试人员联合完成，由测试人员编写测试计划，测试方案，测试用例以及测试报告。测试实施过程需要开发人员的参与。制定测试计划:(测试设计员)制定测试计划的目的是收集和组织测试计划信息，并且创建测试计划。1.确定测试需求—根据需求工件集收集和组织测试需求信息，确定测试需求。2.制定测试策略—针对测试需求定义测试类型、测试方法以及需要的测试工具等。3.建立测试通过准则—根据项目实际情况为每一个层次的测试建立通过准则。4.确定资源和进度—确定测试需要的软硬件资源、人力资源以及测试进度。5.评审测试计划—根据同行评审规范对测试计划进行同行评审。设计测试:(测试设计员)设计测试的目的是为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。1.设计测试用例：对每一个测试需求，确定其要的测试用例。对每一个测试用例，确定其输入及预期结果。确定测试用例的测试环境配置、需要的驱动界面或稳定桩。编写测试用例文档2.开发测试过程：根据界面原型为每一个测试用例定义详细的测试步骤。为每一测试步骤定义详细的测试结果验证方法。为测试用例准备输入数据。编写测试过程文档。在实施测试时对测试过程进行更改。3.设计驱动程序或稳定桩—设计单元测试和集成测试需要的驱动程序和稳定桩。实施测试:(开发人员和测试人员)实施测试的目的是创建可重用的测试脚本，并且实施测试驱动程序和稳定桩。编写驱动程序和稳定桩—根据设计编写测试需要的测试驱动程序和稳定桩。实施单元测试:(开发人员)执行单元测试的目的是验证单元的内部结构以及单元实现的功能。1.执行单元测试—按照测试过程手工执行单元测试或运行测试脚本自动执行单元测试。2.记录单元测试结果—将单元测试结果作详细记录，并将测试结果提交给相关组。3.回归测试—对修改后的单元执行回归测试。实施集成测试:(开发人员或测试员)执行集成测试的目的是验证单元之间的接口以及集成工作版本的功能、性能等。1.执行集成测试—按照测试过程手工执行集成测试或运行测试脚本自动执行集成测试。2.记录集成测试结果—将集成测试结果作详细记录，并将测试结果提交给相关组。3.回归测试—对修改后的工作版本执行回归测试，或者对增量集成后的版本执行回归测试。实施系统测试:(测试人员)执行系统测试的目的是确认软件系统工作版本满足需求。1.执行系统测试—按照测试过程手工执行系统测试或运行测试脚本自动执行系统测试。2.记录系统测试结果—将系统测试结果作详细记录，并将测试结果提交给相关组。3.回归测试—对修改后的软件系统版本执行回归测试。测试用例编写方案及相关约定编写原则（1）基本的原则就是：“一点多例”，就是针对一个测试点或者功能点，编写多个测试用例，从多个方面进行测试。各个部分的用例编写的都贯穿着这一基本思想。（2）单元测试由开发人员执行，可以自身决定是否编写单元测试用例。（3）对于每个用例事件流，测试需求的详细列表至少会包括一个测试需求。对于需求规格说明书中的功能描述，将至少派生一个测试需求。（4）测试项描述-简要说明测试用例所要涉及的项和特性、对于每一项、可考虑引用以下文件：需求说明书、设计说明书、用户手册、操作手册。（5）输入说明描述-规定执行测试用例所需的各个输入。有些输入可以用值（允许适当的误差）来规定。而另一些输入，如常数表或事务文件可以用名来规定。规定所有合适的数据库、文件、终端信息传送的值。（6）输出说明描述-规定测试项的所有输出和特性（如：响应时间）。提供各个输出或特性的正确值。（7）测试用例的设计，始终要考虑测试的执行，同时测试发现的问题和总结的经验也可以用来完善测试设计。衡量测试用例设计的质量标准（1）可测性：测试用例的所有步骤是可测的，测试的步骤是具体可实施后的，按照每个步骤是可以走通的。（2）可验证：测试的每个步骤验证点是具体、可验证的。期望结果不是抽象的描述，而是可获得的。（3）全面性：测试执行人员，无须考虑怎么测、而是参照测试用例设计的步骤执行，测试数据的准备也要在测试设计时考虑，而且要具备高覆盖率和全面性。测试用例公共预置条件1数据库基本数据已配置正确2前台与后台服务程序连接正常业务场景运行体征运营指标运营指标输入单位信息处理结合单位信息，展示相应辖区的渣土车备案书、在线数，以及事故数量、预警处理数量，以及五类要素的画像信息输出支持渣土车整体指标查看：包括渣土车备案数、实时全市在途渣土车辆数、今日上线车辆数、今日渣土车运行风险指数。支持出行强度查看：今日平均行驶里程、今日平均行驶时长等行驶特征展示。支持违规预警数据的多维度展示。支持交通事故数据的多维度展示。画像指标画像指标输入单位信息处理驶员、车辆、企业、工地、路线五大要素的基本信息相关联输出对驾驶员、车辆、企业、工地、路线五大要素的体征信息进行精细化管理，支持风险画像一级体征，及进一步支持查看其详细信息。地图展示地图展示输入单位信息、车辆信息、地理信息平台接口处理单位信息、车辆信息、地理信息平台接口相关联输出地图实时展示各个辖区在途渣土车数量，刷新频率不高于5分钟，各区域颜色根据数据值高低进行颜色区分。运行监测渣土车监测渣土车监测输入单位信息、渣土车GPS信息、预警类型处理结合单位信息、预警类型与渣土车GPS进行匹配输出系统中至少实现6类预警：超速、偏离路线、驶入围栏、逾期未年检、上路未开GPS、群众举报预警支持对车辆、企业预警数据，以每周的频率，提供给蓉e行。支持正常车辆、异常车辆、静止车辆、低速车辆实时位置的图上展示，并支持显示车辆的详细信息，查看车辆运行轨迹。驾驶员监测驾驶员监测输入单位信息、人员信息、预警类型处理结合单位信息、预警类型与人员信息进行匹配输出支持以车辆为载体，进行驾驶员相应监管信息呈现，驾驶员画像、登记信息、事故信息等。工地监测工地监测输入单位信息、工地信息、预警类型处理结合单位信息、预警类型与工地信息进行匹配输出支持对工地进行监管，基本信息、审批线路、运输企业、所含车辆、风险画像、视频监控。通过图层方式显示数据。可以进一步查看工地基本信息、视频信息、以及审批路线情况。精细管理线路审批线路审批输入账号信息，调用接口处理智能交通综合集成管理与应用平台对接输出线路审批功能完备业务监管-预警处置业务监管-预警处置输入日期处理预警信息、单位信息输出1）支持预警信息下发工作流。由支队下发分局（大队），分局（大队）甄别处置并反馈。2）支持预警信息展示，包括预警信息、已下发的预警信息以及相关预警类型等属性的筛选功能。3）根据预设的规则，预警结果支持自动下发。4）根据分局的处置结果，预警状态分为：未处理、处置中、已完成、已忽略。业务监管-约谈反馈业务监管-约谈反馈输入日期处理预警信息、单位信息输出支持以每周一次的频率自动推送预警信息至车籍地属地部门，各个分局进行企业约谈并反馈。系统支持按照企业进行预警归类，企业约谈状态分为：未处理、待审核、被驳回、已完成。分局约谈记录上传不合格，支持支队最对进行审核驳回处理。业务监管-事后监管业务监管-事后监管输入日期处理预警信息、单位信息输出1)支持根据时间，筛选及下载抄告。2)支持抄告模板的下载，以及模板自动根据预警情况，生成相应格式的文档，和数据统计表格3）支持处置结果的上传。研判分析风险画像风险画像输入当前日期处理结合车驾管的风险画像、卡口数据、全市路网数据输出1）驾驶员画像支持对接车管所画像数据，进行整体以及单人的画像信息展示。并可进一步查看其分数的详细信息。2）渣土车画像支持对接车管所画像数据，进行整体以及单车的画像信息展示；3）企业画像对接车管所画像数据，进行整体以及单个企业的画像信息展示；4）工地画像根据工地渣土车的画像数据进行所属工地风险画像；5）审批路线画像支持根据预警信息、事故信息、违法信息以及通行频次进行路线画像。同时支持点击某条路线，地图展示该路线及该路线上的风险路段信息。情报研判情报研判输入当前日期处理结合车驾管的风险画像、卡口数据、全市路网数据输出未开GPS分析研判：支持使用卡口过车数据或废片二次识别数据与GPS数据进行碰撞，识别出两者差距较大卡口，进行排序并地图呈现，便于交警缉查布控。高频路段研判：支持通过车辆GPS数据进行数据分析，识别出通行频次高的路段，进行排序并地图呈现。车辆聚集地研判：支持通过车辆GPS数据进行数据分析，识别出疑似车辆聚集地，进行过车排序并地图呈现。车辆点位热力图：支持通过车辆GPS数据进行数据分析，实时统计车辆热力图，地图呈现。GPS异常GPS异常输入日期处理结合GPS数据以及后台GPS异常算法输出GPS以上的车辆数据配置管理电子围栏电子围栏输入地理信息平台接口处理调用接口输出支持通过新增电子围栏功能在地图上标绘新增的电子围栏，并可设置围栏名称、应用时间等信息。报警阈值管理报警阈值管理输入地理信息平台接口处理调用接口输出支持对超速预警进行阈值设置管理，及不同区域区分设置各自的阈值。主要设置速度阈值以及连续点数菜单管理菜单管理输入组织机构信息处理组织机构信息输出支持提供自定义菜单层次结构角色管理菜单管理输入组织机构信息处理组织机构信息输出支持根据用户可查看的页面权限、操作权限不同，为用户创建、分配相应的角色，同时支持角色权限设置、删除角色和角色信息维护操作。组织管理组织管理输入组织机构信息处理组织机构信息输出支撑支队、分局组织信息管理。用户管理用户管理输入组织机构信息、用户信息处理组织机构信息、用户信息相关联输出系统提供用户管理功能，对所有用户进行组织管理，进行如新增/删除/修改/查询用户、配置角色、用户信息维护等操作。支持用户修改自己的密码实施建议对系统测试人员进行必要的培训，提高他们的测试效率。项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。附录一缺陷