软件测试过程中会遇到的问题-转载

转载：https://www.jianshu.com/p/cfedc1f1ecfe

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

 

1.提测质量差

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

问题分析

A.版本提测质量差，但基于发布时间已在，因此。在提测差时就开始测试提测质量差的点：基于每项功能的完成度都不高-有些功能均未实现

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

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

解决方式：

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

 

2.版本控制

问题描述：

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

问题分析：

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

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

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

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

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

 

3.功能反复

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

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

问题分析：

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

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

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

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

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

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

解决方式：

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

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

 

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

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

问题分析：

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

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

解决方式：

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

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

 

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

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

问题分析：

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

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

解决方式：

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

小版本里的改进与问题

现存在问题：

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

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

改进点：

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

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

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

2.提测流程：

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

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

 

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

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

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

1、这个bug我这边重现不了

解决办法

bug应该简明扼要，重点突出。

如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。在复现问题时，希望能大致判断几个问题点，然后和测试人员沟通下，需要如何捕获信息，捕获哪类信息？是不是提供debug版本进行复现，或者根据预判的点增加打印信息版本进行复现？

 

2、这个不是代码问题，需求这么定义的

解决办法

需求也是人定义的，如果觉得有异议

可以找需求人员询问清楚，为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。

 

3、这块是别人负责的，我负责的部分没有问题

解决办法

如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然项目经理当然有项目经理的处理办法。可是测试遇到这样的问题怎么办呢？把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。

 

4、有问题吗？（也就是开发不认为这是个问题）
解决办法
测试人员一定比开发要敏感，对bug
的容忍度也要低一些。特别是一些不符合用户习惯的bug
，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。

 

5、用户不会像你这样操作的！
解决办法
用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，
我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。 总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。

转载于:https://www.cnblogs.com/privilege/p/11259276.html