2周qa总结

日志

9/5


1 以前的认识:在编程时对于接受参数的检验注重于是否为空和长度限制等方面,并没有更为细致的考虑,认为过多的校验没有必要
  今天的改变:对于用户输入要进行严格的控制,最大程度上保证其正确性,因为我们保存了一个不正确的值,并不知道它在什么时候对系统产生破坏性影响
              有时考虑性能方面的影响,视情况宽松

2 低级bug容易发现,开发时做好自测是必要的,自测时也要考虑各种可能的情况,这一点非常重要
  团队质量意识,当自己出现问题后,要积极与团队成员交流该问题,以减少开发测试成本

3 字符串是最容易出错的地方,对他的控制,除了基本的空值、null值和长度校验,对字符串的内容也有必要做控制,
  比如是否允许汉字、转义字符、符号字符,如scope_code,应当只包包含数字和字母;密码也有其组成上的要求;
  比如字符串前后去除空格
  这方面在现在的开发中基本上是没有考虑的

4 在接口开发时,对于其内部逻辑要有清楚的描述,

  比如哪些字段是必须的,没有会产生什么样的情况,哪些值是可以更新的,哪些是不变的


9/7

1 在测试过程中看到list规范的用法,虽然简单,但是很炫酷,在列表和查询方面极为方便:

   排序:$orderby=update_time desc
   分页:$offset=0  $limit=20
   计数: $count=true
   条件过滤:$filter=type eq WORD and word like %ss%


2 对于数据校验的小结
  
   2.1 关于类型转换是由spring框架来做,输入了错误的类型,转换失败,抛出异常,基本不用干涉
   2.2 校验

       枚举:@NotNull校验是否为空  值的正确性有框架判定
       引用:首先@NotNull判定是否为空,然后@valid进行级联校验
       数值:@NotNull判断是否为空, 使用@size/@Max/@Min进行大小的控制
       日期:@NotNull校验是否为空  @DateTimeFormat结合jode可以固定日期的格式
                  对于日期的范围 注解解决不了 需要写方法判断了
                 日期类型输入纯文本数字也是可以通过的  值得注意
       字符串:使用@NotBlank,而不是@NotNull、@NotEmpty,@NotBlan是2者的结合;使用@Length限制长度   
               对于其输入的具体内容的控制 目前没有好办法

      @NotEmpty 用在集合类上面  不能为null,而且长度必须大于0  (" ","  ")
      @NotBlank 用在String上面  只能作用在String上,不能为null,而且调用trim()后,长度必须大于0 ("test")    即:必须有实际字符
      @NotNull    用在基本类型上  不能为null,但可以为empty  (""," ","   ")      

3 测试用例的考虑应当广泛,不应局限于正确类型;先划分大的类型,然后再具体的细分

4 测试时参数输入的考虑

   参数数值包含1个、多个、很多个、null、参数值前后包含空格的2种情况
   数字类型:正数、负数、0、0.0、+0.0、-0.0、指数、对数、分数、小数、复数、科学计数法的测试,全角的数字、超大整数,超大的小数,超小的小数
   文字类型:空格(半角、全角)、所有键盘可以输入的字符(全角、半角)、中文、英文、数字、英文双引号、英文单引号、系统保留字、转义字符、编程保留字、数据库保留字  长度限制等   


9/8 

1 关于需求:

每个人对于需求、功能的理解是各不一样的,所以要沟通和确认,才能事半功倍。
尤其是在描述简单或模棱两可的时候。

案例:
处理举报数:是这个时间段所有的处理数(百分比可能大于100%,因为可能处理之前历史遗留的数据):
2016-9-1~2016-9-8:
收到举报:8条
处理举报:9条
举报处理112.5%
从这个层面上看数据可能表现的是一个工作量的显示

处理举报数:是这个时间段收到的举报的处理数(百分比小于等于100%)
2016-9-1~2016-9-8:
收到举报:8条
处理举报:8条
举报处理100%
从这个层面上看数据可能表现的是一个工作效率的及时性显示

2 关于代码:

1 技术是很细节的东西

  1.1 在举报内容里面dealt字段不必要,因为deal_time有同样的效果。
  1.2 使用@Query计数时 可以设置count=true,而不用选出一个list
  1.3 N+1 问题 :对一次查询的结果进行一样的更新操作,可以考虑使用一个批量更新
  1.4 代码使用的语法应当是易于理解的,不该是生僻古怪的:case穿透就不是很恰当,不如if else 易于理解,甚至引起了错误的理解
  1.5 代码在满足功能的前提下要简洁,鸡肋代码就去掉,比如举报内容按照last_report_time排序就可以了,不需要再按照create_time组合排序
      方法的完成的功能要职责明确,尤其方法代码比较多的时候,要学会抽取

2 这次的开发在多方面出现了很多问题,包括技术的理解的,很多代码有想当然的成分,没有经过仔细的推敲,也没有思考有没有更为合理或更好的方法。
  多问自己为什么我这样做,有益于促进自己的思考。


9/9

测试用例编写感悟:
  
  首先要对UE理解到位,有些点不仔细看和思考是很容易忽略的;对应到开发,不仅在开发前要确认,开发后也要验证是否一致和满足
  正向用例容易发现,反向用例不易得出。

交流的收获:
 第一次听到无注释代码的概念,通过简洁明确的方法命名解释起功能。
 在service层,一般是业务的描述,在repository,一般是数据操作的描述。

 方法返回值类型为集合时,如list,在没有值得时候,不要返回null,而是返回空集合(empty)





总结:


这次测试实习,让我对测试工作有了整体的的了解。
首先,在认识上有了新的转变,必要全面的测试工作是保证产品质量的有效且必不可少的手段。
然后,具体过程中,第一阶段是一个整体学习的过程,主要是通过一些文档了解测试目标、基本的测试方法、测试用例设计和bug的划分与管理等知识。
第二阶段测试接口,设计执行正反用例,尤其对于设计反向用例时,如何有组织地划分不同类型的用例,拓宽用例的范围;还有在数据校验、类型转换方面,了解到一些值得注意的点。
后面有接着做了前端的测试和性能的测试,如何理解UI和UE,如何抽取和挖掘需求,如何思考需求-功能列表-信息结构的转换;性能测试时做的不足,尤其在测试环境、过程的控制和结果的分析上。
期间,在与金龙交流中,对于重构和代码规范有初步的学习和了解。
在以后的学习和工作中,首先要注重代码的规范性,包括命名、方法抽取、校验、异常多个方面。
然后是要自测及时发现问题,尤其是反向用例而不仅仅是只有对的情况。
最重要的是对于需求的理解,模糊地带要及时确认。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值