在整个软件测试过程中，遇到了一些问题，及在遇到这些问题后所采取的措施。

 

1. 提测质量差

问题描述：第一个提测版本差，有些均未通过冒烟测试

问题分析

A. 版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试

提测质量差的点：- 基于上每项功能的完成度都不高 - 有些功能均未实现 -

B. 新的团队，团队处于磨合期

C. 在提测时，对提测要求不明确，在时间点到后，匆忙提测

解决方式：

明确版本提测要求，并且开发得到了足够的时间。

 

2. 版本控制

问题描述：

最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好

问题分析：

A. 基于版本提测质量差，而且每天出一个版本，差上加差，

B. 虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。

解决方式：暂停每天发布一个版本

前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段

后期：以测试一轮周期，发布最新版本

 

3. 功能反复

问题描述：在上一个版本是OK的功能，在新版本中功能失常

功能反复分两点：一是大功能反复， 二是小功能（如：某个bug）反复

问题分析：

大功能反复：情况主要发生成项目前期和中期

A. 功能未完成，在完善功能时，未考虑到与该功能相关的点

B. 在提测之后，发现一些问题，导致了整个模块重构，重构后导致了问题的反复

小功能反复：这个情况主要发生在项目中后期

A. 因为项目里的部分开发是外援的，在项目中期时，撤出了团队，新接手的人员，对代码不熟悉，在修改bug时，经常出来顾此失彼

B. 开发小一在修改代码时，动到了小二的代码，导致了小二出了问题

解决方式：

对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试

对小功能反复 ，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题仍然存在

 

4. 需求不明确，前后不一致

问题描述：需求不明确，特别在一些边界，各端统一上

问题分析：

A. 交互文档经历6任交互，最后一任交互只参与两个模块的定义，现任交互对于以往交互了解不够深入

B. 产品提测时，交互验证不足

解决方式：

由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。

在后期的小版本中，我们把这类问题尽量控制在提测之前（详见小版本里的改进与问题）

 

5. 测试和开发信息不对称

问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致

问题分析：

A. 在开发阶段，测试并未参与讨论需求，还在其他项目里

B. 需求重新确认后，没有及时通知测试

解决方式：

强调消息需要通知到测试，现在阶段，如果因这种类型而引起的问题，将建ticket，指派给相关人员。

 

6. 小版本里的改进与问题

现存在问题：

1. 现对Release版本会做RC checklist, 进行最后版本的质量控制，

但会存在一些问题，在小版本提测时，就已经存在，而冒烟测试是测不到的，在最后做checklist时，才发现

改进点：

1. 需求疑问在提测之前尽量提出，并且通知到开发，在开发阶段便把该问题解决

测试在开发阶段跟踪产品进度

在写测试用例时，就把问题抛出。

2. 提测流程：

对功能方面的ticket，交互在提测之前便在开发机器上验证，通过后再提测

把不符合交互预期的问题，在提测之前更改，节约了时间，避免问题在提测后才提出

另外一些测试过程中遇到的问题和沟通方式

从一开始，测试就要关注需求。

往往在讨论设计时，开发和需求很容易忽略了测试成员，他们潜意识里觉得这不关测试什么事。可是，测试也要熟悉业务，熟悉功能，熟悉各种设计，而且测试需要站在用户的角度来去考量他们的设计是否有不合理的地方，并提出自己的建议。这些工作，测试成员需要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试成员的重要性。  其次，沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题，及我的解决办法。