企业网站建设的类型主要有node做网站

企业网站建设的类型主要有,node做网站,软件技术有学做网站吗,网站建设基础1.接口测试简介 接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换#xff0c;传递和控制管理过程#xff0c;以及系统间的相互逻辑依赖关系等。 2.接口测试流程 接口测试的…1.接口测试简介接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换传递和控制管理过程以及系统间的相互逻辑依赖关系等。2.接口测试流程接口测试的流程和功能测试流程类似依据的对象是需求说明书和接口需求接口测试流程如下3.接口测试范围业务功能包括正常、异常场景是否实现业务规则覆盖度是否全面参数验证边界、业务规则是否达到要求异常场景重复提交、并发提交、事务中断、多机环境、大数据量测试性能测试响应时间、吞吐量、并发数、资源要求安全测试权限验证、SQL注入等4.接口测试重点● 检查接口的功能检查接口的功能有没有实现也就是请求会不会成功如果不成功会不会返回错误代号或错误信息● 检查接口返回的数据检查接口返回的数据、数据格式、数据类型是否与预期一致正向且传递的参数正常● 检查接口的容错性接口是否可以正常处理假如传递的参数足够大或者为负、空值时● 检查接口的性能http请求接口大多与后端执行的SQL语句性能、算法等比较相关● 检查接口的安全性外部调用的接口尤为重要。5.接口测试需求分析● 首先根据接口设计的技术架构方案了解清楚被测接口对应的公共入参、入参、出参及返回数据的Json结构规范根据测试场景进行测试。● 理解接口参数熟悉接口参数的输入要求、输入值范围、必填项等。● 理解接口输出熟悉返回json的结构构成、返回值类别、返回值范围、返回data的不同类型等。● 理解接口的逻辑、接口的业务关联熟悉技术方案中的接口相互关联、依赖的关系接口与接口之间的数据传递等。● 寻找测试点根据输入 (参数名、取值范围)、输出 (参数名、返回值范围)、关联关系进行测试点分析。6.接口测试用例设计接口测试的主要测试对象是接口但是随着系统复杂度越来越高接口越来越多完全覆盖所有接口是很难的一件事情并且实际过程中任意内部接口的变动都可能导致我们的测试用例的不可用。接口用例设计优先级优先级–针对所有接口暴露在外面的接口因为通常该接口会给第三方调用供系统内部调用的核心功能接口供系统内部调用非核心功能接口。优先级–针对单个接口正向用例优先测试逆向异常用例次之 (通常情况非绝对)是否满足前提条件 是否携带默认参值参数 参数是否必填 参数之间是否存在关联 参数数据类型限制 参数数据类型自身的数据范围值限制。接口用例设计方法测试用例编写注意事项进行测试执行编写时有如下的原则1.不同的接口参数覆盖不同的业务场景2.在后台构造合适的数据来满足接口的测试用例3.根据接口的返回值断言其是否返回期望结果并查看数据库验证4.测试用例涉及多个步骤的应对涉及的步骤都验证5.删除测试过程中产生的结果确保每个用例执行前都是一个清洁的环境。7.接口测试用例模板8.接口数据准备9.接口测试工具接口测试工具选择接口工具Postman/Jmeter/SouapUI/python单个接口测试时使用 Postman多个接口测试时可以使用Jmeter或者使用python脚本Jmeter可以测试各种类型的接口不支持的也可以通过网上或自己编写的插件进行扩展。postman功能上更简单组织方式也更轻量级它主要针对的就是单个的 HTTP 请求。接口测试工具根据对比抓包工具个人比较喜欢Charles嘛但是也可以使用fiddler或者其他的抓包工具。jmeter使用dome10.接口测试原则基础配置如域名、环境配置等单出文件配置方便不同环境测试、脚本维护明确接口实现什么样的功能实际需要什么样的功能是否一致接口测试数据太多用该数据驱动模式更有层次且易于维护要在众多测试用例中选出冒烟测试用例及可用于性能测试的用例先单接口测试再多接口业务测试测试完成以后需要清洗脏数据。11.接口测试执行实例11.1 使用Jmeter测试接口实例接口测试环境准备Jdk1.8 或以上http://www.oracle.com/technetwork/java/javase/downloads/index.htmlJmeter 下载址址http://jmeter.apache.org/download_jmeter.cgi插件的下载安装地址http://www.jmeter-plugins.org/12. 如何快速生产脚本生成既然使用到了jmeter团队又是多人的情况下那么 jmeter 脚本的生产力是一个很大的问题再加上团队不是每个人对 jmeter 的熟悉程度都是不一样的所以脚本的编写和快速生产就是个问题针对这个个人建议脚本的生产建议从以下几个方面考虑使用jemter原生的录制器手写jmeter脚本但是需要对jmeter相对熟悉使用fiddles抓包工具导出生产针对web页面个人推荐BlazeMeter的谷歌插件。针对以上五种生产jmeter脚本快速生产的方案都可以很好的辅助编写jmeter 的脚本在这里很多同学肯定会问为什么不使用metersphere这个项目本身很优秀了但是由于公司的原因所以最后放弃很多同学肯定想录制生成直接回访就完事我只能说太简单这样你的脚本使用一次基本就报废 会造成脚本的重复编写费时费力这个时候需要测试强硬一点了大家采用统一的录制控制方式去录制同意脚本编写的方案毕竟在怎么录制都是不行的所以最好的实践方式就是采用录制为主修改为辅的解决方式去编写复用率高的脚本。13.团队协作落地相信jmeter很多测试小伙伴都很熟悉肯定也都熟悉他有一个最大通病就是case太多的时候一点都不方便管理。其实这个问题我也遇见了因为现在的团队不只是我一个人单打独斗我还有队友所以对jmx脚本的管理我在团队里面采用的是git管理我们的脚本我们在团队内部和开发约束测试环境的时候所有的部署都走test的一个代码分支这样做的好处就是为了减轻jmx脚本的复杂性同时也避免了在发布生产环境的时候将脚本发布到生产环境因为最初的初衷使用jmeter做接口测试的情况下就是因为团队开发的同学不写单元测试测试同学会Java的只有一两个服务又多公司的迭代速度又快开发提测的功能一直没有很好的健壮性所以我在想能不能在开发部署成功的时候或者定时轮询执行一下每个服务的接口以达到提测的质量。在团队实践中也遇到了一些问题如下token的时效性原因导致脚本老是执行失败数据的唯一性例如我每次请求的时间都是不一样的等数据库的连接数老是超标因为团队存在多个项目组他们之间又是使用相同的数据库只是不同表Jenkins的并发限制因为大家都是使用同一个Jenkins不可能你一个老是占用Jenkins的执行。针对以上的问题我个人是如下解决的首先token校验的问题存在这个问题的根本原因是因为我们每次登录都是图片验证码的登录但是我又不能识别只能求助开发经理让他在测试环境给我们测试写了一个万能验证码再拿这个这个验证码去刷新token和或获取对应的opop参数是内部特有的验证数据的唯一性这个当时头疼了好久最后只能去百度最后发现jmeter还有很强大的功能就是函数助手里面有各种函数例如获取时间戳随机数生成uuid等直接开箱即用。熟悉mysql的小伙伴都知道MySQL的默认最大连接数是200数据库连接池老是超标最后查看了mysql日志发现连接数占用最大的是开发的代码里面写了很多多表联查的大SQL尤其是公司大数据那帮人的sql一个SQL语句执行半个小时…因为去年(2020年)MTSC深圳站的时候听了唯品会的同学分享接触到了sql扫描检查当时在sonar扫描代码的时候加入了sql的扫描和开发老大商量去除了项目中大部分的长sql语句最后去请教了运维的同学和公司dba的大佬当时运维同学有点不配合的最后买了一包好烟在加各种舔最终终于同意扩大数据库的连接数最终勉强解决了这个问题。jenkins并发机制的问题这个是jenkisn本身就存在的瓶颈当时给公司运维提了个需求让他多起几个jenlkins的的节点测试专门使用一个节点。14.接口测试结果报告由于使用了jmeter为了测试的时候可以实时查看个人建议使用 influxdbcadvisorgrafana 搭建一套配合 jmeter 的报告可视化的监控系统。搭建步骤如下创建容器挂载目录mkdir -p /dockerdata/influxdb mkdir -p /dockerdata/grafana安装 influxdb 数据库docker run -d \ -p 8083:8083 \ -p 8086:8086 \ --expose 8090 \ --expose 8099 \ --name influxsrv \ -v $PWD:/var/lib/influxdb \ influxdb;安装 cadvisor 容器监控docker run \ --volume/:/rootfs:ro \ --volume/var/run:/var/run:rw \ --volume/sys:/sys:ro \ --volume/var/lib/docker/:/var/lib/docker:ro \ -p 8081:8080 \ --detachtrue --link influxsrv:influxsrv \ --namecadvisor \ google/cadvisor:latest \ -storage_driverinfluxdb \ -storage_driver_dbcadvisor \ -storage_driver_hostinfluxsrv:8086;安装 grafanadocker run \ -d \ -p 3000:3000 \ -e INFLUXDB_HOSTlocalhost \ -e INFLUXDB_PORT8086 \ -e INFLUXDB_NAMEcadvisor \ -e INFLUXDB_USERroot \ -e INFLUXDB_PASSroot \ --link influxsrv:influxsrv \ -v $PWD:/var/lib/grafana \ --name grafana \ grafana/grafana;最终结果如下需要注意的点既然使用influxdb存储jmeter的数据那么就不得不提jmeter的Backend Listener后端控制器的配置这个超简单但是我没有使用默认的因为默认的只能查看 压测的tps这些再加上脚本的每个场景接口我加入事务控制器所以我采集的是事务控制器一个事务代表一个接口或者代表多个接口启动了influxdb之后需要进入容器创建对应的数据库要不数据没办法存储为了方便在grafana上面看到了每个接口的请求参数和返回值这个是因为之前公司每个项目已经接入普罗米修斯的监控在配置普罗米修斯监控的时候我们加入了自定义监控所以这款我直接使用普罗米修斯原有的配置的面板还有因为插件的原因当时遇见了influxdb里面没办法失败 “/” 所以控制器的命令 “/” 可以使用下划线代替。13.接口测试中常见问题接口测试经常遇到如下的bug和问题传入参数处理不当导致程序 crash;类型溢出导致数据读出和写入不一致因对象权限为进行校验可以访问其他用户敏感信息状态处理不当导致逻辑出现错乱逻辑校验不完善可利用漏洞获取非正当利益等。15.接口自动化适用场景及持续集成接口自动化框架JmetermavenJenkinsgitJmeter作为执行者的角色每次负责执行具体的接口/性能测试脚本并得到结果生成报表。Maven和Git是作为管理者角色前者主要负责项目的依赖管理而后者主要负责项目的代码管理。Jenkins作为调度者主要根据我们设置的build触发条件和事件调用jmeter进行测试 ## maven集成jmeter插件。dependency groupIdorg.apache.jmeter/groupId artifactIdApacheJMeter_components/artifactId version5.4.1/version /dependencyjmeter 镜像的制作因为在上面我们说了我们使用了自己的Backend Listener插件由于网络原因所以在运行docker容器的时候我们需要将jmeter容器使用-v参数挂在到本地。再加上网络的原因我们只能自己制作镜像了制作镜像的dockerfile如下FROM java:8 ENV http_proxy ENV https_proxy RUN mkdir /jmeterdocker RUN mkdir -p /jmeterdocker/test RUN mkdir -p /jmeterdocker/test/input/jmx RUN mkdir -p /jmeterdocker/test/input/testdata RUN mkdir -p /jmeterdocker/test/report/html RUN mkdir -p /jmeterdocker/test/report/jtl RUN mkdir -p /jmeterdocker/test/report/outputdata RUN chmod -R 777 /jmeterdocker RUN cd /jmeterdocker ENV JMETER_VERSION5.4.1 ENV JMETER_HOME/jmeterdocker/apache-jmeter-${JMETER_VERSION} ENV JMETER_PATH${JMETER_HOME}/bin:${PATH} RUN wget https://archive.apache.org/dist/jmeter/binaries/apache-jmeter-${JMETER_VERSION}.tgz RUN tar -zxvf apache-jmeter-${JMETER_VERSION}.tgz RUN rm apache-jmeter-${JMETER_VERSION}.tgz需要注意的点因为使用了docker启动运行容器那么在运行完成之后需要在对应的shell脚本中接入如下命令在每次运行构建之前删除对应的容器。docker rm - f [容器name]16.目前设计的自动化接口测试案例有两个运行场景测试前置、开发自测一个新的自动化接口测试案例开发完成后直接发给接口对应的开发安排在开发本地环境执行一旦开发确认完成接口开发就开始执行接口测试案例基本上可以实时拿到测试结果方便开发快速做出判断。【开发本地运行的方式就是打开JMeter工具导入JMX文件开始执行可。回归测试开发本地测试通过后或整个需求手工测试通过后把自动化的接口测试案例做分类整理挑选出需要纳入到回归测试中的案例在持续集成环境重新准备测试数据并把案例纳入到持续集成的job中来这些用于回归的接口测试案例需要配置到持续集成平台自动运行。对接口测试而言持续集成自动化是核心内容通过自动化的手段才能有效降低成本提高接口测试的价值。如果使用LR、JMeter、SoapUI工具做自动化测试工具本身支持命令行模式运行可以结合Jenkins等自动化平台实现项目版本更新后的自动化回归测试。关于持续自动化回归测试的建议接口脚本开发时要注意参数的取值的可用性不因为时间或数据状态的变化引起脚本不能正常运行降低脚本维护成本。接口回归功能的覆盖度控制需要根据脚本的实际功能和重要性判断自动化回归覆盖度回归内容越多脚本维护成本越高一般应用接口不建议全功能覆盖毕竟接口有变化会做详细测试如果没修改其它变更可能对其产生的影响一般不会影响其逻辑判断。接口脚本需要一定的自动化校验能力除请求http状态的判断外还需要对核心内容的正常性做判断判断内容可与数据库内容匹配等方式不建议用写死的内容。持续性能测试还需要做好相关的监控、性能指标的分析自动化减少人工操作。总结感谢每一个认真阅读我文章的人作为一位过来人也是希望大家少走一些弯路如果你不想再体验一次学习时找不到资料没人解答问题坚持几天便放弃的感受的话在这里我给大家分享一些自动化测试的学习资源希望能给你前进的路上带来帮助。软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。视频文档获取方式这份文档和视频资料对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你以上均可以分享点下方小卡片即可自行领取。