软件测试必须要知道十个关键点

Posted 2020-07-25

软件测试行业急需大牛

　　记得2年前刚毕业的时候听说了软件测试这个行业，当时也去百度仔细进行了一番搜索，评价基本千篇一律的看好。看好的原因在于，专家认为未来的互联网市场用户体验至上，而产品质量与用户体验有紧密的联系，自从近年产品经理岗位火了之后，人人都是产品经理的概念深入人心，但其实人人也都要具有质量观念，出色的产品质量可以提供更好的用户体验。

　　说被专家一席话打动有些牵强，当时就是因为自己的开发功底不足，退而求其次选择了杭州软件测试一家公司谋生。而生活中很多事都要亲历了才知道究竟是怎样~其实，国内的软件测试行业没有书中以及媒体描述的那么好，规范、流程都需要各个公司摸索制定。流程是否规范，对测试的能力要求高低，自动化与接口测试完善与否，很多工具平台或软件是否能够重复使用，这都说明着该公司在软件测试方面的积累。

　　但凡接触过软件企业的人应该都知道，从公司的生态链来说，软件测试属于最下游，这也决定了很多情况必须要被动接受。即使某个测试攻城狮理论知识丰富，辨识风险能力强，在测试中独具慧眼，但是一个产品需求的变更就可以让他傻眼，接着很努力的去适应这种节奏。也许他抱怨，也许他吐槽，背后将产品、运营骂了N多遍，但是毫无用处，产品运营主导必然是趋势，测试主导是做不出好产品的。

　　还有一个点的确争论了很久，就是关于出现问题承担责任的问题。如果产品上线没有问题那是皆大欢喜，如果有问题，几乎所有人都会把测试拉上一起垫背。他们会认为就算上游环节各种问题，但是到了测试这里就应该“合理把控”各种，将风险点罗列出来并告知各责任人，有时候一句“为什么没有测出来”竟让测试同学无言以对。

　　看了以上的内容，各位看官会觉得戾气太重，的确，测试的地位往往很尴尬，有种“别人狂欢有我毛事，出了问题我很悲催”之感。但不可否认的是，一个好的测试人员非常难得，懂业务懂代码，写的了接口测试，做的了性能优化，还能协调各种矛盾。所以好的测试可以成为好的开发，可以成为好的产品，可以成为好的运维……

　　一，软件测试要做什么？

　　在每个软件企业，测试人员参与的需求主要来自以下三个方面：

　　1，产品经理——针对产品本身，也许是功能优化，也许是模块新增

　　2，产品运营——将产品配合运营活动展开，用于拓展新用户及提升用户活跃度

　　3，技术人员（开发主导）——技术改造或代码重构

　　所以，对于测试人员来说，需要了解产品想怎么玩儿，用户会怎么玩儿，运营想要用户怎么玩儿，开发怎么实现，测试怎么进行，何为技术难点。我去！这是要把PD、运营、开发集于一身的节奏啊！

　　我相信在很多公司最了解产品的一定是测试，因为随着测试人员尽早的参与整个流程，就会接触所有的角色。所以总结下来基本就是测试比产品了解开发，比开发了解运营，比运营了解产品，还要最了解测试及产品质量。

　　二，软件测试工程师的几个阶段

　　各行各业的成员都有不同的能力阶段，软件测试也不例外。依据每个人的能力不同，所做的事情是有明显区分的，这里列出了常见的几种进行分析。

　　1，手工测试（纯黑盒测试），即使发现缺陷的能力非常强，也会很快遇到发展瓶颈，因为任何手工测试的风险都较高，并且投入产出比不尽如人意。项目变更后，能够复用的只有个人经验，对团队建立与知识沉淀是几乎无帮助的。（经验可以分享？谁能保证人人适用呢。）

　　2，黑盒自动化测试，稍微进阶了一些，提高了效率，可以做到定时自动执行，但是维护自动化脚本也是相当痛苦的，就算可以将一些代码抽象为公共模块，却无法避免前端的改动。目前产品功能自动化测试都基于比较浅的层次，所以是否开展、以多大范围开展是个值得仔细权衡的点。

　　3，接口测试（包括接口自动化），这算比较深入的，有时感觉当一个测试真正抛开了前端页面，从接口层面开始介入测试时，他才真的成为了一名合格的测试攻城狮。此时可做的内容如满天繁星，想象空间无穷。

　　4，性能测试，无论对于App还是后台服务器，性能都是非常重要的点，专业的性能测试攻城狮对单一方向的要求很高，对性能问题的嗅觉也会更敏感。

　　5，白盒测试，这个方向非常高深，真正的白盒测试是要能够去验证代码的正确性和有效性，这些攻城狮的水平应该高于很多开发。

　　好的测试真的很屌，不这样觉得往往是因为没发现。自己曾经“coding能力不够，所以入了测试这行”的想法真的是图样图森破啊。

　　三，软件测试工程师的职位

　　就像文章开头所说到的，好的软件测业发展试工程师不仅能在测试岗位上继续有造诣，也有能力从事一些其他岗位工作的，以下列举出常见的，当然跨度很大的岗位调动肯定也会存在，只是这更大程度取决于个人能力与喜好，很难通用。

　　1，产品经理：我一直认为测试转岗产品是很正常的，但是局限性在于测试能不能把眼光放高，原先是关注每个细节，而现在要考虑全局而有取舍。对产品的熟悉程度固然达标，但是能否将一个人的想法传递给你的leader及团队还需要多加努力。

　　2，项目经理：测试转项目经理的难度应当是最小的，许多能力是通用的，对技术的了解在一定程度也能够支撑，但是在如今的互联网企业都弱化了项目经理的概念，需要更快速的应对变化，去到一个逐渐被市场淘汰的岗位真的好吗？

　　3，测试专家：这就自动拓展到上文中的软件测试几个阶段了，如今的市场对专家级别的需求太急切了，软件测试在国内发展的年限不久，可想一个专家是多么抢手的。

　　4，运维工程师：这个转岗有一定的难度，但是如果本身接触的就是服务器的测试工作，并且对服务器的各种操作都很熟悉，转岗还是很有希望的。

　　四，软件测试工程师的一些误区

　　1，发现的问题停留于表面，而不继续深挖

　　2，对整个产品没有宏观概念，而紧抠每个细节

　　3，测试执行对于质量保障的作用不超过50%，真正想要做好，应当从上游开始慢慢规范4，一味相信自动化测试

　　5，不要认为测试工程师的任务仅仅是测试

　　6，不区分测试重点，认为测试做到大而全总是没错的

　　五，软件测试工程师的好习惯建议

　　1，先分析，再执行，这样会事半功倍

　　2，测试的最终目的是把控目的，不要想着找出所有bug

　　3，坚信测试工程师也是有地位的，对于产品、运营那些变态的需求学会合理拒绝，测试工作当然自己做主

　　4，MindManager、流程图等软件经常使用，会对你的思维拓展有帮助

　　但绝不是做好了上面五个环节就能代表自己很出色，因为你一定还听说过“bug是找不完的”这么个预言。

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

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

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

　　七，熟悉产品各个模块

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

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

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

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

　　八，对于测试用例的优先级明确划分

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

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

　　九，能做成自动化测试要努力

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

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

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

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

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

　　十，介入需求一定要早

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

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