精华内容
下载资源
问答
  • 在这个系列里,主要介绍了如何从零开始去搭建一个可用的自动化工程框架,但是还缺乏了一些细节的补充,例如对于自动化测试而言,如何提高其测试的稳定性?本篇文章,将会和读者一起探讨这个问题。装饰器与出错重试...

    在之前,我写过一个系列“从零开始搭建一个简单的ui自动化测试框架(pytest+selenium+allure)”,在这个系列里,主要介绍了如何从零开始去搭建一个可用的自动化工程框架,但是还缺乏了一些细节的补充,例如对于自动化测试而言,如何提高其测试的稳定性?

    本篇文章,将会和读者一起探讨这个问题。

    装饰器与出错重试机制

    谈到稳定性,不得不说的就是“出错重试”机制了,在自动化测试中,由于环境一般都是测试环境,经常会有各种各种的抽风情况影响测试结果,这样就为测试的稳定性带来了挑战,毕竟谁也不想自己的脚本一天到晚的出各种未知问题,而往往这种环境的抽风(通常是前端页面的响应速度和后端接口的响应速度)带来的影响是暂时的,可能上一秒失败了,下一秒你再执行又好了,在这种情况下,如果你有一个出错重试机制,起码可以在这种暂时性的影响下让你的脚本安然无恙,下面我们具体的说一下做法。

    什么是装饰器?

    因为我们的做法依赖装饰器,所以在去做之前,先简单介绍一下装饰器。

    装饰器,表现形式为,在方法(或者类)的上面加上@xxx这样的语句,假如我们已经实现了一个装饰器名叫retry,那么我们想用它就这么用:

    @retry

    def test_login():

    print("test")

    error = 1/0

    如果retry实现了出错再次重试(稍后再说如何实现),那么这么使用的话,就会让test_login这个case在执行出错的时候再次执行。

    很神奇,让我们来看看实现retry的代码:

    def retry(func):

    def warp():

    for time in range(3):

    try:

    func()

    except:

    pass

    return warp

    就结果而言,执行以下代码:

    @retry

    def test_login():

    print("test")

    error = 1/0

    test_login()

    和执行:

    retry(test_login)()

    是等价的,由此我们可以看出,装饰器其实本质上就是一个函数,这个函数接收其他函数(或者类)作为参数,通过对这个函数(或者类)的调用或者修改,完成不更改原始函数而修改该函数的功能。

    在这里还有一个知识点,你有没有想过,在retry内部的函数warp(),是怎么拿到func这个参数来执行的?执行retry函数return的是warp这个函数,而warp并没有接受func这个传参啊。

    这就是python里的闭包的概念,闭包就是指运行时自带上下文的函数,比如这里的warp这个函数,他运行的时候自带了上层函数retry传给他的func这个函数,所以才可以在运行时对func进行处理和输出。

    了解了装饰器和闭包,那么下面就很容易做到对测试用例的出错重试机制了。

    编写一个出错重试装饰器

    现在,我们来尝试自己编写一个用于测试用例的出错重试装饰器,代码如下:

    def retry(times=3,wait_time=10):

    def warp_func(func):

    def fild_retry(*args,**kwargs):

    for time in range(times):

    try:

    func(*args,**kwargs)

    return

    except:

    time.sleep(wait_time)

    return fild_retry

    return warp_func

    这个装饰器可以通过传入重试次数(times)和重试等待时间(wait_time),对待测用例实行重试机制。

    pytest里的出错重试机制实现

    在测试框架pytest里,已经实现了有关出错重试的策略,我们首先需要安装一个此类的插件,在cmd内执行以下命令安装:

    pip install pytest-rerunfailures

    如果你需要将此机制应用到所有的用例上,那么请在执行的时候使用如下命令(reruns是重试次数):

    pytest --reruns 5

    来执行你的用例;

    如果你期望加上出错重试的等待时间,请使用如下命令(reruns-delay是等待时间):

    pytest --reruns 5 --reruns-delay 1

    来执行你的用例;

    如果你只想对某几个测试用例应用重试策略,你可以使用装饰器:

    @pytest.mark.flaky(reruns=5, reruns_delay=2)

    例如:

    @pytest.mark.flaky(reruns=5, reruns_delay=2)

    def test_example():

    import random

    assert random.choice([True, False])

    更详细的介绍请参阅官方文档 。

    Allure里的测试用例分层

    刚刚我们实现了用例的出错重试机制,但是这仅仅解决了脚本在不稳定环境下的稳定性;如果还想要脚本变得更加容易维护,除了传统的po模式使用例和元素分离之外,我们还可以引入测试用例分层机制。

    为什么要采用分层机制?

    传统的po模式,仅仅实现了用例和元素分离,这一定层面上保障了用例的可维护性,起码不必头疼于元素的变更会让用例到处失效;但是这还不够,例如,现在有三个case,他们都包含了以下步骤:登录、打开工作台、进入个人中心;那么如果不做分层,这三个用例会把这三个步骤都写一遍,如果某天页面的变动导致其中一个步骤需要更改,那么你不得不去每个用例里去更新那个步骤。

    而如果,我们把用例当做是堆积木,登录、打开工作台、进入个人中心这三个步骤都只是个积木,那么我们写用例的时候,只需要在用到这个步骤时,把积木搭上去;如果某一天,其中一个积木的步骤有变动,那么只需要去更改这个积木的内容,而无需在每个使用了这个积木的用例里去改动。

    这大大增强了用例的复用性和可维护性,这就是采用分层机制的原因,下面,我会就allure里的分层机制做介绍来讨论具体如何实现。

    allure的装饰器@step

    在allure里,我们可以通过装饰器@step完成分层机制,具体的,当你用@step装饰一个方法时,当你在用例里执行这个方法,会在报告里,表现出这个被装饰方法;而@step支持嵌套结构,这就意味着,你可以像搭积木一样去搭你的步骤,而他们都会一一在报告里被展示。

    下面直接用allure的官方示例作做举例:

    import allure

    import pytest

    from .steps import imported_step

    @allure.step

    def passing_step():

    pass

    @allure.step

    def step_with_nested_steps():

    nested_step()

    @allure.step

    def nested_step():

    nested_step_with_arguments(1, 'abc')

    @allure.step

    def nested_step_with_arguments(arg1, arg2):

    pass

    def test_with_imported_step():

    passing_step()

    imported_step()

    def test_with_nested_steps():

    passing_step()

    step_with_nested_steps()

    运行这个case后,报告是这样的:

    fd52e1016245e9c58704db99d01812ec.png

    可以看到,

    test_with_nested_steps由passing_step()和step_with_nested_steps()这两个方法组成;

    而step_with_nested_steps()又由nested_step()组成;

    nested_step()又由nested_step_with_arguments(1, 'abc')组成;

    这样就像搭积木一样,组成了测试用例;而在报告里,也层级分明的标识了步骤的嵌套结构。

    这样,我们就可以通过一个又一个@step装饰的方法,组成测试用例;同时报告里也会支持层级显示;从而完成我们的分层机制。

    有关@step的更多详细介绍请参阅官方文档。

    展开全文
  • Web全面性能测试模型

    2021-03-23 13:56:56
    至于如何制定合理性能  性能测试、压力测试、负载测试、强度测试稳定性测试、健壮性测试、……,这么多眼花缭乱性能测试类型名称,估计很少有人能准确区分并说出定义来。至于如何制定合理性能测试策略,...
  • 需要测试的是一个什么样功能? 需求是这样:开发在Framework层增加了app应用权限管控(Android11中基本权限、自动以权限、AIDL),服务端可以通过下发指令到手机,控制app可以访问及不能访问权限。同时安装app...
  • 这个Grid规模挺大的,有七八十台机器,有全球各地的用户在上面运行Web的自动化测试。用户数量众多,Test Case也很多。然而Selenium Grid并没有那么给力,有时候会莫名其妙的Down掉。一开始我们每天重启一次服务,...

         我们公司使用Selenium Grid已经有两年的时间,今年中开始由我们来维护我们公司的Selenium Grid。这个Grid规模挺大的,有七八十台机器,有全球各地的用户在上面运行Web的自动化测试。用户数量众多,Test Case也很多。然而Selenium Grid并没有那么给力,有时候会莫名其妙的Down掉。一开始我们每天重启一次服务,相对稳定。然而后来连一天里面都会出现这种情况。

     

        为了解决这个问题,我痛下决心,开始漫长的调试之旅。网上相关的资料几乎没有,我也摸索了很长时间,下面记录下来跟大家分享一下。

     

        首先,建立压力测试的环境,请参考http://shijunjuan.iteye.com/admin/blogs/1997768

        然后,建立Selenium Grid的调试环境,请参考http://shijunjuan.iteye.com/admin/blogs/1997764 以调试方式启动GridLauncher

        因为之前已经阅读过Selenium Grid的代码,对它的代码有一定的了解,所以没有进行更多的调试,直接开始压力测试。启动jvisualvm来监视Hub的内存和线程情况。

         重现问题后,Hub hang了,在Eclipse里面Suspend 线程进行调试,查看Stack,看看卡在哪里了。也可以通过jvisualvm的ThreadDump,来查看线程卡在哪里。我看到大多数线程都停在了某一步,所以可以知道这一步出问题了。

         经过这样的分析,然后再网上查阅相关的知识。Selenium Hub用了Jetty Server作为Web服务器,所以有一些问题都跟Jetty和httpclient的使用有关。

        查出问题之后,我做了相应的fix,然后重新测试以验证fix的正确性。

        作为开源项目,我需要提交我的fix,这样在新的版本中才能有正确的修改,这样也可以回馈Selenium社区。所以我提交了我修改,发了四个Bug, 期待等Francois回来会修改这几个问题。

                                           i.              https://code.google.com/p/selenium/issues/detail?id=6770&thanks=6770&ts=1388044086

                                         ii.              https://code.google.com/p/selenium/issues/detail?id=6771&thanks=6771&ts=1388044233

                                        iii.              https://code.google.com/p/selenium/issues/detail?id=6772&thanks=6772&ts=1388044312

     

                                        iv.              https://code.google.com/p/selenium/issues/detail?id=6773&thanks=6773&ts=1388044400

     

     

    我的分享故事结束了,如果大家在用开源软件时,发现问题,也可以进行调试,修改,提交,积极参与开源软件的开发和改进。

    展开全文
  • web测试知识点整理

    2017-02-10 17:56:00
    web如何测试的? 1. 通用功能测试和可用性测试 2. 性能测试和安全性测试 3. 兼容性测试 4. 数据库和稳定性测试等 web功能测试怎么测? 从一下几个方面来进行WEB测试: 1. 链接测试 2. 表单测试 3. ...

    web是如何测试的? 

    1. 通用功能测试和可用性测试

    2. 性能测试和安全性测试

    3. 兼容性测试

    4. 数据库和稳定性测试等

     

    web功能测试怎么测? 

    从一下几个方面来进行WEB测试:

    1. 链接测试

    2. 表单测试

    3. Cookie测试(是否加密,页面帐号密码保存)

    4. Session测试(长时间不操作,再操作后是否要重新登录) 

    5. 脚本测试

    6. 文件上传测试

    7. 数据库测试

     

    web可用性测试怎么测?

    主要有两点:

    1. 站点整体布局

    2. 页面导航直观 站在用户的角度去使用软件,要求操作简单,易理解,简单高效 

     

    web的安全性怎么测试?  

    主要有以下几点:

    1. 认证与授权

    2. 密码加密

    3. Session和Cookie确认不会信息泄漏

    4. 文件上传漏洞(非法文件上传)

    5. SQL注入(万能密码)于验证系统不会因为非法输入而将SQL语句的运行顺序进行修改

    6. 使用日志系统将各种操作进行记录

    7.抓包,超时间

     

    Web的兼容性怎么测试? 

    服务器端:测试不同版本的WEB服务器,链接不同的数据库,或者使用不同的网络环境

    客户端:不同的硬件平台,不同的IE浏览器内核的兼容性(主要有IE6,IE7,IE8,搜狗,火狐) 挑选主流浏览器全跑 其他挑选主要功能,界面无差异

     

    OSI7层模型

    1. 物理层(二进制传输)

    2. 链路层(介质访问)

    3. 网络层(寻址和最短路径)

    4. 传输层(进程间的连接)----tcp

    5. 会话层(主机间通信)

    6. 表示层(数据表示)

    7. 应用层(处理网络应用) ---http

     

     

    tcp和udp有什么区别 

    udp(速度快)与tcp最大的差别在于它在建立连接前不会进行三次握手,属于不可靠的传输

    tcp:适合大数据传输,要建立三次握手,四次挥手

    udp:QQ传输信息量少,小数据传输 启动一台

    转载于:https://www.cnblogs.com/sallyliu/p/6387460.html

    展开全文
  • 第2章 Web全面性能测试模型性能测试、压力测试、负载测试、强度测试稳定性测试、健壮性测试、……,这么多眼花缭乱性能测试类型名称,估计很少有人能准确区分并说出定义来。至于如何制定合理性能测试策略...
     marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280">

    第2章          Web全面性能测试模型

    性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、……,这么多眼花缭乱的性能测试类型名称,估计很少有人能准确的区分并说出定义来。至于如何制定合理的性能测试策略,同时把这些性能测试组织起来,并设计对应的测试用例,就更不用说了。因此,性能测试的设计、组织、实施一直不容易开展。

    为了解决这些问题,本章提出了“Web全面性能测试模型”。主要讲解在企业的实际工作中,如何比较全面的开展Web性能测试工作,使Web性能测试工作更加合理、高效率的开展。

    本章重点讲解全书的理论核心“Web全面性能测试模型”,主要包含如下的内容:

    l         Web性能测试策略制定原则

    l         Web性能测试用例设计模型

    l         Web全面性能测试模型使用方法

    注:本章的Web全面性能测试模型主要是针对系统测试阶段的性能测试而提出,单元测试阶段的性能测试一般是测试人员配合开发人员进行,可以划分到单元测试阶段,不在本书研究之列。

    2.1         Web全面性能测试模型简介

    通过第1章的学习可以看出,性能测试的很多内容都是关联的。这就提供了一个思路:性能测试的很多内容可以经过一定的组织统一来进行。统一开展性能测试的巨大好处是可以按照层次由浅入深对系统进行测试,进而减少不必要的工作量,以实现节约测试成本的目的。为此,本章提出了“Web全面性能测试模型”。

    Web全面性能测试模型”提出的主要依据是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试,而这些类型测试的实施也是很类似的。举例说明:针对一个网站进行测试,模拟1050个用户就是在进行常规性能测试,用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作,就包含了强度和大数据量测试。

    在“Web全面性能测试模型”中,把Web性能测试分为八个类别,然后结合测试工具把性能测试用例分为五类。后面的2.3节将会展开讨论“Web全面性能测试模型”的测试用例设计方法。下面首先介绍八个性能测试类别的主要内容。

    (1)       预期指标的性能测试:系统在需求分析和设计阶段都会提出一些性能指标,完成和这些指标相关的测试是性能测试的首要工作之一。本模型把针对预先确定的一些性能指标而进行的测试称为预期指标的性能测试

    这些指标主要指诸如“系统可以支持并发用户1000、“系统响应时间不得高于10秒”等在产品说明书等文档中十分明确的内容。对这种预先承诺的性能要求,测试小组应该首先进行测试验证。

    (2)       独立业务性能测试:独立业务实际是指一些核心业务模块对应的业务,这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试的重点。因此不但要测试这类模块和性能相关的一些算法,还要测试这类模块对并发用户的响应情况。

    核心业务模块在需求阶段就可以确定,在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用领域的软件,通常从单元测试阶段就开始进行测试,并在后继的集成测试、系统测试、验收测试中进一步进行测试,以保证核心业务模块的性能稳定。何时开始测试核心模块主要由性能测试策略决定,读者可以参考2.2节“Web性能测试策略模型”部分。

    用户并发测试是核心业务模块的重点测试内容。“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能,并且持续一段时间。对“相同”的功能进行并发测试分为两种类型,一类是在同一时刻进行完全一样的操作,例如打开同一条数据记录进行查看;另外一类是在同一时刻使用完全一样的功能,例如同时提交数据进行保存。可以看出后者是包含前前者的,前者是后者的特例。后面2.3节的测试用例中会对这部分内容进行更详细的讨论。

    从微观角度讲,同时使用某一核心模块“不同”的功能,也是一种组合业务性能测试,只不过这种组合的相关业务的分类是一致的。因此在2.3.2节的“并发用户用例”设计中将会以“模块”为单位进行用例的设计,把用户并发测试分为“核心模块性能测试”和“组合模块性能测试”两种类型来进行讨论。

    (3)       组合业务性能测试:通常不会所有的用户只使用一个或者几个核心业务模块,一个应用系统的每个功能模块都可能被使用到。所以Web性能测试既要模拟多用户的“相同”操作(这里的“相同”指很多用户使用同一功能),又要模拟多用户的“不同”操作(这里的“不同”指很多用户同时对一个或者多个模块的不同功能进行操作),对多个业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试,也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模板的组合并发情况。

    由于组合业务测试是最反映用户使用情况的测试,因而组合测试往往和服务器(操作系统、Web服务器、数据库服务器)性能测试结合起来,在通过工具模拟用户操作的同时,还通过测试工具的监控功能采集服务器的计数器信息,进而全面分析系统的瓶颈,为改进系统提供有利的依据。

    用户并发测试是组合业务测试的核心内容。“组合”并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发,每组的用户比例要根据实际情况来进行匹配。

    (4)       疲劳强度性能测试疲劳强度测试是指在系统稳定运行的情况下,以一定的负载压力来长时间运行系统的测试,其主要目的是确定系统长时间处理较大业务量时的性能。通过疲劳强度测试基本可以判断系统运行一段时间后是否稳定。

    (5)       大数据量性能测试:大数据量测试分为三种:一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试,主要测试运行时数据量较大时的性能情况,这类一般都是针对某些特殊的核心业务或者一些日常比较常用的组合业务的测试

    第二种是极限状态下的数据测试,主要是指系统数据量达到一定程度时,通过性能测试来评估系统的响应情况,测试的对象也是某些核心业务或者常用的组合业务。例如某系统的数据每年只在年底备份转移一次,则可分别选择一个季度、半年、一年作为基线,并模拟输入各个时间段的预计数据量,然后来测试系统的性能,进而预估系统的性能走向。

    最后一种就是把前两种结合起来进行的大数据量测试,主要是测试在极限状态下、同时运行时产生较大数据量时的系统性能。

    由于大数据量测试一般在投产环境进行,通常把它独立出来并和疲劳强度测试放在一起,在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。

    (6)       网络性能测试:网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中,主要是测试应用系统的用户数目与网络带宽的关系。网络性能测试一般有专门的工具,本书不再赘述,网络测试的任务通常由系统集成人员来完成。

    (7)       服务器性能测试(操作系统、Web服务器、数据库服务器):服务器性能测试分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它种类性能测试的时候,监控服务器的一些计数器信息,通过这些计数器对服务器进行综合性能分析,找出系统瓶颈,为调优或者提高性能提供依据。“高级服务器性能测试”一般不由测试人员进行,而是由专门的系统管理员来进行,例如数据库服务器由专门的DBA来进行测试和调优。本书主要讨论在测试中常见的“初级服务器性能测试”,既通过工具对服务器资源进行监控的性能测试。

    (8)       一些特殊测试:主要是指配置测试、内存泄漏测试等一些特殊的Web性能测试。这类性能测试或者和前面的测试结合起来进行,或者在一些特殊情况下独立进行,本书重点讨论前一种情况。后一种情况往往通过特有的工具进行,投入较大,可以不作为性能测试的范畴来研究。

     

    Web全面性能测试模型”是在上面对性能测试分类和总结的基础上提出的,主要包含三部分的内容。

    第一部分:Web性能测试策略模型,本部分内容是整个模型的基础。软件类型决定着Web性能测试策略,同时用户对待软件性能的态度也影响着性能测试策略的制定。本部分内容主要结合软件类型和用户对性能重视程度来讨论Web性能测试策略制定的基本原则和方法。本部分内容将在2.2节进行详细的讨论。

    第二部分:Web性能测试用例设计模型,本部分内容是模型的核心部分。主要思想是结合测试工具,把上面性能测试的八项内容进一步归纳,形成五类测试用例:

    (1)       预期指标的性能测试;

    (2)       并发用户的性能测试;

    (3)       疲劳强度和大数据量的性能测试;

    (4)       服务器性能测试;

    (5)       网络性能测试;

    在具体的Web性能测试用例设计中,往往和测试工具结合起来,把服务器、网络性能测试的用例设计与前三种类型性能测试的用例设计结合起来进行。例如MI公司的LoadRunner就能在进行压力测试的同时,完成后面两类测试的数据采集工作,因此后面两部分的测试用例设计可以和前面融会在一起,在第5章的案例多采用了这种方式来进行设计。

    Web性能测试用例设计模型在2.3节进行详细的讨论。

    第三部分:模型使用方法,本部分内容讨论如何在工作中使用“Web全面性能测试模型”,具体在2.4节进行详细的讨论。

    2.2         Web性能测试策略模型

    本节主要介绍Web性能测试策略制定方法。性能测试策略一般从需求设计阶段开始讨论如何制定,它决定着性能测试工作将要投入多少资源、什么时间开始实施等后继工作的安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素,其中软件的自身特点起决定作用。

           软件按照用途的不同可以分为两大类:系统类软件和应用类软件。系统类软件通常对性能要求比较高,因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用,特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件,这类软件使用比较频繁,用户较多,一般也要较早进行性能测试;一般类应用主要指一些普通应用,例如办公自动化软件、MIS系统等,一般应用类软件多根据实际情况来制定性能测试策略,比如OA系统,可以早开始、也可以最后进行性能测试,这类软件受用户因素影响比较大。

           用户按对性能的关注度的不同一般可以分为四类,即特别关注、中等重视、一般关注、不怎么关注,这么划分主要是为了说明用户对性能测试的影响。实际上,用户不关注性能并不意味着测试人员就可以忽略性能测试,但是如果用户特别关注性能,测试人员也应该特别重视性能测试。表2-1列出了性能测试策略制定的基本原则(注意:这里的用户是广义范围的用户,包括所有和产品有利害关系的群体。因而不单单指最终使用产品的用户,这些用户既可以是提出需求的产品经理,也可以是公司的董事会成员,甚至是项目的研发人员)。

    软件类别

     

    用户重视程度

    系统类软件

    应用类软件

    一般应用

    特殊应用

    高度重视

    从设计阶段就开始针对系统架构、数据库设计等方面进行讨论,从根源来提高性能;

    系统类软件一般从单元测试阶段开始性能测试实施工作,主要是测试一些和性能相关的算法或者模块。

    设计阶段开始进行一些讨论工作,主要在系统测试阶段开始进行性能测试实施。

    从设计阶段就开始针对系统架构、数据库设计等方面进行讨论,从根源来提高性能;

    特殊应用类软件一般从单元测试阶段开始性能测试实施工作,主要是测试一些和性能相关的算法或者模块。

    中等重视

    可以在系统测试阶段的功能测试结束后进行性能测试。

    一般重视

    可以在系统测试阶段的功能测试结束后进行性能测试。

    不怎么重视

    可以在软件发布前进行性能测试,提交测试报告即可。

    2-1性能测试策略制定基本原则

           从表2-1可以看出:1系统类软件”、“特殊应用类软件”应该从设计阶段开始进行性能测试;(2)制定性能测试策略的主要依据由软件的特点来决定,用户的态度对策略会有一定的影响,但不是决定因素。

    软件的特点决定性能测试策略的另外一个重要原因是“一般应用类软件”本身对性能要求不高,发生性能问题概率不高,因此可以通过提高硬件配置来改善运行环境,进而来提高性能。不过这也不是绝对正确的观点,例如一个几千用户来使用的OA系统,仍然要高度重视性能,不管客户对待系统的性能是什么态度。

    虽然从硬件方面解决性能问题往往更容易做到,同时还可以降低开发成本,但是也不能过分让用户进行较大的硬件投入,否则会降低“客户满意度”,调整性能最好的办法还是软硬件相结合。

           “用户对待系统性能的态度影响性能测试策略,但不起决定作用”的根本原因是最终要把产品交付给用户来使用,而不是做出来给用户欣赏。因此不管用户是否重视性能测试,甚至根本不关心,对于性能要求高的软件产品也应按照表2-1的策略来执行性能测试。只是如果用户如果特别重视性能这方面,这意味着测试团队可能将要进行更多的成本投入,因为有义务使用户满意。

           下面是一些Web性能测试策略制定的案例。

    案例一:一个银行卡审批系统的性能测试策略制定案例。这个项目的性能测试策略从立项时开始制定,贯穿整个项目的执行过程(在5.3节将会进一步讨论本案例)。

    银行卡业务系统属于特殊应用软件,加上用户高度重视性能,因而采取的策略是从设计阶段就开始进行性能测试的准备工作,案例详细信息如表2-2

    产品类型

    银行卡审批业务系统,使用非常频繁,业务量每年达到200万左右,属于银行领域的特殊应用软件。

    项目背景

    系统属于第二次重新开发,前一开发商在系统开发完成后没有通过性能测试,100个左右用户并发访问系统时数据库服务器崩溃。因此新的系统从项目启动开始,性能测试已经成为用户关注的焦点。

    用户要求

    用户提出性能方面首先过关,否则功能再好也不会投产。

    性能测试策略

    从系统设计阶段开始进行性能测试准备工作,测试人员主要是参加系统的设计、评审。因为前一开发商失利的重要原因是数据库设计不合理,所以重点讨论了数据库的设计。

    系统设计阶段,完成了性能测试方案的设计。

    单元测试阶段通过测试工具对一些重要模块的算法进行测试。主要是一些并发控制算法的性能问题,测试对象是一些核心业务模块。

    集成测试阶段进行组合模块的性能测试。

    整个系统测试阶段都在进行性能测试,性能测试和功能测试同步进行。对功能测试引起的一些相关修改,立刻进行性能测试。

    验收测试阶段时,在用户现场的投产环境进行性能测试,根据测试结果对系统运行环境进行调优,达到较佳的运行效果。

    2-2某银行项目测试策略制定案例

    案例二:一个OA系统的测试案例,其性能测试策略和案例一差别很大。

    产品类型

    企业办公系统,用户数目在1000人以内,主要是一些信息的发布,以及公文流转、收发邮件等功能。软件系统的地位属于辅助办公功能。因此该类软件属于一般类型的应用软件,对性能要求不高,性能测试不属于重要工作。

    项目背景

    已有稳定产品的实施工作。主要是按照客户的个性化需求进行二次开发。

    用户要求

    客户提出了性能方面的需求:要求系统响应时间不要过慢,可以满足2000个用户来使用。

    性能测试策略

    系统测试阶段开始进行性能测试准备工作,完成测试用例设计。目标主要是评估系统性能,根据测试结果对系统进行一定的优化。

    验收测试阶段在用户现场执行性能测试用例,根据测试结果进行一定的调优工作,提交测试报告给用户以便进行系统验收。

    2-3OA项目测试策略制定案例

    案例三:一个门户系统的测试案例。

    产品类型

    主要是用于一些单位信息的发布,用户在50人以下。因此该类软件属于一般类型的应用软件,对性能要求很低。

    项目背景

    软件运行的硬件环境较好。

    用户要求

    用户没有提出具体的要求。

    性能测试策略

    验收测试阶段在用户现场进行测试,根据测试结果进行一定的调优工作,提交测试报告给用户,以便进行系统验收。

    2-4某门户项目测试策略制定案例

           三个案例不足以说明所有的性能测试策略制定的方法,但是通过这三个案例可以对性能测试策略制定有了更进一步的了解,能够认识到到性能测试策略的制定由软件自身特点决定,同时受用户态度的影响。实际上,软件项目的背景、软件运行环境等许多方面都会影响性能测试策略的制定。因此,本节提出的只是基本的参考方案。制定测试策略是十分复杂的工作,最有效的方法就是“从实际出发”。项目的特点千差万别,只有把用户当成“上帝”,充分为用户考虑,才可以制定出合理的性能测试策略。

    本节介绍了性能测试策略制定的基本思路和方法。性能测试策略是后期性能测试工作的基础,决定着性能测试工作的投入,因此要充分意识到这一工作的重要性,认识到只有做好了前期的“路线”制定工作,才可以走对后面的“道路”。

     


    展开全文
  • The web has evolved. Finally, testing has too. 事实上对于 UI 自动化测试来说,...相比之下,如何提高测试用例稳定性以及出现错误时 debug 便捷性才是让 UI 自动化测试方案落地重要细节。 那么为什么我们还...
  • 简单理解性能测试,以及如何测试,如何优化! 啥是性能测试? 性能测试就是对你整个系统处理能力进行评估。 都要测试啥? 响应时间,并发数,吞吐量,性能计数 性能测试方法? 性能测试,负载测试,压力测试,...
  • 正式环境的稳定性,除去软件自身的质量因素,主要与运行的主机、网络等基础设施相关,而测试环境的稳定性则更多受到人为因素影响。由于频繁的版本变更,以及部署未经充分验证的代码,测试环境出故障的情况屡见不鲜。...
  • WebUI自动化从业界看,难推进,易烂尾,原因基本在于:维护成本高、运行速度慢、稳定性差 Dagger专注于WebUI自动化,从技术上克服了速度与稳定问题(见下文)。只封装够用浏览器操作为API,并充分简化/强化这些API...
  • 阿里的许多实践看似简单,背后却蕴涵着许多思考,譬如测试环境的管理。  互联网产品的服务通常是由 Web 应用、中间件、数据库和许多后台业务程序组成的,一套运行环境就是一个...正式环境的稳定性,除去软件自身...
  • Web UI层自动化测试,估计大家痛苦都差不多。成本高,维护成本更高,稳定性差,效果尴尬等等。其实市面上已经有很成熟工具,能够完全模拟手工直接操作浏览器。例如: QTP,webdriver等,如何运用这些工具写...
  • 竭尽所能提供最佳服务质量,但是我不保证应用程序可持续性或稳定性如何托管我自己Mocky实例 工作正在进行中。 请过几天再回来! 建筑 API Mocky API是使用Scala和服务器编写。 模仿将与一起存储到...
  • 本文主要介绍如何用Java针对Restful web service 做接口自动化测试(数据驱动),相比UI自动化,接口自动化稳定性可靠性高,实施难易程度低,做自动化性价比高。所用到工具或类库有 TestNG, Apache POI, Jayway ...
  • 本文主要介绍如何用Java针对Restful web service 做接口自动化测试(数据驱动),相比UI自动化,接口自动化稳定性可靠性高,实施难易程度低,做自动化性价比高。所用到工具或类库有 TestNG, Apache POI, Jayway rest...

空空如也

空空如也

1 2 3 4 5 ... 11
收藏数 201
精华内容 80
关键字:

web的稳定性如何测试