产品需求下达之后, 测试人员标准执行方案！

大家好，我是你们的菜鸟小编！

今天给大家聊聊 需求下达之后软件测试人员应该如何做？这个点！

粉丝后台很多给我留言说新进一家企业整体测试流程不知如何走，希望我给点建议

所以我以个人经验特地输出一套标准化执行方案，希望大家有所帮助，文章很多方法是超级实用的战术，希望支持一波分享、转发、点赞

1.了解需求实际业务背景以及需求背后的意义 

a. 通过任何方式跟业务聊聊实际要解决的实际业务问题，或者想实现怎么样的效果

b. 这个环节一般可以确认产品宣讲的功能与实际的业务需求是否脱轨

c.  如果在这个过程发现与产品宣讲的有出入的点，记录下来，与产品确认斟酌，可拉小范围(产品、业务、项目经理、测试)二次会议

这个过程可能会有些繁琐，但是老三觉得这是一个很有意义的环节，充分体现测试的权重并且可能还会避免产品返工的问题

有时候目标就是一堆人坐在一起，喝喝茶，聊着聊着就清晰了

2. 画业务流程图

a. 推荐工具https://www.processon.com/ 在线画图工具

b. 画业务流程是进一步加深测试人员对业务印象

c. 业务理解的透，在实际测试场景中，测试更能发现潜在问题

d. 该流程图还可以分享给对应的项目成员，侧面体现测试工作的细致

3. 拆分功能模块

a. 推荐使用工具：xmind

b. 拆分每个模块，从客户端到服务端，按照业务的走向列出每个模块功能点，细到对应菜单、功能按钮

这个过程就好比阿米巴细胞，将事情细分化，一个点一个点覆盖，避免功能遗漏

4. 提取每个模块测试点

a. 推荐使用工具：xmind

b. 基于拆分出的功能点层级之下，根据测试用例编写方法以及个人的经验，针对每个模块的属性，梳理出有可能出现的缺陷测试的点；常规的测试点，需要充分覆盖

5. 编写测试用例(时间足够充裕前提下)

a. 推荐使用工具：Excel

b. 时间充分前提下，可以将xmind测试点进行分模块进行整理在excel中，这个过程需要编写人员补充操作步骤，以及一些前置条件

c. 在编写用例过程，可能还会发现之前写测试点没有想到的场景，此时需要补充测试点，以及测试用例

测试用例编写的意义在于方便后期其它人员协助你测试或者交接工作，所以大家要按照规范去写，毕竟是很耗时的东西，做就做清晰漂亮点

PS：其实如果版本是自己去测试，按照业务的熟悉程度，个人可以直接根据测试点进行操作测试，节约时间人力成本

但是作为测试最好还是输出一份冒烟测试用例给到开发进行版本提测前自测

6.测试环境以及测试数据的准备

a. 测试环境条件充裕的直接是由运维来搭，人员条件不充裕的是由测试或者开发来搭，这个过程值得操作，比起点点点这是个提升的机会

b. 测试环境搭好后，可以叫开发拿本地代码去测试环境调试， 这样提前发现环境配置的问题

c. 测试数据准备是测试必备的技能，一般都是操作数据库(修改订单时间、生成各种状态的订单等)

或者需要使用一些常规工具生成我们当前不存在的测试实例，例如非常规类型的图片、语音、文档等

7.测试时间/人力的评估

a. 根据实际开发的业务模块的范围以及开发的时间去评定

b. 例如此次开发的模块跟旧模块无关，都是独立的，开发10天，那测试就可以取开发二分之一5天上下可灵活调配0.2天

c. 如此次开发的模块跟旧模块有关，涉及到新老模块的联合测试，开发10天，那测试就可以取开发二分之一，加一天，6天，上下可灵活调配0.2天

  

一切的准备，以及精细化的操作，前提是为了交付给客户一个完美的产品

背后更是让自己养成一个良好的工作习惯，功能测试做的好，薪资一样20+

以上经验个人很受用，花钱都买不到，点个赞吧！

加小编微信加测试开发群

查看更多精彩文章，请订阅以下公众号

推荐阅读

测试总监 : "支付功能如何测试？"

阿里VS字节 ，offer选哪个比较好？

测试总监：" 你这么坚决离职，下家找好了吗？"