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

软件测试行业急需大牛

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

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

　　但凡接触过软件企业的人应该都知道，从公司的生态链来讲，软件测试属于最下游，这也决定了不少状况必需要被动接受。即便某个测试攻城狮理论知识丰富，辨识风险能力强，在测试中独具慧眼，可是一个产品需求的变动就可让他傻眼，接着很努力的去适应这种节奏。也许他抱怨，也许他吐槽，背后将产品、运营骂了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自动化和功能自动化有可能选择不一样的框架

　　第三，区分优先级，通常来讲，使用频率高的模块优先考虑

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

　　十，介入需求必定要早

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

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