精华内容
下载资源
问答
  • 接口测试-Mock测试方法

    万次阅读 多人点赞 2019-05-26 22:29:02
    对于某些不容易构造(如 HttpServletRequest 必须在Servlet 容器中才能构造出来)或者不容易获取的比较复杂的对象(如 JDBC 中的ResultSet 对象),用一个虚拟的对象(Mock 对象)来创建以便测试的测试方法。...

    一、关于Mock测试

    1、什么是Mock测试?

    Mock 测试就是在测试过程中,对于某些不容易构造(如 HttpServletRequest 必须在Servlet 容器中才能构造出来)或者不容易获取的比较复杂的对象(如 JDBC 中的ResultSet 对象),用一个虚拟的对象(Mock 对象)来创建以便测试的测试方法。

     

    2、为什么要进行Mock测试?

    Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。所以,Mock既能出现在单元测试中,也会出现在集成测试、系统测试过程中。Mock 最大的功能是帮你把单元测试的耦合分解开,如果你的代码对另一个类或者接口有依赖,它能够帮你模拟这些依赖,并帮你验证所调用的依赖的行为。比如一段代码有这样的依赖:

    当我们需要测试A类的时候,如果没有 Mock,则我们需要把整个依赖树都构建出来,而使用 Mock 的话就可以将结构分解开,像下面这样:

     

    3、Mock对象适用场景

    (1)需要将当前被测单元和其依赖模块独立开来,构造一个独立的测试环境,不关注被测单元的依赖对象,只关注被测单元的功能逻辑。

      -----比如被测代码中需要依赖第三方接口返回值进行逻辑处理,可能因为网络或者其他环境因素,调用第三方经常会中断或者失败,无法对被测单元进行测试,这个时候就可以使用mock技术来将被测单元和依赖模块独立开来,使得测试可以进行下去。

    (2)被测单元依赖的模块尚未开发完成,而被测单元需要依赖模块的返回值进行后续处理。

    1)前后端项目中,后端接口开发完成之前,接口联调;

    2)依赖的上游项目的接口尚未开发完成,需要接口联调测试;

      -----比如service层的代码中,包含对Dao层的调用,但是,DAO层代码尚未实现

    (3)被测单元依赖的对象较难模拟或者构造比较复杂。

      -----比如,支付宝支付的异常条件有很多,但是模拟这种异常条件很复杂或者无法模拟,比如,查询聚划算的订单结果,无法在测试环境进行模拟。

     

    4、Mock测试的优势

    (1) 团队可以并行工作

    有了Mock,前后端人员只需要定义好接口文档就可以开始并行工作,互不影响,只在最后的联调阶段往来密切;后端与后端之间如果有接口耦合,也同样能被Mock解决;测试过程中如果遇到依赖接口没有准备好,同样可以借助Mock;不会出现一个团队等待另一个团队的情况。这样的话,开发自测阶段就可以及早开展,从而发现缺陷的时机也提前了,有利于整个产品质量以及进度的保证。

     

    (2)开启TDD模式,即测试驱动开发

    单元测试是TDD实现的基石,而TDD经常会碰到协同模块尚未开发完成的情况,但是有了mock,这些一切都不是问题。当接口定义好后,测试人员就可以创建一个Mock,把接口添加到自动化测试环境,提前创建测试。

     

    (3)可以模拟那些无法访问的资源

    比如说,你需要调用一个“墙”外的资源来方便自己调试,就可以自己Mock一个。

     

    (4)隔离系统

    假如我们需要调用一个post请求,为了获得某个响应,来看当前系统是否能正确处理返回的“响应”,但是这个post请求会造成数据库中数据的污染,那么就可以充分利用Mock,构造一个虚拟的post请求,我们给他指定返回就好了。

     

    (5)可以用来演示

    假如我们需要创建一个演示程序,并且做了简单的UI,那么在完全没有开发后端服务的情况下,也可以进行演示。说到演示了,假如你已经做好了一个系统,并且需要给客户进行演示,但是里面有些真实数据并不想让用户看到,那么同样,你可以用Mock接口把这些敏感信息接口全部替换。

     

    (6)测试覆盖度

    假如有一个接口,有100个不同类型的返回,我们需要测试它在不同返回下,系统是否能够正常响应,但是有些返回在正常情况下基本不会发生,比如,我们需要测试在当接口发生500错误的时候,app是否崩溃,别告诉我你一定要给服务端代码做些手脚让他返回500 。而使用mock,这一切就都好办了,想要什么返回就模拟什么返回,不用再担心我的测试覆盖度了!

     

    5、Mock测试存在的问题

    使用Mock测试有时可以提高团队的开发效率,但当B、C都开发完成代码后,这时应该把E2E测试代码从使用Mock测试改为调用真实的模块,以避免出现模块之间集成部分漏测的问题。这里说mock存在的问题,主要是让开发和测试不要过分的依赖/相信mock接口。

     

    使用mock时,切记的几点:

    1)测试人员不应该被覆盖率高的E2E自动化测试所迷惑,覆盖率高不代表没有问题。尤其在接手新项目中,需要查看E2E测试中有没有使用Mock测试,进一步去判断这些地方使用Mock测试是否合理,这些Mock测试是否应该换成真实模块间的调用和集成。

    2)当把mock接口换成实际接口后,测试/开发也必须把之前的测试重新做一遍。

    ps: 当你使用mock接口来提高效率,请注意:你的工作量其实是比 直接只用实际接口 多了 一倍的。如果测试时,偷懒,替换成实际接口后,只是简单测试,那么 当实际接口和mock预期接口有差异时,故障便和你相遇了。

    建议: mock接口只能主流程联调/ 异常返回测试,不要过分依赖mock接口进行测试。

    3)测试完毕,上线前,请一定确保 为了mock而做的相关代码/配置文件的修改,已经完全恢复了。

    建议:上线checklist中条条列出,并上线前review

    ---------------------

    原文:https://blog.csdn.net/huazhongkejidaxuezpp/article/details/67018676

     

    二、Mock测试方式

    1. Mock Server-Moco

    这是一个jar包,只要执行该jar包,指定配置文件,就可开启一个http服务器提供服务,并且修改配置文件后也无需重启服务,支持动态加载。我使用的是moco-runner-0.10.2-standalone.jar,运行方式如下:

    ```java -jar moco-runner-0.10.2-standalone.jar start -p 8080 -c XXX.json```

    XXX.json就是我们的mock配置文件,比如:

    [     {         "description": "api 1",         "request" :{             "method" : "get",         "uri" : "/foo"         },         "response": {             "json": {"foo":"bar"}         }     } ]

     

    以上就可以实现当我们访问127.0.0.0:8080/foo时,返回一个json为{"foo":"bar"}。

    具体其他使用方法请参照官方文档:https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md

     

    2. fiddler

    fiddler大家都很熟了,在windows环境可以随便自定义返回内容,但一个很大的缺点是,它不跨平台,而我们平时的很多场景下,是需要在Linux下进行mock的。

    还有一些其他mock工具,大多都是通过编写js代码或者python、java等代码来达到mock目的,此处就不再介绍了。

     

    在选择mock工具时,可参考以下几个方面:

    一是数据要好管理,别让我管理一堆文件;

    二是mock接口最好可以设置成和真实接口完全一致,这样就只需要切换hosts就可以切换mock接口和真实接口,不需要修改代码;

    三是跨平台,mock接口在windows和Linux下都需要可用。至于跨域、动态加载什么的,这是必须条件。

     

    三、Mock测试示例

    1、使用Fiddler进行Mock测试

    ------这种调试方式适用于rest接口调试,web界面调试等。

    测试工程师在做测试时,也需要服务器返回一些特殊的数据来做测试,使用 Fiddler AutoResponder功能来伪造测试数据(创建虚拟对象),能大大减少测试工程师的工作量。

    1.1 Fiddler AutoResponder工作原理

    使用Fiddler可以替换自动返回的一个【伪造】的HTTP响应,这与使用断点修改HTTP响应类似,只不过AutoResponder是自动的,操作更加方便。即,浏览器发出的HTTP请求并没有到达服务器,而是被Fiddler直接返回了一个【伪造】的HTTP响应。

     

    1.2 使用Fiddler进行Mock测试

    (1)接口抓包-----找到要mock的接口

    以掘金首页为例,找到下面的接口 https://gold-tag-ms.juejin.im/v1/categories

    (2)复制接口数据到本地

    在接口上进行右键点击,选择save -> …and Open as Local File -> 默认会保存至桌面,示例中的数据,保存到了桌面的test.json

    (3)修改数据

    修改保存到本地的json文件,示例中仅修改了页面的标签数据。

    (4)替换json文件

    在web session 面板中找到对应的请求,然后将其拖到AutoResponder面板中,在RuleEditor中单击“Find a file...”,选择本地json文件的路径。

    (5)激活规则

    选中“Enable rules”,激活规则。选中“Unmatched requests passthrough",放行不匹配的HTTP请求。

    (6)save,刷新页面

    单击“Save”按钮。只需修改本地保存的json文件,然后刷新浏览器(或直接访问接口),就可以看到效果了。

    *PS:部分内容根据网上资源整理,此博客仅作个人学习使用。

     

     

    展开全文
  • 黑盒测试的测试方法

    万次阅读 多人点赞 2017-12-19 11:35:22
    一般我们在做软件测试的时候,会遇到黑盒测试,白盒测试,我们今天主要说的是黑盒测试的 主要测试方法有那些。接下来就是干货了。 最常见的是  边界值 等价类 错误推测法 场景法 因果图法 判定表组成法 正交实验...

    一般我们在做软件测试的时候,会遇到黑盒测试,白盒测试,我们今天主要说的是黑盒测试的 主要测试方法有那些。接下来就是干货了。

    最常见的是

        边界值  等价类  错误推测法  场景法  因果图法 判定表组成法   正交实验设计  


    下面是详细的解释:


    前言:在期末考到来的时候复习下黑盒测试。文章copy&paste了很多别人的东西。文章里有很多不足之处。欢迎拍砖!!!!!

    黑盒测试仅需知道系统的【输入】和【输出】,不需要知道代码是怎么写的。


    一、边界值测试

    经实践总结:大量的软件缺陷发生在输入域和输出域的边界上。所以在设计测试用例的时候,应该重视边界。

    例如只有一个输入条件时,可以这么选取测试用例。(以坐标轴举例。以红点表示测试用例)


    例如当有两个输入条件的时候,可以这么选取测试用例。(以红点表示测试用例)


    ps:要测试健壮性(软件有没有金刚不坏之身)的时候,可以这么设计测试用例。

    选取略小于最小值的无效测试数据(或者略大于最大值的无效测试数据)。

    (以蓝点表示测试用例)



    小结:边界值测试是一种最基本的黑盒测试方法,它是“等价类划分”这种测试方法的良好补充。但该方法会有较大的冗余和漏洞。

    边界值测试对布尔型无效(因为布尔型不是“true”就是“false”,不存在边界值的概念)

    边界值测试并非黑盒测试独有,它也可以应用在白盒测试(比如数组边界的测试、对循环次数边界的测试……)

    -------------------------------------------------------------------------------------------------------------------------

    二、等价类划分

    要做到穷尽测试是不可能的,所以在设计测试用例时往往要先划分等价类再选取“人大代表”。

    划分的子集应该满足如下因素:

    (1)每个子集内部所有的数据都是等价的

    (2)子集之间互不相交

    (3)所有子集的并集是整个输入域或输出域

    PS:

    (1)【有效等价类】是相对于规格说明合理的、正确的、有意义的输入数据构成的集合。

    (2)【无效等价类】是相对于规格说明不合理的、错误的、无意义的输入数据构成的集合。

    小二啊,上一个例子:

    如网站注册用户名的时候,输入框要求“用户名由字母开头,后跟字母或数字的任意组合,且长度<=8”。

    (1)有效的等价类划分

    username = {0<全字母的长度<8}

    username = {0<(字母开头+数字)的长度<8}

    (2)无效的等价类划分

    username = {0<全数字的长度<8}

    username = {0<(数字开头+字母)的长度<8}

    username = {全字母的长度>8}

    username = {全数字的长度>8}

    username = {(数字开头+字母)的长度>8}

    username = {0<(字母开头+数字)的长度>8}

    小二啊,再上一个例子

    例:每个学生可选修1-3门课程
    •可以划分一个有效等价类:选修1-3门课程。
    •可以划分两个无效等价类:未选修课;选修课超过3门。
    ------------------------------------------------------------------------------------------------------------------
    针对缺陷相关性假设,可将等价类测试分为【弱等价类测试】和【强等价类测试】。
    在现实情况中,由于缺陷的可能情况非常多,一个子集中的数据对某种缺陷是等价的,但对另外一种缺陷可能又是不等价的。
        弱一般等价类(WN)测试:
                      考虑单缺陷假设; 测试用例使用每个等价类中的一个值。
               强一般等价类(SN)测试:
                      考虑多缺陷假设; 测试用例集合为等价类笛卡儿积。
    小二啊,再上一个例子。
     
    1、弱等价类
    弱等价类是考虑某个单一缺陷情况下的等价情况,子集里所有数据在这种缺陷假设下是等价的,并且划分成的几个等价类能够覆盖整个测试空间的单一缺陷。比如以下一段程序:
    void Func(unsigned int x)
    {
    if ( x > 10 )
    {
        Func1();
    else
    {
        Func2();
    }
    }
    我们可以将数据划分为两个等价类,0~10为1个等价类,大于10的数据为1个等价类,
    在考虑“>”号误写成“<”号这种缺陷的情况下,这两个等价集中的数据都是等价的,比如0~10这个等价类中,使用0或使用10来进行测试都能发现缺陷。这两个等价类中各自抽取一个测试数据进行测试,都能代表其他数据揭示出“>”号误写成“<”号这种缺陷来,因此整个测试空间都被覆盖了。
    2、 强等价类
    强等价类是在多个缺陷假设前提下,各个等价类中的可测数据在单个或多个缺陷假设下是等价的,并且划分的各个等价子集中各自取一个测试数据可以覆盖整个测试空间的多个缺陷情况。
    再考虑前面弱等价类中的例子程序,出错的可能性有那些呢?除了大于号会错写成小于号外,
    实际上还有可能写成大于等于号,
    10有可能写成1或100等大于10或小于10的数,
    【为方便描述以错写成1和100为例】,事实上错误写成其他数和错写成1和100是等价的。这样将各种可能出错的情况组合起来,程序中的判断条件有可能有以下12种情况:
    判断条件
    揭示缺陷的等价类
    判断条件
    揭示缺陷的等价类
    判断条件
    揭示缺陷的等价类
    x>10
    是正确的代码 
    x>1
    {10}
    x>100
    {11}
    x<10
    {>10}
    x<1
    {>10}
    x<100
    {0~9},{10}
    x<=10
    {10},{>10}
    x<=1
    {>10}
    x<=100
    {0~9},{10}
    x>=10
    {10}
    x>=1
    {10}
    x>=100
    {11}
    考虑0~10这个集合,在误写成中间一列条件中情况下,里面的数据并不等价,比如误写成x>1的情况下,使用1做测试和使用2做测试揭示缺陷是不同的,使用1做测试发现不了缺陷,但使用2测试就能发现缺陷。
    在判断条件误写成x>=10条件下,10和0~9中的任一数据也不等价,并且使用大于10的数据也无法揭示出条件错写成x>=10这个缺陷,因此整个测试空间的多个缺陷无法被已划分的两个等价类来覆盖,10需要单独划分成一个等价类。
    这样将数据划分成三个等价类{0~9}、{10}、{大于10的数据},再看看这三个等价类是否可以覆盖表中各种出错情况,显然在x>100和x>=100两种情况下,大于10的数据集合中的数据是不等价的,使用大于100的数据不能揭示出缺陷,但使用大于10小于100的数据却能揭示出缺陷,因此需要对大于10的数据再划分等价类,实际上只要将边界值{11}划一个单独的等价类就可以了。
    这样总共得到四个等价类{0~9}、{10}、{11}、{大于11的数据},从这四个等价类中各取一个数据的话就可以将以上列出的所有可能的缺陷情况都揭示出来,但是各个等价类并不是对所有缺陷都等价的,这种划分的等价类由于可以将各种缺陷情况覆盖到,把它叫叫做强等价类。

     PS:

    在等价类测试当中,强指的是多缺陷假设,而弱指的是单缺陷假设,前者表明了一个笛卡尔乘积的概念;一般指的就是正常值,即不需要考虑异常者,而健壮性则刚好相反,即需要考虑异常者。

    弱一般等价类:单缺陷假设,不考虑异常区域
    强一般等价类:多缺陷假设,不考虑异常区域
    弱健壮等价类:单缺陷假设,要考虑异常区域
    强健壮等价类:多缺陷假设,要考虑异常区域;即一个全笛卡尔乘积

     

    小二啊,再上一个例子
     
    某城市电话号码组成规则是:地区码 + 前缀 + 后缀。
    地区码:空白 | 3位数字; 
    前缀:非0且非1开头的3 位数字; 
    后缀:4位数字。 
    被测试程序模块接受符合以上条件的电话号码,拒绝所有不符合规定的号码。
    请用等价分类法设计测试方案。
     1)划分等价类
    输入条件 有效等价类 无效等价类
    地区码 j:空白、k:3位数字 n:有非数字字符、o:少于三位数字、p:多于三位数字
    前缀 l:200-999之间的任意数字

    q:有非数字字符、r:起始位为0、s:起始位为1、

    11:少于三位数字、12:大于三位数字

    后缀 m:4位数字 13:有非数字字符  14:少于四位数字  15:大于四位数字

     2)设计测试用例

     

     

    小结:等价类测试可以处理布尔型和逻辑型的问题。建议在划分等价类后对每个等价类进行编号,这样可看起来会更清晰。

    -----------------------------------------------------------------------------------------------------------

    三、因果图

    毛泽东《反对本本主义》:“因为他们有丰富的经验,不但懂得现状,而且明白因果。”

    基于因果图的测试方法要考虑如下问题

    (1)规格说明书有哪些原因?

    (2)规格说明书有哪些结果?

    (3)规格说明书中各种原因之间的关系怎么样?

    (4)规格说明书中各种结果之间的关系怎么样?

    (5)规格说明书中原因和结果之间的约束条件怎么样?

    (6)如何从规格说明书中的原因和结果设计测试用例?

    因果图




    【a】恒等: 若c1为1,则e1也为1。若c1为0,则e1也为0;

    【b】非: 若c1是1,则e1是0.若c1为0,则e1是1;

    【c】或: 若c1与c2中有一个是1或者两个都为1,则e1是1。若c1和c2都为0,则e1是0;

    【d】与: 当且仅当c1和c2都是1,则e1为1,否则e1为0.

    ------------------------------------------------------------------------------

    E约束(异;异或): a,b最多有一个可能为1,不能同时为1.

    --------------------------------------------------------------------------------------------------



    约束(或;包含): a,b,c中至少有一个必须为1,不能同时为0.

    --------------------------------------------------------------------------------------------------------



    O约束(惟一): a和b必须有一个且仅有一个为1

    -----------------------------------------------------------------------------------------------------------------------



    R约束(要求):a是1时,b必须是1,即a为1时,b不能为0

    -----------------------------------------------------------------------------------------------------------------------



    M约束:对输出条件的约束,若结果a为1,则结果b必须为0.

    ----------------------------------------------------------------------------------------------------------------------

    小二啊,上一个例子。

    某个软件的规格说明书中规定:第一个字符必须是A或B,第二个字符必须是一个数字字符,在此情况下进行文件的修改。

    但如果第一个字符不正确,则给出信息L;如果第二个字符不正确,则给出信息M.


    可按照如下步骤设计测试用例:
    (1)根据软件规格说明书,列出原因和结果.
    (2)找出原因和结果之间的关系,原因和原因之间的约束关系,画出因果图.
    (3)将因果图转化为判定表
    (4)根据判定表设计测试用例

    解:

    原因:
    C1:第一个字符是A;
    C2:第一个字符是B;
    C3:第二个字符是一个数字字符.
    结果:
    E1:给出信息L;
    E2:修改文件;
    E3:给出信息M;



    转化成决策表

    小结:因果图可以用于描述输入与输出的相互关系。但是其绘制过程比较繁琐。因果图可以转化成决策表。建议直接绘制决策表。

    -----------------------------------------------------------------------------------------------------------------------------------------------
    四 、决策表
    决策表能让你的逻辑更严谨些
    小二,先上菜,再看菜单:
     ……对功率大于50马力的机器并且维修记录不全,或者已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。 
    •解答: 
    –①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。 
    –②列出所有的条件桩和动作桩
    •③填入条件项。可从第1列条件项开始,逐列向右填满。如第1列是: Y  Y Y ,第二列是: Y Y N 等等。 
    •④填入动作顶。这样便得到形如图的初始判定表:
     
     
     

    条件桩:列出了问题的所有条件。
    动作桩:列出了问题规定可能采取的操作。
    条件项:列出针对它所列条件的取值,在所有可能情况下的真假值。
    动作项:列出在条件项的各种取值情况下应该采取的动作。
    规则:由动作项和条件项组成。

    决策表的建立步骤
    1、列出所有的条件桩和动作桩;
    2、填入条件项;
    3、填入动作项,制定初始判定表;
    4、简化;合并相似规则或者相同动作。


    小二,上一个例子。
    已知a、b、c三边,判断是否能构成三角形?如果是三角形的话,是什么哪种三角形?
     
    小结 :决策表测试仅适合对输入域展开分析,不适合对输出域展开测试。
    ---------------------------------------------------------------------------------------------
    五 、错误推测法
    (阿克琉斯的脚踵?希腊神话的传说人物阿克琉斯,他除了脚踵以外全身刀枪不入,后来被射中脚踵而死亡,意思是指一个人的致命缺点!)
    错误推测法凭借的是测试人员的直觉和经验来推测系统中可能出现的各种缺陷。
    常常是列举出系统中所有【可能的缺陷和容易发生缺陷的特殊情况】,并根据它们来设计测试用例。
    小二啊,上几道例子

    例如: 测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:
    I.     输入的线性表为空表;
    II.    表中只含有一个元素;
    III.   输入表中所有元素已排好序;
    IV.   输入表已按逆序排好;
    V.    输入表中部分或全部元素相同。

    例如:查询功能
    A、无条件查询
    B、是否支持模糊查询
    C、查询的关键字之间是否可用连接符
    D、输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据
    E、若查询结果为空,是否给与相应提示

    例如:登录功能
    A、输入的数据前存在空格,是否能够正常登录
    B、输入的密码是否能够加密显示
    C、密码框的复制、粘贴功能是否被屏蔽掉
    D、用户在注销之后是否能够再登录成功
    E、输入的数据有误,用户是否可以无休止地尝试登录

    小结:

    优点:充分发挥个人的经验和潜能,命中率高
    缺点:覆盖率难以保证;过多的依赖于个人的经验

    ----------------------------------------------------------------------------------------------------------------------

    六、场景法
    软件的工作流程往往对应着现实生活的场景。应该从更高些的视角来把握系统的业务流程,了解功能模块。
    在熟悉流程的基础上才能讨论局部细节的测试设计。场景法的核心是事件流和场景。
    这是一个场景法的示意图。

    在这个图中,有一个基本流和四个备选流。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:

      场景 1 基本流

      场景 2 基本流 备选流 1

      场景 3 基本流 备选流 1 备选流 2

      场景 4 基本流 备选流 3

      场景 5 基本流 备选流 3 备选流 1

      场景 6 基本流 备选流 3 备选流 1 备选流 2

      场景 7 基本流 备选流 4

      场景 8 基本流 备选流 3 备选流 4

      从上面的实例我们就可以了解“场景”=“基本流”+“备选流”。

      基本流:采用直黑线表示,是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)

      备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(实际上是各种“非主流”的情况)

     下面是场景法的基本设计步骤

        1. 根据说明,描述出程序的基本流及各项备选流 
        2. 根据基本流和各项备选流生成不同的场景 
        3. 对每一个场景生成相应的测试用例 
        4. 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值

    小二啊,上一个例子:

    有一个在线购物的实例,用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用帐号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。

     step1:来确定基本流和备选流:

    step2:根据基本流和备选流来确定场景:

    step3:设计用例

      对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

      下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。

      本例中,对于每个测试用例,存在一个测试用例ID、场景的条件、测试用例中涉及的所有数据元素、以及预期结果。

      通过从确定执行用例场景所需的数据元素入手构建矩阵。然后,对于每个场景,至少要确定包含执行场景所需的适当条件的测试用例。例如,在下面的矩阵中,

    V(有效)用于表明这个条件必须是 VALID(有效的)才可执行基本流,

     I(无效)用于表明这种条件下将激活所需备选流。

    “n/a”(不适用)表明这个条件不适用于测试用例。

       

    step4:设计用例设计数据,把数据填入上面的用例表中。


    注:测试用例只是购物的一部分测试用例,应该还可以继续补充以达到比较好的覆盖。

    -------------------------------------------------------------------------------------------------------------------------

    注释:功能图法、正交实验法也是黑盒测试法


    展开全文
  • 白盒测试方法和黑盒测试方法

    千次阅读 2018-03-04 13:08:14
    本文摘自kerryzhu测试方法的辩证统一 http://blog.csdn.net/KerryZhu/article/details/763181,感谢原创作者 白盒测试方法和黑盒测试方法黑盒测试方法,不考虑程序内部结构和内部特性,而是从用户观点出发,针对...

    本文摘自kerryzhu测试方法的辩证统一 http://blog.csdn.net/KerryZhu/article/details/763181,感谢原创作者


     白盒测试方法和黑盒测试方法

    黑盒测试方法,不考虑程序内部结构和内部特性,而是从用户观点出发,针对程序接口和用户界面进行测试,根据产品应该实现的实际功能和已经定义好的产品规格,来验证产品所应该具有的功能是否实现是否满足用户的要求。

    所以,黑盒测试方法技术相对要求低,方法简单有效,可以整体测试系统的行为,可以从头到尾(end-to-end)进行数据完整性测试。黑盒测试方法适合系统的功能测试、易用性测试,也适合和用户共同进行验收测试、软件确认测试。黑盒测试方法不适合单元测试、集成测试,而且测试结果的覆盖度不容易度量,其测试的潜在风险比较高。

    由于白盒测试方法,已知产品的内部工作过程,针对性很强,可以对程序每一行语句、每一个条件或分支进行测试,测试效率比较高,而且可以清楚已测试的覆盖程度。如果时间足够多,可以保证所有的语句和条件得到测试,测试的覆盖程度达到很高。白盒测试方法适合单元测试、集成测试,而不适合系统测试。白盒测试方法准备的时间很长,如果要覆盖全部程序语句、分支的测试,一般花费比编程更长的时间。

    白盒测试方法所要求的技术也较高,相应的测试成本要大。对于一个应用的系统,程序的路径数可能是一个天文数字,即使借助一些测试工具,白盒测试法也不可能进行穷举测试,企图遍历所有的路径往往是做不到的。即使,穷举路径测试,也不能查出程序违反了设计规范的地方,不能发现程序中已实现但不是用户所需要的功能,可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。

    展开全文
  • 渗透测试方法

    千次阅读 多人点赞 2021-03-28 10:00:47
    文章目录渗透测试方法论2.1 渗透测试的种类2.1.1 黑盒测试2.1.2 白盒测试2.2 脆弱性评估与渗透测试2.3 安全测试方法论2.3.1 开源安全测试方法论(OSSTMM)2.3.2 信息系统安全评估框架2.3.3 开放式Web应用程序安全...

    渗透测试方法论

    渗透测试(penetration testing,pentest)是实施安全评估(即审计)的具体手段。方法论是在制定、实施信息安全审计方案时,需要遵循的规则、惯例和过程。人们在评估网络、应用、系统或三者组合的安全状况时,不断摸索各种务实的理念和成熟的做法,并总结出了一套理论——测试方法论。本章简要介绍了渗透测试方法论的各关键要点,涉及的主题包括:

    ● 两种广为认知的渗透测试类型——黑盒测试和白盒测试;

    ● 漏洞评估和渗透测试的区别;

    ● 业界普遍采纳的安全测试方法论,以及其核心功能、特征和优势;

    ● 典型的渗透测试所涉及的10 个阶段;

    ● 安全测试的道德准则。

    渗透测试可能是单独进行的一项工作,也可能是常规研发生命周期(例如,Microsoft SDLC)里 IT 安全风险管理的一个组成部分。产品的安全性并不完全取决于 IT 方面的技术因素,还会受到与该产品有关的最佳安全实践的影响。具体而言,增强产品安全性的工作涉及安全需求分析、风险分析、威胁建模、代码审查和运营安全。

    通常认为,渗透测试是安全评估最终的也是最具侵犯性的形式,它必须由符合资质的专业人士实施。在进行评估之前,有关人员可能了解也可能不了解目标的具体情况。渗透测试可用于评估所有的IT基础设施,包括应用程序、网络设备、操作系统、通信设备、物理安全和人类心理学。渗透测试的工作成果就是一份渗透测试报告。这种报告分为多个部分阐述在当前的目标系统里找到的安全弱点,并且会讨论可行的对抗措施和其他改进建议。充分应用渗透测试方法论,有助于测试人员在渗透测试的各个阶段深入理解并透彻分析当前存在的防御措施。

    2.1 渗透测试的种类

    虽然渗透测试各种各样,但是业内普遍将其划分为两类:白盒测试和黑盒测试。

    2.1.1 黑盒测试

    在进行黑盒测试时,安全审计员在不清楚被被测单位的内部技术构造的情况下,从外部评估网络基础设施的安全性。在渗透测试的各个阶段,黑盒测试借助真实世界的黑客技术,暴露出目标的安全问题,甚至可以揭露尚未被他人利用的安全弱点。渗透测试人员应能理解安全弱点,将之分类并按照风险级别(高、中、低)对其排序。通常来说,风险级别取决于相关弱点可能形成的危害的大小。老练的渗透测试专家应能确定可引发安全事故的所有攻击模式。当测试人员完成黑盒测试的所有测试工作之后,他们会把与测试对象安全状况有关的必要信息进行整理,并使用业务的语言描述这些被识别出来的风险,继而将之汇总为书面报告。黑盒测试的市场报价通常会高于白盒测试。

    2.1.2 白盒测试

    白盒测试的审计员可以获取被测单位的各种内部资料甚至不公开资料,所以渗透测试人员的视野更为开阔。若以白盒测试的方法评估安全漏洞,测试人员可以以最小的工作量达到最高的评估精确度。白盒测试从被测系统环境自身出发,全面消除内部安全问题,从而增加了从单位外部渗透系统的难度。黑盒测试起不到这样的作用。白盒测试所需的步骤数目与黑盒测试不相上下。另外,若能将白盒测试与常规的研发生命周期相结合,就可以在入侵者发现甚至利用安全弱点之前,尽可能最早地消除全部安全隐患。这使得白盒测试的时间、成本,以及发现、解决安全弱点的技术门槛都全面低于黑盒测试。

    2.2 脆弱性评估与渗透测试

    正确地理解和使用安全评估领域的技术术语十分必要。在您的职业生涯中,您可能时常会遇到那些不了解行业术语,却需要从这些专用名词里选一个进行采购的人。其实商业公司和非商业机构里大有这样的人在。至少您应该明白这些类型的测试各是什么。

    脆弱性评估通过分析企业资产面临威胁的情况和程度,评估内部和外部的安全控制的安全性。这种技术上的信息系统评估,不仅要揭露现有防范措施里存在的风险,而且要提出多重备选的补救策略,并将这些策略进行比较。内部的脆弱性评估可保证内部系统的安全性,而外部的脆弱性评估则用于验证边界防护(perimeter defenses)的有效性。无论进行内部脆弱性评估还是进行外部脆弱性评估,评估人员都会采用各种攻击模式严格测试网络资产的安全性,从而验证信息系统处理安全威胁的能力,进而确定应对措施的有效性。不同类型的脆弱性评估需要的测试流程、测试工具和自动化测试技术也不相同。这可以通过一体化的安全弱点管控(vulnerability management)平台来实现。现在的安全弱点管控平台带有可自动更新的漏洞数据库,能够测试不同类型的网络设备,而且不会影响配置管理和变更管理的完整性。

    脆弱性评估和渗透测试两者最大的区别就是:渗透测试不仅要识别目标的弱点,它还涉及在目标系统上进行漏洞利用、权限提升和访问维护。换句话说,脆弱性评估虽然可以充分发现系统里的缺陷,但是不会考虑去衡量这些缺陷对系统造成的危害。另外,相比脆弱性评估,渗透测试更倾向于入侵,会刻意使用各种技术手段利用安全漏洞;所以渗透测试可能对生产环境带来实际的破坏性影响。而脆弱性评估则是以非入侵性的方式,定性、定量地识别已知安全弱点。

    为何需要渗透测试?

    如果不能确定防火墙、IDS、文件完整性监控等风险减缓控制的实际效果,那么就应当进行渗透测试。虽然漏洞扫描(脆弱性评估)能够发现各个漏洞,但是渗透测试则会验证这些漏洞在实际环境里被利用的可能性。

    有些观点认为,这两种类型的安全评估重复性很高,只是同义词而已。这种观点绝对有误。合格的安全顾问会根据客户的商务需求,选择一种最合适的安全评估向顾客推荐,绝对不会把不同类型的安全评估混为一谈。然而,仔细核实安全评估项目的内容和做出最终决定确实是顾客的责任。

    渗透测试的价格比脆弱性评估的价格要高。

    2.3 安全测试方法论

    为满足安全评估的相应需求,人们已经总结出了多种开源方法论。无论被评估目标的规模有多大,复杂性有多高,只要应用这些安全评估的方法论,就可以策略性地完成各种时间要求苛刻、富有挑战性的安全评估任务。某些方法论专注于安全测试的技术方面,有些则关注管理领域。只有极少数的方法论能够同时兼顾技术因素和管理因素。在评估工作中实践这些方法论,基本上都是按部就班地执行各种测试,以精确地判断被测试系统的安全状况。

    本书再次向您推荐几种著名的安全评估方法论。本章将重点突出这些方法论的关键特征和优势,希望它们能够帮助您拓宽网络安全和应用安全评估的视野。

    ● 开源安全测试方法论

    ● 信息系统安全评估框架

    ● 开放式Web 应用安全项目

    ● Web 应用安全联合威胁分类

    ● 渗透测试执行标准

    上述这些测试框架和方法论,都能够指导安全人士针对客户需求制定最得当的策略。其中,前两个方法论所提供的通用原则和方法,几乎可以指导面向任何类型资产的安全测试。由OWASP(Open Web Application Security Project)推出的测试框架主要面向应用安全的安全评估。PTES(Penetration Testing Execution Standard)能够指导所有类型的渗透测试工作。然而需要注意的是,安全状态本身是一个持续变化的过程,而渗透测试只能够获取目标系统在被测试的那一时刻的安全状态。在测试的过程中,哪怕被测的信息系统发生了细微的变化,都可能影响安全测试的全局工作,从而导致最终的测试结果不正确。此外,单一的测试方法论并不一定能够涵盖风险评估工作的所有方面。而拟定适合目标网络和应用环境的最佳测试策略,确实是安全审计人员的职责。

    安全测试的方法论有很多。要选取最佳的指导理论,就需要综合考虑成本和效果的因素。所以,评估策略的筛选工作受到多种因素的制约。这些因素包括与目标系统有关的技术细节和各种资源、渗透人员的知识结构、业务目标以及法规问题。以业务的角度看,效果和成本控制至关重要。本文介绍的这几种方法论,在官方网站上都有非常正规的详细说明文件。在此,我们对它们进行简要总结。如需了解详细的工作流程,您需要亲自访问相关网站,仔细研究各种文件和实施细则。

    2.3.1 开源安全测试方法论(OSSTMM)

    开源安全测试方法论(Open Source Security Testing Methodology Manual,OSSTMM)(官方网站是http://www.isecom.org/research/osstmm.html)是由Pete Herzog 创建,继而由ISECOM发展的测试方法论。它是国际公认的安全测试和安全分析标准。很多企业正在他们的日常评估工作中应用这一标准。以技术的角度看,这一方法论把安全评估工作划分为 4 组:范围(scope)、信道(channel)、索引(index)和矢量(vector)。“范围”指代评估人员收集被测单位全部资产相关信息的工作。“信道”则是这些资产之间的通信方式和互动类型;包括物理方式、光学方式和其他方式的通信。每个信道都构成了一套独特的安全组件,都要在评估阶段进行测试和验证。这些组件包括物理安全、人类心理学、数据网络、无线通信介质和电信设施。所谓“索引”,泛指特定资产和相应ID的对应关系。例如,审计人员常常要明确MAC地址和IP地址的对应关系,就是为了整理一种索引。而“矢量”指的是审计人员访问和分析功能性资产的方式。以上几个部分,组成了全面评估被测IT运营环境的整个技术流程,被称为审计范畴(audit scope)。

    OSSTMM的方法论总结了多种形式的安全测试,并将它们划分为6个标准种类。

    ● 盲测(blind):事先不了解目标系统的任何情况的测试就是盲测。然而,在评估过程开始之前,被测单位会知道何时开始安全测试。道德黑客(Ethical hacking)和对抗竞赛(War Gaming)就是典型的盲测。因为盲测遵循了道德规范,事先通知被测单位,所以这种测试方法也被广泛接受。

    ● 双盲测试(double blind):在双盲测试中,审计人员事先不清楚目标系统的情况,被测单位事先也不会知道将有安全测试。黑盒审计和渗透测试都属于双盲测试。当前绝大多数的安全审计采用双盲测试方法。对于审计人员来说,选择能够胜任的最佳工具和最佳技术已经是一种考验了。

    ● 灰盒测试(grey box):在灰盒测试中,审计师仅了解被测系统有限的情况,被测单位也会知道审计开始和结束的时间。脆弱性评估就属于灰盒测试。

    ● 双灰盒测试(double grey box):双灰盒测试工作的方式类似于灰盒测试。只不过在双灰盒测试中,会给审计人员定义一个时限,而且这种测试不涉及信道测试和渗透矢量。白盒审计就属于双灰盒测试。

    ● 串联测试(tandem):在串联测试中,审计人员对目标系统只有最低限度的了解,而在测试开始前他们会通告被测单位。需要注意的是,串联测试会测试得比较彻底。水晶盒测试和内部审计都是串联测试的例子。

    ● 逆向测试(reversal):在逆向测试中,审计员充分了解目标系统;而被测单位将永远不会知道测试的时间或方式。

    OSSTMM推广的技术评估框架十分灵活。即使某个项目在逻辑上可分为3个连续的信道和5个安全组件,我们照样可以使用OSSTMM的框架评估其安全性。OSSTMM体系的测试方法,通过检查访问控制安全、流程安全、数据控制、物理位置、周界防护、安全意识水平、信任关系、反欺诈控制等诸多过程,全面评估被测单位的安全性。总体而言,这一理论强调测试目标和测试方法,注重在测试前、测试中、测试后应当采用的相应策略,而且介绍了解读和综合分析测试结果的方法。确切掌握目标系统当前的防护水平至关重要,有关数据十分珍贵。OSSTMM 引入了RAV(Risk Assessment Value,风险评估值)的概念,并通过它阐述了这一理论的很多理念。RAV 的基本功能是分析测试结果,进而基于三个因素(运营安全、损耗控制、局限程度)的标称值来计算安全的标称值。最后求得的这个标称值称为 RAV 得分。在引入 RAV 得分的概念之后,审计人员可以量化评估当前的安全状态,并可为企业安全的下一步目标设定里程碑。从商业的角度来看,RAV 有助于优化安全投资,并可助您选择更为有效的安全解决方案。

    主要特性与优势

    OSSTMM的主要特性与优势如下。

    ● OSSTMM 的方法可从本质上降低假阴性和假阳性的发生率。它推出的测量方法具有普遍的应用价值。

    ● 该架构适用于多种类型的安全测试,可用于渗透测试、白盒测试审计、漏洞评估等其他测试。

    ● 它能够确保每次评估应进行得全面彻底,还能保证评估过程的一致性、可测性、可靠性。

    ● 该方法本身可分为4个相对独立的阶段,即定义阶段、信息阶段、调节阶段和控制测试阶段。每一个阶段都会获取、评估和验证目标环境中的相关信息。

    ● RAV 的计算方法综合衡量了运营安全、损耗控制、局限程度的情况。它的计算结果即RAV得分,可代表目标系统当前的安全状况。

    ● 这种方法的评估报告均采用安全测试审计报告(STAR,Security TestAudit Report)模板。以这种格式书写的报告同时适合被测单位的管理层和技术层阅读,有助于他们共同理解测试目标、风险评估值(RAV)和每个阶段的测试结果。

    ● 该方法定期更新。OSSTMM 会符合安全测试、法规和法规问题的新变化。

    ● OSSTMM 与行业法规、企业政策,以及政府法规兼容。此外,官方认可的审计员都是直接从ISECOM(安全与开放式方法论研究协会)获取的资格认证。

    2.3.2 信息系统安全评估框架

    信息系统安全评估框架(Information Systems SecurityAssessment Framework,ISSAF) (www.oissg. org/issaf)是另外一种开放源代码的安全性测试和安全分析框架。为了解决安全评估工作的逻辑顺序问题,该框架已分为若干个领域(domain)。不同领域评估目标系统的不同部分,而且可以根据实际情况对每个领域进行相应调整。把这一架构与日常业务的生命周期相结合,可以充分满足企业安全测试的准确性、完整性、高效性的需求。ISSAF兼顾了安全测试的技术方面和管理方面。在技术方面,它有一整套关键的规则和程序,形成了一套完备的评估程序。在管理方面,它明确了在整个测试过程中应当遵循的管理要则和最佳实践。应当注意,ISSAF主张安全评估是一个过程,而不是一次审计。审计框架应当分为计划、评估、修复、评审以及维护阶段,应当有更为完善的标准。然而ISSAF具有灵活和高效的特点,是审计工作各个阶段的通用准则,可适用于所有企业结构。

    这一框架的交付报告分为业务活动、安全措施、目标系统中可能存在的安全弱点的完整清单。其评估过程注重分析被测单位最容易被利用的关键漏洞,侧重于以通过最短路径尽快完成测试任务。

    ISSAF 的技术评估基准十分全面,可用于测试各种技术和不同流程。不过,丰富的内容带来了一大副作用,即要跟上评估领域的技术变化速度,这一框架就需要频繁更新。相对而言,OSSTMM受技术更新影响的幅度略小。即使审计人员使用不同的工具和全新的技术,他们遵循的方法论却基本不变。虽然如此,但是ISSAF仍然号称是由最新的安全工具、最佳实践,以及补充安全评估计划的管理理念所组成的广泛框架。它也可以和OSSTMM或其他测试方法论一起使用,从而能够兼有各种方法的优点。

    主要特性与优势

    ISSAF的主要特性与优势如下。

    ● ISSAF 主要测试当前安全控制措施中的严重漏洞,所以它在保障系统安全方面的意义重大。

    ● 它关注信息安全范畴内的各个关键领域,涵盖了风险评估、业务结构和管理、控制评估、服务管理、安全策略的开发和常规的最佳实践。

    ● ISSAF 渗透测试方法论评估网络、系统或应用程序的安全性。应用该框架可以无阻碍地把精力重点放在特定技术上,如路由器、交换机、防火墙、入侵检测和防御系统、存储区域网络、虚拟专用网络、各种操作系统、Web 应用服务器、数据库等。

    ● 通过必要的控制和处理,它可以统一技术层和管理层这两方面人员对安全测试的理解。

    ● 它可帮助管理人员理解当前边界防御体系的现有风险,并可指出可能影响业务完整性的安全弱点,从而帮助人们主动地减少风险。

    可同时结合OSSTMM和ISSAF两种理论评估企业环境的安全状况。

    2.3.3 开放式Web应用程序安全项目

    开放式 Web应用程序安全项目(Open Web Application Security Project,OWASP)定期推出其top 10 project( 排名前十位的安全隐患防护守则)以提高公共对应用安全的认知意识。这个项目公开了编写安全程序所需遵循的各种原则和惯例。OWASP 的测试项目(https://www.owasp.org/index.php/owasp- Testing_Project)公布了一套非常实用的安全测试指南。您应当仔细阅读这部分内容,因为这个测试框架往往可以指导您的工作。

    OWASP 的Top 10 Project 总结了各种攻击矢量,按照各种隐患可能在技术上和业务上造成的危害,对影响应用安全的风险进行分类和排名。在评估应用程序安全时,这些排名前十的安全风险揭露了普遍存在于各种技术和平台的通用攻击方法。它还阐述了测试、验证和修补应用程序安全弱点的具体方法。尽管Top 10 Project揭示了安全领域的高风险问题,但是这10种风险也只是Web应用程序安全性问题的一部分而已。尽管如此,OWASP社区的很多指南仍然可以指导开发人员和安全审计人员有效地管理Web应用程序的安全。

    ● 测试指南:https://www.owasp.org/index.php/OWASP_Testing-Guide_v3 _Tab1e_of_Content

    ● 开发人员指南:https://www.owasp.org/index.php/Guide

    ● 代码审查指南:https://www.owasp.org/index.php/Category: OWASP_Code_Review_Project

    OWASP的Top 10 Project每年都会更新。如需获取详细信息,请访问这个项目的官方网站https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

    主要特性与优势

    OWASP的主要特性与优势如下。

    ● OWASP 推出了Web应用程序的十大安全风险的测试方法。应用这些方法,可使应用程序避免出现常见的安全缺陷,免受常见攻击的危害,进而巩固了应用程序的保密性、完整性和可用性。

    ● OWASP 社区研发出大量安全工具,这些工具可辅助进行自动或手动的Web 应用程序测试。Kali Linux 收录了其中较为著名的程序,如WebScarab、Wapiti、JBroFuzz和SQLiX等。

    ● 在网络基础设施的安全评估方面,OWASP 测试指南为您提供了特定技术的评估细则。举例来说,它的甲骨文(Oracle)的测试方法与 MySQL 的测试方法就各有针对性。该指南采用多种相互关联的方法评估各种技术,有助于审计人员因地制宜地制定测试方法。

    ● 它鼓励研发人员在研发周期的每个阶段进行有计划的安全测试。这能提高应用程序的健全性、安全性,并能减少程序中的错误。

    ● 它在业内的认可度和知名度屈指可数。若把排名前十位的安全隐患防护守则与其他Web应用程序安全评估标准结合使用,您可同时满足一个以上的安全标准。

    2.3.4 Web应用安全联合威胁分类

    只有彻底、严格的测试流程,才能发现应用程序的安全隐患,而这些测试流程完全可以纳入软件的开发生命周期。Web 应用安全联合威胁分类(Web Application Security Consortium Threat Classification,WASC-TC)是这样的一个评估Web 应用程序安全性的开放标准。与OWASP标准相似,它也从攻击和弱点两方面讨论安全问题,但这一标准以更为深入的方式解决安全隐患。要识别、验证应用程序所面临的各种威胁,就要遵循标准化的工作流程。WASC-TC可以迅速适用于各种技术环境,有着显著的易用性。整体上说,它能够帮助开发人员和安全审计人员以不同的视图了解Web应用程序面临的安全威胁。

    ● 枚举视图:枚举视图是分析Web 应用程序攻击手段和相应安全弱点的基础。它从定义、类型和多种编程平台的实例这几个角度,详细讨论了每种攻击手段和每个安全弱点。另外,所涉及的安全弱点和攻击手段都被分配了唯一的识别编号,以便于人们引用。目前,这个视图里总共有49个WASC-ID号码(1~49)。这些编号并不代表相应条目的危害程度,仅仅是为了方便引用而分配的编号。

    ● 开发视图:开发视图关联分析外部的攻击和程序内部的安全弱点,将开发人员的视野转向程序自身的漏洞。这一分析适用于开发周期的三个阶段,即设计、实现(编程)、部署阶段。如果在明确应用程序的需求时没有充分考虑安全方面要求,就会在研发周期的初期阶段引发漏洞,形成设计阶段的安全弱点。不安全的编程规则或不当的惯例产生会造成实现阶段的安全弱点。无论在应用程序、Web 服务器或是其他外部系统的配置过程中哪个部分出现差错,最终都会导致部属阶段的安全弱点。可见,这个视图以最佳安全实践为蓝本,提出了将安全保障措施融入到日常的研发生命周期的具体方法。

    ● 交叉引用视图:这个视图关联地分析了多种Web 应用安全标准。通过对该视图的引用,审计人员和开发团队能够把当前所使用的标准中的术语(标准条款)与其他标准的相应内容进行对照分析。如此一来,只需要较少的开销,就可以让一个项目同时符合多种不同的安全标准。因为不同的应用程序安全标准会从不同的角度评估应用程序的安全性,所以它们衡量同一的风险的评估指标也不尽相同。因此,要对不同安全标准进行差异性分析,才能够正确地计算安全风险及其严重程度。当前WASC-TC 中的攻击方法和薄弱环节,可以映射到OWASP 的Top 10 Project、Mitre通用缺陷列表(Common Weakness Enumeration,CWE)、Mitre 通用攻击模式列表和分类(Common Attack Pattern Enumeration and Classification,CAPEC)、SANS-CWE 排名前 25 的软件高危错误列表(SANS-CWE Top 25 list)。

    Mitre’s CWE 的官方网站是https://cwe.mitre.org/

    Mitre’s CAPEC 的官方网站是http://capec.mitre.org/

    SANS-CWE的排名前25的软件高危错误列表的发布网站是http://www.sans.org/top25-software-errors/

    如需详细了解 WASC-TC 及其评论,请访问官方网站:http://projects.webappsec.org/Threat-Classification

    主要特性与优势

    WASC-TC的主要特性与优势如下。

    ● WASC-TC 围绕常见攻击和常规弱点这一中心,深入讨论了 Web 应用程序运营系统的安全评估方法。

    ● 无论何种Web 应用程序平台,都可使用Kali Linux 的工具集验证、测试WASC-TC提出的常见攻击和常规弱点。

    ● 它提出了三种不同视图,即枚举视图、开发视图和交叉引用视图。枚举视图起到了基础数据库的作用,它列举了在 Web 应用中所有可能被发现的攻击方法和安全弱点。开发视图将这些攻击方法和安全弱点进行关联分析,整理成一系列漏洞,并根据它们在开发过程中的出现阶段进行分类。而开发阶段又可分为设计阶段、实现阶段和部署阶段。WASC-TC 标准的交叉引用视图用于对照、引用其他的应用程序安全标准。

    ● WASC-TC 标准已经得到了业界的广泛认可。在许多开源和商业解决方案里,特别是漏洞评估和管控产品中,都能看到WASC-TC的身影。

    ● WASC-TC 也可以和其他著名的应用安全标准兼容,例如OWASP 和SANS-CWE。

    2.4 渗透测试执行标准

    渗透测试执行标准(Penetration Testing Execution Standard,PTES)的先驱都是渗透测试行业的精英。这个标准由渗透测试7个阶段的标准组成,可在任意环境中进行富有成果的渗透测试。它的官方网站详细介绍了具体测试方法,有兴趣的读者可访问 http://www. pentest-standard.org/index.php/Main_Page

    根据这一标准,标准的渗透测试可以分为下述7个阶段:

    ● 事前互动;

    ● 情报收集;

    ● 威胁建模;

    ● 漏洞分析;

    ● 漏洞利用;

    ● 深度利用;

    ● 书面报告。

    PTES 的官方网站详细介绍了每个阶段的思维导图(mind maps)和组成步骤。这些内容有助于审计人员根据被测环境的测试要求,对PTES标准进行相应调整。只要在其官方网站上点击思维导图的构成节点,就可详细查看该节点的各个组成步骤。

    主要特性与优势

    PTES的主要特性与优势如下。

    ● 它是非常全面的渗透测试框架,涵盖了渗透测试的技术方面和其他重要的方面,如范围蔓延(scope creep)、报告,以及渗透测试人员保护自身的方法。

    ● 它介绍了多数测试任务的具体方法,可指导您准确测试目标系统的安全状态。

    ● 它汇聚了多名日行一“渗”的渗透测试专家的丰富经验。

    ● 它包含了最常用的以及很罕见的相关技术。

    ● 它浅显易懂,您可根据测试工作的需要对相应测试步骤进行调整。

    2.5 通用渗透测试框架

    Kali Linux 属于通用型操作系统,它配备有多种安全评估工具和渗透测试工具。在没有合适的测试理论指导的情况下冒然使用这些工具,可能会导致测试失败,测试结果可能无法让人满意。因此,从技术管理的角度来看,遵循正规的测试框架对安全测试极为重要。

    这一小节将通过黑盒测试的具体方法和白盒测试的通用测试方法介绍通用测试框架。它涵盖了典型的审计测试工作和渗透测试工作会涉及到的各个阶段。评估人员可以根据被测目标的具体情况对上述测试方法进行相应调整。这一方法论由一系列相关步骤所组成。要想成功完成安全评估项目,必须在测试的初始化阶段、测试进行阶段以及测试结束阶段全面遵循这些步骤。这些步骤包括:

    ● 范围界定;

    ● 信息收集;

    ● 目标识别;

    ● 服务枚举;

    ● 漏洞映射;

    ● 社会工程学;

    ● 漏洞利用;

    ● 提升权限;

    ● 访问维护;

    ● 文档报告。

    无论是进行白盒测试还是黑盒测试,选择和使用测试步骤都是测试人员的责任。在测试开始前,测试人员需要根据目标系统的实际环境和已掌握的关于目标系统的情况,制定最佳的测试策略。下文将会介绍每一个测试阶段,包括它们的简要描述、定义和可能适用的应用程序。虽然这种通用测试方法论可以配合其他的方法论同时使用,但是它只是一种指导建议,而不是全能的渗透测试解决方案。

    2.5.1 范围界定

    在开始技术性安全评估之前,务必要观察、研究目标环境的被测范围。同时还要了解,这个范围牵扯到多少个单位,是单个单位还是多个单位会参与到安全评估的工作中来。在范围界定阶段,需要考虑的典型因素如下。

    ● 测试对象是什么?

    ● 应当采取何种测试方法?

    ● 有哪些在测试过程中需要满足的条件?

    ● 哪些因素可能会限制测试执行的过程?

    ● 需要多久才能完成测试?

    ● 此次测试应当达成什么任务目标?

    审计人员只有确切理解被评估系统所使用的技术,理解其基本功能,以及相关技术与网络之间的相互影响,才能成功达成渗透测试的目标。因此,无论是进行什么类型的安全评估项目,审计人员的知识结构都将起着至关重要的作用。

    2.5.2 信息收集

    在划定了测试范围之后,就需要进入信息收集阶段。在这个阶段,渗透测试人员需要使用各种公开资源尽可能地获取测试目标的相关信息。他们从互联网上搜集信息的互联网渠道主要有:

    ● 论坛;

    ● 公告板;

    ● 新闻组;

    ● 媒体文章;

    ● 博客;

    ● 社交网络;

    ● 其他商业或非商业性的网站。

    此外,他们也可借助各种搜索引擎中获取相关数据,例如谷歌、雅虎、MSN必应、百度等。进一步说,审计人员可以使用Kali Linux 收录的各种工具在测试目标的网络系统里挖掘信息。这些运用漏洞数据挖掘技术的工具能够收集可观信息,包括DNS服务器、路由关系、whois数据库、电子邮件地址、电话号码、个人信息以及用户账户。收集到的信息越多,渗透测试成功的概率就越高。

    2.5.3 目标识别

    这个阶段的主要任务是识别目标的网络状态、操作系统和网络架构。该阶段工作旨在完整地展现目标网络里各种联网设备或技术的完整关系,以帮助测试人员在接下来的工作里枚举目标网络的各种服务。Kali Linux 提供的一系列先进的网络工具,可以轻松探测到联网主机,识别这些主机运行的操作系统,并根据每个设备在网络系统中的不同角色对它们进行归类。这些工具通常采用了基于上层网络协议的主动和被动的检测技术。它们能够通过不同的方式巧妙地利用各种协议获取许多有用的信息,比如操作系统指纹等。

    2.5.4 服务枚举

    这一阶段会根据前面各个阶段的成果,进一步找出目标系统中所有开放的端口。一旦找到了所有开放的端口,就可以通过这些端口来列出目标系统上运行的服务。有很多扫描端口的技术,如全开(full-open)扫描、半开(half-open)扫描、隐蔽式(stealth)扫描等。这些技术都可用来检测端口的开放情况,甚至可以扫描处于防火墙或者入侵检测系统保护下的主机。主机上开放的端口都有相应的服务程序,对这些信息进行深度分析之后,可进一步发掘目标网络基础设施中可能存在的漏洞。因此,这个阶段为其后的测试工作打下了基础,有助于测试人员继而发现各种网络设备上可能会造成严重危害的安全漏洞。Kali Linux收录的部分自动化工具可以辅助审计人员完成这一阶段的目标。

    2.5.5 漏洞映射

    至此为止,我们已经充分收集了目标网络的各种信息。接下来,我们就可以根据已经发现的开放端口和服务程序,查找、分析目标系统中存在的漏洞。Kali Linux 系统中提供的一系列自动化的网络和应用漏洞评估工具可以担任完成这个阶段的任务。当然,人工(手动)完成这些任务未尝不可,只是人工操作极为耗时,而且需要有关人员拥有专家级的知识。但是,如果能够将自动和手动这两种不同的测试方法结合起来,审计人员对目标系统的认知就会更为清晰、透彻,并能够仔细地检查任何已知和未知的漏洞。否则,被遗漏的漏洞将会一直残留在目标网络系统里。

    2.5.6 社会工程学

    如果目标网络没有直接的入口,欺骗的艺术将起到抛砖引玉的重要作用。对目标组织中的人员进行定向攻击,很有可能帮助我们找到渗透目标系统的入口。例如,诱使用户运行会安装后门的恶意程序,就可能为审计人员的渗透工作形成突破。社会工程学渗透分为多种不同实现形式。伪装成网络管理员,通过电话要求用户提供自己的账户信息;发送钓鱼邮件来劫持用户的银行账户;甚至是诱使某人出现在某个地点——这些都属于社会工程学攻击。在社会工程学中,达成同一既定目标的实现方式应有尽有。需要注意的是,在对目标实施欺骗以达成渗透目标之前,多数情况下需要长时间研究目标人员的心理。另外,在开展这个阶段的工作之前,您需要事先研究国内的法律是否有关于社会工程学的相关条款。

    2.5.7 漏洞利用

    在仔细检查和发现目标系统中的漏洞之后,就可以使用已有的漏洞利用程序对目标系统进行渗透。某些情况下不得不对漏洞利用程序(exploit)进行额外的研究和修改,否则它可能就无法正常工作。虽然这听起来就很麻烦,但是先进的漏洞利用(修改)工具可使这项工作容易得多,而且Kali Linux 已经收录了这种工具。此外,审计人员可以把客户端漏洞利用程序和社会工程学进行结合,进而控制目标系统。这个阶段的主要任务是控制目标系统。整个流程可以分为3步,涉及攻击前、攻击、攻击后的相关行动。

    2.5.8 提升权限

    获取目标系统的控制权是渗透成功的标志。接下来,审计人员就可以依据其所拥有的访问权限,在被测系统中自由发挥。审计人员也可以使用适用于目标系统的本地漏洞来提升自己的权限。只要他们能够在目标系统上运行提权漏洞利用程序,就可以获得主机上的超级用户权限或者系统级权限。审计人员还可以以该主机为跳板,进一步攻击局域网络。根据之前对渗透范围的界定,审计人员接下来会开展的攻击可能是受限制的,也可能是不受限的。而后,他们很有可能以各种方式获得与被控制系统有关的更多信息。具体的说,他们可能使用嗅探手段截获网络数据包,破解各种服务的密码,在局域网络中使用网络欺骗手段。所以说,提升权限的最终目的是获得目标系统的最高访问权限。

    2.5.9 访问维护

    多数情况下,审计人员需要在一段时间内维护他们对目标系统的访问权限。例如,在演示越权访问目标系统的时候,安装后门将节省重新渗透目标系统所耗费的大量时间。这些情况下,访问维护将节约获取目标系统访问权限所需要的时间、花费和资源。审计人员可以通过一些秘密的通信隧道,在既定时间内维持对目标的访问权限。这些隧道往往基于特定协议、代理或者点对点通信方法的后门程序。这种对系统的访问方法可以清楚地展示,入侵人员在目标系统实施攻击时隐匿行踪的具体方法。

    2.5.10 文档报告

    在渗透测试的最后一个环节里,审计人员要记录、报告并现场演示那些已经识别、验证和利用了的安全漏洞。被测单位的管理和技术团队会检查渗透时使用的方法,并会根据这些文档修补所有存在的安全漏洞。所以从道德角度来看,文档报告的工作十分重要。为了帮助惯例人员和技术人员共同理解、分析当前IT基础架构中的薄弱环节,可能需要给不同的部门撰写不同措辞的书面报告。此外,这些报告还可以用来获取和比较渗透测试前后目标系统的完整性。

    2.6 道德准则

    专业的、道德的、经过授权的安全测试服务,离不开由事先约定的规则所组成的安全测试道德准则。这些准则约定了安全测试服务的服务方式、安全实施的测试方法、合同和谈判所约定的法律条款、测试的范围、测试的准备、测试的流程,以及报告结构的一致性。要顾全上述因素,就要仔细地考察、设计在整个测试过程中都要遵循的正规的操作方法和相关流程。下面将介绍一些常见的到的准则。

    ● 审计人员不得在和客户达成正式协议之前对目标系统进行任何形式的渗透测试。这种不道德的营销方法有可能破坏客户的正常业务。在某些国家或地区,这种行为甚至可能是违法行为。

    ● 在测试过程中,在没有得到客户明确许可的情况下,测试人员不得进行超出测试范围越过已约定范畴的安全测试。

    ● 具有法律效力的正式合同可帮助测试人员避免承担不必要的法律责任。正式合同将会约定哪些渗透行为属于免责范围。这份合同必须清楚地说明测试的条款和条件、紧急联系信息、工作任务声明以及任何明显的利益冲突。

    ● 测试人员应当遵守测试计划所明确的安全评估的时间期限。渗透测试的时间应当避开正常生产业务的时间段,以避免造成相互影响。

    ● 测试人员应当遵循在测试流程里约定的必要步骤。这些规则以技术和管理不同角度,通过内部环境和相关人员来制约测试的流程。

    ● 在范围界定阶段,应当在合同书里明确说明安全评估业务涉及到的所有实体,以及他们在安全评估的过程中受到哪些制约。

    ● 测试结果和书面报告必须清晰,其顺序必须一致。报告中提及的所有已知的和未知的漏洞,必须以安全保密的方式递交给有权查看报告的相关责任人。

    2.7 本章总结

    本章详细介绍了多种渗透测试方法论,以及渗透测试的基本术语、相关类型,还有这些术语和业内其他术语之间的区别。本章的重点内容如下。

    ● 渗透测试可分为黑盒测试和白盒测试。黑盒测试也称为外部测试,在黑盒测试中,审计人员事先不了解目标系统的内部结构或任何技术。白盒测试也叫内部测试,在白盒测试中,审计人员了解目标系统的全部细节。结合黑盒测试和白盒测试的测试类型,称做灰盒测试。

    ● 脆弱性评估和渗透测试最基本的不同点在于:脆弱性评估旨在找出目标系统中存在的安全漏洞,并不会去衡量这些漏洞可能造成的相应危害;而渗透测试会进一步利用这些漏洞,发起实质性攻击以评估它们可能造成的安全问题。

    ● 虽然业内有很多安全测试方面的方法论,但是在评测网络系统或应用程序安全性方面,只有极少数的方法论才能够具有阶段性的循序渐进的指导意义。本章介绍了5个非常有名的开源安全评估方法论,突出了它们的技术功能、主要特征和优势。这5 个方法论分别是开源安全测试方法论( OSSTMM )、信息系统安全评估框架(ISSAF)、开放式Web应用程序安全项目(OWASP),渗透测试执行标准(PTES)以及Web 应用安全联合威胁分类 (WASC-TC)。

    ● 本章还介绍了一个简单的结构化的通用测试方法论。它由安全测试行业标准方法归纳而来,分为多个标准化测试阶段。这些阶段分为:范围界定、信息收集、目标识别、服务枚举、漏洞映射、社会工程学、漏洞利用、提升权限、访问维护、文档报告。

    ● 最后,本章讨论了在整个安全评估过程中必须遵守的渗透测试道德准则。在安全评估的各个阶段落实有关道德准则,可以切实保障审计人员和商业实体双方的各自利益。

    在接到一个渗透测试任务时,如何从客户那里获取相关信息,又如何对信息进行管理?请参见下一章。

    展开全文
  • 等价类划分测试方法 在很多情况下,很多人想到的测试方法是穷举测试,穷举测试是最全面的测试,但是数据量很大的情况下不太现实,测试效率太低 实现目标:用最少的测试数据,比较高的效率,以达到最好的测试质量 ...
  • 软件测试方法

    万次阅读 2019-04-16 14:49:22
    ...软件测试方法 编辑讨论 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。 用户界面...
  • 软件测试之软件测试方法

    千次阅读 2019-06-15 15:50:40
    软件测试过程中,最主要的就是要掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。 软件测试方法 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样...
  • 白盒测试方法

    千次阅读 2019-08-12 19:27:47
    白盒测试法检查程序内部逻辑结构,对所有逻辑路径进行测试,是一种穷举路径的测试方法。但即使每条路径都测试过了,仍然可能存在错误。因为: 穷举路径测试无法检查出程序本身是否违反了设计规范,即程序是否是一个...
  • 性能测试方法

    千次阅读 2019-04-26 09:53:39
    备注:以下是常用的测试方法,当然我们还是要根据项目的需要而定,不同项目,不同业务,压测方法不同。比如长连接和短链接不同,协议不同,测试方法不同,大家要根据情况而定。 负载测试:通过在被测系统上不断加压...
  • 测试评审方法---测试方法

    千次阅读 2018-09-19 20:59:11
     本章重点要求读者掌握测试方法、评审方法、验证与确认、测试自动化、面向对象的测试等5 个方面的知识。  1 测试方法   在介绍软件测试之前,首先应该明确“错误”(error)和“缺陷”...
  • 软件测试方法一般分为两种:白盒测试与黑盒测试。其中,白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试,着重于程序的内部结构及算法,通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动...
  • 基准测试方法

    千次阅读 2018-06-25 22:51:46
    在讲解基准测试方法之前,先来看下如何避免一些常见的错误。 1.使用真实数据的子集而不是全集。例如应用需要处理几百GB的数据,但测试只有1GB数据;或者只是用当前数据进行测试,却希望模拟...
  • 黑盒测试用例测试方法

    万次阅读 2018-05-25 17:55:21
    黑盒测试用例设计方法一、等价类划分法 等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集合。在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的。 等价类划分有效等价类和无效等价类...
  • 测试方法之Java白盒测试(一)

    千次阅读 2019-12-20 22:13:53
    说明:该篇博客是博主一字一码编写的,...一、测试方法的分类 静态测试方法 动态测试方法 1.静态测试方法 不执行程序的测试方法。 主要用于测试文档和代码(文档)。 2.动态测试方法 通过运行程序来...
  • IDEA自动生成测试类以及测试方法

    千次阅读 2020-04-27 21:15:37
    IDEA自动生成测试类以及测试方法 把光标移至需要生成测试类的类后面,右击Go To → Test 点击Create New Test 讲Testing library设置为JUnit4,勾选上你需要生成的测试方法,再点击ok (如果设置为JUnit5,则...
  • 软件测试方法与测试策略

    千次阅读 2017-12-30 23:45:59
    测试方法:是指解决问题的技术手段或工具的集合。 测试策略:是指如何选择和运用方法来解决具体问题。策略定义了: * 要使用的测试方法和工具 * 测试要完成测试和测试成功的评价标准。如测试用例通过率95%,表示...
  • 白盒测试是测试人员常用的一种测试方法,越来越受到测试工程师的重视。白盒测试并不是简单的按照代码测试用例而走,需要根据不同的测试需求,结合不同的测试对象,使用适合的方法进行测试。本文介绍六种白盒测试方法...
  • 黑盒测试方法

    万次阅读 2018-06-07 16:46:04
    黑盒测试方法 边界值分析 等价类划分 决策表 因果图 一 边界值分析方法 1 边界值分析 1.1 边界值分析原理 边界值分析关注的是输入空间的边界,以标识测试用例。边界值测试背后的基本原理是错误更可能...
  • 软件测试方法分类

    千次阅读 2019-06-02 14:59:09
    软件测试方法种类繁多,有白盒测试、黑盒测试、静态测试、动态测试、集成测试等等,记忆起来容易混乱,傻傻分不清楚,如果把软件测试方法进行分类, 就会清晰很多。现在te...
  • 功能测试方法

    千次阅读 2013-08-01 16:03:06
    功能测试主要采用黑盒测试方法,结合测试内容对功能进行测试,同时在测试过程中对用户需求、设计文档和使用手册进行检查。测试方法主要根据测试对象的不同灵活进行选择。 功能测试主要分为功能模块测试和业务流程...
  • 白盒测试主要包含如下测试方法: 1.语句覆盖 语句覆盖要求必须编写足够多的测试用例,使得每一个可执行的语句都至少被执行一次,语句覆盖常常被称为“最弱的覆盖”,因为它只考虑了可执行语句,但是无法测试隐式...
  • 测试方法】概率测试

    千次阅读 2018-07-20 17:59:52
    测试方法】概率测试 时间:20180720 有关概率测试: 方法1:将配置表调成0和1,0是一定不会有,1是一定会掉落。例如掉落宝箱A,B,C三种,在其他条件满足的前提下,设A权重0,B权重1,假设掉落A,B两个物品,无论...
  • dubbo接口测试方法

    千次阅读 2018-08-10 18:45:43
    dubbo接口测试方法一 dubbo接口测试方法二 备注 dubbo接口测试方法一 测试前准备 git clone https://github.com/goghcrow/dubbo_ab.git cd dubbo_ab make 测试例子一: ./dubbo -h10.9.58.51 -...
  • APP功耗测试方法

    万次阅读 2018-04-26 23:27:55
    功耗测试可以基于硬件测试方法(第三方精密仪器)和基于软件测评方法。下面就两种测试方法进行阐述:一、为什么要进行耗电量测试1、app耗电量测试是用户非常关注的一个方面,如果一些app设计不好或者代码有缺陷,就...
  • 大数据测试方法

    万次阅读 多人点赞 2015-11-03 15:41:12
    一.功能性测试   大数据功能主要涉及系统实现面向大数据分析应用的POSIX API,包括文件读取与...功能测试工作量大,应该重点考虑应用自动化测试方法进行,同时结合手动测试补充,自动化工具推荐ltp,fstest和locktest
  • (1)白盒测试:又称为结构测试或逻辑驱动测试,是一种按照程序内部逻辑结构和编码结构,设计测试数据并完成测试的一种测试方法。 (2)黑盒测试:又称为数据驱动测试,把测试对象当做看不见的黑盒,在完全不考虑...
  • android性能测试方法

    千次阅读 热门讨论 2017-12-20 17:39:46
    【Android应用】性能测试方法 前言 Android设备的性能测试涉及面较广,且机型较多,所以Android设备的性能测试先天就是比较复杂的。此文力图以最简洁、最直接的方式阐述Android应用性能测试方法,同时也会...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 251,435
精华内容 100,574
关键字:

测试方法