测试管理 测试质量管理 (一)

陈子昂 · March 16, 2016 · Last by 吕明浩 replied at February 24, 2017 · 7578 hits

前言

测试需要基于高使用率,高复用,维护成本低的情况下去开展工作.否则一人离开一技失去对测试团队是有很大影响的.
开展非功能测试业务时需要评估工作量和定下固定维护人员.不成熟不用,开销高不用,也是很多企业关注的.
“测试是一个服务部门”质量把控的环节,当前工作中是如何开展的?
先确定每个阶段质量目标是什么,不应该区分测试的领域,质量关注是尽可能降低风险,尽可能在交付日期内交付1个符合品质标准的版本,让质量不会成为制约项目时间的要素。
鄙人当前阶段主要是用以下的方法:
一)版本隔离
二)版本控制
三)质量区域
四)不同里程碑SLA
五)测试模块(版本测试和专项测试)

开发完成度达到百分比的进度,取决项目的版本阶段。
从base,aplha,open_beta,close_beta,RC,release
在close_beta来根据里程碑最终服务标准来确定是不是进行下一个阶段版本,还是reopen_beta。
Base阶段测试可以不介入,除非是有技术难点,比如新引擎,新技术例如之前u3d进入国内,我就对unity3d是否支持os,杀毒软件会否误报,im工具组合运行兼容性,稳定性都进行测试评估。Aplha阶段尽早介入测试,在这个环节最好用的是W模型,对于测试人员素质需要前期的培训。
这里还是讲版本交付阶段的,主要是应对快速上线的。
在这里我之前想提及1个如何收敛缺陷的问题,因为这个是术 和质量保证这块是间接关系。
每个测试团队最好先好好挖掘缺陷管理工具的功能,初期花点时间培训,确保bugOR建议描述清晰,主题和系统模块分配正确,概率性问题描述清楚,问题发生环境正确,问题优先级合理,问题过滤器使用,热门问题和逾期问题跟踪等。

一)版本隔离

1.单独的测试服务器
Beta后由稳定的版本后,最好日常测试中研发版本和测试版本分成2个服务器,测试服务器由测试svn merge和服务端相关更新,这样可以规避开发版本产生的一些抛错混淆质量。

2.分支管理
实现分支管理的,第一步就是需要有集成编译的,hudson+svn持续集成编译发布。要实现快速上线的基础也是这个,需要非手动编译发布的环境,测试团队也要学会使用。
项目组和测试配合过程中,如果没有分支管理,将使代码版本隔离失去意义。分支管理可以具体看看svn merge branch,是最基础的。
如果面对海外版本和不同版本资源号差异,一定要管理好版本阶段的整包和当前版本资源号应用版本号的文档,这里属于测试内部的文档管理,也可以随时应答项目组问询版本号出什么版本的问题。

3.研发的版本交付出口
交付唯一出口测试,项目组版本提交后,测试服务器测试通过后,最终交付到运维手上,是测试给予的包。如果包含md5验证的文件,md5码以测试给予匹配。
当然如果封版本阶段,如果还有需求变更,有需求变更单,需要多方一起确定才能补充提交是最好的。

二)版本控制

1.维护测试最小密度-测试用例
包含测试点变更到测试用例维护,变更冒烟测试文档,冒烟测试控制在40分钟左右。
冒烟测试会根据简单操作常发的点,只要任务分解法,定期维护下,不用人力充足,也是可以执行的,测试用例维护也是,用例是保证测试方法大家一致和规避漏测的。
存在冒烟测试一般是beta阶段后,版本交付前会分三轮去执行。

2.版本交付测试流程控制
一轮测试主要是关注本版本新功能的测试,做好问题备注。
二轮测试主要是把所有模块的重要case过再回归一遍
二轮测试的多产问题的case上关注修改状态和是否需要特殊的测试。
三轮测试就是必修问题都修复后,进行冒烟测试或者快速复查,封版上线。
第三段是需要资历比较深的测试人员或者测试负责人变更下角色,确定版本发布时间和跟踪svn里提交项。
Svn里可以对单文件提取slowlog.把关配置表.
配置表相关的最好可以有检查工具,复用程序的读表和代码数据读入适用程序提供的接口.无论是程序还是策划修改,都可以察觉.
如果团队有能力做性能测试,最好做下基准测试,对比二个版本的差距,为何会有对应的性能参数变化,是否合理。
应对持续交付,需要做checklist
checklist是本期新增和优化内容,如果本期有额外产生问题没有修复的,需要滚动到下期,持续维护这份文档,文档可做为交付给项目组和外部用。

