提测质量差
问题描述：
第一个提测版本差，有些均未通过冒烟测试
问题分析：
版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试。提测质量差的点：基于每项功能的完成度都不高、有些功能均未实现。新的团队，团队处于磨合期。在提测时，对提测要求不明确，在时间点到后，匆忙提测。解决方式：
明确版本提测要求，并且开发得到了足够的时间。
版本控制
问题描述：最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好。
问题分析：
基于版本提测质量差，而且每天出一个版本，差上加差，虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。解决方式：
暂停每天发布一个版本前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段。后期：以测试一轮为周期，发布最新版本。
功能反复
问题描述：
在上一个版本是OK的功能，在新版本中功能失常
功能反复分两点：一是大功能反复，二是小功能（如：某个bug）反复
问题分析：
大功能反复：情况主要发生在项目前期和中期
功能未完成，在完善功能时，未考虑到与该功能相关的点在提测之后，发现一些问题，导致了整个模块重构，重构后导致了问题的反复小功能反复：这个情况主要发生在项目中后期
因为项目里的部分开发是外援的，在项目中期时，撤出了团队，新接手的人员，对代码不熟悉，在修改bug时，经常出来顾此失彼。开发一在修改代码时，动到了二的代码，导致了二出了问题解决方式：
对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试对小功能反复，没有有效的处理方式，测试这边可以做的是加强测试。
需求不明确，前后不一致
问题描述：
需求不明确，特别在一些边界，各端统一上。
问题分析：
交互文档经历6任交互，最后一任交互只参与两个模块的定义，现任交互对于以往交互了解不够深入。产品提测时，交互验证不足。解决方式：
由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。在后期的小版本中，我们把这类问题尽量控制在提测之前（详见小版本里的改进与问题）
测试和开发信息不对称
问题描述：
测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致。
问题分析：
在开发阶段，测试并未参与讨论需求，还在其他项目里。
需求重新确认后，没有及时通知测试。
解决方式：
强调消息需要通知到测试，现在阶段，如果因这种类型而引起的问题，将建ticket，指派给相关人员
小版本里的改进与问题
现存在问题：
现对Release版本会做RCchecklist，进行最后版本的质量控制，但会存在一些问题，在小版本提测时，就已经存在，而冒烟测试是测不到的，在最后做checklist时，才发现。
改进点：
需求疑问在提测之前尽量提出，并且通知到开发，在开发阶段便把该问题解决测试在开发阶段跟踪产品进度在写测试用例时，就把问题抛出。提测流程：
对功能方面的ticket，交互在提测之前便在开发机器上验证，通过后再提测。把不符合交互预期的问题，在提测之前更改，节约了时间，避免问题在提测后才提出。另外一些测试过程中遇到的问题和沟通方式
从一开始，测试就要
转载请注明：http://www.0431gb208.com/sjsbszl/2214.html
