喜欢是淡淡的爱,爱是深深的喜欢!!

发布新日志

  • 怎么做json接口api的测试

    2017-06-03 16:02:39

     客户端joson格式接口aip测试
    接口通讯分为get和post请求两种,分享一个如何进行api接口的测试
    1、chrome浏览器输入http://apizza.cc/ 或者添加扩展程序
    2、进入创建一个项目

    举例说明:
    开发提供接口文档,跟进接口文档进行测试地址拼接以及测试用例设计
    如接口文档:

    如psot请求

    获取应答

    如GET请求


    获取应答


    可以根据相关情况设计测试用例进行接口API的测试。




  • 测试人员的核心价值(转)

    2012-10-10 16:53:59

    既然是“核心价值”,就应该能用一句话说清楚。关于软件测试的核心价值是什么,各种观点争论了很久,似乎很难得出一个明确的结论。这里有个很重要的原因,就是我们都深陷在测试工作的细节里面,没办法看清自己的位置和价值。不识庐山真面目,只缘身在此山中。

    要想搞清楚这个问题,我们必须走出围城来进行分析,如果把软件测试看成一种服务,那么从客户的视角来评判,最合适不过了。下面讲一件真实的事情。

    有一次我回家跟老友一起吃饭,聊起最近的工作。老友的单位是一家大企业,几个月前委托一家软件开发公司,开发了一套很大的企业管理软件。现在软件已经开发完成,进入了验收阶段。现在问题来了,负责验收软件的是信管部,部门老大非常担心软件的质量,希望能在验收签字前,把软件的严重质量问题都找出来,可是又不知道该从哪下手,如果能有一个权威的软件评测机构,对软件进行专业的测试,就最好了。

    “你们淘宝的软件测试,应该做的很专业吧,能不能帮我们来测试一下这个软件?你们接这种业务么?”老友提出这个问题。

    虽然淘宝测试现在还没有这种外接服务,不过这是一个难得的,饶有趣味的话题。

    “那你想要我们来测试哪些东西呢?哪些地方最担心?”

    “主要是性能吧,如果全公司人一起来用,不知道会不会出问题。还有就是数据的安全方面,公司的重要数据一定要绝对安全,不能被挖走。”

    “那软件的功能呢,功能需不需要我们来测一下?”

    “功能就不用了,我让我们部门的人来点点就行了。”

    听到这话我有点觉得不爽,不过想想倒也没必要跟老友去争辩这个问题,其实这确实是很多人对软件测试的看法。后来这个话题被岔开,没有继续谈下去了。

    所以下面的谈话并没有真实发生,是我用推理的方式,把讨论继续了下去,非常有趣。

    “功能测试并不是随便点点这么简单,淘宝的测试非常专业的,因为我们...”

    大家注意,精彩的地方到了,当我说出一个原因,并且能让老友信服,那就说明,这就是软件测试的核心价值了。

    “...我们的工程师对需求理解得很透彻,对业务很精通。”

    “我们部门的人对需求也很清楚的,因为他们就是最终的用户。”在平时的项目里我们也发现,无论需求分析做得多细致,软件交付以后,用户总能提出很多问题和改进意见,这是正常的,大可不必因此责怪测试工程师,因为没有人比用户更了解需求。最重要的是,不要让用户发现既严重又初级的Bug。

    “...我们编写的测试用例、文档非常专业非常完整,能够保证测试的质量。”

    “很好啊,你们很专业,不过这是你们内部的工作方式,我不是很关注的。”这里并不是否定测试文档的作用,只不过测试文档是测试团队的过程产物,无法直接给用户带来价值。

    “...我们对软件的架构设计非常了解,可以提前发现软件设计中的重要缺陷,避免返工。”

    “嗯,这个非常好,不过现在他们已经开发完了,要是在他们编码之前,请你们来对设计方案把把关,就好了。”用户非常希望能控制软件开发的全过程,而软件设计是最重要的里程碑,设计是否合格,直接影响后面的工作。

    “...我们能看懂代码,找出代码里的问题,不仅如此,我们还能修复Bug。”

    “好是好,不过代码量那么多,你们需要多少人来做啊?至于修复Bug,还是让他们自己改吧,不然我花那么多钱请他们干吗?”

    “...我们现在用的最好的测试管理工具,还有最好的自动化测试工具,可以把测试完全自动化。”

    “挺好,不过我还是担心需要的资源太多,自动化测试是挺好,你说说具体好在哪里呢?如果比手工测试成本低,就行。”同样的,用户对我们用什么方式测试并不特别关注,成本才是关键。

    “...我们的工程师工作效率很高,测试速度非常快,比你们部门的人要快50%。”

    “厉害!不过我们这里的薪水都比较低的,你们都是高薪IT,人月成本这么高,如果测的结果差不多,还是我自己找人来做吧。”

    “...我们的工程师都是专业人员,你的人只能发现一些表面的Bug,而我们能找出隐藏很深,并且很严重的Bug,这些Bug提早发现,能减少很多损失。”

    “有道理,其实我也担心他们这样点点,有些深层次问题发现不了,要是上线一段时间以后,大家才发现,那改都来不及了。”

    好了,这段虚拟的对话就到此为止,下面我们来做一些分析。先看一下最开始提到的性能测试和安全测试,这两个测试类型有一定的技术壁垒,因此性能和安全的Bug,不是每个人随便就能发现的。另外虚拟对话中提到,发现软件设计方案中的问题,也非常有难度。而功能测试的门槛相对较低,即使没受过训练,一般人也能发现一些初级的Bug,这让很多人产生一个错觉:“一般人”都能做功能测试。

    要证明这个错觉不成立,其实也挺容易,那就是看测试人员所发现的Bug,与“一般人”有哪些不同。如果找不到明显的不同,那错觉就变成了现实,如果测试人员没发现的Bug,让一般人或者用户发现,那就更杯具了。由此我们推理出测试的核心价值:

    能发现一般人发现不了的Bug!

    这句话看起来非常简单朴实,但是包含了很多因素。目前淘宝测试团队所设定的金Bug大奖(Gold Bug Award),就是为了鼓励测试工程师体现这一核心价值。

    有的测试工程师,由于项目时间太紧,开发匆忙赶出的代码质量又不合格,所以大部分时间都纠缠在初级的Bug里面,根本没时间、没精力去关注深层次Bug,虽然做的很辛苦,也做了很多项目,但是成长很慢,原因就在这里。

    要解决这个问题,测试工程师一方面要加强对开发技术的学习,了解软件程序的内部结构,为发现深层Bug创造必要条件;另一方面,要想办法推动开发提高代码质量,让自己从初级Bug里解脱出来,为自己赢得更多的时间,来寻找深层Bug,并且总结发现Bug的技巧和经验。

    到这里我们对测试核心价值的讨论可以告一段落了,软件测试要体现核心价值,自说自话是没有意义的,只有把测试作为一种服务提供给客户,让客户来评判,测试才能发展得更好。现在淘宝测试团队也专门成立了TAAS团队(Testing As A Service),在测试服务化上进一步探索。

  • 测试基本教程

    2011-12-16 18:16:47

  • (转)翻页功能测试用例设计(详细)

    2011-12-16 18:09:23

    翻页功能我们常碰到的一般有以下几个功能:

      1、首页、上一页、下一页、尾页。
      2、总页数,当前页数
      3、指定跳转页
      4、指定每页显示条数

      当然,有一些是少于多少页,全部以数字的形式显示,多于多少页后,才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。

      对于1翻页链接或按钮的测试,主要要检查的测试点有:

      1、有无数据时控件的显示情况
      2、在首页时,首页和上一页是否能点击
      3、在尾页时,下一页和尾页是否能点击
      4、在非首页和非尾页时,四个按钮功能是否正确
      5、翻页后,列表中的记录是否仍按照指定的排序列进行了排序

      对于2总页数,当前页数,主要要检查的测试点有:

      1、总页数是否等于总的记录数/指定每页条数
      2、当前页数是否正确

      对于3指定跳转页,主要要检查的测试点有:

      1、是否能正常跳转到指定的页数
      2、输入的跳转页数非法时的处理

      对于4指定每页显示条数,主要要检查的测试点有:

      1、是否有默认的指定每页显示条数
      2、指定每页的条数后,列表显示的记录数,页数是否正确
      3、输入的每页条数非法时的处理

      分析完上面的测试点,应该可以进行用例的设计了。

      step 1: 列表无记录
      expect: 1、四个翻页控件变灰不可点击
      2、列表有相应的无数据信息提示
      3、不可指定页数
      4、不可指定跳转页
      5、总页数显示为0
      6、当前页数显示为0

      step 2: 列表的记录数<=指定的每页显示条数
      expect: 1、四个翻页控件变灰不可点击
      2、总页数显示为1
      3、当前页数显示为1

      step 3: 列表的记录数>指定的每页显示条数
      expect: 1、默认在首页,当前页数为1
      2、列表的数据按照指定的排序列正确排序
      3、记录数与数据库相符
      4、总页数=记录数/指定的每页显示条数

      step 4: 列表的记录数>指定的每页显示条数,在首页
      expect: 1、首页变灰不可点击
      2、上一页变灰不可点击
      3、下一页可点击,从(每页指定条数+1)条记录开始显示,当前页数+1
      4、尾页可点击,显示最后页的记录

      step 5: 列表的记录数>指定的每页显示条数,在中间的某页
      expect: 1、首页可点击,显示1到每页指定条数的记录
      2、上一页可点击,显示上一页的记录
      3、下一页可点击,从后一页的记录
      4、尾页可点击,显示最后页的记录
      5、列表的数据按照指定的排序列正确排序
      6、当前页数为所在页

      step 6:列表的记录数>指定的每页显示条数,在尾页
      expect: 1、首页可点击,显示1到每页指定条数的记录
      2、上一页可点击,显示上一页的记录
      3、下一页变灰不可点击
      4、尾页变灰不可点击
      5、列表的数据按照指定的排序列正确排序
      6、当前页数为最后一页的页数

      step 7:输入每页显示条数为正整数
      expect: 1、每页显示条数更新成指定的条数
      2、超过指定的条数的记录分页显示
      3、总页数更新成列表的记录数/每页显示条数

      step 8:输入每页显示条数为0
      expect: 1、提示“每页显示条数必须为大于1的整数”
      2、提示后每页显示条数恢复为上次生效的条数

      step 9:输入每页显示条数为负数
      expect: 1、提示每页显示条数必须为大于1的整数
      2、提示后每页显示条数恢复为上次生效的条数

      step 10:输入每页显示条数长度超过数据库指定的长度<<<maxlen>>>
      expect: 1、提示每页显示条数不能超过<<<maxlen>>>位
      2、提示后每页显示条数恢复为上次生效的条数

      step 11:输入每页显示条数为字符串,如中文翻页数
      expect: 1、提示每页显示条数必须为大于1的整数
      2、提示后每页显示条数恢复为上次生效的条数

      step 12:输入每页显示条数为特殊字符,如%
      expect: 1、提示每页显示条数必须为大于1的整数
      2、提示后每页显示条数恢复为上次生效的条数

      step 13:输入每页显示条数为html字符串,如<br>
      expect: 1、提示每页显示条数必须为大于1的整数
      2、提示后每页显示条数恢复为上次生效的条数

      step 14:输入跳转的页数为存在的页数
      expect: 1、正确跳转到指定的页数

      step 15:输入跳转的页数不存在或非法值
      expect: 1、跳转的页数值置为1,显示第一页的数据

      以上的用例是将总页数,当前页数都揉进了翻页控件的测试用例中了。

  • 测试的基本概念(共享)

    2010-12-16 16:57:55

    测试的基本概念(共享)
  • (转)关于LoadRunner的迭代

    2010-12-13 09:50:20

    通过用lr做负载压力测试过程发现,如果设定不同的action迭代次数,每次得出的结果是不同的,曲线的表现形式也是不同的。这点就使我们会感觉困惑,为什么要设置action的迭代次数?以及对于不同的应用系统应该怎样设置迭代次数呢?

    首先你要理解性能测试是在干什么?

    性能测试是模拟系统一段时间内真实的压力情况,以考察系统的性能。

    再看怎么模拟系统真实的压力情况?比如在半个小时内,用户都在进行登录操作,且平均分布在这半个小时内。我们要做的是什么?模拟这半个小时用户的行为。怎么模拟?估算出同时操作的人数,并用LoadRunner不断的发送登录请求,这就是我们为什么要迭代。

    至于迭代次数,只要能够模拟出真实情况,多少次都无所谓,不过10次8次估计是模拟不出来。迭代次数至少要保证压力达到一个稳定值后再运行一段时间,这样我们得到的数据才是有效的。所以我们除非是特别要求,一般不用迭代次数,而是用运行时间。

    1,迭代和并发,是完全不同的概念。没有什么关系。

    比如,一个用户迭代十次,还是一个用户的压力。

    10个用户执行一次,就是10个用户的压力。10个用户迭代10次,还是10个用户的压力。但他们都和参数化的数据有关系(也要看参数化是如何设置的,以及系统如何判断提交值的)。

    2,你要是想知道,LR是如何实现迭代和并发:

    说一个比较容易理解的层面:迭代就是不停的反复调用同一脚本,反复执行,注意,对1个用户执行10次来说,只会分配一块内存。10个用户执行一次,是调用同一脚本10次,会分配10块内存。LR调用脚本,编译后,运行,按脚本发送数据。

    比如:web_url这样的函数,执行就会发HTTP request。

    如果你还想知道更细节的进程和函数的实现,只能侧面验证(具体方法看各人的能力和擅长),因为我们都不是LR的开发者。

    3,太显然的问题了,参数化时选择每次出现唯一,只要参数够用就OK,不够用,就设置相应的规则。

    action在场景运行中iteration只对其起作用,对vuser_init和vuser_end都不起作用,action是一个可以被重复使用的最小单位其实你可以将所有脚本录制到一个action里,只是不方便管理罢了。

    举个最简单的例子,像lr自带的例子——订票系统,你如果把所有脚本都录制到一个action里,那回放的时候,每个用户登录就只能买一张票,而如果想一个用户买多张票的话,这样就行不通了。那你就要设多个action,并把登录和结束各录制在一个action里,把买票录到一个action中,这样,将买票的action迭代多次,而用户登录和结束只运行一次,这不就模拟了现实中的情况了吗?

    其实LoadRunner 是以客户端的角度来定义“响应时间”的,当客户端请求发出去后, LoadRunner 就开始计算响应时间,一直到它收到服务器端的响应。这个时候问题就产生了:如果此时的服务器端的排队队列已满,服务器资源正处于忙碌的状态,那么该请求会驻留在服务器的线程中,换句话说,这个新产生的请求并不会对服务器端产生真正的负载,但很遗憾的是,该请求的计时器已经启动了,因此我们很容易就可以预见到,这个请求的响应时间会变得很长,甚至可能长到使得该请求由于超时而失败。等到测试结束后,我们查看一下结果,就会发现这样一个很不幸的现象:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,而这个时候的平均响应时间,其实也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果,设置步长则可以缓解这一情况,这样,应该试试设置pacing,再运行看看情况。

  • tomcat与WEB测试

    2010-12-10 10:36:58

    tomcat与WEB测试.pdf

    共享

  • 敏捷宣言遵循的原则

    2010-12-09 10:13:43

      n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
      n 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
      n 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
      n 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
      n 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
      n 在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
      n 工作的软件是首要的进度度量标准。
      n 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
      n 不断地关注优秀的技能和好的设计会增强敏捷能力。
      n 简单是最根本的。
      n 最好的构架、需求和设计出于自组织团队。
      n 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
      当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。
      n 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
      n 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
      n 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
      n 粘滞性: 做正确的事情比做错误的事情要困难。
      n 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
      n 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
      n 晦涩性: 很难阅读、理解。没有很好地表现出意图。
  • 测试基础综合知识

    2010-12-08 16:52:11

    测试基础综合知识

    网上下载的,共享下

  • Junit源代码学习

    2010-12-08 16:25:46

    Junit源代码学习
  • 登陆我们能想到的测试点

    2010-12-08 11:29:41

    需求:登陆界面:两个输入框(用户名和密码)不能为空,输入错误的用户名和密码要有错误的提示;

          两个按钮:登陆,退出;

     

    分析影响该功能的因素及每个因素的可能取值:

             用户名:正确,错误,空;

            密码:正确,错误,空;

             点击按钮:登陆,退出;

     

    A:相关组合的tc;

    用户名:         密码:     点击按钮:     预期结果:    

    正确                   正确                   登陆

    正确                   正确                   退出

    正确                   错误                   登陆        

    正确                                          登陆        

    。。。。。。

     

    B:其他方面:

    1.       考虑输入值的类型,范围,数据长度校验;‘错误’是本身输入数据格式的错误,还是输入格式正确却与预期的数据不符?

    2.       用户的友好性方面:

    a.       输入正确的用户名和密码,回车,可直接登陆;

    b.       登陆界面设计的合理(如:按钮对齐,输入框对齐,字体大小,字体描述正确等等);

    3.       异常方面:

    a.       用户名密码非法输入,确认后,程序是都有效处理;

    b.       用户名密码输入超长,确认后,程序是否有效处理;

    4.       安全方面:

    a.       密码的保存是否加密过后;

    b.       程序是否防止了SQL注入攻击;

    5.       登陆的用户名和密码是否有被记忆功能,是否支持复制,粘贴;

    6.       系统对用户的登录次数的限制;

Open Toolbar