项目发布总是要人肉回归很多应用，怎么办

chop123

项目中涉及到很多应用，测试通过发布之前总要回归很多相关的应用，在这期间发布的一些日常或项目，自动化脚本覆盖不全，大多需要人肉去回归，浪费人力，回归效率低。给正在做的项目或日常工作带来风险，这个一直苦恼着我，大家有什么好的办法和建议吗？请指点指点

archonwang

MIT方法。

wpyily

为什么自动化脚本覆盖不全？

ahtest

自动化脚本覆盖不全: 这是肯定的,自动化能代替手工测试是有限的,它的最大做用是在帮人做回归.

chop123

呵呵，偶来回答自己的问题：
在我们的软件开发过程中，只要软件发生了改动，不管是功能的变更、模块的增加或者bug的修改，都会对现有的软件造成影响，也就可能带来问题。当软件的 bug被发现提交后，有可能发生以下几种情况：a、追踪系统不够完善，该bug被疏忽没有得到修改；b、开发对于bug的理解不同，造成修改后的结果与期望仍不一致；c、理解不够深入，只修改了bug描述的表面现象，深层原因没有找到； d、bug被修改，但没有考虑到与此问题关联的其他模块；e、本bug被修改，之前被本bug掩盖的其他错误得以显现出来。回归测试正是为了检查以上情况是否发生，检验已经被发现的缺陷有没有被正确的修改和修改过程中有没有引发新的缺陷，以确保修改达到了预期的目的。
　　针对上面列出的几种情况，总结归纳出几种选取回归测试用例的方法：1、发现缺陷的用例，这些用例可以验证发现的缺陷是否得到正确修改，可以完全检测出上述 a、b中情况，在一定程度上也可以发现c；2、发现缺陷用例所在模块的其他用例；3、出错模块周边以及与其有联系模块的用例，这些模块的识别可以寻求开发人员的帮助；通过方法2、3，可以基本检测出c、d；另外，通过执行方法1、2、3选取的用例，也基本可以检测e的情况。4、软件的核心用例，这些用例应该在设计测试用例的时候就被定义出，它们体现整个软件的核心流程、必须实现、完成的重要功能点，回归测试时执行它们是为了确定本次修改对核心流程和重要功能是否造成影响；5、如果时间、精力、资源允许，可以再执行全部用例，不过一般很难碰到“时间、精力、资源允许”的实际情况。

　　回归测试一项很重要、但也很费时且重复性很多的活动，同时由于该阶段处于后期，也许错误都被正确的修复好了、也许没有引入新缺陷、执行了很多测试用例都没有再发现新问题（很遗憾，这些情况一般都不会发生），这当然是我们理想的状态，但也容易给测试人员带来疲惫感，所以我认为在回归测试中引用自动化是一项不错的选择，这里的自动化主要针对4中描述的软件核心用例，对于这些每一轮测试都必须执行的用例使用自动化，可以提高不少的效率！

flowingcloud

也遇到类似的问题。尤其是d和e的情况。暂时还未有很好的对策。

ymyfox

我们也是人肉，没有好的办法

peag

BUG的用例，有关联的用例，主要功能的用例

msnshow

没办法，自动化做不了，那就得人工去做

迪斯科

有耐心 沉着下 能进行重复工作

当初招聘要求上应该有吧