3.计划,每日汇总,测试数据采集
如果存在多部门合作的,我是会在每周分周三前和周三后列1个计划后,让所有测试人员明确本周目标和工作内容,同时如果有变更,也会对计划做出变更。实际上这个并不用人员充足的情况下都可以进行。
由测试经理对工作内容进行汇总,了解测试进度情况和阻塞项,由测试经理或者负责人去推动一些进度或者做接口工作。
每日汇总:任务完成度,测试负责人确认任务,bug新增,bug修复率,未fixed数量,是否存在阻断。阶段版本:问题top5的产生模块,测试密度(数字),缺陷收敛曲线图,激活率,不可重现问题占比,热门问题占比。
里程碑版本:历史遗留问题数量,高发问题区域,安全区,不可必现问题,非内网版本载体问题数量,测试密度,逾期问题总计等。
其中不要轻易做一些对项目帮助不大的任务,所以任务分配时有很大意义,除非是项目空闲期进行技能提升。
修复率没有改善,可以考虑适当堆积一部分bug,这里指挂起,挂在测试人员或者测试经理身上,根据开发节奏进行。

4.交叉测试(不是很推荐)
这里想提到,交叉测试存在必要性,在现代的质量里比较陈旧,交叉测试是可存在,但不是绝对需要,优点是易培训和管理。
建议是宁可用数据化去管理缺陷密度,激活率,阻断模块,逾期修复。交叉测试用于测试中后期,后期需要给予更稳定的测试,让测试人员固定负责一些模块是必要的。在项目多和人员不充足的情况下,我们也实现了很少加班。
交叉测试带来负面效果是测试成员对团队的依赖性,而且往往是一个版本后,如果次日进行回归,除非用例调整后,如果没有,只会让团队产生疲惫。当缺陷数量无法堆积,产生杀虫剂驳论后,会因为团队里不同的人测试方式场不一样,进行交叉测试。
这里有一项破绽,我们从何得知应该需要多少的bug才需要开启回归测试或者多少bug量才是不够的,还是需要回归数据化管理。交叉测试并不会影响是否漏测,只是面对杀虫剂驳论。不过在测试团队培养里,成员对于不同项的测试进行交叉测试熟悉是必备的。

5.适配测试切入点
适配测试在测试领域里可以拆成4部分(载体兼容,分辨率显示兼容,安装、反安装,机型适配)
除非这个引擎是团队第一次接触的,否则只需要在beta阶段的每个大版本进行一次。
第一步还是确保游戏引擎和载体的支持度。除了机型适配需要用到云测试,其他都可以使用adb shell来测试安卓的,Ios也有其他办法。

举个页游的例子:
适配测试由1个人专门花1~2天完成更合适,而不用由不同的人平时测试项目用不用的浏览器测试没意义,反而会把一些偶发的问题,误导成因浏览器的因素,会引导程序初步判断。
适配测试在交付环境中是很重要的,尤其是最终上线时。
游戏产业的测试人员配置通常不好,但很多模块的拓展,大有大改善,小有小改善。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 17 条回复 时间 点赞

看来是个PM.

#1楼 @t880216t nono,我是测试。这些本来就是测试的活,PM就算做也不专业,软件工程和测试不分家。

里程碑测试修复率和新增 都有应用的曲线,而你要完善这些曲线并让其健康,就要填充问题和修复率,于是有了目标。测试密度只是指引,这就是一些人的测试之道。维护目标,分析缺陷产生区域,分析偏差,解决非必现的,降低问题激活率,开发测试等和这些不冲突,我们的道。

#2楼 @jiazurongyu 那你总结也是够透彻的了,像你学习。

#4楼 @t880216t 测试在工序中是下游的,所以只能努力想办法了。

讲的挺好,流程是个很好借鉴的点,学习了,有机会实践下。

好专业。

写的不错,学习一下

#2楼 @jiazurongyu 很不错,有这方面的书籍推荐下吗

听君一席话,省我几本书啊!好文!赞!!

实在不建议做交叉测试,为懒人提供偷懒的机会。也让参与人员产生侥幸心理--反正我有问题他也测出来了就随便应付下吧

以前对这块忽略了,但是在工作积累中发现这些非常重要,否则比较混乱,现在工作模式跟你陈述的差不多,大大提高了测试工作开展,很不错,支持~

有没有尝试过探索测试方法呢 建议可以学习一下

3.研发的版本交付出口
交付唯一出口测试,项目组版本提交后,测试服务器测试通过后,最终交付到运维手上,是测试给予的包。如果包含md5验证的文件,md5码以测试给予匹配。
测试服务器测试通过后交付运维发布,发布后是否还会做线上验证?

#14楼 @mindysz 会的,测试服务器->正式服务器,线上会开设置ip白名单,测试先进去预先登陆。主要是验证增量更新的内容后,在关闭白名单发布给用户。用户上线后半小时到一定时间内,也会收集下用户反馈情况。

学习了

学习了,挺有用的。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up