大家讨论下关于测试用例优化以及减少测试用例的方法
大家好， 我目前身处一个test team的lead的位置。负责一个做了N年的项目，于是问题就来了，由于不断的有新的release, 导致TC的数量不断增大，现在已超过1W+了，如果还按照当前的模式，那么数量只会像滚雪球一样越滚越大。现在老大们意识到了这一点，让我们必须有效的减少TC数量，以及优化一些老的TC。因为数量过大，这个过程对于我来说完全是一个新的挑战。我相信大家的项目组曾今都或多或少遇到这样的问题，希望大家帮我出谋划策或share你们的经验。谢谢 都不知道具体用例的粒度和具体情况，怎么谈优化。让一个用例覆盖多个点；组合条件上进行优化，可以适当的减少数量。
但是，就个人觉得，你们的问题，应该考虑用例自动化和用例优先级重要性考虑（可以考虑只跑某部分重要的用例，时间有限的情况下）。
BTW，几年前你们的用例有更新过吗？ 用例的优化看你是以什么为目的，如果是以提高回归测试的有效性为目的，那么分优先级别，如果是以梳理业务的角度，那么分模块、分类，能帮你为测试提供比较好的指导，如果是要重构测试用例，你还是推到重来，前面的用例只做业务的借鉴。 回复 2# omg
你好呀，你所谈到的问题我也考虑到了，用尽量少的case去cover更多的检查点，但是有可能会导致部分case过长。还有，1W+的case 去go through一遍还是很花时间的，我们又不可能停下当前的测试工作full time的做这事，所以才头痛呀。 自动化我们也做了1000多个case。划分优先级的问题这个对于资深的员工还好，毕竟对业务熟悉了，对于初级的就很难了。
旧的case在每个release都有refine，但是还是更不上增长的速度。 我也知道肯定是我们design的粒度过小导致的 如果之前版本的功能相对稳定，可以考虑提取主要功能测试用例（优先级重要性体现出来了）；具体可以先按照详细测试用例走几遍，等各测试人员对被测模块都熟悉了，在一个版本中进行优先级标定，测试结束后提取（提取主要功能要狠下心来去删除，颗粒度要事前定好），之后测试就是：旧版本主要功能+新增功能的测试策略；至于你说的新人问题，可以按照3楼说的来让他们尽快上手熟悉业务 回复 4# zhouhuiri
长期计划啊，慢慢做。
优先级负责人分了，就行了，下面的人跑用例就行了。
粒度，可以有粗粒度，同时也保留细粒度的。 最重要的，还是你的目的。 本帖最后由 forstkksk 于 2013-7-27 21:16 编辑
做了一个已经持续了三四年的项目，两个月一个大版本，每个版本1K+用例
组长挑选重点用例作为每轮版本的预测试用例，
一般就是基础功能的测试，大概就是客户验收测试中的场景 回复 8# forstkksk
一般公司都是这么干的，全走的话吃不消的 有时间就做呗，这事情，不说了，有些人还是懂的。
页:
[1]
