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

east_rise

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

zwjpriya

我觉得应该和业务有关系吧.

ecust

用一句话也许能解释：测试是不可能穷尽的。

和你的签名一样：一切皆有可能！！！

想尽量少的遗漏，就必须把业务全部搞清楚，进行详尽的用例设计，尽可能的模拟真实使用环境去测试。

milklybaby

我觉得LZ的问题在测试工作中是不可避免的。引发生产问题的原因有很多，比如测试环境与生产环境不一致（涉及到分行特色部分），版本有问题，发布时少了参数等等。

所以，要想尽量避免LZ说的情况，得从开发测试过程、配置管理、发布管理等多方面入手才行。

chech28

汗一下，楼主啊，你这个问题谁要是可以回答的话，大公司都抢着要那个人去做测试总监咯。

dongri

银行的生产问题相对算少的了，知识一旦发生影响比较大。
测试不是保证不出问题的

meng0819

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

janson512

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

kico0212

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

wzb521

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

wzb521

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

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

个人见解

east_rise

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

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

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

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

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

lyscser

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

wzts1985

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

velata

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

studping

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

lixiuquan_163

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

紫晴

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

east_rise

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

east_rise

支持