穿梭在银河的火箭队——Alpha冲刺测试随笔

测试工作安排

阶段名称	说明	测试人员
后端模块测试	由后端成员负责对自己开发的模块进行测试	各后端成员
后端接口测试	后端成员模拟前端请求测试自己完成的API接口	各后端成员
前后端集成测试	前后端集成后，对各功能模块进行集成测试	各前端成员以及文职人员

各阶段测试详细说明

• 后端模块测试：由后端成员负责对自己开发的模块进行测试，主要是测试service层、数据库存储、redis存储、工具类等功能方法是否正常运行，并编写后端模块测试文档
• 后端接口测试：后端成员模拟前端请求测试自己完成的API接口，尝试各种非法情况，并编写接口测试文档
• 前后端集成测试：根据各功能模块，前端成员分别对各自的功能模块进行测试，并由文职人员模拟新人用户来进行测试，编写集成测试文档

——————————————————————————————————————————

前后端集成测试文档格式：

【标题】
测试人：XXXX
测试目的：
测试方法：（输入怎么样的非法格式之类的）
测试结果：（贴图）

——————————————————————————————————————————

后端测试：
1.每个人拉取一条dev分支到自己的本地，把数据库redis的连接改成本地的，在本地上测试，以免影响前端编写
2.后端模块测试文档格式：
【标题】
测试人：XXXX
测试目的：
测试代码：（贴图）
测试结果：（贴图）

3.后端接口测试文档格式：
【标题】
测试人：XXXX
请求方法：
路径：
请求参数：（贴图）
请求结果：（贴图）

——————————————————————————————————————————

每个同学测试完成后把doc文档提交到群文件中的相应文件夹，命名格式示例：2219000330_后端模块测试文档

要在每个测试文档末尾写上自己的测试体会

——————————————————————————————————————————————

测试工具选择和运用

• Junit
• 浏览器
• Postman
• 手机模拟器
• 手机

测试用例文档

• alpha冲刺测试文档（下方三文档汇总）

• 后端接口测试文档

• 后端模块测试文档

• 前后端集成测试文档

测试体会

• 110：

  在集成测试的阶段，会暴露很多bug，可以优先解决那些导致系统崩溃和严重影响功能的bug，剩下的有时间再修复。写代码的时候要注意多写注释，这样改bug的时候会方便很多。

• 139：

  测试体会：发现自己在做自己部分的时候总是会按照正常的逻辑去做，就忽略了其他的，像错误操作或者错误输入等这类的逻辑错误，导致出现bug，所以应该要在写代码的时候就去考虑各种情况，这样才能尽量地避免掉bug的出现。这次测试发现我们组大家找bug的能力真不错，能从各种角度去使用app，找到bug ，再进行修改让项目更加完善。

• 236：

  ​ 本来以为写完了就可以了，然后在测试阶段发现了很多在前期没有注意到的地方，有各种意想不到的bug，还有些不合理的地方，甚至是一些页面的适配性不好、各模块页面之间的交互，然后在第一次测试改bug之后，我们还能发现很多之前没发现的问题。
  ​ 这次的软件测试真的让我意识到了它在软件周期中的重要性，以及我们开发过程也有挺多没考虑到的地方，我也会在下次的开发中注意这些问题。
  ​ 测试中，也不乏乐事，组里的同学用各种奇奇怪怪的操作测出了一堆奇奇怪怪的bug，app属实是让他们给玩明白了，每次看到小组群里的那些神奇的发现bug的操作，都让我大为震撼。

• 304：

  在我的印象里，软件测试就是通过人工或者自动化的方式对软件进行检测，并发现软件的缺陷的一个过程，而软件测试工程师就相当于质检员的角色，在软件研发的周期中验证当前的软件产品是否是客户想要的产品。简单来说，软件测试就是在不断的从软件中找缺陷，并及时提出，推动开发人员及时修正，最终目的就是让公司能够保质保量地向客户交付软件产品 。

• 312：

  采用黑盒测试，站在用户角度去测试，有些bug不易复现，还是需要视频记录，方便发现触发bug的条件。很多时候需要数据从一个页面转递到另一个页面，数据结构可能发生了变化，一旦要测试的模块可用，就可以开始集成测试。还要考虑环境进行详尽的测试，以确保集成系统正常工作。

• 330：

  这次测试，发现许多和原先设想的不一致的地方，很多地方的测试都是有相互联系的地方，比如redis工具类等等，测试成功了也不代表就万事大吉，其中印象最深刻的就是有关javaCV视频处理的第三方依赖，在本地的windows上测试的时候一切都正常，然后一部署到linux服务器上瞬间就崩了，结果查资料发现这个依赖不能用javaCV0.8，应该是太老了不支持有关linux的依赖，所以只能重新下载有关linux的依赖再次部署就正常了，不过副作用就是下载依赖的时候很难区分javaCV的各种版本，打包文件大了300多MB。此外，有很多功能进行了类似的改变，如获取空教室，只能让前端从福大教务处爬取下来再传给后端，否则就会出现类似python爬虫导致后端服务器ip被封的问题，为此还特意去学习了fiddle抓包工具，以便去研究福大教务处的接口,还有很多地方的非法异常处理感觉可以再完善一点，但是这次冲刺已经没啥时间了,总而言之，还得练，希望后续有机会进行完善

• 105：

  测试的难点果然在导包和依赖，百度了好久，尝试好久，终于加上正确的依赖，然后就一气呵成搞定。

• 104：

  通过这次测试，发现有些细节处理得还不是很好，鉴于时间关系，就先冲刺，记录下来，便于下次版本更新迭代。除此之外，在测试过程中，学会了如何使用postman以及Cookie进行测试，怎么去设计一个完整的，健壮的测试。测试的方式，以及测试的方法仍有待提高。通过测试也能够很好的了解到每个接口的需求，以及作用，以及接口的完整性。

• 125：

  测试真的太有意思了，可能是我个人玩心比较重，疯狂地找bug，前所未有地感受到了alpha冲刺的快乐。特别是组员发现的稀奇古怪的bug真的太有意思了，我感受到了小组在找bug方面大家一致的激情。

• 136：

  • 在接口测试中，对于前后端之间的交互有了更深入的认识，前后端之间要多加沟通，互相清楚双方想要的数据以及提供的数据，这样可以避免双方走错路。后端人员编写代码时，将错误的情况以及原因通过请求结果反馈给前端能够给前端人员带来很大的帮助。
  • 我原先预想这次测试会比较顺利的进行，但是最开始就报错了，导致解决了很久的bug，后面实际上的测试代码编写时间不多。这次bug处理时间久在于对报错的信息提取的不太精确，导致上网搜索的时候没有找到正确的解决方案。也因为这个bug，对测试有了更深入的了解。

项目测试评述

本次测试是在项目的稳定阶段执行的，符合《构建之法》中提到的“实战中的测试是在项目的稳定阶段执行的”。 在测试过程中会影响正常使用的bug都解决了，当然也发现了一些可以优化的地方，由于时间关系，我们决定到beta阶段再进行完善和拓展。如今的项目版本系统基本功能基本完备，可以满足运作需求。