内存储器：最小可用内存量。在同一时间打开很多程序，起码在客户端平台上。
一般要检查的地方
●检查错误消息和警告，是否会因为容量问题出现，并且是否有帮助，能被理解。
●数据是否丢失？
●系统有没慢太多？
●超时是否发生？在这种情况下也可能发生故障。
●如果这些看起来是好的，是否所有数据真的被处理或存储？甚至包括文件、对象或表的最后部分？
●数据是否存储错误？
●数据丢失或写入时是否没有警告？
如何查找测试条件
测试条件就是可能会发生问题的那个数据点。
找到是哪一个输入数据和输出数据发生在应用程序或功能项目里。
找到数据量的约束，特别是最大量和最小量。包括尤其是临时存储的数据或从临时存储区读取的数据。
对于每一个数据元素，查看是否会发生比允许值更大的容量值。查看如果数据元素被总计起来会发生什么情况。数据最大量是否会跑出界限？那么相加合计呢，如果很多对象都被相加起来？那样是否会发生溢出边界值？
如果一个数据元素是暂时存放的，多大空间是必须的？如果有很多这样的元素，这空间可以很小吗？
如果存在任何一种编号或编码的规则，规则里面是否会有约束条件，用来限制编码存储容量的扩展？比如，有两个字符字段，里面可能就不会有超过26×26容量之外的代码。
查找系统范围内的数据的边界值，比如硬盘容量的最大值，文件系统容量的最大值，最大文件长度，缓冲区长度等，然后观察其中任何一个是否会发生问题。
找出临时存储媒介的限定范围，像邮箱，CD,DVD,磁带的最大长度。
查找通信的限制，比如消息文件的超时和最大长度。查出在快超时前有多少数据可以传输。
寻找数据临时存放的地方。在那里找出存储数据、读和取出这些数据的功能。制作存储和删除两个过程的测试场景。努力找出该地方是否会填满或发生溢出。这需要长时间的场景测试，甚至可能需要调用随机生成函数。检查在发生很多交易记录后，是否会导致问题的发生。
容量测试可以被省去吗？
拿走容量测试的前提条件是，容量问题在早期测试的时候已经审核通过了，而且回答是非常肯定的。这表示容量已经在较低水平测试中测试过并核对过了，或者审查和结论已经是肯定的。
警告当整合多个独立系统在同一平台上执行时：必须保证每个系统都有自己足够的资源。如果某个系统不能保证平台上提供必要的资源，在这种情况下各种内存，所有系统一起的容量测试应在每个系统的最大数据量下执行。
核对列表：
如果至少有一个问题的答案是NO，容量测试就是有意义的。
●整个系统下的容量测试，是否在前面就执行过，然后结果是否被审核过？
●我们能否保证系统始终有他需要的内存资源？
●我们是否可以保证多个系统共享硬件？
●我们是否能保证没有比指定数据量大的数据量发生？
●假如存在数据容量超过了指定量，然后系统又不能很好的工作的情况，危险性是否是低的？
生成数据时的问题：
●记忆碎片难以生成
●生成数据的关系完整性
●键盘输入信息的动态生成
●数据应遵循的使用概况
版权声明：51Testing软件测试网原创出品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
