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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

个人见解

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

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

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

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

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

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