做手工测试三年多了,现在有空整理下最近的项目的小总结。第一次发帖,水平不高,也没有什么技术含量方面的东西,更多的是态度方面的。和大家多多交流。~
项目总结: Quick so: 1)
第一次POC时bug众多,主要集中在 1)
UI。比如时间选择框点一下出现,点其他位置时它应该消失。但当点其他button或者文本框时就没有验证它是否消失。还有其他涉及浏览器兼容性的UI问题。那时候是随便点点都有好多UI问题。 2)
IE7和IE9的兼容性测试。因为页面用了大量的css表单,在IE7和IE9的环境下的显示情况不尽相同,有时在IE9下面没问题,在IE7下面就很多问题。 3)
Javascript控件多造成了很多功能性问题。比如一个典型的bug是那个类似百度的文本框带搜索功能的,可以增减的。当删除第一个文本框时,后面再次增加的文本框的搜索下拉列表功能消失了。原因就是因为后面的文本框都是copy的第一个文本框的全部属性。第一个删除了,后面的文本框的功能自然就消失了。这个我在test case里没有包含,ad-hoc也没有想到这种情况,这是test case design时的重大失误,考虑的情况不够周到。从测试方法上没有把边界值验证的方法用于这种文本框的情况。 4)
快捷键测试。比如想到了tab,没有想到shift tab的验证. 2)
经过第一次poc的失败,后面对系统进行了更加仔细的测试。这时才感到手工测试学问颇多,而且最重要的是态度。只有按照严格的测试标准,才能给用户良好的使用体验。后面把更多的时间放到UI的验证上,主要是: 1)
检查页面的整体风格,颜色,布局是否美观。页面有三个滚动条,保证三个滚动条的样式一致。 2)
所有的报错信息,报错弹出对话框全部仔细检验。 3)
快速的操作测试性能。有个bug无意中在此情况下发现。就是上述的文本搜索框点击+加一行的功能。当我连续快速做操作时,添加的文本搜索框有的添加不出来,有的只添加了一半,有的形状变小,等等ugly.原因是这个功能是个动画效果,如果用户的操作时间短于它完成一个动画的周期,就会出现各种ugly.之前并没有开发人员告诉我这是个动画效果。这个bug纯属是在ad-hoc下发现的。所以作为测试人员,当你不知道系统的实现方法的时候,就要发挥想象力想到各种可能的情况,对于动态生成的控件做些暴力性测试。 4)
对第一个文本框的测试。这个文本框就是允许用户输入任意字符最多不超过60字。并且旁边有个功能能够动态地计算剩余还可以输入多少字符。这个文本框测下来bug有十几个。最后快UAT的时候还找到一个bug,就是当我用enter做换行一到总的字符达到60个时,所有的换行都消失了,都变成在一行显示了。虽然到现在我也不知道这个问题从开发的角度出在哪里,但总结的经验教训就是javascript做的玩意儿属于不太靠谱的,必须不断地对它测试测试再测试,保证bug就像宝藏一样源源不断。 5)
有个bug是在没有拿到最新版本找到的,说明开发很有前瞻性已经先于我考虑到了。就是在SO的结果页面,当SO的行数少时没问题,当SO的行数很多时,页面就ugly了。OK键都跑到表单上遮盖掉表单了。这说明UI的问题也要考虑极限情况,在一条两条的时候ok,可不能保证数量多的时候还ok。 6)
最后产品环境迁移的时候,还有个UI问题,和开发确认了,开发leader承认这是个issue但由于要保证产品的稳定性怕一改会牵出其他问题他们把这个issue defer了。就是上面那个文本搜索框,当添加的个数>3时,右侧会出现滚动条,保证所有添加的文本搜索框都在这个section以内。问题出在当我加到第四个文本框时,右侧的滚动条没有放置在最下端,导致最后一行最下面的一部分总是显示不全,这个用户体验是很不好的,因为用户在最后一行输入的时候框的下边线看不到。这个issue我以前提过,之前的问题是最上面的边框显示不出来,开发说css要一点点儿调,结果调完就变成下边框显示不出了。那时我验证了认为上边框ok了就忽略这个问题了。其实应该再多做些测试,保证没有其他问题或者其他问题在可接受的范围内。如果这两个issue只能择其一,那肯定保证最下面边框一定出现,当时没有做这两种显示效果的比较,属于测试仍然不够细心。以后吸取教训。 这个虽然是个小项目,但还是学到了很多东西。特别是和开发坐在一起并肩奋斗,在他们身上也学到了不少东西。他们做事情挺认真的,基本都是html5,css,javascript,jquery的新手,但他们对css表单一丝不苟的调试,细心的态度让我很敬佩。有的issue他们在我测试之前自己就发现了,甚至在和我说的时候我半天都没意识到那是个问题,他们都还认真地调,认真的改。这样的精神真值得我一个需要更加细心态度的测试人员学习。总之一句话,只有严格的标准才能出现最好的产品。 |