适用场景:队伍管理、业务提升
行文逻辑:抓班子建设→抓作风建设→推进信息化建设
一、贯彻抓班子、带队伍、促工作的要求,以党的xx大精神为指针,切实加强公安交警队伍建设
(一)按照“三抓、三提、三增、三树”的队伍建设思路,努力打造政治坚定、业务精通、作风优良、执法公正、服务到位的交警队伍。
抓班子建设。按照建设学习型、创新型、务实型、高效型、团结型、廉洁型领导班子的要求,继续强化大队班子、大队二级班子的建设工作,增强班子的团结与活力,发挥班子的模范带头作用,增强队伍的凝聚力和战斗力;抓作风建设。以和谐警民关系建设为契机,深入开展队伍工作作风、纪律作风、生活作风养成教育和整顿,进一步培养队伍爱岗敬业、严守纪律、善于服务、积极拼搏的团队精神,促进大队各项工作的顺利开展;抓制度建设。巩固队伍正规化建设成果,抓好执法规范化建设,进一步完善健全大队各项规章制度,严格规章制度的贯彻执行、严格绩效考核,做到以制度管人、按制度办事,促进各项公安交通管理业务工作的顺利开展。
通过“三抓”,要达到三提、三增、三树立的效果。一是提高民警的政治水平,增强政治敏锐性,树立服务大局、促进发展的思想;二是提高民警的业务水平,增强规范化执法能力,树立立警为公、执法为民的思想;三是提高民警的服务水平,增强群众工作能力,树立服务群众、便民利民思想。
(二)强化警务保障,加强廉政建设,坚持从优待警。
进一步落实健全从优待警、关爱民警、维护民警合法权益工作制度,完善保障机制,确保基本的警务保障和警务装备,保护民警合法权益,维护民警正常执法权益。围绕中心工作和重要警务部署,切实加强警务督察工作,重点对民警执法过程、执法程序开展督察,努力营造正常的执法环境,维护法律的严肃性。进一步巩固和完善党风廉政建设责任制,层层签订党风廉政责任书,按照廉政建设工作要求,抓好党风廉政建设工作。
(三)加强党的基层组织建设,强化党员队伍教育管理。
进一步深入学习《中国共产党章程》,巩固和发展先进性教育成果,推进“云岭先锋工程”建设,按照“五好五带头”的要求,不断加强党的思想建设、组织建设、作风建设和制度建设,促进大队工作业绩再上一个新的台阶。同时,认真落实“三会一课”制度,不断加强党员队伍教育管理,健全管理制度,拓宽教育渠道,丰富教育形式,提高教育质量,加强对非党业务骨干的培育,发展壮大党员队伍。
二、加强“三项建设,全面提升全县公安交通管理工作水平
(一)推进信息化建设,提升科技应用水平。抓好智能交通控制系统的调研工作和单警科技装备的配备工作,狠抓交通管理信息化建设和应用这个重点。结合我县实际,先期做好交通监控设备的设置调研,从着力解决县城道路通行效率和交通秩序问题,解决云保线事故多发路段交通安全工作计划隐患入手,不断推动交通管理水平的提高。以交警队信息平台的应用为重点,完善机动车登记、驾驶证管理、交通违法、交通事故信息等业务的采集、录入、运用;完成标准化信息采集系统及大、中队的双向视频会议系统的建设,加强对web网站相关管理办法的贯彻落实。
(二)推进执法规范化建设,提升执法效果。开展文明、规范执法学习教育活动,规范执勤执法行为,深化专、兼职法制员和值日警官制度,着力在容易发生执法问题的重点岗位和关键环节完善执法规范化体系,健全交通管理执法责任制体系及执法质量考核评议体系。在执法中做到依法文明、公平正义、及时高效,杜绝执法的随意性,使各项执法活动符合“大限度地激发社会创造活力,大限度地增加和谐因素,大限度地减少不和谐因素”的要求,实现政治效果、法律效果和社会效果的有机统一。进一步完善、规范非现场执法模式,提高执法效率。同时,完善信访工作相关制度,以维护法治、保障权益、疏导化解,实现停访、止争、息诉,促进和谐建设。
(三)推进和谐警民关系建设,着力构建和谐警民关系。按照公安部关于构建和谐警民关系的有关要求,县局、市交警支队的统一部署,加强和谐警民关系建设,不断提升公安交通管理机关和交通民警的执法形象,为公安交管信息化建设、执法规范化建设创建良好的外部环境。进一步树立理性、平和、文明、规范执法的理念,增强做群众工作的能力;进一步改进工作方式,提高改善民生、服务民生的水平;进一步加强能力建设,提高队伍综合素养;进一步创新执法环境,不断解决影响公正、文明执法的突出问题;进一步强化警民互动,共谱警民和谐的新局面,提高公安交通管理部门满足人民群众新期待、回应人民群众新要求的能力,为维护社会稳定创建更加良好的警民关系。
适用场景:软件测试方案制定、系统性能评估实施
行文逻辑:介绍背景→制定计划→准备环境→执行测试→分析结果
利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误,但是错误总是存在的,如果开发者找不到错误,那么,客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一,很多软件开发组织将30%—40%甚至更多的项目资源用在测试上,软件测试技术和软件测试策略受到了高度的重视和广泛的应用。
本文不想就软件测试技术和软件测试策略作深入的理论分析,而是列举一个在软件系统测试阶段进行的压力测试实例,希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
首先介绍一下实例中软件的项目背景,该软件是一个典型的三层c/s架构的mis系统(客户端/应用服务器/数据库管),中间层是业务逻辑层,应用服务器处理所有的业务逻辑,但应用服务器本身不提供负载均衡的能力,而是利用开发工具提供的orb(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是:进行单个应用服务器的压力测试,找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是:假定在实际环中,用户只启用一个应用服务器进行所有的业务处理。方法是:按照正常业务压力估算值的1~10倍进行测试,考察应用服务器的运行情况。
压力测试的详细计划如下:
压力
1、名称
河北省公安交通管理信息系统压力。
2、测试内容
2.1背景
本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷,长时间运行测试软件来测试被测系统的可靠性,同时还要测试被测系统的响应时间。用户的实际使用环境:
◇由两台 xseries250 pc server组成的microsoft cluster;
◇数据库管理系统采用oracle8.1.6;
◇应用服务器程序和数据库管理系统同时运行在microsoft cluster上。
◇有200个用户使用客户端软件进行业务处理,每年通过软件进行处理的总业务量为:150万笔业务/年。
2.2测试项
应用服务器的压力测试;
2.3不被测试的特性
◇系统的客户端应用程序的内部功能;
◇数据库中的数据量对程序性能的影响。
3、
3.1测试强度估算
测试压力估算时采用如下原则:
◇全年的业务量集中在8个月完成,每个月20个工作日,每个工作日8个小时;
◇采用80—20原理,每个工作日中80%的业务在20%的时间内完成,即每天80%的业务在1.6小时内完成;
测试压力的估算结果:
去年全年处理业务约100万笔,其中15%的业务处理每笔业务需对应用服务器提交7次请求;70%的业务处理每笔业务需对应用服务器提交5次请求;其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果,每年的业务增量为15%,考虑到今后三年业务发展的需
要,测试需按现有业务量的2倍进行。
每年总的请求数量为:(100*15%*7+100*70%*5+100*15%*3)*2=300万次/年。
每天的请求数量为:300/160=1.875万次/天。
每秒的请求数量为:(18750*80%)/(8*20%*3600)=2.60次/秒。
正常情况下,应用服务器处理请求的能力应达到:3次/秒。
3.2测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境:公司内部的以太网,与服务器的连接速率为100m,与客户端的连接速率为10/100m自适应。
2)使用两台ibm xseries250(1g内存)pc server作microsoft cluster,安装系统软件
20xx advance server及microsoft cluster server(mscs)。
3)数据库管理系统的安装及配置:在测试用的ibm xseries服务器上安装oracle8.1.6,数据 库采用
fail safe(ofs)的active/passive配置。 安装数据库管理系统及支撑软件(包括visibroker和bdeadministrator)。
4)安装被测的应用服务器程序。
5)客户端的pc机:10台(pⅲ600/128m ram)。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用delphi编写,要求测试程序实现如下功能:
1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况:第一种,发送的请求至少包括10个参数,参数类型涵盖字符、日期、数字种类型;接收的
响应信息不少于1个参数;第二种,发送的请求不少于1个参数;接收的响应信息至少包括10个参数,参数类型涵盖字符、日期、数字种类型。
2)必须能够通过参数设定在每台pc机上运行的客户端测试程序个数、请求的时间间隔(单位:毫秒)、运行时间(单位:小时)。
3)在数据库中建立测试记录表,生成测试记录,向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括:发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名:test_log,字段名:machine、id、start_time、end_time、flag。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能,参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求,数据有效性的具体要求参见数据库设计及系统设计文档。
3.3破坏性测试
按照设计连接的客户端连接数量进行测试,把应用服务器处理请求的"设计频度增加1-10倍,分别测试出现错误的状态和和出现错误的比率,考察是否出现不可恢复错误,系统设计要考
虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间:2天;这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次ibm xseries pc
server的内存及cpu使用情况,包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4强度稳定性测试
选择一种负荷比设计负荷重的情况(应用服务器处理请求的频度为应用服务器处理请求的 设计频度的
1.5倍),进行24小时稳定性测试。
3.5测试方法和工具
黑盒测试
测试工具:无外购的测试工具,自己编制的测试工具。
3.6测试时间计划
3.6.1环境准备:2天。
其中:基本硬件、软件环境及系统本底数据的准备:1天,
系统客户端测试程序的编写及测试:1天。
3.6.2破环性测试:2天。
3.6.3强度稳定性测试:1天。
3.7测试中的问题及处理
3.7.1暂停标准和再启动要求
暂停标准:被测试软件在强度稳定性测试中频繁出现异常(每小时出现1次以上)时。用户或公司要求暂停测试时。
再启动要求:通过调试后,预计被测试软件的可靠性有所提高时,可再次启动测试。
3.7.2不可预见问题
不可预见问题包括:
◇测试环境被破坏而导致测试无法进行;
◇当出现上述不可预见问题时,测试终止,就已完成的测试内容编制测试总结报告,并在报告中说明测试终止的原因。
3.8测试报告 20xx.06.21
测试总结报告提交日期:20xx.06.21。
3.8.1应生成的测试文件
测试记录(测试负责人和参与测试的人员签字);
测试总结报告。
3.8.2测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境;
被测试软件的压力测试结论:响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间,并发数与失败的关系。
4、人员和职责
4.1职责
测试工程师:负责编写,组织测试,对测试过程进行记录,收集、整理测试记录数据,对测试结果进行分析,编写测试总结报告。
软件工程师:负责编写、调试客户端测试软件;数据库管理系统的安装、ofs配置及系统的本底数据准备。系统工程师:负责测试用的硬件维护及操作系统安装、mscs配置。
总工程师:负责对及测试总结报告进行批准。
用户:必要时可参加测试,并提出具体的测试要求;可要求暂停测试。
4.2人员和训练要求
本次测试无特别的人员及培训要求。
5、批准
本必须经过总工程师批准后才能开始实施。