软件测试你造麽？这些工程师是做什么的你造麼？

---

前言

软件测试你造麽？

现在，几乎所有接触IT行业的人都开始熟悉软件测试了。但似乎所有人的评判标准似乎还停留在“能更多更快找出bug的才是好的测试工程师”。仔细思考这句话，有错吗？好像逻辑上挺能说得过去，于是不光别人这样认为，测试工程师自己也开始这样考量自己了

这样下来，测试工程师就直接与“找bug的人”划上了等号。我挺想用本末倒置来形容这种现象，当然回想自己这几年多的工作，与这也比较类似。对测试工程师来说，目的是要保证产品质量，找bug只是其中比较重要的一个环节，但绝不是做好了这个环节就能代表自己很出色，因为你一定还听说过“bug是找不完的”这么个预言

那么问题来了，软件测试到底是要做什么！

这个问题有些纠结，因为翻开书，都会先把软件工程大篇幅描述一遍，然后告诉你一整套规范的软件企业流程，具体怎么用，几乎没有涉及。当你了解之后，进了公司，发现“我X，完全不一样”，说好的这些规范怎么都不执行，这个公司是不是不靠谱啊

答案当然是否定的，leader当然知道需求的变更、开发的延迟都会对软件质量带来风险，但是对当下的市场来说，按照流程按部就班肯定不符合大局。那么测试工程师要怎样适当地将风险降低呢？分享一些小经验，对于大牛来说直接跳过吧

熟悉产品各个模块
对任何一个产品，增加对产品的熟知程度总归不是坏事。当知道产品的开发逻辑是怎样的，便能很好的响应需求变更

举个例子，产品的需求原本使用A方案实现，却由于需求进行了微调，使用B方案将更适合。对于没有经验的产品经理，往往从开发那里获取方案，此时开发流程已经开始，调整方案将会增加工作量，带来风险是必然的，那么对测试来说，该如何给出建议？

如果对产品逻辑不知晓，当然是任由开发“摆布”，后期二次改动同样需要工作量。但如果熟悉产品逻辑，可以将两种实现方案进行比较，列出优缺点进行评估，最终采用更合理的方式解决问题

所以，对产品各个模块的熟悉是测试人员一个非常必要的能力

对于测试用例的优先级明确划分
在测试时，大家总是会忽略测试用例的重要性。一个产品动辄上千的用例实在让人头疼。但是，好的测试用例能够帮助测试工程师在时间紧急的时候提高测试效率

测试工程师对测试用例一定不陌生，但是挑选待执行的用例时往往比较随意，有一句话特别好，“差不多就行了”。但这个差不多往往是坑了自己，工作量变大，有效性可能降低，反而得不偿失

能做成自动化测试要努力
如果你有想法把产品的部分功能做成自动化测试，那么恭喜你，至少为自己减少工作量提高效率找了一个好思路。But，自动化没有想象中那么简单

首先，得要研究不同的自动化测试框架，并且找到当前产品适用的

第二，区分好产品模块，哪里适合，哪里不适合，比如UI自动化和功能自动化有可能选择不同的框架

第三，区分优先级，一般来说，使用频率高的模块优先考虑

另外，实现时一定要考虑方案是否完善，一个半成品的自动化测试代码更加坑人

介入需求一定要早早早
千万不要认为测试工作开始于开发的动工，了解需求对于测试工作太重要了。工作中，经常会出现产品经理描述需求不明确，或者产品、开发、测试三方理解不一致，提前统一战线必然有利于降低风险

同时，讨论评估需求时，测试工程师可以从需求的来源进行分析，提出这个需求是不是该这么做，虽然没有太多的工作量，但是对于产品的质量和可用性是很有好处的

下面是我整理的2022年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结

如果觉得自己落后了，不要找理由，不要找借口，首要是检查灵魂是不是懒惰了。如果觉得自己疲劳了，不要抱怨，不要气馁，首要是检查自己是不是方向需要调整了

理想再远大，也需要点滴的努力；口号再响亮，也需要实际的行动。不论你有多么宏伟的规划、多么昂扬的斗志，不去行动，终究是空中楼阁。千里之行，始于足下；漫漫长路，不如就从此刻出发！

---