[项目管理] 关于测试与测试设备的一些想法

QA如何跨岗

2019年SAFEe培训时，问一个系统测试同事，现在都不写用例了，这样主要工作就是重复：自动回归测试/升级测试/补丁测试/初装测试/开ticket/性能测试；有没有觉得厌烦？其实不应厌烦这样的重复工作；可以开阔一下思路，如果工作重复就说明有改进的余地。这些反倒是提升系统知识的机会，做自动化开发的机会，当然机会的存在，并不一定会直接提升自己；而是要主动深入，把握机会，才能得到提升。进而进化到开发，架构，需求分析岗位。当然毋庸置疑需要付出努力。

测试需要做适当的初步分析

测试除了需要具体基本的测试功底之外。从各方的设想，管理人员，开发，周围同事，还是需要一些debug问题的能力，即使不是那面强烈的能力，也需要基本分析能力（有助于增加自己的reputation）。

系统警告信息是分析问题的原点，如果有警告

系统警告信息是系统对于自身发现的问题，但是不能解决时，上报给管理员的一个警告。其中带有大量的有用信息，是分析问题的起始点。有时候测试开出问题之后，可能以问题描述作为问题分析的起始点，这样就有可能导致遗漏系统警告信息，因为测试可能没有注意到警告，在问题描述力没有提及。
最近遇到一个例子，说这个备板一直处于同步状态（从主板同步信息）。如果一开始就关注系统警告问题分析就简单了。

从开发者角度感悟测试

当一名好的测试，在遇到问题时，第一时间的应对步骤是：开个bug/ticket，或者主动分析一下，而不应该重装系统/重启系统等操作来尝试恢复。要正向解决问题，这样我们才有机会做de-bug操作，从中学到更多。即使是一名新手。而且经过多年观察，新手往往可以发现更多bug，这也就是新人无形中没有（不存在/打破了）老测试人员一些不好的固有思维/行为：比如遇到问题重启系统。
即使最后发现不是bug，我们也是从中获得了de-bug的技能。

关于测试环境问题的一个讨论

之前组会听到一个例子，说是系统测试和自动化测试两方讨论一个问题：自动化坚持要在跑用例时将所有的模拟器重启一下，保证环境干干净净。即使用例失败，也只是用例问题，不会出现测试环境问题。
我认为这不是一个问题正向解决的例子。会导致的一个问题，恰如同事所说：“自动化这样的操作，使得自动话完美的避开了我们要测的环境测试”。而现场的环境既复杂又掺杂难以预料的几率事件，我们想要模拟环境问题还来不及，怎么能忽略。
如果是正向分析问题，不只是可以发现产品问题，还可以找到测试环境的问题。既然是问题，如果可以正向解决是最好不过，即使是测试环境问题。

对于软件测试。如果遇到问题，只要是被说成环境问题，我们就有理由将其看成是一种推卸责任的借口。 环境怎么会有问题呢，环境没有问题，因为环境无时无刻不在变化，世间万物也都在适应环境。如果软件不能适应环境，就说明软件有问题，或者容错性差。
即使是载体硬件出现了问题，我们也应该追根到底找出来解决，提升硬件能力。
如果说硬件问题不好解决，那只是时间问题，时间到了硬件都要被淘汰。当然软件也会被淘汰，如果不做适应，淘汰的更快。

云化之后测试设备的管理

现在很多公司的测试设备都进入云化，以节约成本。同时会有专门的实验室人员来管理云的部署分配等一系列问题。普通用户很难访问平台主机。这样造成的问题之一就是，开发、测试访问平台主机，分析平台问题的能力在变弱。之前还记的有客户抱怨说你们支持对云环境问题分析的能力不行，这哪里是不行，根本就分析的机会都少。都是开ticket，让特定的实验室人员解决云环境问题。所以客户遇到问题时，如果牵扯平台相关的问题，需要加一个lab支持一块做现场问题分析。