服务器端模块测试需求的深度挖掘
列出一份开发提供的简单的不能再简单的XXX数据库提测文档，测试文档里没有提供任何有价值的测试信息，到底该从哪个方面考虑测试需求呢？
测试要点建议
测试1（正确性测试）
测试2（稳定性测试）
程序性能稳定，不出core
无内存泄漏。
测试3（性能测试）
对比性能和qps
第一锹挖谁？当然是对口开发同学！
除了需要跟开发同学了解清楚待测模块的具体功能点之外，以下问题也必须请开发讲清楚：
需求方是谁：数据库的需求方是哪些模块？注意，数据库的需求方应该不止一个，或许上线后需要支持
多个产品的多种数据存储。
[书签]记录下所有的需求方，如果能落实到具体接口人就是最好了。
上一代数据库的不足在哪里：长江后浪推前浪是有原因的，无风不起浪嘛，那么风是什么？测试同学需
要了解风的起因，一定是上一代数据库不能满足现有某些产品的需求了，才会推动重新开发二代新数据
库。那么以前的数据库是哪些方面存在问题？不能满足哪些需求了呢？为什么不能满足需求了呢？（你
们觉着这三个问题问的内容相同吗？）
本次新数据库的新功能是哪些：根据上一代模块的特点，通过跟开发沟通确认最新模块的改进点在哪里，
哪些功能是继承了一代旧版代码的功能，哪些功能是本次新增加的功能等。必须注意深挖技术实现！！！
这句话说起来容易，执行起来肯定是有困难的，必须具体情况具体分析，具体技术具体深挖，我在这里也
只能提醒大家到这儿了。不过，以数据库测试为例，用我微薄的经验提醒一下需要考虑的代码实现挖掘的
方向：内存数据缓存机制、内存数据更新机制、内存数据push到物理硬盘的机制、物理硬盘上的数据存储
机制、物理硬盘数据增删改的具体实现、随机读接口、顺序扫接口等等。
第二锹挖谁？应该是需求方。
还记得第一锹里挖出来的“书签”吗？他们是这次行动的驱动器，也是本次任务成败的关键所在，不挖出
他们的真实需求，做出来的东西就算技术再NB但没人用就是最大的失败。
上一代数据库的不足在哪里：什么？你看着眼熟？！恭喜你，你答对了！必须跟需求方确认他们认为之
前的服务不满意的地方在哪里，他们期望的功能和性能指标是什么。跟需求方明确了目标和需求之后，
再与开发人员的描述对比，分析双方描述一致和不一致的功能点，再次找各方确认目前的实现是否能够
满足需求方的要求。正所谓了解市场需求，才能为产品打开市场嘛，在互联网公司的技术部门干活，跟
做市场的道理是一样的。
将会运用在哪个运营流程里：运营流程是非常重要的，必须了解待测模块将要运行到实际流程里的以下各
项内容：实际产品的数据规模（预期可能存储的最大数据量），数据特点（是什么样的数据，key是什么，
value会是什么），数据类型，数据分类（是否会存储多种类的数据），各类型请求访问量（get请求、pu
t请求、扫库请求），请求访问线程峰值（多个client多线程访问的情况），请求访问性能峰值。了解这些
都是为了增加测试覆盖度，为测试提供相关标准
轮到第三锹了：挖运维！
疑问：咦，什么嘛，刚才不是挖过运营流程啦？怎么还挖？
回答：同学，别急，肯定是挖的内容不一样嘛！
以下就是需要找运维同学了解的具体内容：
1.将来被测模块在服务器上的实际运营环数
2.将来被测模块运行程序的服务器cpu、内存、硬盘等的具体情况
3.是否还有其他模块共用服务器？其他模块是哪种消耗类型：内存消耗？磁盘io消耗？磁盘空间消耗？cpu
消耗？网络连接数消耗？
4.能够接受被测进程对资源的占用最大值是多少？cpu占用、内存占用、磁盘io占用、磁盘空间占用、网络
连接占用等
5.再了解一下现在正在使用的、将来会被替换的旧模块，在线上运营流程的实际情况，与开发人员提供的
作对比：比如数据规模、数据特点等等
结束语
需求挖掘的方向取决于具体被测模块的实际需要，也许除了以上提到的各方之外，还可能会有其他的需求
方和相关部门。在测试之前一定要了解清楚跟被测模块有关联的所有部门，需要对各方需求各个击破，去
打破每个砂锅问到底吧。
学习了，很棒！
页:
[1]
