IT测试团队 一次测试例会

                 [b]一次会议纪要[/b]
时间：2012年4月19日 16：40-17：45
地点：F1-20-A09R
与会人员：A1、A2、A3、A4、A5、A6、A7、A8、A9、A10、A11、A12
会议主持：A7
会议纪要：A12
会议议题：
1、	欢迎新会员加入
2、	分析问题单，提升发现问题的能力
第一项：欢迎新会员加入
新会员：A2、A12
第二项：问题单分析与总结分享
发言要点记录
1.	A10
	通过查看别人的问题单，扩宽了自己发现问题的方法和角度；
	举例：测试浏览器的兼容，窗口和标签测试。
2.	A9
	之前的问题没有修改彻底，重复出现，或引入新问题；
	本轮测试应该再关注一下上轮测试的问题；
	旧有的规则不熟悉导致提单无效；
	开发的翻译未经翻译中心审核，不规范。
A1建议：
	维护一份权限相关的表，记录与之有关的权限问题，并持续更新；
	非问题也是有价值的，应分析其产生的原因。
3.	A11
	模块交互的部分，问题较多，应多角度测试；
	举例：多界面跳转的合理性、正确性；
	思考：如何提早发现问题，通过用例来发现功能问题，提高测试价值。
A9补充：
	开发较少自验，过于依赖测试；
A1指出：
	我们应尽量要求开发自验，但测试发现问题要暴露出来。

4.	A12
	测试的新特性中引用旧有功能模块时，可以参考之前的旧有模块相关问题单；
	举例：Vplan中有搜索和时间控件等，可查看之前有关搜索和时间控件的问题在此是否存在。
5.	A8
	安全性测试、脚本注入；
	关注异常提示信息；
	键盘鼠标作为输入都要测试，举例，鼠标可点击提交，但键盘不行。
6.	A6
	建议学习用户行为分析：色彩、屏幕、操作焦点、使用习惯等，是拓展思路的途径，也是提高问题单有效率的方法；
	提单风格：不同级别的问题单使用的模板、描述方法、重点应有所差异；
	 回归问题单时思考别人提单的角度，以及自己能否学习；
	思考问题单可能引发的问题，涉及的模块；
	用户关注的就是重要的；
	需求变更、新特性、邮件、中英文、易用性、session、兼容性等是问题多发点。
7.	A13
	要考虑非常规操作；
	关于翻页的易用性建议写入规格；
	关注开发修改的记录，从中学习并了解系统内部逻辑，自我提升。
8.	A2
	DTS提单规范；
	环境问题，建议测试之前按照checklist检查测试环境；
	多人操作后台权限导致权限混乱，引发无效问题单；
	需求规格澄清；
	如何将别人发现问题的能力转化为自己的。

9.	A1
	代表用户去做测试；
	逆向测试要结合用户场景来做；
	测试与用户接触太少，建议测试轮流介入UAT，由A3接口指导；
	没有测试是100%充分的，应思考如何在有限时间内交付客户满意的产品；
	每个特性应有质量等级，如必备质量+魅力质量，必备质量的满足是出口的最低标准，而魅力质量会转化为必备质量。
10.	A5
	网上问题单，原因、解决方法，是否符合最初的规格；
	分析问题单，尽早发现问题；
	借鉴别人的经验，总结分享。
A1补充：
	零散的经验应充分分享输出，才具有最大的价值；
	分门别类形成checklist，持续完善，或许，出本书也未尝不可。
A6补充：
	学习是自发的，仅依赖团队的进步是不行的，要主动出击。
11.	A7
测试应从三个角色着眼：
	用户，关注的功能、易用；
	测试，连接用户与开发，尽可能发现问题；
	开发，开发的不良习惯，较少关注容错、友好，不同浏览器的特性，举例：flash控件。
12.	A3
	测试不应是单纯的使用者、操作者，深入理解系统有助于提升提单质量和能力；
	遇到系统报错，提单时应粘贴错误日志。
指定下次会议议题：如何展现测试人员的价值
指定下次会议主持：A3
指定下次会议纪要：A13