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，如何抽取和挖掘需求，如何思考需求-功能列表-信息结构的转换；性能测试时做的不足，尤其在测试环境、过程的控制和结果的分析上。
期间，在与金龙交流中，对于重构和代码规范有初步的学习和了解。
在以后的学习和工作中，首先要注重代码的规范性，包括命名、方法抽取、校验、异常多个方面。
然后是要自测及时发现问题，尤其是反向用例而不仅仅是只有对的情况。
最重要的是对于需求的理解，模糊地带要及时确认。