7.4工作&学习

;VH rw7T[0工作：51Testing软件测试网d7G.H|7f;Vr5}l`

7cb l%[#a#Q-w\051Testing软件测试网#Vqp5D T%] J}
1、客服端重新设计了新界面，测试加上应对想不到也一直要拖了好几天。有时就是系统测试和应对花的时间好多啊。昨天发现个bug，是当客服端和客户端聊天时，当输入有大括号时，系统会把之后的聊天记录都屏蔽掉，开发方面在注释中写明了原因是由于大括号是RTF文件中的特殊字符，这时的版本号是1.6.0.1；之后提交了1.6.0.2版本，确认了这个问题，发现在描述的好几种情况中，还有三种情况下此bug还存在，没办法，把bug Reopen，在注释中更信息描述还存在的bug，开发这时给的注释是：测试不够仔细造成的（初看以为是说测试组方面，马上回去详阅了提交的bug，各种情况都说得很清楚，那应该是说开发自己）；之后再提交1.6.0.3版本，又确认了这个bug，没问题了，全都考虑全面，解决了；当然每次提交的版本不可能只有这么一个bug，之后还提交了1.6.0.4，在确认其他bug的时候，突然发现有个聊天记录又出现了部分丢失的情况，原来又是由于记录中包含了大括号所致。突然之间，心里感觉到一种说不出来的滋味，一个bug要重复确认几次，而且马上又来给你重现，一般来说，刚确认完毕的bug近期是没有时间去确认是否重现的，而且又不是主系统流程，系统测试是不可能再次发现的，测试组是要保证质量的，对发布后的产品是要负责的，但这样的情况怎么能够放心呢，难道每次都要在花费大力气再重新完整的测试一遍？显然是不可能的，项目进度不允许，个人也不乐意。还有种情况就是开发改bug的时候基本都是你提什么他就改什么，而很少会去考虑问题的根本原因，相关联的问题和修改后可能会引发的新bug，他们想着反正后面有测试组在把守着，这样自己也乐得轻松。这样却苦了测试。由于测试的工作性质，测试方面必须尽量搞好跟开发的关系，所以我在提交bug 的时候都是尽量把同一功能的，同一个性质的bug写在一起，算一个bug，这样也是为了开发方便修改，而且让报表好看点，同时不会让开发对测试那么反感。但有时想想开发那边的bug，是否应该严格执行bug流程，让开发看看那个bug从上面一路刷下来的感觉呢，说不定会让他们更用心去编他们的code，不过这样以后一些问题就不太好协商了，有时是不知道要如何权衡。近期考虑初步使用自动化来执行不必要的重复工作。

v6c?^ev&@h!u0 51Testing软件测试网g K;RU0E