黑盒测试和白盒测试(软件测试能报名吗)

软件测试现在算是还不错的一个岗位，现在行业里也有很多培训机构在做软件测试工程师方面的培训。如果对测试岗位有兴趣的话，还是可以报名参加培训，未来也有这样的机会。

测试工程师相对于程序员来说，门槛会稍微低一点点，但是未来的发展空间还是挺大的，而且要做精了，还是很有难度。从最初级的黑盒测试到白盒测试，然后进阶到自动化测试。未来其实测试工程师还是会和代码有很深度的接触。

至于测试能够干到多少岁，这个其实没有一个严格的标准，要看个人的身体素质和知识水平了。可能知识水平大家都能够理解，也就是能力强，自然就能够走得比较久。不过，身体素质是什么标准？

其实，在IT行业有一个没有明说的潜规则，就是测试的时间是最可能被压缩的。

可能对软件工程有点了解的人都知道，简单来说，软件研发的过程包括需求分析设计->系统设计->编码->测试->上线。当然，测试又分为了几个阶段，这里就不去再拆分了。而测试作为系统上线前的最后一个阶段，常常会成为项目周期紧张时被压缩的对象。

也就是说，原计划4月1日提测，5月1日上线，但是由于需求的变化，程序员呼呲呼呲的加班改功能，大呼4月1日不可能提测，做不完，然后测试的时间也就被压缩了。而这个时候如果你认为程序员给你的就是可以流畅的进行测试的版本，那就大错特错了。中间可能出现各种各样阻碍你测试用例执行的情况，最终结果就是，上线时间是推不了的，测试就来个007吧。

所以，拥有强健的身体，是做测试所必备的要素。当然，程序员也是一样的，只是程序员的坑可以留到测试阶段，但是测试的坑留到上线，那就会变成一口锅让人背了。

个人的核心竞争力与所在行业发展的趋势，以及随着行业及相关行业的发展对从业者提出的要求应该是有着直接关系的。

比如，十年前与现在相比，测试人员的核心竞争力已经发生了明显的变化。

随着敏捷、类敏捷、Devops等模式的引入，系统架构由单体架构到SOA再到微服务等架构的发展，以及数据治理、人工智能的应用，软件交付周期逐渐缩短，技术复杂度不断提升，对测试人员提出了越来越高的要求。

软件测试行业的发展现状

我们可以先了解一下测试行业的发展趋势以及随着相关行业的发展，对测试人员提出了哪些要求，我想若我们达到了未来发展的要求，那么这就是具备竞争力的体现。

之前写过《2018年度软件测试行业现状报告》的解读，其中有总结以下几点：

测试人员对需求分析的投入在逐渐增大，同时测试人员逐渐开始注重客户问题的分析，更关注用户体验和用户反馈。敏捷和类敏捷型项目已经占到了已经极高的百分比，而DevOps模式的使用已经持续数年稳定增长，DevOps正在成为软件交付的最佳模式 ， 同时我们发现瀑布或类瀑布开发模式比重逐渐降低。较去年，自动化测试技术比例基本保持稳定且处在一个高占比的状态。不了解、不使用自动化的越来越少。同时令人兴奋的是，发现越来越多的测试人员将自动化技术应用于日志和数据分析、综合监测。

敏捷及DevOps模式的应用，对测试人员提出了不同于以往的要求（以前测试基本上都在开发阶段之后和产品上线之前完成），使得测试人员在开发阶段之前加大了对需求分析等测试分析和设计（测试左移）、同时不断提高自动化测试技术的投入和应用、促使测试技术多样化（如，日志和数据分析，产品质量运营）发展（测试右移）。

同时，敏捷一直强调“团队为质量负责”，测试不再是测试人员的专属，这里我们需要重新思考下，质量由整个团队负责，那么测试的价值如何更好的体现——如何提高测试效率。

DevOps模式更是对测试、尤其是自动化测试、编码能力提出了更高的要求。

在这样的行业发展背景和趋势之下，我们不难得出 测试逐渐向测试开发过渡 已经是一种潜在或者显在的趋势，无论我们决定将来走技术路线还是管理路线。

若我们现在具备如上所说的测试开发能力，那么至少我们是具备竞争力的。

这里需要注意的是具备了一定的开发基础 并不等同于 能够做好测试，之所有测试开发成为一种趋势，是因为在具备优秀测试设计等测试能力的基础上，若具备一定开发能力和思维的测试人员，能够更好的从质量、效率、风险、成本之间寻求一种平衡。

什么是核心竞争力

