51Testing软件测试论坛

标题: 如何在软件频繁改变时测试 [打印本页]

作者: jackei 时间: 2004-6-7 19:09
标题: 如何在软件频繁改变时测试
就像一句古老的谚语中说得：“唯一不变的是改变”。
在软件开发模型中，曾被认为最优秀的瀑布模型的一个缺陷就是假定很少或者没有改变，而现实世界是每天都在改变的。也因为如此，其他的开发模型比如“快速应用开发（Rapid Application Development，RAD）”逐渐发展成可以接收改变，并通过计划好的迭代过程利用这些改变来改进软件的开发模型。
虽然RAD可以帮助软件开发人员加快开发的速度，但是却也让测试人员非常头痛。因为每一次改变都有可能产生新的缺陷，而要想找到新的缺陷只有一个办法——进行全面的回归测试——对所有原来已经测试通过的部分再次测试，对返回值进行比较并找出不同的地方。

这里有两个问题需要注意：

1）在软件频繁改变的时候，可能进行全面测试吗？

实际上这是不可能的。不过，这个问题本身就有问题^_^，因为很多时候甚至都不可能在一个完全稳定的环境中测试软件。这个问题其实是想问：“在软件频繁变化的时候，能否进行有效的测试？”我们能否期望通过更好的使用人力和其他资源来完成这种测试？我们能否找到所期望的那么多缺陷？
通过对使用RAD方法的项目的观察，我发现软件测试过程对于发现缺陷是非常重要的，不同的过程会表现出不同的效果。因为大多数时候我们的开发过程都不是简单的重复，所以在RAD环境中就不能象其他环境那样——尝试着用各种方法到处看看能不能找到一些缺陷。

2）在软件频繁改变的时候，有哪些策略可以使用？

应该花些时间学习怎样在不同的环境下开展工作，不过在软件频繁改变的时候有些一般的策略还是可以参考的。
.首先，你必须接受这个事实——你不可能有6周的时间对一个每天都在变化的软件进行测试——或者说你的老板不会允许你在每次软件改变后都用这么长的周期来进行测试。唯一的办法是你要定义一个可以快速有效的完成测试任务的过程。
.进行风险评估。能够区分不同测试对象的风险级别是非常重要的，因为这样你就可以通过对不同的测试对象排列优先级，在那些很简单的问题上只花费较少的时间，而对更高的风险则给予更高的优先级和更多的时间以及其他资源。
.必须有一个确定的工作版本（基线版本），以便于你在将来进行测试的时候可以进行比较。
.自动化测试。使用捕捉/回放工具可以借助一些自动化特性帮助你来对软件进行回归测试。应该考虑花些时间和资金把一些工具融入到你的团队中，让大家都学会如何使用这些工具会对你的工作有所帮助。对于一个不愿引入新技术的组织——比如自动化测试工具——是很难在软件频繁改变期间完成测试的。这就像盖一座房子，手头上必须要有些合适的工具才行。
.自动化工具只能对你的操作进行记录和回放，这是不够的。你必须明确业务需求，设计测试用例和测试过程，制定测试计划。另外，如果人们想在长期工作过程中获得比短期工作更多的好处，就需要考虑测试用例和测试脚本。

在软件频繁改变的时候进行测试不是不可能的，但是需要快速的响应、努力工作和维护对改变的跟踪。
在软件频繁改变时进行测试同样需要一个有创新思维的团队和过程，工具自己不会工作，只有在工作中由最优秀的人员在合适的时机使用才会产生最好的效果。使工具、人员和过程达到一个最理想的结合是一件非常有挑战性的事情。

参考资料：“Testing During Rapid Change” By Randy Rice, CQA, CSTE

----------------------------------------------
【郑重声明】
本人依法保留对本文的所有权利，未经本人允许，任何人不得擅自将本文中内容用做任何盈利性的用途。为尊重作者的劳动成果，如需转载或引用，请注明文章出处及作者。

moc.liamtoh@nahc_iekcaj

[ Last edited by jackei on 2004-6-7 at 19:10 ]

作者: abba2004 时间: 2004-7-5 13:57
首先问下，楼主所说的软件改变是何种类型的改变呢？种类太多了吧。:d
软件改变不光是测试人员头痛的问题，包括项目管理人员和程序员都会对此头痛不已。毕竟"重用性"还是应该体现到一个公司的积累上来的。

作者: 云层 时间: 2004-7-19 22:31
.进行风险评估。能够区分不同测试对象的风险级别是非常重要的，因为这样你就可以通过对不同的测试对象排列优先级，在那些很简单的问题上只花费较少的时间，而对更高的风险则给予更高的优先级和更多的时间以及其他资源。

这点非常重要，对于测试人员的经验要求很高

作者: indebted 时间: 2004-8-3 09:50
标题: 软件版本的改变
我想软件的改变就是同一个软件，但在测试过程中由于遇到了很多bug，使得开发人员修改时非常困难，必要进行功能或者某些模块的更改。还有就是客户提出的新的功能要求等。在整个测试和客户试用期间软件的更改可能是非常大的。有时有必要重新进行详细的测试。因为更改的模块可能会引起其它原来没有问题的模块也产生问题。所以测试时要有耐心。可能某一个模块前面几个版本一直没有问题，后面的版本可能就会有问题，所以不容忽视。
我就经常会遇到这样的问题，同一个软件更改了好几个版本，每次除了认真测试更改的功能和bug外，也不能忽视其它原来没有问题的模块。还有就是原来第一个或者第二个版本出现的bug，虽然以后修改了，但后来的版本也可能会使得bug重现。所以每一个环节都不容忽视。
不知各位有没有象我这样的情况的？有没有可以改进的建议？多谢指教！

