随着系统
逐步成熟
每个版本包含新特性越来越少但是新功能对原系统影响有多大是我们在测试时需要重点考虑问题
此时就势必要进行回归测试而且系统越成熟回归测试比重也会越大这将会对测试工作带来不小挑战 在实际工作中
经常是
方面求全希望覆盖面尽量广避免漏测另方面求产出大量回归测试用例可能只发现很少问题投入和产出不太匹配会影响测试人员士气甚至测试管理者也会对这种投入产出有所质疑并且设计大量自动化测试脚本会占用大量时间 引子就说这么多
看看大家对这普遍问题有什么看法和建议 回答:
最近刚到新公司上班
面临比较突出问题是人力紧张由于公司产品用在Windows mobileMTKKjavaSymbianwebsite几部分测试人员<5(+上我)如何高效组织测试团队(Team)确实是个挑战？回归测试属于软件Software测试环节比较重要部分所以花费了些时间整理总结此文希望能给测试人员稀少产品或项目众多公司提供些建议: 所谓回归测试
即就是在软件Software生命周期中只要软件Software发生了改变就可能给该软件Software产产生问题；所以每当软件Software发生变化时 我们就必须重新测试现有
功能以便确定修改是否达到了预期目检查修改是否破坏原有正常功能 其实仅单纯从英文单词Regress很好理解:
to a worse or less developed state.即是退化衰退意思 检查软件Software从正常
稳定状态退化或是衰退到不正常工作不稳定状态 注意:回归测试不仅仅是针对在系统测试阶段
而是在软件Software生命周期中^_^ 如果以上
定义均明确后有效回归测试应从这几方面: 其实最有效
回归测试思路方法建立在开发测试库基础上；开发在创建测试库每次生成
新版本时都可以运行这些用例 只有有效
从源头避免风险才能有效进行回归测试(目前国内公司能从事此级别太少) 1 强调单元测试时加强回归测试
引入代码评审引入自动测试; 2 集成和系统级
测试时加强测试用例评审回归测试用例选择； 具体
选择可以参考以下几点: 1 开发设计测试用例时制定优先级
如高中低方便以后自动化或是策略选择； 2 配置管理时
引入测试用例基线管理有效管理测试用例； 3 定期维护测试用例增
删保持最新状态； 回归测试时需考虑效率和覆盖度有效配合
通常策略有以下几种: 基于风险选择测试:
哪些功能是软件Software
特色？ 哪些功能是用户最常用
？ 哪些功能出错将导致用户不满？
哪些
是最复杂、最容易出错？ 哪些
最容易扩散
？ 哪些
是开发者最没有信心？ 备注:只有有效
避免最大风险用户反感问题回归测试可以说达到了70%任务! 基于Regress衰退概念
测试: 开发人员修改
局部时可能已经处理了症状所以主要测试其被改变模块和它接口上； 但是也可能存在未触及到根本原因
所以需要测试周边及相互依赖性部分； 本身可能得到了修复但修复也可能造成其他所以有必要为每个修复设计回归测试 基于全面测试策略:
如果时间充足
资源齐全可以进行全面测试,最低遗漏回归风险但测试成本最高非上策! 其它
回归测试: 1 基于GUI方式
自动化回归测试技术 2 基于Ad Hoc 回归测试:增加随机测试
避免回归测试肓点 3 基于交叉测试:多人互动
回归测试尤其在核心功能点交互性比较 
最新评论