系统测试中，还包括内存泄漏测试（Memory-Leak Test）、数据库测试（Database Test）。
内存测试主要针对应用软件的内存管理和释放机制，测试当大数据量传输、数据阻塞、频繁操作等异常情况下，内存使用和释放的正常性。
一般使用自动化工具来进行此类测试，少量的内存测试用例可并入性能测试用例中。
数据库测试是一类重要测试类型，主要测客户端与后台Server之间的数据传输、并发、准确同步等。
一般手机客户端和后台的各类服务器等都有数据交互，应当针对这些Server进行专门的服务器测试，其中数据库测试和文件系统测试自然是重要组成部分！
项目开发前期，即自Kick off至Alpha release阶段，跟随软件的快速变化，我们所做的是迭代测试（REQ Test/ Function Test/ Sanity Test）。此间每天采用CIS自动生成的Daily build，在更新版本上进行迭代式测试。在Scrum Team内随时与开发、产品进行沟通，快速反应解决问题。
项目中期，自Alpha release ~ Beta release阶段，功能模块已基本集成，需要开始执行大规模的系统测试，并穿插周期性的功能测试。测试频度和范围视项目的测试周期、人力而定，但一般开始要先执行一轮全面系统测试（Full ST），以正确、完整地评估软件产品质量。
之后再根据各模块成熟度和缺陷状况，决定如何对FT和ST进行针对性裁剪，选择新增模块、薄弱模块和重点模块的关键项用例来对软件产品做局部测试。
此期间延长软件版本的迭代周期，每周更换2~3个测试版本，而不是每天更新版本。但需随时监察Release note和与开发及时沟通，知道有较大的功能性改动或重要的bug-fix时，就及时更换新版本进行测试！
最后一个阶段——项目后期，也就是Beta release ~ Final/Product release之间的阶段，是产品发布测试期。此时已进入产品稳定和待发布期，在此期间，就不能像以前一样频繁更换测试版本了。一般产品质量较好时，我们采用每周更换一次新版本的更新频度。
在这个阶段内，需要做的就是针对发布版本（Release candidate）的产品级测试，包括所有系统测试类型、验收测试、缺陷跟进及处理等。
在产品发布之前1~2周，一定要最后做一次全面覆盖测试（Full Test），包含功能测试、系统测试的全部用例执行，以在最大程度上保证发布产品的总体质量！
如上所述，当功能测试、系统测试、缺陷数量等均已达QA所订的质量目标后，在正式发布之前，当PD/UI已完全确定、稳定时，我们要做一轮验证测试。
验证测试（Verification Test）是针对PD/UI/GUI的核查和验证，主要包括需求测试和UI验证。
需求测试是核查所有需求点，看其所标示的功能是否已在软件发布版本上正确、完整实现。
UI/GUI验证是核查软件产品的功能，是否与UI上标示的业务流程、界面显示完全一致，GUI中的每个Text/Graphic/Icon大小、颜色、色阶色深是否与定义一致。
最后一类测试，就是稳定性测试，主测两个指标——MTBF和MTTF，均使用自动化测试工具实现。
MTBF也就是平均无故障运行时间，应使用自动化Tool，在4台测试机上进行连续的、模拟用户行为的功能测试，取其均值作为考核指标。
另外MTTF测试是在Android系统下直接运行adb命令，模拟在测试机上乱点乱划的行为，考察无故障运行时间。这是另一类稳定性测试！
注意：为通过Alpha/Beta/Final release，我们有时会在里程碑截止日期（Milestone Deadline）到达之前，针对未达质量目标的功能测试/系统测试，再做一轮回归测试，以验证通过Release standard。
而各阶段测试期间，我们也会针对局部的重点问题、严重缺陷和关键功能，做一些针对性测试，如焦点测试、集中测试、探索测试、自由测试等。其实从真正意义上来说，这些已经不属于测试类型的范畴，而是一些不同的测试方法！
回归测试（Regression Test），是针对之前的一轮测试进行的再次测试验证，以达到QA定义的质量指标。FT/ST等都可以做回归，但以ST Regression较为重要。
回归测试的范围主要包括以下三部分：上轮测试中的Fail case，需重新验证看是否已Pass；目前遗留的所有缺陷，进行修复验证；针对缺陷集中的薄弱模块、重点模块，进行引申测试。
焦点测试（Focus Test）也就是专题测试。当测试过程中发现严重且普遍、涉及模块较多、影响较大的缺陷或问题时，应马上安排人手进行专门性测试。Test Leader围绕此问题设计专题测试用例，测试人员在执行过程中，也要自己进行思维发散和延伸，多做一些周边的操作测试，以在最大程度上发现可能的隐藏缺陷！
集中测试（Test Workshop），亦称圆桌测试，也是在产品测试过程中经常采用的一种测试方式。顾名思义，它就是把一群用户级测试人员集中起来，在一个封闭会议室中，大家围着圆桌共同进行产品使用和测试。这些人可以是真正不了解产品的最终用户（End User），也可以是相互交换测试模块后的专职测试人员。测试的目的就是为了集中发现问题，尤其是那些因测试习惯性思维和行为盲区导致的潜在缺陷和风险点。
探索测试（Exploratory Test），简称ET，其实是一种有导向、有目的的自由测试方法。它采用了一些科学统计和分析方法，针对性地对一些重要、关键测试点和模块、范围进行测试。主要由一名ET Leader做主导，负责定义Test point、安排测试内容/人力/时间、一对一开会讨论、总结编写ET Report等。
自由测试（Free Test）就很简单了，大家都知道，就不多做赘述了。FreeTest可以随便找人来使用软件产品，寻找潜在的风险和隐藏的问题。也可以设定特定的目标用户群，从其中各抽出一部分人来集中进行自由测试。这样对样本点采集的全面性和可靠性更有意义，有时我们也会这样做！
总之，测试类型千变万化，但万变不离其宗。我们在真正的测试项目管理中，一定要认真考虑、分析清楚当前处于哪个阶段、面临哪些重要问题、针对这些情况应采取何种测试类型来应对。
天底下所有的技术、知识都是死的，运用存乎一心，只有它们变成了你身体的一部分，真正能够掌握、运用和创新改进的时候，你才能说“我真的会了！”
