银行软件在经过几轮的测试后,为什么还是会出现一些生产问题?

east_rise

银行软件都要经过单元测试、集成测试、模拟测试、3轮测试后，还是会出现生产问题，不知道大家对此问题是如何分析的？或是这样的问题为什么容易遗漏，怎么样来避免上面出现的问题？

huishelml

我们平常在测试时,通过技术测试,功能测试,回归测试,经过这一系列测试后,能发现80%的问题,而另外20%的问题在哪?有以下几个方面:
1)由于测试人员对银行业务理解不到位,漏到一些业务的场景的测试.这个是很关键的.所以说银行的测试不能停留在表面测试,应能深入了解需求.
2)环境引起的,测试环境与生产环境不一致导致生产出现问题而测试环境上却是正解.
3)版本控制问题,这个出现的概率少一些,毕竟银行的版本控制相对其他行业应规范很多,但难免也有失误的时候.
4)还有的就是本身测试人员自己犯下的错误.

漩涡鸣人

1、业务
2、回归测试执行力度
3、用例评审

tianyu23

其实测试人员应该从业务部门向科技部门提需求开始就介入项目，了解项目到底要做什么，在这个过程中发挥测试人员考虑问题缜密的优势，对需求文档进行静态测试，找出文档中不合理或错误的地方，减少在测试过程中扯皮的现象。至于生产问题是必不可少的，毕竟测试环境和生产环境的一些参数设置是不一样的，没必要太在意

兰色犹豫

谁敢保证测试以后就没有问题了？？？

east_rise

支持

east_rise

支持

east_rise

作为银行系统的测试人员，这里主要是探讨如何提高我们的测试质量，并且尽最大能力去降低银行系统的缺陷，尽可能的减少生产时出defect。
   当然测试后的产品百分之百的0缺陷是没有的，但是这个帖子的本意还是学习大家平时在测试过程中遇到的问题尤其是遗留到生产后的问题和解决这些问题的方法，还有就是哪些流程本身做的不够完善，以后需要加强控制的点。仅此而以，并不违背测试的宗旨。

紫晴

主要还是跟业务有直接关系。作这软件的所有成员，不是业务专家。在需求上不能全面性，加上经过几个来回的传递。

lixiuquan_163

我觉得你的三轮测试还是不够的，你们前两轮的测试都是开发阶段的测试，系统还没有成型，在这个阶段的测试是不能测出业务层面的错误，至于你说的第三轮模拟测试，我觉得对于银行系统来说，这是远远不够的，最少还有非功能测试没有做，许多非功能性问题都还隐藏着，我个人觉得：对银行系统，测试应该从需求阶段介入，从开发阶段的单元测试，集成测试，系统测试，到开发完成后的功能验证测试，非功能验证测试，到最后的上线版本验证，这是一个完整的体系，如果能按照这个体系走下去，相信最后上线的版本一定是可以信赖的！

studping

记住：测试只能把尽可能多的defect找出来，而不能把所有的defect都找出来。

velata

楼主自己的分析已经很好了哦～
不过我们1－7都控制得很好也会有bug遗漏到用户那边去的情况发生
我们的主要原因是没有站在用户的角度去试用业务系统，只是站在技术人员的立场去做测试。
PS：我们是做证券软件测试滴～

wzts1985

恩···我现在也是刚入行··谢谢

lyscser

需求分析和需求评审是关键点，把握不好的话，再强的测试团队都测试不出什么好成果

east_rise

非常感谢各位的积极讨论，知道了很多需要注意的地方.

  就现在所处的环境,主要面对以下几个问题,说出来共享一下，看看大家是否遇到这样的问题

1、业务人员提供的需求不够清晰，很多细节方面没有具体指出，加上开发人员与测试人员对项目的需求理解都有遗漏，项目前期开发质量和测试质量较低。
2、整个项目的设计需求阶段不完善，表现在一个项目从立项到结束，时间紧张，每天靠加班加点来完成任务，无论是开发人员还是测试人员整个项目都很疲惫，降低了工作效率。
3、文档控制，项目需求不断更新且未同步，造成测试人员与开发人员拿到的需求文档为两个版本，目前此情况已解决。
4、测试前期准备不够充分，项目较多的情况，测试人员很难将下一个项目中的测试细节想的面面俱到并实施到测试用例当中，只是对项目整体有个大概的了解，以致进入测试阶段不能把握好每个细节。
5、测试之间的依赖性，对于一些项目，集成测试阶段没有足够的时间测试，只是通过性的测试走一遍，然后就提交到系统测试，这样一层一层的走下去，不难想象，可能会产生一些问题。
6、针对一些连贯性的交易，测试的不够充分，因为每个人基本都是测试独立的交易，到最后把整个流程跑完，并且基本上每条路径都能跑到，但还是有些遗漏的路径，或是根本就没想到的测试点。
7、提交版本问题，提交集成测试的项目版本与系统的测试版本不一致，问题情况也不相似。
8、测试环境不一致；集成测试环境与系统测试环境不一直；系统环境与模拟环境不一致，模拟与生产环境不一致。都有可能导致一系列问题。
9、学习银行业务，把握整个的业务流程，熟悉哪些经常使用的功能模块， 这样至少不会出现重大的生产问题。

其他的应该还有很多吧，由于接触的面窄，还需要进一步学习，希望以后大家多多指教。

[ 本帖最后由 east_rise 于 2008-6-2 22:53 编辑 ]

wzb521

首先，测试不是按几轮来算质量的，试着去分析一下BUG的性质及起因
1、测试用例是否足够充分
2、关联BUG的存在，某些用例不能一次执行下去
3、是否需求变化引起新BUG的出现
4、哪些是由于修复其他BUG引入的缺陷。
5、是否有环境因素引起的设计原因，比如说：测试环境未用到集群，而开发环境用到了集群，那么对于应用到单例模式的设计，就要考虑斟酌一下了。
6、是否是环境因素引起的其他原因，比如银行内的网段限制，或者说防火墙限制等。
7、…………等，时间条件不去细想了，测试的问题需要具体问题具体分析

PS：
“我觉得应该和业务有关系吧.”，这条个人觉得说的不对，银行的业务也就是需求是更新很快，但银行还是会保证每个迭代周期内需求的稳定的。
“对于需求评审、设计评审、代码走读什么的”，个人觉得楼主应该是无能为力的，楼主所能做的就是根据质量缺陷，去反向查找软件过程中的不足，之后考虑如何改进质量管理方式。

个人见解

wzb521

软件测试对软件质量的保证是有限的，切记切记。
你有对质量的不满和遗憾，说明你对测试的态度很端正，责任心很强。

kico0212

测试环境和生产环境不一样  用起来会有很大的区别   
生产环境事实上是没办法测试的   说实在话UAT环境也不是实际生产环境   
测试环境的版本拿上生产环境或多或少肯定会出现一系列的问题  
有时候重大的问题可能就是由于小小的环境区别造成的  比如网络环境

janson512

测试环境和真实的生产环境不一样吧
最好能在生产环境上测试下

meng0819

我觉得这正是测试存在的原因，bug产生的原因很多。我想以下问题对楼主有所帮助：
需求是否得到验证？
设计是否得到验证？
代码编写是否符合规范？
签入代码前需要做什么工作？
签入后如何验证？
性能是否符合要求？
其中，我觉得最难以把握的是需求。我们与客户对需求的理解可能存在偏差，这部分偏差一定是日后的bug。设计与需求可能也会有偏差，这就是验证的重要性了。