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