前一阶段测试发稿功能的时候，那就先讲一下发稿的需求，用户可以最多上传9张图片，文字与图片是二选一的关系。看到这个需求，那就假设图片是必选的，如何测试设计用例？
首先说一下前置条件，这是很多测试人员在实际工作中容易忽略的问题，但这又是至关重要的
前置条件：a.选择的图片存在b.选择的图片不存在（图片不存在，图片正在加载中）
情况a就不赘述了，下面针对情况b说一下
b1.从icloud库中选择的的图片尚未下载完成，会造成NullPointerException，因为此时相当于是没有对象的
既然是图片，就会涉及到图片类型，图片内存，图片张数，下面都是在图片存在的前提下设计的
1.图片张数：1-9（需求嘛）
2.图片类型：常见的图片类型.png,.jpg,.gif等
（图片格式是计算机存储图片的格式，常见的存储的格式有bmp,jpg,png,tif,gif,pcx,tga,exif,fpx,svg,psd,cdr,pcd,dxf,ufo,eps,ai,raw,WMF,webp等）
3.图片内存：小到100K，大到10M，一般大小为3-5M，当然测试的时候还可选取全景图和长图测试（内存大啊）
上传图片，就会牵涉到网络环境，比如wifi,4G,3G,2G,高延迟，以及网络切换等，这里就不仔细讨论
测试过程中，发现连续多次发送9张全景图后，应用就闪退了，查看日志发现出现了OutOfMemoryError，原来是出现了内存泄漏啊。为什么刚开始上传的时候没有出现？为什么多次发布后会出现这个问题？后来了解了OOM（out of memory）相关知识后瞬间明白了，终于知道为什么第一家公司的时候，那些偶现的问题在开发修复后，为什么让我们压力测试100次了
下面介绍一下内存泄漏和内存抖动
其实大多数App或多或少都存在一定的内存泄漏情况，这些内存泄漏可能存在于特定的运行环境时才会发生。而内存泄漏堆积会引发严重后果内存泄漏（OOM）。内存抖动是指内存频繁地分配和回收，而频繁的gc会导致卡顿，严重时和内存泄漏一样会导致OOM。
1.图片资源占用内存较大，所以需要申请的内存也较大
2.网络图片加载，资源申请，这也属于前者，前面b1例子
当用户退出此页面时，申请的资源没有被释放。所以用户在不用打开此页面进行操作时，会不断的分配所需资源，但是系统给应用分配的资源是有限的，当系统无法再给用户分配资源时，就会发生OOM。此种情况下，可以通过压力测试来实现。比较靠谱的方法是，针对用户经常使用的场景进行压力测试，过程中观察Android studio里Monitor里memory曲线图
下面就说一下之前出现的另外一个场景，恍然间明白为什么上家公司让我们会做压力测试，100次啊，200次的用例也有涉及
项目上线后开启了公测，第一个用户反馈在浏览动态过程中会闪退，当时就觉得应该是使用的手机太过XX了吧，所以也就没当回事，后面有第2个，第3个反馈...这就很奇怪了，后面开发说是发生了内存泄漏。用户在浏览动态过程中会不断打开动态详情，然后应用没有对动态详情页内存做回收处理，所以就发生了OOM