写在前面：测试是一门枯燥的行业，但也不仅仅是测试这个行业。
为什么写这篇文章呢？
想想已经很久没有写过文章了，在公司的每一天都经常更新内部的文章，在公司也被人成为文档小能手了。每天我都会去总结一下自己今天做了什么，明天应该做些什么。不断在自我反思和提升中成长。
工作了五年之余，说说自己对测试这个行业的看法，以及帮助即将进入测试这个行业的你提供一个更好的选择机会。
我为什么选择测试这个行业？
当初自己还是电脑的小白的时候，已经有很多人家里有了电脑这神奇的东西了。从选择计算机专业到计算机专业毕业，再到如今的计算机行业，每一步都不容易，每一天都需要不断学习。
无论是前端开发，还是后端开发，还是测试开发，甚至是软件测试，这些跟计算机相关的行业，一旦你有新知识没有了解的话，那么，你很快就会成为社会的弃子了。虽然，你可能会说，你现在的公司不需要学习那么多东西，但是，除非你不会跳槽，否则结果都一样。
软件测试这个行业，主要的职责就是发现产品的问题，帮助开发快速定位问题，协助开发解决问题，保证产品的质量。就因为可以提前了解用户没了解到的功能，这就引起我当年选择这个行业的好奇心了。因为这样自己很有满足感，很多用户不知道的问题，自己可以先知道，很多用户没了解的隐藏福利，自己可以先提前知道，这就是测试，发现很多人没发现到的好东西。
如何做好软件测试工程师
写在这里，没人能做一个很好的评估者，也没有很好的标准者，能做到的是，软件测试工程师保证产品的质量。
我们需要了解到的是，一个产品从研发到测试到最后的上线生命周期是怎样？
需求的提出 > 需求评审 > 进入开发测试阶段 > 开发技术方案 & 测试用例设计 > 开发 & 测试用例评审 > 开发 & 执行测试用例 > 开发 & 测试bug验收测试 > 产品 & UI验收 > 上线
从上面中可以看到测试介入的阶段是整个产品的生命周期的。从需求评审到最后的上线，测试都会参与到里面的对应角色。
那么既然知道我们每一个环节都少不了测试，那么如何做好一个测试工程师呢？
1. 需求评审中，我们需要参与的角色是围绕这个需求，是否在技术上会存在风险，是否会因为这个需求导致产品的其他功能出现问题，这方面会更加考验的是一名测试工程师的业务能力，对公司产品的业务能力，只有对产品有深层次的认知才适合参与需求的评审。
例如：一个国际平台，包含全球的语言，货币，在不同国家IP下的登录注册页面是不一样的。这个时候，产品提供一个需求就是部分用户使用Google登录可以使用one tap免密登录，直接使用Google账号实现下次免密登录。
虽然说，这个需求就如此简单，开发只要实现将当前用户的cookie记录在local storage里面，就可以实现产品的需求了。但是作为一个全球平台，要知道的是，国内IP是没有Google登录的。所以，需要对国内IP地址做区分了，一旦测试不了解这功能的话，可能就会造成国内用户也会弹出Google登录的弹窗了，这里的风险就是国内用户没有Google登录，而我们却提供了入口对用户的误导。
2.开发技术方案，需要测试参与其中的原因就是，技术方案不一定涵盖需求所有功能，测试应该在这个时候起到关键作用。开发的认知是，只要实现需求的功能，而测试的认识应该是围绕需求，是否对其他功能有影响。
例如：就拿上面的需求继续分析，按照开发的角度分析，就是实现用户缓存下来的cookie，只需要在local storage中做缓存就足够了。那么站在测试角度，如何分析这个技术方案呢，就是我们需要区分不同国家地区的IP地址
if country.get($ country).IP == china.IP || currency.get() == china.currency || language.get() == china.language{ main.run (platform) };else{ main.run(google.one_tap) }
这里的意思就是，如果用户进入的是国内IP或者选择是中文语言或者选择的是中文货币，那么就不应该展示Google的登录入口，我们就需要考量技术方案的问题，去帮助开发更好去了解产品的需求。
3.用例的设计，是在测试阶段最为重要的部分，也是考量测试能力最为关键的部分。测试能力行不行，就看你的测试用例设计覆盖程度有多少。
思考测试用例设计，就需要从测试的专业角度去出发。黑盒测试，白盒测试，接口测试，性能测试，兼容性测试。看起来很简单的测试行业，涵盖的技术却很多人不了解的。根据不同需求，设计最适合需求的用例，这就能提高测试效率了。
4.测试用例评审中，我们需要做的是把需求根据自己的理解讲解出来，不是产品的大致讲解，而是涉及到每一个功能的改动，以及每一个接口的改动，我们都需要体现在测试用例中，目的是为了防止产品以及开发没考虑到的地方。
5.测试中提的bug，这个环节，应该是开发吐槽最多的环节了。很多时候，开发认为这不是bug，这个bug复现不了，这个bug不会这个需求引起的，这个bug影响不大，这个bug不用管，这个bug后期再去优化....这都是开发不想去修改bug的理由。为什么不想去修改这个bug呢，是因为我们测试提交的bug，不够体现出现bug的严重性，对产品，对功能，以及对未知风险的严重性。很多人会觉得，这个bug的确像是开发说的，不严重，不用管，后面再优化。那么我拿一个例子出来，你就信了。
有一次测试的过程中，因为在测试app的很多时候，我们需要关注兼容性的测试。我们使用iPhone8-12的测试机进行测试的时候，都觉得没问题，但是当我对抓包进行分析时，发现，首页的页面加载比其他页面的要就一到两秒。因为需求改动了app的首页，一旦我们觉得这不是问题的话，那么就会存在的风险就是，有可能出现页面闪退的问题，可想而知，闪退的问题一旦发生在app中，用户的丢失量是多少，公司的损失谁能承担。谁也承担不了。
当时我对接口进行抓包，发现接口返回的图片是原图(2M及以上)，这就是造成页面加载慢的原因，每一张图片都需要花费2M及以上的流量，那么一个首页就需要几十M的流量了，想想，需要加载多久才会加载完，一次加载就几十M，多加载几次，就不难发现会导致闪退了。
这就是对bug严重性不够有风险把控的后果了。
6.测试的验收环节也是测试当主角的时候，因为在验收的过程中，我们需要完整地演示产品所需要的功能，还有符合产品需求的功能，还有其他页面是否会产生影响。
直到上线，测试都会在每一个环节中起到不可替代的作用。所以，这就是公司为什么需要测试工程师的原因，也是为什么现在的公司对测试工程师要求越来越高的原因了。在敏捷开发测试的环节，测试都是至关重要的角色。
测试工程师的未来之路
未来怎么走呢，现在可以给你提供两条路，一是管理，而是技术。管理的范围比较广了，一旦你对公司的业务很了解了，你就可以转项目经理跟进每个需求的进度；转产品，为公司的产品多样性贡献一份力量；直升测试管理，将自己的测试思想传承给接下来你管理的每一个小伙伴。
另外就是转技术了，哪些技术可以提供选择呢？同样是很广的防线，一旦你对前端的技术有足够的了解，以及你也热爱的话，那么就是转前端开发了；转后端开发，很多人觉得后端开发不就是curl的复制粘贴吗，是，首先你得有这个能力写curl；最后一个就是测试开发工程师了。到目前为止，也没有一个很官方对测试开发工程师的含义，所以测试开发是干什么的呢，那就得看公司的造化了。
测试的方向很多，能转的方向也很多，不转也可以。一个是深度行业的探索，一个是广度行业的摸索，都是自己人生色彩的浓重一笔呢。
码字不容易，如果觉得有道理的话，可否激励一下，点赞再走？
