总结2

这是我第二次参加项目的测试，在本轮测试中，我主要负责APP的语音播报部分，知识库的文章发布部分，个人中心模块以及CVR、解码器、视频矩阵综合平台、视频矩阵综合平台子系统以及智能机箱的告警测试，智能机箱的在线率统计，在本轮测试中，个人总结如下：
##1、 提缺陷时畏手畏脚。
受张影响，遇到缺陷，总是怀疑是不是自己测试错了，即使发现问题确实存在，可依然存在不敢提缺陷的心理。因为脑子里总是想着张那句“不要轻易给别人提缺陷”。所以下一次的测试中，遇到缺陷一定要大胆提。胆大心细。如果真的是自己的问题，就让他们把缺陷关掉好了。
##2、 用户需求的重要性。
用例中有些部分与实际操作不符合，遇到这种问题是，我首先怀疑是自己没有找到。7月20号晚上邓找我谈话，再一次强调了用户需求的重要性。所以下一次一定要有用户需求。这样遇到用例与实际功能不符合的地方，一定要查看用户需求。通过用户需求，可以大大提高测试的效率，因为这样就不用找开发或者张工询问是不是缺陷。
##3、 一个模块的缺陷会导致几个设备都存在相同的问题。
由于我负责测试CVR、解码器、视频矩阵综合平台、视频矩阵综合平台子系统以及智能机箱的告警测试，很多功能他们使用的都是一套代码，所以需要重复进行测试。这也是用例里面要求的，所以我不是很清楚下次遇到这种测试，是否需要逐一进行测试，还是进行一个设备的测试之后就跟开发沟通一下，让他们告诉自己其他的应该也存在相同的问题。如果可以这样做，那么可以大大提高测试的效率。
##4、 用户名称要按照规则进行设置
由于这次测试涉及到了不同权限的账户，所以需要设置多个角色进行登录，由于经验不足，我的名称是c**+数字组成的，这大大降低了后续登录账户的效率，因为每次登录前都需要进行查找相应的角色对应的账户。
##5、 明确自己的目标。
7月20号邓找我谈话，他的意思是让我来做性能这一块的测试。因为现在组里要慢慢转向自动化测试，并且和系统那边沟通之后希望把性能测试提前到集成测试来做。因为我之前有看loadrunner，所以组里安排我来学习这一块的内容。邓#问我的意愿，理想主义的我想一把抓，然后挑重点，事实是我没有那么多时间，所以希望我能来专心做性能测试。既然如此，不管怎么样，就在性能测试这条路走下去。算是一技之长吧。
##6、 对项目的理解
运维6整个系统偏向于监控设备的状态，以便及时发现问题，而1.更偏向与设备发现问题之后去进行系统报警，安排人员进行维护，当然，他也有监控模块，但是他的重点更在于维护设备。
##7、 发现用例外的缺陷
在做智能机箱在线率统计的测试时，导出的列表明细中有些条目是空白，我想当然的以为就是这么设计的，但是张*看到之后说不应该是这样，所以让我提缺陷，开发看到缺陷之后，进行统一调整。这个事情提醒我，对用例保持怀疑的态度，对所有的问题抱着疑问的态度，哪怕不是一个缺陷，至少也能把系统进行完善，总归是有用处的。就像杨老师说的，没有白费的功夫，总有用到的一天。