一直升级的项目如何做测试？

Maisie_09

很多项目是这样的情况：每隔一段时间会发布一个新patch，测试的工作量在逐渐递增，越来越大。
eg：本来是项目A，第一个patch1时，工作量是测试1，回归A+1；第一个patch2时，工作量是测试2，回归A+1+2；……

对于这种项目，大家有什么好的建议？

xahuanyu008

现在的项目基本都是这样的吧，每次都做好相应版本的测试就行了，下次不需要再全部版本测试了吧

Maisie_09

回复 2# xahuanyu008

不做回归，貌似不行，以前的功能很容易出问题。

lzr2008

回复  xahuanyu008

不做回归，貌似不行，以前的功能很容易出问题。
Maisie_09 发表于 2012-5-17 10:22

    以前的功能出问题的原因是什么？当前发布的版本的功能影响到了以前的功能还是修改了以前的bug？
   这种情况可以考虑引入自动化测试。

lzr2008

回复  xahuanyu008

不做回归，貌似不行，以前的功能很容易出问题。
Maisie_09 发表于 2012-5-17 10:22

    以前的功能出问题的原因是什么？当前发布的版本的功能影响到了以前的功能还是修改了以前的bug？
   这种情况可以考虑引入自动化测试。

zurie

也是经常遇到这种问题，只能全部回归测试，测不到肯定会出问题

ffan1027

1、先要求开发人员自测，做冒烟测试，给出冒烟测试结果，保证主要流程能跑通，无二级bug
2、要求开发人员提交测试时，写修改记录，release note
3、测试人员先对修改及新增功能进行测试，第一轮测试肯定会发现bug。然后再对未作修改的部分做回归测试。第二轮及第三轮，也相应如此。如果人手多的话，可以分工，谁来做回归测试，谁来做修改点和新增功能点测试。

这样可以迅速发现问题，节省时间提高效率

Maisie_09

回复 8# ffan1027
总的工作量还是那么多，只是分了一部分给开发，我们开发不做测试的，做也是走走形式~~行不通

Maisie_09

跟大家分享：
Q：对于新产品和维护版的老产品设计的用例应该注意些什么呢?
A：新项目和维护项目从本质上看没有区别，维护产品，无非就是新增功能和缺陷修复两大类，和新项目相比，唯一需要注意的就是新增\修复的功能是否对其他部分有影响，这里就涉及到一个回归策略的问题——老功能要测多少。一般来说，需要和开发讨论确定受影响的范围，然后制定测试范围。当然最理想的情况就是整个系统全测，因为一旦系统复杂了，没有哪个开发能说清楚影响范围。
“新产品”在了解需求的情况下，先设计测试用例，再测试，避免发生遗漏。“老产品”维护，若改变了需求，依然先设计（修改）测试用例，再测试，避免发生遗漏；若项目紧急可先测试，再修改测试用例。
Q：对于产品的测试，每次更新版本的功能都不一样，而每次都要进行旧功能的测试，怕新增加的功能影响到周边的功能，怎样设计用例更加全面呢？
A：这是最常见的形式。可以分成新功能测试和老功能回归两块。新功能测试不讲了，你也清楚，老功能回归这块需要一个回归测试，视测试自动化的程度来定，自动化程度低，那就需要制定详细的回归策略，和开发讨论清楚新增、修改功能的影响范围，来定回归测试用例；自动化程度高的，那就直接全面回归就行了。

ffan1027

回复 9# Maisie_09


    工作是工作，如果你的要求就是走走形式还不如不要求。

wanghaibin

一定要注意（版本控制）

liute

做好缺陷管理

haha_faraway

回复 10# Maisie_09


    严重同意！呵呵。。谢谢分享

kkjjhhn1980

那你可以分版块或者分时间阶段测试，这个主要还是要跟开发人员多多沟通！

zhangxd12

先做修改或新增模块的测试再做回归测试

斯琴彪娃

建议考虑自动化测试

lintongyan

先跑基本功能，再在bug点多测测，晚上在跑长期