什么是核心竞争力，我个人认为核心竞争力一定程度可以理解为不可替代性，所做的事情或者所具备的能力是否可以能被大部分人替代，这就是 是否具备核心竞争力的一个重要体现。

相对于测试而言，核心竞争力可以是在某一领域的专业性深度足够深。

比如性能测试，曾在一次互联网测试开发大会上，看见过某位前辈讲到过的一个案例：在定位某个性能问题时，挖掘到操作系统内核的深度，并且发现是因操作系统内核缺陷导致的性能风险，这个定位问题的过程及结果就是测试专业性深度的体现。

也可以是具备一定的测试广度，并且能够根据不同场景灵活适当的将其融合到一起，做到质量、成本、效率、风险的平衡。

比如产品迭代初期，一方面产品初步成形，需求变更频繁、功能稳定性差，同时受到客户和市场压力，往往迭代时间紧张，此时对于测试要解决的就是质量与效率平衡问题，自然而然想到自动化测试，然而这个时候自动化是不是合适的呢，显然自动化初期投入到项目的确能起到效率提升的目的，但随着迭代发展，会出现什么情况？需求变更引入的自动化维护成本，如果此时业务测试不具备测试开发能力，那么这个维护成本将变的更高，本来就项目时间紧张，自动化维护工作自然而然就变的力不从心，由此，一两个版本迭代之后，自动化测试就慢慢淡出了视野之外。一般来讲，需求度量一般要从最原始的需求开始，比如迭代初期项目时间紧，考虑到版本稳定性，通常不会选择自动化测试（除非自动化的开展或重构成本非常的低），而是从需求优先级、质量目标、测试覆盖等角度，对测试广度、测试深度进行测试策略设计，优先保障核心功能质量。这也是很多公司对测试开发的要求是首先要懂测试、然后懂开发的原因，能够对业务测试遇到的问题提出适合的技术解决方案，避免盲目开展自动化、工具开发，导致“药不对症”。

虽然我认为核心竞争力一定程度可以理解为不可替代性，但并不意味着封闭，反而要有更加的开放思想，帮助团队测试人员提升基础能力水平，提升他们对测试的理解和认识。进一步思考测试技术能力的水平赋能和流程能力建设，这对我们的发展有着更大的帮助，也是我们价值的重要体现。

同时，建议了解一下现有比较主流的开发、测试思想、模式，如DevOps开发模式、测试左移与右移思想等等；测试应用领域，如人工智能测试；测试技术，如数据、接口的自动化等等，使得我们对测试的认识具有一定的前瞻性。

白盒测试：

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。

黑盒测试：

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

最大区别：

二者最大的区别就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能。

去年我们公司将近20多人的软件测试团队，平均每天每人要加班3个小时。

IT互联网行业加班已经成为常态了，为了项目能迅速落地，抢占市场，只要靠人力投资，压缩项目周期。

但今年开始，测试团队在缩编，一直裁员。在帮同事二次推荐就业时就发现，要求变高了，以前基本是手动测试，功能测试，现在基本都要求会语言，会自动化测试，要写脚本。

软件测试行业，大部分人是非专业的，从培训机构出来，这个数量规模很大，将来工作竞争压力也不小。

至于和开发比，那开发基本找的都是专业的，难度也是很大的，我碰到过有开发做累了想做测试的，但没有测试想做开发的。如果说测试加班需要2小时，那开发的加班则是他的2倍。

在工厂中测试一般分为2种，一种是生产线的qc（包括qa）测试，一种是开发阶段的品证测试（软件+硬件）。

qc测试主要是按照作业指导书（sop）来进行，sop中指定的测试内容必须测试到，全测的产品必须做测试记号（每个人分配不同的记号），如是QA抽检必须记录流水号，抽捡合格才能Pass，不管是qc还是Qa都必须做好测试报表，测试过程中如发现问题要及时通报。

经测试pass的产品如果发现有不良，可重新拿sop核对测试，如sop没有指定测试该项内容则为sop缺陷。如sop有测试该项目且故障重现或故障不能重现，需工程师分析原因。

开发阶段的品证测试必须在测试前先制定测试计划，check list中应包含兼容测试、用户体验测试、ui测试、黑盒测试（有的公司同时要进行白盒测试）、性能测试、可靠性测试，当然要先搭建好测试环境。

做为测试人员只要严格按照check list的内容进行测试，做好测试记录，测试过程中我现问题及时通报，测试完成后输出测试报告并跟进bug的处理进度。

只要严接按照以上步骤进行测试，测试人员一般不会背黑锅。但，如果是自己的失误造型不良输出那就另当别论了！