今天组织了用例评审会，娃哈哈，前一天就听说领导不参与，很好，正合偶的心意。哇哈哈~~全过程进展得还算是蛮顺利的。全程白话说话，霹雳巴拉一样开机关枪，真是酷啊！以下是总结交流所得：

　　1、xx项目中，培训计划于组织培训中当计划数据与实际数据产生差异时的测试。

　　2、输入框的问题，有些输入框限制了所输入的字符的格式，但是却并没有限制这些

　　错误格式的字符通过复制黏贴的方式输入这些错误的字符。

　　3、表单中，有时候输入了字段后，然后不点击Enter按钮，不点击提交，如果这样也可以成功的提交表单的话。这也算是一个bug。这个也是以往在测试过程忽略的。

　　4、浏览功能，按照界面原型的做法是，浏览按钮放在列表的右上方，点击浏览时要先选中列表中对应的数据，然后在点浏览。但是经过与开发的沟通后发现，这样的做法不是很好，要加以过多累赘的逻辑判断。开发的想把这些按钮放到列表中，这样可以通过gridview中的事件来控制。个人觉得这样从代码逻辑上来说虽然可以，但是从界面上来说这显然对列表能否显示全部的数据造成一定的影响。所以总的来说，很多东西还是不能两全其美的。任何的时候都应该辩证的看问题，无论是这样或是那样的做法，也许在一定程度上来说看似很好，但是其实质上可能又会引入一个新的问题。这些都是难所避免的。

　　5、输入框的限制问题，在以往的系统测试中，对于手机号码、电话号码、邮编等都是限制输入格式与长度的，其实这样的做法有时候也有不好的做法，虽然看上去系统的逻辑好像是得以更加的完善了。但是，实际上载完善的同时也会引入一些其他的问题，诸如这样都限制得太死了，有时候想提交数据时会给用户造成不灵活。比如说输入手机号码，正常的话所输入的手机号码应该是字符格式且是11位才对的，但是如果这样限制了，如果用户期望输入两个手机号呢？这样在提交表单时就不够灵活了。

　　个人觉得，用例评审会在时间允许的前提下是个不错的差事，无论是对开发人员还是对于测试人员来说都是一个很好的互补的过程。第一，从开发人员的角度来说，有些地方测试考虑到测试了，但是开发的在编码时却没有考虑到。这样一来也可以避免bug了。第二，从测试人员的角度看，有些问题是开发人员在开发过程中考虑到，但是测试人员并没考虑到的。这样又可以加强测试人员的工作效率。第三，从其他方面说，无论是开发人员还是测试人员，都可以通过这样的评审会提高自身的表达能力、沟通能力。这些对于一个人综合素质的培养也是很重要的。

版权声明：本文出自anitalaw的51Testing软件测试博客：http://www.51testing.com/?258306

原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。