光荣之路：产品测试规范（二）

转载地址：http://mp.weixin.qq.com/s/mP6L7MfMCQLXmN0FQGVRVQ

需求梳理2

1.2.1 需求梳理

根据需求文档、需求规格说明书来对需要测试的功能点进行梳理，而且通过需求文档能够更加了解项目的业务场景，一般情况下，在项目中需求文档有3种现状：

1.  有详细的需求文档：

比较严谨负责的团队项目的实施是有详细的需求文档的，我们就可以详阅需求文档来进行测试点的梳理工作，对于需求中你认为不明确的地方可以找项目领导人进行沟通，做到对需求整体把握和理解，利于测试更好的进行。

2.  需求文档不明确即有文档但是文档很粗糙：

一般有两种办法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因比如时间紧张或者开发就是不愿意，那么就需要自己去沟通对于文档中不明确的点问清楚，切记不要含糊不清的测试，于人于己都没有好处。

3.  没有需求文档：

如果你运气很不好遇到了，虽然我很同情你，但是貌似同情没啥用，我们知道做测试很重要的一点是：我有一个预期，我要把软件运行的实际值跟我的预期去比对，如果达到了预期，那么就没问题，如果跟预期不一致那就是有问题。那么如果没有需求，我们该怎么办：

第一种靠嘴去问，大家去协调，协商沟通，然后大家都回答没问题了，我会自己写一个概要的需求描述，然后让他去确认，他说可以，那咱们就这样测，有问题就不断的口头沟通；

第二种要基于用户使用的场景和行业的经验来去做判断它是不是合理的。

测试计划 3

1.3.1 测试工具选取

测试工具说明：

以上列出了自己在测试过程中所用过的一些工具，每种都有自己的利弊和自适应的测试场景，可以进行参考和根据实际需求来进行分析选取。

1.3.2 测试人员分配

测试场景敲定以后，对于大业务量的测试工作或者团队合作测试的任务需要分配好各自的任务，让大家各司其职，如：测试环境梳理和搭建人员、测试数据准备人员、测试脚本编写人员、测试执行人员、测试日志收集人员、测试结果汇总分析人员，每个人可以负责一个模块或者多个模块，更甚者有的项目任务量不多，一个人搞定这么多部分也是大有人在，即一个人搭建环境、一个人准备数据写测试用例准备测试、收集日志进行分析，这对测试人员的要求比较高才能更好保证产品的输出质量。

1.3.3 测试业务场景选取

根据需求说明文档，梳理需要测试的业务点和场景，比如应用系统的性能测试，需测试nginx负载节点的性能情况，是否可支撑1000/s的业务能力，极限环境下支撑2万/s并发，节点接收报文常规为几byte，大报文可达到8k，节点支持分布式部署。则我们根据这些信息可以梳理我们需要测试的场景有：直接压测一台节点观察性能峰值、nginx负载一台节点的性能、nginx负载两台节点的性能、nginx负载三台节点的性能、报文场景为500字节、1KB、8KB、并发数为依次递增至1500并发(保证1000/s并发是否可以)，看是否满足常规业务处理能力，极限测试下并发数为2万，测试7*24小时，观察极限处理能力。

1.3.4 测试环境梳理

根据测试场景以及梳理的被测系统、压力系统、压力机情况、给定的服务器数量，绘制测试环境搭建图谱即每个应用系统搭建数量、各节点所在机器，如下图梳理了整个系统部署的流程及每个应用、监控工具、测试工具应该部署的机器情况，让人一目了然。

1.3.5 测试数据梳理

这里的测试数据内容很广，可包括测试准备和测试执行阶段所需要的一切数据来源，如：测试脚本、测试参数化文件、测试账号、辅助性测试程序等，即让测试工作更加有条不紊的进行，而不是等到测试时才发现这个东西要去找，那个东西又没有弄得自己手忙脚乱，降低测试效率。比如，下面是一段造数据的存储过程脚本：

（待续）