软件做了微小改动后，该如何进行测试？

[dwchen1999]

下面是本人对这个问题的思考，请多多指教。若有谁有好的观点，分数本人大方。
一、问题的缘起
　　随着各个公司对软件质量的重视，软件测试越来越受到大家的关注。招聘软件测试人员的也越来越多。当然这是一个利好消息。不过我在一个颇有名气的软件公司做过几个月的软件测试，感觉跟想象中的软件测试工作相去甚远。其中，最让我感到不理解的是：当一个软件做了一些微小的改动后，整个软件需要全部测试一遍，即所有的测试用例得重新测试一遍。后来我到几个软件公司面试，谈起为什么离开那家有名的软件企业，我的理由就是对那种做法不理解。但是，几个面试官都认为那种做法是理所当然的。（呜，我没被录用！）再后来，我把这个想法和几个同事交流，经过充分的辩论，我的思路基本清晰了。现在整理出来，希望得到大家的指教。窃以为，这个一个具有重要理论和现实意义的问题。
二、问题的抽象描述
　　为了以后论述的方便，我把这个问题抽象出来，重新描述如下。（可别笑我罗嗦。）
　　问题：软件做了微小改动后，整个软件是否该完整地重新测试一遍？
　　微小改动的含义：软件的结构没有改动，绝大部分的代码没有修改，最典型的例子是：部分字符串常量变动了，比如菜单的字符变了。
　　整个软件完全的重新测试的含义是：针对这个软件的所有的测试用例(TEST CASE)都得运行一遍。

　 三、问题的分析
　　软件做了微小改动后，最自然的想法是只对修改过的部分进行测试。比如汽车换了一个螺丝，自然只是检查换上的螺丝及附近的一小块地方。反对的理由是：软件和硬件不一样，不能做类比，软件的任何微小改动都可能影响整个系统的运行；一个微小的改动，也许会出人意料地影响其他部分。
　　两种观点的出发点是截然相反的。前一种的出发点是：软件是按照已知的方式运行的，软件的改动对其他部分的影响是可以预见的。后一种的出发点是：软件的运行是不可预料的，软件各部分之间的关系是不可预见的。
　　客观的现实是：在绝大多数时候，软件是以已知的方式运行的，软件各个部分之间的关系是确定的；但是也有例外。用汇编语言开发过程序的人会有这种经历：即使仅仅改变一个字符串，整个程序的运行就完全变了。但是，用Ｃ等高级语言开发程序，修改一个字符串就引发出人意料的影响的情况是极少的。
　　根据以上分析，我们可以得出这么一个论点：如果程序只改变了部分字符串常量，况且程序是用高级语言编写的，那么不需要完整的重新测试一遍，只需检查修改的字符串即可。实在不放心的话，系统的主要功能再大致检查一下。
　　对于上面的论点，应该能得到大多数人的赞成吧。（有不赞成的请告诉你的理由。）
　　对于上面的论点有什么实际意义，也许会受到怀疑，或许你会说，只是改动一些字符串的情况太少了。你是对的，这种情况是较少，但还是有的。我就碰到过。对于很多网站项目，修改字符串的情况就更普遍了。遇到这种情况，测试起来是很不舒服的，因为你很可能找不到任何BUG。就我工作过的公司，对于网页（WEB PAGE）测试的要求是：一字一字的核对。你想想，只是修改了个把字符，就需要对全部页面一字一字的重新核对一遍，那时多么的枯燥乏味啊！若你不知道修改了那些字符串，那可更惨了。关于测试部门是否应该知道开发部门具体修改了那些地方，怎么修改的，我打算在另外一篇文章了专门讨论。
更进一步，我提出一个更具现实意义的论点：在软件结构良好的项目里，如果只是修改了部分模块，况且模块的接口很清楚，那么，通过分析模块之间的相互关系，可以只测试相关的模块及模块之间的接口。
如果这个论点成立，将是软件测试人员的一大福音。但是它涉及到的问题很多，比如：1）、测试人员是否应该知道开发部门到底修改了那些模块及是怎样修改的，测试人员是否应该了解软件的内部结构及实现情况；2)、这种模块间的相关性分析由谁来做，如何保证这种分析的正确性；3）、做模块间的相关性分析的”得“和“失”到底哪个大？如何权衡利弊？
这个问题论述起来确实复杂。留到以后再论述。希望能得到大家的反馈。

四、结论
　　”只要改动过，就要完整的重测一遍“不能奉为教条，具体问题要具体分析，不可一概而论。

[qiuafa]

劫分 & 捧场

[yukin2003]

如果改的那些完全獨立﹐則可以只測那一部分﹐如果與其它的有關聯﹐則應該全部測一遍。
個人觀點﹐僅供參考﹗

[cdy90]

我认为时间允许的话应该慎重些，进行完全测试，如果不行至少要对该功能模块进行测试。

[sunshy]

楼主的意见我基本同意，只是有几点个人看法，
1.随着自动化工具的引入，大规模的重用case成为了可能，特别是你说的那种情况，完全可以加个字符串匹配的校验点，让机器自己去跑吧，为什么还要人盯着核对呢？这样做，所费的功夫也就是开始录制脚本和以后的偶尔维护而已。

2，改动字符串这种情况确实不具备测试的普遍意义。我想面试你的人提出的问题也是“微小功能改变”的那种情况吧。在这种情况下，非常有必要尽可能多的覆盖所有相关路径（case），因为程序员很少让你知道这个修改所涉及的其他东西。
3。我们都知道，测试不可能覆盖所有bug，那么一点功能上的改动，他会在路径分支上引起什么样的变化？基于目前测试工程师面对程序的透明性，我觉得只有尽可能多的执行case 才能保证质量。
3。完全独立的改动，也涉及接口功能和数据，你肯定要在测试接口之前准备独立数据、测试独立的模块，然后再测接口，还有其他和他有路径关系的模块，呜呼~这和彻底的执行case已经没什么本质区别了…… 当然完全无关的确实没必要测，不过你能保证没有什么内存冲突之类的问题吗？:P


对于楼主的3个问题，我也谈谈自己的看法：
1。答案是肯定的。这样一旦出现了错误，你可以根据自己的专业经验进行有效定位。同时，对项目/产品的深入了解有利于你的case设计和数据准备。
2。模块间的相关性分析应该由项目组整体进行讨论、出一套结果、经过QA评审；或者至少要有PM和TM共同拿出结果。
3。得失问题很难讲，有时候可能把问题细节化，反而影响了效率。但总的来讲，测试工程师对模块内部及模块间关系有比较高的了解，对于测试工作利大于弊。

我所知道的工程实际是：项目的改动如果是受控的，那么每一个相关联的人都会得到通知。

[baoweihui]

就我们公司而言，改动必须通知到测试部门，测试和开发的有经验者一起对改动进行评估，根据进度和评估的结果来决定需要跑哪些测试用例。呵呵，当然有时间有人力就全部跑了，否则只能跑专家们认为需要重新测试的用例了。

[chico]

我就是那家公司的QA,现在到TA了，做自动化测试。
对于大部分的主要功能逻辑，公司以后希望用自动化测试，可能影响到的关键部分可以重点做人工验证。

但问题又来了，测试人员毕竟没有很好的编码经验，如何掌握所影响的模块？没办法，那只有根据具体情况而定了。

今后，国内对QA的的要求会越来越高，也只有这样，才是真正意义上的QA。

[webcat]

如果没有涉及程序逻辑的更改知识表面的更改，由测试人员验证一下就可以了，如果程序逻辑改变了，相关的测试用例就必须重新测试一便。