[项目管理] 关于测试与测试设备的一些想法
QA如何跨岗
2019年SAFEe培训时,问一个系统测试同事,现在都不写用例了,这样主要工作就是重复:自动回归测试/升级测试/补丁测试/初装测试/开ticket/性能测试;有没有觉得厌烦?其实不应厌烦这样的重复工作;可以开阔一下思路,如果工作重复就说明有改进的余地。这些反倒是提升系统知识的机会,做自动化开发的机会,当然机会的存在,并不一定会直接提升自己;而是要主动深入,把握机会,才能得到提升。进而进化到开发,架构,需求分析岗位。当然毋庸置疑需要付出努力。
测试需要做适当的初步分析
测试除了需要具体基本的测试功底之外。从各方的设想,管理人员,开发,周围同事,还是需要一些debug问题的能力,即使不是那面强烈的能力,也需要基本分析能力(有助于增加自己的reputation)。
系统警告信息是分析问题的原点,如果有警告
系统警告信息是系统对于自身发现的问题,但是不能解决时,上报给管理员的一个警告。其中带有大量的有用信息,是分析问题的起始点。有时候测试开出问题之后,可能以问题描述作为问题分析的起始点,这样就有可能导致遗漏系统警告信息,因为测试可能没有注意到警告,在问题描述力没有提及。
最近遇到一个例子,说这个备板一直处于同步状态(从主板同步信息)。如果一开始就关注系统警告问题分析就简单了。
从开发者角度感悟测试
当一名好的测试,在遇到问题时,第一时间的应对步骤是:开个bug/ticket,或者主动分析一下,而不应该重装系统/重启系统等操作来尝试恢复。要正向解决问题,这样我们才有机会做de-bug操作,从中学到更多。即使是一名新手。而且经过多年观察,新手往往可以发现更多bug,这也就是新人无形中没有(不存在/打破了)老测试人员一些不好的固有思维/行为:比如遇到问题重启系统。
即使最后发现不是bug,我们也是从中获得了de-bug的技能。
关于测试环境问题的一个讨论
之前组会听到一个例子,说是系统测试和自动化测试两方讨论一个问题:自动化坚持要在跑用例时将所有的模拟器重启一下,保证环境干干净净。即使用例失败,也只是用例问题,不会出现测试环境问题。
我认为这不是一个问题正向解决的例子。会导致的一个问题,恰如同事所说:“自动化这样的操作,使得自动话完美的避开了我们要测的环境测试”。而现场的环境既复杂又掺杂难以预料的几率事件,我们想要模拟环境问题还来不及,怎么能忽略。
如果是正向分析问题,不只是可以发现产品问题,还可以找到测试环境的问题。既然是问题,如果可以正向解决是最好不过,即使是测试环境问题。
对于软件测试。如果遇到问题,只要是被说成环境问题,我们就有理由将其看成是一种推卸责任的借口。 环境怎么会有问题呢,环境没有问题,因为环境无时无刻不在变化,世间万物也都在适应环境。如果软件不能适应环境,就说明软件有问题,或者容错性差。
即使是载体硬件出现了问题,我们也应该追根到底找出来解决,提升硬件能力。
如果说硬件问题不好解决,那只是时间问题,时间到了硬件都要被淘汰。当然软件也会被淘汰,如果不做适应,淘汰的更快。
云化之后测试设备的管理
现在很多公司的测试设备都进入云化,以节约成本。同时会有专门的实验室人员来管理云的部署分配等一系列问题。普通用户很难访问平台主机。这样造成的问题之一就是,开发、测试访问平台主机,分析平台问题的能力在变弱。之前还记的有客户抱怨说你们支持对云环境问题分析的能力不行,这哪里是不行,根本就分析的机会都少。都是开ticket,让特定的实验室人员解决云环境问题。所以客户遇到问题时,如果牵扯平台相关的问题,需要加一个lab支持一块做现场问题分析。
相关文章
- C# .net中获取台式电脑中串口设备的名称
- 分享45个设计师应该见到的新鲜的Web移动设备用户界面PSD套件
- USB设备驱动总结
- 利用useragent判断移动设备
- Qt编写安防视频监控系统61-子模块5设备控制
- OAK智能深度相机通过modbus tcp协议控制PLC设备
- SAP UI5 应用开发教程之三十四 - SAP UI5 应用基于设备类型的页面适配功能(Device Adaptation)试读版
- Atitit.获取主板与bios序列号获取硬件设备信息 Wmi wmic 的作用
- android 9.0实现通过系统属性控制挂载otg设备功能
- 大型物联网平台如何来保障亿级设备安全连接上云?
- 联想thinkpad笔记本 蓝屏后设备管理器里面独立显卡突然消失了
- HomePwn:一款专用于物联网设备渗透测试的“瑞士军刀”
- 关于如何解决甚多USB设备连接的问题
- 中职网络安全竞赛设备-----文件上传渗透测试
- STM32开发(13)----获取唯一设备标识符UID