作者: pent 时间: 2004-8-27 11:03
这个论题还是挺值得探讨的，我们的情况也和楼上的类似。

从这篇文章学习中，我总结如下，欢迎交流：
1、在软件频繁改变的时候，不可能进行全面测试，但可以进行有效的测试；
2、有效的测试通过以下的策略来实现；
3、对产品功能进行重要性及风险评估，通过评估结果来平衡测试重点及测试时间；
4、在产品功能的正确性上有一个衡量的标准，以便测试时更好的发现问题；
5、自动化测试可以很好的解决这个问题（但目前自动化测试比较难实现）；
6、明确业务需求，设计好的测试用例是一种很好的补充；

作者: kkey 时间: 2004-12-15 19:09
这是我们公司常遇到的问题.我会尝试楼主的建议.

作者: 沐蓝 时间: 2004-12-22 22:27
在软件频繁改变的时候用自动化测试,是自寻死路.

作者: 嘘garfield 时间: 2004-12-23 16:06

Originally posted by indebted at 2004-8-3 09:50:
我想软件的改变就是同一个软件，但在测试过程中由于遇到了很多bug，使得开发人员修改时非常困难，必要进行功能或者某些模块的更改。还有就是客户提出的新的功能要求等。在整个测试和客户试用期间软件的更改可能是 ...

出现这种情况绝对是最容易让人疏忽的

作者: 嘘garfield 时间: 2004-12-23 16:08
标题: 我是一个新手
我在想:楼主的确介绍了一个好方法.但是在时间比较充裕的情况下,多做测试其实也是一个积累经验的好机会

作者: fox-inv 时间: 2004-12-28 14:54
做功能测试的时候用自动话测试工具，比如WR，如果开发一直是按照需求在开发而没有改变，那么用WR还不错，正如楼主所说，如果软件改变太频繁，那么我们用自动化测试就很不明智，因为我们需要改动测试用例，测试脚本。

作者: kittypp 时间: 2004-12-29 14:15
标题: 谢谢
我也经常遇到这样的问题，很头疼，现在好了，我可以尝试一下您的建议

作者: 森林一木 时间: 2004-12-31 00:06
标题: to 嘘garfield
不能用这种方式来积累经验啊：）

作者: hxf 时间: 2005-10-13 17:58
已经也遇到过这样的问题，感觉很迷惑。

作者: TestTip 时间: 2005-10-14 08:37
在软件频繁改动的情况下，更体现出测试经理的价值来。不同的角色有不同分工，测试经理在这种情况下更要指挥好，确定一个好的测试策略：
1 测试组应当及时知道每次变化的具体内容。否则就会出现测试时不知道什么是对的，这是不可以的。测试经理要去交涉。
2 不管怎么变，软件测试的基本要求不能变。软件都有基本功能，用基本功能来确定是否采用一个新的版本来测试。如果基本功能都错了，让开发人员去修改错误，不要浪费测试的时间。
3 测试用例及时刷新。
4 测试经理要给测试争取到时间。时间特别紧张的情况下，不容易发现bug。如果新的改变对测试来说是不可完成的任务，还是不要去改的好，至少要让决策层明白其中的风险。

－－－－－－－－－－－－－－
《我在微软做软件测试》在我的个人网站www.TestTip.com

作者: Jon 时间: 2010-11-2 14:13
首先非常感谢楼主给我们分享。
关于第一点我不是很赞同，测试的目的不单单是发现缺陷，发现缺陷多就说明测试的好，这种结论已在当前测试行业不认同了，不错上文中提出了寻找一种能代替之前的测试方法或工具的测试思想是非常重要的，也就是我们倡导的如何进行聪明测试，所以说敏捷的开发模式，或说敏捷的测试方式一定会渐渐运转起来，而且会融入项目开发模式中去，以后开发和测试的工作会协助的更紧密，其实保证质量不光是测试人员的事，PD、DEV和QA都是保证质量的关卡；
关于第二点我还是比较赞同，也就是我们要进行聪明的测试，那么怎么才能聪明起来呢，走捷径吗？必须通过提升代码的质量和自动化回归测试来改变目前的测试思想，首先我们要控制提测版本的质量，那么怎么控制，谁来控制？其实就要有相关规范和流程来约束开发同学，提测的版本只有达到一定的基准方才进行提交给测试工程师测试；关于自动化，其实是一个比较大的话题，属于测试行业中的一个技术领域，如果要谈起来的话，写一天也写不完，我想说的就是如何才能发挥自动化的带给我们价值，让自动化真正提升我们测试过程和结果的效能，这才是我们进行自动化的目的，而不是大家经常说的简单脚本开发、录制、回放等等操作上的功能。我的理解目前在项目中自动化可分为环境自动化（主要是环境搭建脚本自动化，一键式脚本搭建）、功能UI自动化（基于功能GUI类的功能自动化）、接口自动化（体现在接口封装类、MOCK技术）等，其实每个环节都可以再进行细分且可以深入优化的，有兴趣的同学可以和我再探讨的。
所以在当前我们软件频繁改动的情况下，测试方案和测试策略是非常重要的，我们要把改变的内容变成不变的东西，过程的沟通、评审环节将会占去我们很大的一部分工作，这也就是我上面提到的聪明测试，或者说敏捷的测试。

作者: corrine-li 时间: 2010-11-2 16:45
值得收藏

作者: mackeal 时间: 2010-11-9 15:15
我们公司经常碰到类似情况，测试主管也不知道如何去处理，尴尬

作者: helios 时间: 2010-11-19 11:16
同上

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)