本文已参与「新人创作礼」活动，一起开启掘金创作之路。
多学些东西多一条路，自知自身算法能力不足的情况下，我开始逐渐将目光投向相对不那么卷的测开。
需求
开发以及测试其关注的核心的在于这两个字——需求。所谓需求，概念上我们将其定义为：
满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能
一般来说，需求是分为两部分的————其一，为用户需求，简单来说就是甲方所提出的需求，若是没有甲方，那么则指的是终端用户使用产品时必须要完成的任务；其二，为软件需求，指的是开发人员必须实现的软件功能。据说(毕竟至少写下这篇文章时，我还没有工作)，公司再进行开发时一般会将用户需求转化为软件需求，所以开发人员与测试人员工作时只需要看着软件需求就可以了。
需求是测试人员开展软件测试工作的依据。
一般来说，软件测试的基本流程是这样的：
业务需求->软件功能需求点->测试需求点->测试用例
描述起来就是：在具体设计测试用例的过程中，测试人员首先需要清楚每一个业务需求对应的多个软件功能需求点，然后根据每一个功能需求点对应一个测试需求点，最后再根据测试需求点设计合适的测试用例。
测试用例
所谓测试用例，是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例解决了两大问题：测什么，怎么测。
软件错误BUG
官方的解释在这里就不多说了，简单来说，程序运行时没有产生用户预期的结果，这种情况下都可以称之为软件错误。
软件测试的生命周期
软件测试的生命周期：需求分析->测试计划->测试设计/开发->测试执行->测试评估
各阶段细化
需求阶段：测试人员了解需求，对需求进行分解从而得出测试需求
计划阶段：根据需求编写相应的测试方案或测试计划
设计阶段：测试人员搭建测试用例框架，根据需求与设计编写一部分测试用例
编码阶段：单纯做测试的话一般是不需要编码的，专业的白盒测试人员可以根据已经编码的模块执行单元测试，进一步完善与细化测试用例并调整整个测试计划。
测试阶段：根据测试用例和计划进行测试，在执行过程中记录，管理缺陷，测试完成之后编写测试报告。
运行维护
描述一个BUG
针对BUG的描述在不同的公司之中一般会有不同的要求规范，不过大体来说还是要包括以下部分：
发现问题的版本、问题出现的环境、错误重现的步骤、预期行为的描述、错误行为的描述...
