精华内容
下载资源
问答
  • 经常会有小伙伴来问我,他们的区别到底是什么,还有的没做过这方面的测试想去尝试一下,会来问我需要注意什么,写出来给需要的小伙伴参考一下,个人经验分享,欢迎大家来留言区讨论交流。 1、系统架构 WEB端:B/S...

    写在前面:本人具有测试行业9年软件测试经验,其中对于Web端和移动端都有过丰富的项目经验。经常会有小伙伴来问我,他们的区别到底是什么,还有的没做过这方面的测试想去尝试一下,会来问我需要注意什么,写出来给需要的小伙伴参考一下,个人经验分享,欢迎大家来留言区讨论交流。

     

    1、系统架构

    WEB端:B/S结构,WEB端的前端一般不做端的区分。WEB端的上线不管是预发布还是N环上线,server上线后,前端同步更新,一般是不存在多个版本的问题;

    移动端:C/S结构,移动端的前端分为安卓端&iOS端。移动端的server上线后,客户端还是存在多个版本,需要考虑旧版本兼容&回测问题

    2、抓包工具

    WEB端:WEB端有个比较方便的方法可以查看前端请求的接口:Chrome浏览器里打开检查,可以从network里直接查看前端请求的接口。当然也可使用抓包工具抓取请求。

    移动端:移动端常用的的抓包工具有Charles、fiddler等,可以通过连接代理等方式抓取请求

    3、UI自动化

    WEB端:WEB端常见的就是 unnitest + selenium 了,需要安装所需要浏览器的driver

    移动端:移动端常见 appium,是在selenium的基础上发展而来,当然还有一些封装的很不错的工具,例如网易出品的基于图像识别和 poco 控件识别的 Airtest

    4、接口自动化

    WEB端:WEB端的接口相对简单

    移动端:需要带上version/productid等参数信息,因为可能会有新旧版本兼容等问题,不同版本可能会出现返回不一样的情况。需要有 client 信息,Android/iPhone/iPad,一般可以提取成环境变量单独存放

    5、性能

    WEB端:WEB端的性能更注重页面响应速度,一般会用JMeter

    移动端:更注重并发、qps、耗电量等指标,同样也会用JMeter,另外也有集成好的PerfDog等工具可应用

    6、兼容

    WEB端:更侧重于电脑系统、浏览器类别/版本的兼容

    移动端:更侧重手机系统版本、品牌、屏幕尺寸、分辨率等的兼容

    7、安全

    WEB端:常用工具:BurpSuite、appcheck、appscan等(目前我就接触过这几个哈哈)

    移动端:有一些第三方的加固可以接入例如:360加固,爱加密等;可根据项目的需求调研选择,有一点副作用就是可能会带来crash率的一点点上升,接入后需要比较全面的回归测试

    8、app测试更注重的一些方面

      安装、卸载、覆盖安装(关注缓存)、冷启动/热启动等

      中断事件(返回,画面、音频的打断,电话、锁屏、切后台等操作)

      操作类型:手势(左滑右滑上滑下滑,拖动,长按,多点触控)

      网络状况:4G/Wi-Fi,网络切换,弱网,断网

      权限:拍照、录音等需要权限

      安装包的大小

      横竖屏翻转

      app大多是直接面向用户的,所以交互体验比web端的要求要高许多,同时一些网络情况、内存等影响因素比较多且复杂,所以一些容错的处理也非常重要。

    展开全文
  • 接下来我将主要介绍一下Web端性能测试各阶段需要注意和考虑的问题。希望对新手朋友有一些帮助。1、对测试系统进行分析,明确需要对什么进行压力测试(接口?web页面?)接口:接口中有哪些参数,各含义,是可选项还是...
    • 作为QA,你了解性能测试么?做过性能测试么?如果都没有,那你是否觉得性能测试很神秘呢?再细分到web性能测试我们又该如何测试呢?接下来我将主要介绍一下Web端性能测试各阶段需要注意和考虑的问题。希望对新手朋友有一些帮助。

    1、对测试系统进行分析,明确需要对什么进行压力测试(接口?web页面?)

    接口:接口中有哪些参数,各含义,是可选项还是必选项,取值范围,是计算密集型,还是IO密集型,期望性能等;

    Web页面:包含哪些接口,涉及哪些服务,期望性能等;

    2、明确被测对象后,考虑测试环境

    a)   被测服务环境是否独立【一般情况下,被测服务的环境尽量与其他服务分开】

    b)   被测对象是否有缓存【要根据实际情况,确定压测过程中是否开启缓存】

    详细说明:首先要了解缓存的有效期,真实的环境中命中缓存的比例大概是多少;不带缓存压测,可知晓系统的最差性能。带缓存压测,数据集的选取非常重要。

    c)   发压机与被测环境要在同机房【简单的ping命令,查看大概的访问延时】

    d)   服务是否有些安全机制【例如:同一ip的访问次数限定,同一用户的操作频率限定】,影响性能测试的因素,在测试前需要关闭。

    e)   host检查(避免压到线上)

    3、详细分析被测对象,编写压测脚本

    a)   请求是http还是https  (ssl, https压不去 | 走http请求  例如:大搜,走IE6 User-Agent)   (https   可以压页面)      

    b)   服务是否与登录有关【登录用户的操作,需要在请求的header中增加cookie字段,标识用户的状态等信息】

    详细说明:

      很多页面在登录与不登录的情况下处理方式是不同的;有些页面也只有登录用户才可以访问;页面的逻辑与用户的等级等状态有关。

      如何获取cookie,fiddler抓包,拷贝整个消息头部的cookie字段。

      涉及cookie字段的,要注意相关参数的有效期,压测前检查是否失效。

    (jmeter设置cookie及相关cookie文件,如下图)

    (Fiddler抓包,获取cookie信息,如下图)

    ed174bead4551e7d6f4687a014586450.png

    c)   有些服务,会检查refer,hostname等参数,压测脚本中需要在header中增加这些字段

    d)   前端页面,有时不同的User-Agent也会影响实际的业务。此时也需要固定请求header中的UA字段

    e)   增加断言【检查业务错误率】

    详细说明:

      jmeter错误率统计的是请求返回非200的情况,但是对于web端而言,在有异常情况的时候,都会有相关的处理方式(例如:302重定向到其他页面),最终不会返回非200。需要设置断言,判断返回页面是否符合预期。

      设置断言,检测返回结果中,是否包含某些参数或值

    (jmeter设置断言举例,如下图)

    f0e5b59e89ec13566339f402a42f9a44.png

    f)   设置日志【设置相关内容的记录与否】

    g)   利用jmeter常用函数,提高效率

    常用函数介绍:

    时间:

    ${__time(,)} 1450056496991   //无格式化参数,返回当前毫秒时间为整数 

    ${__time(yyyyMMdd,)} 20151214 //返回年月日 

    ${__time(HHmmss,)}  092816 //返回时分秒 

    ${__time(yyyyMMdd-HHmmss,)} 20151214-092816 //全 

    random_tt=${__time(,)}_${__threadNum}

    进程:

    ${__threadNum}

    随机数:

    ${__Random(1,100,fun1)}

    编码:

    ${__urlencode(${q})}

    可变参数如进程数等,NUM_THREADS为自己起的名字

    ${__P(NUM_THREADS)}

    对于此种参数传参时为:

    /da1/dongshiyue/jmeter3.0/bin/jmeter.sh -JNUM_THREADS=$1 -JDURATION=$2 -JFILE=$3 -JDOMAIN=$4 -JPORT=$5 -JPATH=$6  -n -t ../tusoujmx/tusou_stable_search.jmx

    实际应用场景:有时为了方便定位问题,会在请求的url中,增加一个唯一的随机参数,格式:randomtt=${__time(,)}_${__threadNum},参数是由时间戳和进程号组合(如下图)。

    a8876f10c61da48fe513746b4a20e34f.png

     4 、准备测试数据集

    a)   压测数据集是性能测试的重中之重,压测数据直接影响测试的价值与可行度

    b)   多个参数的各种组合情况是否覆盖【tips:多个参数多个文件引入时,如果是倍数关系,很多组合情况覆盖不到,需要将各种组合情况列在一个文件中,以参数个数的形式引入】

    c)   Query类的压测,测试数据集的选用,需要考虑的问题

    query 是否需要去重【去重后的query,在一轮测试中,不会命中缓存】

    query 使用线上真实的流量,即从线上日志中获取,不进行去重,能够完整的模拟线上流量

    特殊字符集【特殊字符可能会导致服务挂掉,影响稳定性,常见的一些特殊字符:空格,特殊字符,半角全角符号,其他语言文字等】

    网络攻击字符集【主要是一些js注入,SQL注入,XSS攻击的语句】

    d) 涉及用户状态或等级等功能,准备的cookie数据要涉及不同情况,用户等级的比例也要通过cookie数据的个数进行控制。

    5、进行尝试,确定压测脚本和数据集

    a)   1-4步完成后,开启日志设置中的responseData等参数,压测一轮。检查返回的数据是否符合预期。【可以检查参数是否正确,cookie是否生效等】

    b)   通过尝试,确定并发数

    c)   修改日志设置,关闭responseData,开始压力测试。

    其他注意点:

    (keep-alive  默认是长链接) 跟开发沟通 是否是长链接

    a)   涉及到特殊字符等压测数据,最好将测试数据urlencode之后使用。Jmeter本身的编码功能,对一些特殊字符的支持不是很好,测试会中断。

    b)   压测web页面,页面较大时,为了避免,打满带宽,导致压力上不去的情况,要设置header中的Accept-Encode字段,用压缩形式。

    c)   Jmeter设置的path中,如果包含一些特殊字符例如:&、>、< 等一定要用html实体字符的形式,例如:& --> & > --> >  < --> <

    d)   不熟悉jmx文件的情况下,可以通过windows图形化jmeter界面配置,生成的jmx可直接使用,只需修改路径即可(注意jmeter版本保持一致)。

    5302ff17b89679fe96919bbe31b17979.png

    展开全文
  • web端性能测试之发压篇

    千次阅读 2017-01-16 11:02:07
    接下来主要介绍一下Web端性能测试各阶段需要注意和考虑的问题: 1. 对测试系统进行分析,明确需要对什么进行压力测试(接口?web页面?) 详细说明:  接口:接口中有哪些参数,各含义,是可选项还是必选项,...

    性能测试重要的是如何发压,在什么样的环境下进行,用什么样的流量进行压力测试。接下来主要介绍一下Web端性能测试各阶段需要注意和考虑的问题:

    1.  对测试系统进行分析,明确需要对什么进行压力测试(接口?web页面?)

    详细说明:

    Ÿ  接口:接口中有哪些参数,各含义,是可选项还是必选项,取值范围,是计算密集型,还是IO密集型,期望性能

    Ÿ  Web页面,包含哪些接口,涉及哪些服务,期望性能

    2.  明确被测对象后,考虑测试环境

    a)   被测服务环境是否独立【一般情况下,被测服务的环境尽量与其他服务分开】

    b)   被测对象是否有缓存【要根据实际情况,确定压测过程中是否开启缓存】

    详细说明:首先要了解缓存的有效期,真实的环境中命中缓存的比例大概是多少;不带缓存压测,可知晓系统的最差性能。带缓存压测,数据集的选取非常重要。

    c)   发压机与被测环境要在同机房【简单的ping命令,查看大概的访问延时】

    d)   服务是否有些安全机制【例如:同一ip的访问次数限定,同一用户的操作频率限定】,影响性能测试的因数,在测试前需要关闭。

    3.  详细分析被测对象,编写压测脚本

    a)   请求是http还是https

    b)   服务是否与登录有关【登录用户的操作,需要在请求的header中增加cookie字段,标识用户的状态等信息】

    详细说明:

    Ÿ  很多页面在登录与不登录的情况下处理方式是不同的;有些页面也只有登录用户才可以访问;页面的逻辑与用户的等级等状态有关。

    Ÿ  如何获取cookie,fiddler抓包,拷贝整个消息头部的cookie字段。

    Ÿ  涉及cookie字段的,要注意相关参数的有效期,压测前检查是否失效。

    (jmeter设置cookie及相关cookie文件,如下图)

    (Fiddler抓包,获取cookie信息,如下图)

    c)   有些服务,会检查refer,hostname等参数,压测脚本中需要在header中增加这些字段

    d)   前端页面,有时不同的User-Agent也会影响实际的业务。此时也需要固定请求header中的UA字段

    e)   增加断言【检查业务错误率】

    详细说明:

    Ÿ  jmeter错误率统计的是请求返回非200的情况,但是对于web端而言,在有异常情况的时候,都会有相关的处理方式(例如:302重定向到其他页面),最终不会返回非200。需要设置断言,判断返回页面是否符合预期。

    Ÿ  设置断言,检测返回结果中,是否包含某些参数或值

    (jmeter设置断言举例,如下图)

    f)   设置日志【设置相关内容的记录与否】

    g)   利用jmeter常用函数,提高效率

    常用函数介绍

    时间:

    ${__time(,)}         1450056496991 //无格式化参数,返回当前毫秒时间 

    ${__time(yyyyMMdd,)} 20151214      //返回年月日 

    ${__time(HHmmss,)}   092816        //返回时分秒 

    ${__time(yyyyMMdd-HHmmss,)} 20151214-092816 //全 

    进程:

    ${__threadNum}

    随机数:

    ${__Random(1,100,fun1)}

    编码:

    ${__urlencode(${q})}

            实际应用场景:有时为了方便定位问题,会在请求的url中,增加一个唯一的随机参数,格式:randomtt=${__time(,)}_${__threadNum},参数是由时间戳和进程号组合(如下图)。


     4.  准备测试数据集

    a)   压测数据集是性能测试的重中之重,压测数据直接影响测试的价值与可行度

    b)   多个参数的各种组合情况是否覆盖【tips:多个参数多个文件引入时,如果是倍数关系,很多组合情况覆盖不到,需要将各种组合情况列在一个文件中,以参数个数的形式引入】

    c)   Query类的压测,测试数据集的选用,需要考虑的问题

    Ÿ  query 是否需要去重【去重后的query,在一轮测试中,不会命中缓存】

    Ÿ  query 使用线上真实的流量,即从线上日志中获取,不进行去重,能够完整的模拟线上流量

    Ÿ  特殊字符集【特殊字符可能会导致服务挂掉,影响稳定性,常见的一些特殊字符:空格,特殊字符,半角全角符号,其他语言文字等】

    Ÿ  网络攻击字符集【主要是一些js注入,SQL注入,XSS攻击的语句】

    d) 涉及用户状态或等级等功能,准备的cookie数据要涉及不同情况,用户等级的比例也要通过cookie数据的个数进行控制。

    5.  进行尝试,确定压测脚本和数据集

    a)   1-4步完成后,开启日志设置中的responseData等参数,压测一轮。检查返回的数据是否符合预期。【可以检查参数是否正确,cookie是否生效等】

    b)   通过尝试,确定并发数

    c)   修改日志设置,关闭responseData,开始压力测试。

    其他注意点:

    a)   涉及到特殊字符等压测数据,最好将测试数据urlencode之后使用。Jmeter本身的编码功能,对一些特殊字符的支持不是很好,测试会中断。

    b)   压测web页面,页面较大时,为了避免,打满带宽,导致压力上不去的情况,要设置header中的Accept-Encode字段,用压缩形式。

    c)   Jmeter设置的path中,如果包含一些特殊字符例如:&、>、< 等一定要用html实体字符的形式,例如:'&'--> &amp; '>' --> &gt;  '<' --> &lt;

    d)   不熟悉jmx文件的情况下,可以通过windows图形化jmeter界面配置,生成的jmx可直接使用,只需修改路径即可(注意jmeter版本保持一致)。



    e)   其他资料:http://ferriswheelgyh.blogspot.com/2016/12/jmeter-rcnon-http-response-code.html

           函数:http://jmeter.apache.org/usermanual/functions.html#__P

           教程:http://www.hissummer.com/loadtesting-jmeter.html

    jmeter使用技巧:

    1)限定数据跑1遍就停止
    2)限定请求个数
    3)Post 请求  (传json 数据)
    4)固定QPS不生效










    展开全文
  • web端的性能测试应该注意的指标有:用户操作的响应时间、系统的吞吐量(TPS)、系统的硬件资源情况(CPU、硬盘、磁盘)、网络资源占用情况等。 web性能测试之HTTP请求 关于性能测试中,HTTP请求类的性能指标都...

    什么是性能测试?web性能应该注意些什么?

    性能测试,简而言之就是模仿用户对一个系统进行大批量的操作,得出系统各项性能指标和性能瓶颈,并从中发现存在的问题,通过多方协助调优的过程。而web端的性能测试应该注意的指标有:用户操作的响应时间、系统的吞吐量(TPS)、系统的硬件资源情况(CPU、硬盘、磁盘)、网络资源占用情况等。

    web性能测试之HTTP请求

    关于性能测试中,HTTP请求类的性能指标都需要我们去关注些什么?

    响应时间,这里的响应时间一定得是前端+后端的响应时间,我们惯性的思维都是只关注后端服务的响应时间,其实前端的响应时间也是须考虑在内的。
    并发测试的相应数据,这部分也得考虑前端数据,这只是一个大概的补充,因为具体的系统需要的数据不一样,其中也不乏包括响应时间。
    其中,前端的响应时间都涉及到哪些环节呢?

    DNS解析
    各种请求的连接
    TLS的建立
    字节流的发送
    

    另外,后端响应时间涉及的环节:

    等待(前端请求)
    接收信息流
    返回响应数据
    这其实就是一个比较完整的web端请求所需要的环节,而响应时间就是指的这个请求的过程所花费的时间。这部分时间就是一个用户在操作的时候所等待的时间,所以用户所能接受的时间范围恰好是性能测试所关注的时间范围。通常用户所能接受的系统响应时间是3-5s,若大于这个时间节点,将会使用户失去耐心,取消对系统的操作。
    

    web性能测试之Jmeter

    Jmeter属于一个非常实用的测试工具,在性能测试当中也占有一个非常重要的位置。通常jmeter在性能测试过程中,涉及到的基本是直接对接的后端服务,针对前端的响应基本不会涉及,所以用jmeter来对一个web系统进行性能测试时,很难去捕获到前端的响应数据。但是后端响应数据获取起来非常的便捷,其中就包括:并发数、平均响应时间、错误率、吞吐量等等,如下图:
    
    
    
    那么,关于前端的响应数据,我们该用什么方法去获取呢?接下来讲的一种方法,就是利用LR来进行。
    

    web性能测试之Loadrunner

    Loadrunner则是属于企业软件,这就奠定了它功能繁多,用途广泛的基础。LR算是一个大型的性能测试工具了,但是平常使用也还是其基本的一些功能。LR在用户界面交互上进行了注重,也就是我们之前提到的前端的响应数据,利用LR能够弥补jmeter无法涉及到的前端响应时间这部分,通过更接近用户对界面的交互,得出前端发起请求到请求发送到后台服务这个过程的响应时间。所以,这前后端两部分的响应时间之和,就是我们基本能够判定一个系统真正响应时间的依据。
    

    web性能测试之响应时间

    结合以上提及到的响应时间,它所涉及到的有两个部分,一是前端,二是后端:
    

    在这里插入图片描述

    关于整体系统压测策略

    那提及到系统压测的策略,其实是想提一下怎样去利用单节点和集群这两种方案。通常的压测,都是采用的单节点来进行的,这样“以小见大”的方法不为一个不可采取的方法,但是这其中还是会造成很多的误差。还有就是,单节点的压测容易压低整个系统的性能指标,因为无法充分的利用系统资源。
    
    而集群压测,在环境部署上是一个复杂点,但是能够充分利用系统已有资源,这样得出的数据能够更加真实有效。在有过量的时间时,可以讲单节点和集群的压测数据进行对比,这样就能发现其中存在的差异。
    

    关于性能测试日志

    性能测试中,日志是非常能够反应出测试工作中问题所在的一个环节,通过查看日志来定位问题是一个繁杂但是极为可靠的方式。
    
    此类测试中,都会涉及到哪些日志呢?
    
    
    
    Jmeter端日志
    HTTP端打到Nginx端的日志,这层会涉及到来源IP、请求地址、响应时间等。
    Tomcat层日志
    Server层日志
    

    关于OS层数据监控

    CPU监控,通常的指标是CPU使用率不能超过80%,这样给系统预留一个缓冲的范围。这里提及一点,就是其中涉及到多核CPU的情况,严谨的人会去关注每核CPU的使用情况,因为很多时候多核CPU的利用并不是均衡的,整体的CPU使用情况不能反映出单核的使用情况,容易造成误导。
    
    JVM层监控,这主要是去监控线程,其中包含单线程、多线程,同步线程、异步线程。关于同步线程和异步线程,是一个系统中比较关注的点,假如:一个系统处理事务时,采用的是同步线程,很多事务会等待处理造成阻塞,那么这样的系统处理速度就会受到很大的限制,会被视为一个不合格的系统。
    
    以上算是记录一下从多方面去考虑web性能测试的各个点,从而使测试结果更加真实有效。
    
    展开全文
  • 浅谈Web性能测试

    2020-12-30 16:50:07
    web端的性能测试应该注意的指标有:用户操作的响应时间、系统的吞吐量(TPS)、系统的硬件资源情况(CPU、硬盘、磁盘)、网络资源占用情况等。 web性能测试之HTTP请求 关于性能测试中,HTTP请求类的性能指标都...
  • 功能方面的测试web测试应该没什么差别,但是有些跟手机应用和习惯方面相关的东西需要注意: 1.apk的安装、卸载和升级,看能否正常进行;软件提示更新,是否能成功下载并安装,如果取消更新,下次登录时会不会接着...
  • 应用程序绘画(注意:如果不需要SSR,如何禁用它)。 这旨在成为一个功能丰富的Starter应用程序,其中包含所有最新技术,可用的最佳构建系统,并包括当今单页应用程序(SPA)中所需的许多实际示例和库。 它利用了...
  • (4)集成和测试时,web端需要注意哪些问题? *app端测试无误后,可以在自己的下载网页(或者分享页)里面集成我们的web文档,来实现和在线测试二维码一样的传递参数功能; *集成时需要注意,触发下载时必须调用我们的...
  • 测试培训教材

    2014-04-01 12:10:48
    需要“Launching Quick Test Professional”来进一步地编辑和修改自动化测试脚本。 什么是BPT? 业务组件测试 用户参与、尽早测试: 基于角色和工作流的BPT模型 角色定义应该灵活、根据能力、时间资源等...
  • 软件测试经典面试题 (超实用)

    热门讨论 2012-02-16 13:48:08
    104、在分别测试winform的C/S结构与测试WEB结构的软件是,应该采取什么样的方法分别测试?他们存在什么样的区别与联系? 27 105、在测试winform的C/S结构软件时,发现这个软件的运行速度很慢,您会认为是什么原因?...
  • 测试用例里非常清楚的阐释了开发者和使用者对于这代码的期望和要求,也非常有利于代码的传承。 考虑投入产出比来做测试 说了这么多测试的好处,并不代表一上来就要写出100%场景覆盖的测试用例。个人...
  • 分配第一个cell也就是文字的高度 然后根据图片的部分,分配第二个cell也就是图片的高度二手市场每个cell显示两个商品,很简单的做法图书馆/校园说说/二手市场/网上作业这两个部分因为没有接口,所以直接用web端做的...
  • 这就是为什么说<strong>CSS像素是专门为Web开发者创造的一个抽象层。 三个视口 视口基础 给一个div元素设置width为35%的时候, 是相对于什么的35%? 是相对于父级,而CSS中没有设置宽度的块级元素默认...
  • 由于 web 页面上调用 js 文件不受浏览器同源策略的影响,所以通过 script 标签可以进行跨域请求: <ol><li>首先前端需要先设置好回调函数,并将其作为 url 的参数。</li><li>服务端接收到请求后&#...
  • 微信服务号现在真的很强大,里面有各种各样的服务和功能。...微信本地开发,需要注意的就是调试与测试,因为页面要做手机适配,功能也要做充分测试,并没有普通的web项目那么方便。  微信项目开发
  • tomcat性能调优

    2010-06-17 15:48:00
    测量web服务器的性能是一项让人感到畏缩的任务,但是我们在这里将给出一些需要注意的地方 并且指点你了解其中更多的细节性的内容。它不像一些简单的任务,如测量CPU的速率或者是测量程序占用CPU的比例,web服务器的...
  • spring boot 环境搭建

    2018-07-14 23:22:54
    如果你不了解 Spring Boot 的话,先使用 Eclipse 搭建可能会遇到很多麻烦(可能需要安装插件)废话不多说:01:新建项目 引用模板02 :注意:先添加自己的 JDK 要求 1.8版本以上03:设置相关信息04:选择 Web 05:...
  • NFS服务

    2021-02-23 15:01:33
    一、NFS共享服务 ...2.web端安装http和php 3.上传代码 4.解压代码 5.启动httpd 6.访问页面测试 7.挂载 六、统一用户 1.服务器创建统一用户 2. 需要修改用户的服务 3.修改httpd的用户 4.修改nfs服务的用户 5.修改
  • 时间的应用是非常普遍的. 各个记录都要带上时间,否则不知道什么时间的数据和操作. 前端由分布在世界各地的web...但我们在测试这个api时会很不方便, 因此,后端提供的api,需要注意兼容这两种输入格式,就是时间字符串和时
  • 下列说法正确的是:开发和测试环境必须能反映生产环境 /生产环境同开发和测试环境必须分离/应按照开发和测试计划中设置的标准配置来建立环境 /为了实现对项目的控制,需要注意同步开发和测试环境之间的状态 ...
  • 13.1 为什么需要Web标准 13.2 Web标准 13.2.1 HTML 13.2.2 ECMAScript 13.2.3 XML 13.2.4 XHTML 13.3 文档对象模型(DOM) 13.3.1 DOM标准 13.3.2 DOM与BOM的区别 13.3.3 将HTML文档解析为一棵节点树 13.3.4...
  • linux集群应用实战

    热门讨论 2013-03-27 12:24:49
    配置mysql主从复制需要注意的问题 第25讲 配置mysql+heartbeat+drbd实现mysql写操作高可用 课程目标: 掌握mysql+heartbeat+drbd的配置方式,并可灵活运用 配置mysql+drbd实现数据镜像 配置mysql+heartbeat实现...
  • 主要难点在于和前端交互socket推送,socket推送采用两种方式,web端socket采用SpringSocket,移动端采用Netty推送,其中netty推送通过定时任务处理。 环境搭建 Centos 6.8 MySQL 5.5.16 Redis-x64-3.2.100 Mongodb ...

空空如也

空空如也

1 2 3 4
收藏数 75
精华内容 30
关键字:

web端测试需要注意什么