一、对https进行抓包(Windows-pc端)

1、电脑端安装SSL证书

https_SSL

https_SSL2

2、进行相关配置

 选择SSl Proxying Settings,勾选Enable SSl Proxying,点击Add,输入要抓取的网站的地址及端口(默认是443),如果是抓取任意网站的数据则在host中填写“*”即可

https_SSL3

3、选择Windows Proxy模式

https_SSL4

4、打开浏览器,进行访问即可

二、对https进行抓包(手机端)

→iOS端抓取https

1、完成上述的1、2点

2、连上无线网,在手机上设置代理地址

3、手机端安装证书,使用Safari直接打开下面地址进行安装

  地址:http://www.charlesproxy.com/getssl

  安装好后可在【设置-通用-描述文件】中查看

→Android端抓取https

1、完成上述的1、2点

2、连上无线网,在手机上设置代理地址

3、手机端安装证书,使用安卓自带浏览器直接打开下面地址进行安装

  地址:http://www.charlesproxy.com/getssl

  安装好后可在【设置-安全】中查看

1、【页面/客户端的响应时间】

    响应时间直接影响最终用户的使用体验,从而在很大程度上影响用户忠诚度。是客户发出请求到得到响应的整个过程的时间。

2、【服务器的吞吐量】
    常用的是系统每小时能处理的业务量。例如,最高每小时能接受的网站浏览次数,或者一个电子商务网站每小时能下多少个订单。

3、【最大并发用户数】
    这里的“最大”其实并不是真正的最大,而是在响应时间合理的情况下,能承受的并发用户数。也就是系统最多能承受多少用户同时访问且用户感觉不到页面响应变慢。

4、【能否能稳定的长期运行】
    任何客户都不希望自己的系统动不动就宕机,这会对最终用户造成非常不好的印象,从而给客户的业务带来大的损失。应用服务系统是否能长期稳定运行除了跟服务器的硬件有关系之外,与软件本身也有很大的关系。可利用7*24方式去进行测试。

5、【最大数据规模】
    能保证正常访问的最大容忍数据规模。

6、【服务器后台操作是否会影响前台性能】

7、【什么情况下会导致系统崩溃】

持续更新ing

1、第一次尝试做pizza,海鲜大虾,芝士放好多,很好吃。

2016-03-01 172315

2、抹茶蜜豆卷,配一杯香醇豆浆,甜而不腻,如春风中的甜腻气息萦绕在舌尖。

food

   

测试用例评审检查单
序号 主要检查项 是否通过
1 《需求规格说明书》是否评审?  
2 是否按照测试计划时间完成用例编写?  
3 需求新增和变更是否进行了对应的调整?  
4 用例是否按照公司定义的模板进行编写?  
5 测试用例是否覆盖了《需求规格说明书》?  
6 用例编号是否和需求进行对应?  
7 非功能测试需求或不可测试需求是否在用例中列出并说明?  
8 用例设计是否包含了正面、反面的用例?  
9 每个测试用例是否清楚的填写了测试目的、步骤、预期结果?  
10 步骤/输入数据部分是否清晰,是否具备可操作性?  
11 测试用例是否包含测试数据及数据的生成办法或者输入的相关描述?  
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?  
13 重点需求用例设计至少要有三种设计方法?  
14 每个测试用例是否都阐述预期结果和评估该结果的方法?  
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?  
16 用例覆盖率是否达到相应质量指标?  
17 用例预期缺陷率是否达到相应质量指标?  

那么如何进行测试用例的评审呢?

测试用例评审标准

1、首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。

 如果是测试组内部的评审,应该着重于:

  • 测试用例本身的描述是否清晰,是否存在二义性;
  • 是否考虑到测试用例的执行效率。测试设计的冗余性,造成了效率的低下;
  • 是否覆盖了所有的软件需求;
  • 是否完全遵守了软件需求的规定。这并不一定的,因为即使再严格的评审,也会出现错误,应具体情况具体对待。

 如果是项目组内部的评审,也就需要评审委员会来做了,角度不同,评审的标准也不同。比如:

  • 收集客户需求的人员注重你的业务逻辑是否正确;
  • 分析软件需求规格的人注重你的用例是否跟规格要求一致;
  • 开发负责人会注重你的用例中对程序的要求是否合理。

测试用例评审步骤

 测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。

  1、需要评审的原因

  测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。

  2、进行评审的时机

  一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审;第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张,尽可能保证对用例设计进行评审,提前发现其中的不足之处。

  3、参与评审人员

  这里会分为多个级别进行评审。

  • 部门评审,测试部门全体成员参与的评审。
  • 公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
  • 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

  4、评审内容

  评审的内容有以下几个方面(可使用检查单):

  • 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
  • 优先极安排是否合理。
  • 是否覆盖测试需求上的所有功能点。
  • 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法
  • 是否已经删除了冗余的用例。
  • 是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现。
  • 是否从用户层面来设计用户使用场景和使用流程的测试用例。
  • 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

  5、评审的方式

  • 召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
  • 通用邮件与相关人员沟通
  • 通用即时通信工具直接与相关人员交流

  方式只是手段,得到其它人员对于用例的反馈信息才是目的。

  无论采用那种方式,都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解,以节省沟通成本。

  6、评审结束标准

  在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。