现有的自动化测试有哪些不足呢：

　　● 自动化环境的部署略显复杂。让一个新人跟着文档部署好一套自动化环境，至少需要半天时间，要掌握基本的troubleshoting技巧，写自动化脚本，差不多需要一周时间。

　　● 自动化关键字的实现稍显复杂。部分原因是Domino这样的环境决定的。

　　● 部分自动化测试用例执行时间偏长。

　　自动化测试是个持续投入的过程，一套稳健的自动化测试能提高你对产品质量的信心。

　　2、迭代测试

　　基于这样的开发模型，每一轮迭代，和测试相关的活动有这些：写SRS（也可以RD写），SRS的review， 根据SRS完成Test Design，创建测试用例，测试用例review，一轮新功能的测试，每天自动化回归测试，发现问题，验证问题，又一轮新功能测试，后一轮full cycle测试，实现新功能的自动化，性能测试等。

　　四轮迭代下来，新增测试用例700左右，提的tracker有360多个。因为早期自动化测试的投入，大大减轻了后期手动回归测试的工作量。可以想象下，四个平台，每个平台又要支持多个操作系统版本，这样的测试工作量！

　　在每次迭代过程中，测试而言，有哪些地方可以做的更好呢？

　　首先，每轮迭代后，是不是可以做下测试用例的Refine，即新创建测试用例的优化，可能创建用例的时候时间比较仓促，对产品的理解不透彻，或其他什么原因，在执行的过程，或多或少都会发现测试用例的不合理，有些测试点缺少测试用例，也是当初的测试用例没有覆盖，有哪些地方需要优化的呢？

　　● 测试用例的执行步骤（Step）， 预期结果（Expected Result）。 可能是需求的变化，或则创建用例时理解的错误，按照步骤得不到预期结果，这时候需要调整执行步骤，或则预期结果。

　　● 测试用例的优先级（Priority）。随着测试的进行，对产品的理解也更加透彻，这时候对测试用例的优先级可能和当初写测试用例的时候有些变化。

　　● 补充测试用例。回过头来看那些已经发现的bug，你会发现很大一部分不是通过当初设计的测试用例发现的。这时候需要及时补充测试用例。

　　其次，每一轮迭代测试后，好好分析研究那些已经提交的Tracker， 整理统计这些bug，会学到很多。

　　● 在测试的过程中关注Bug曲线、分布。那个的测试理论“Defect Clustering”告诉我们bug总是喜欢扎堆出现，通过Bug曲线，你会知道那个模块这段时间需要重点测。下面这两幅并不是Bug曲线图，而是我统计的导致产品Crash的Bug的分布，能告诉我哪些模块的代码质量如何。

　　● 关注Bug的Root Cause。我觉得一个好的QA不仅发现Bug， 而且应该有意识的尝试提出Bug预防策略。通过把Bug分类，把Root Cause类似的bug放一起，你会发现很多Bug是可以避免的。比如，之前SEG在处理一个用户提交的bug时，发现这是由于用错了数据类型。而在这一版中，也发现了三四个由于用错数据类型导致crash的例子。如果能整理出来，给RD，让他们有这个意识，这样的Bug可以避免。下面这个图统计的是导致crash的Root Cause有哪些。

　　● 那些每个Iteration都会出现的Bug。四次迭代，期间都经历的UI的变动，每次添加一个新的Feature，都会在log数据库，Notification，隔离数据库中添加相关的UI界面。你会发现每次那些细微的地方，如log数据库中的delete records， log records， notification中新加的功能的条目， 还有那个Copy按钮，RD在第一次迭代的时候，不会注意到这些地方的UI也需要改动，在第三次迭代的时候RD可能换了一个人，这时候他也不会关注到这些地方，这种类似的问题，每次迭代都提，是不是可以在RD在做这一块的时候，给予些提醒呢？

　　● 通过Bug反思测试用例设计。当发现一个Bug并不是通过已有的测试用例发现的（这种情况很常见），特别是新功能，这时候我们可以回忆下当时设计测试用例的时候，是怎么想的，当时采用了什么方法，有没有更好的测试用例设计技术。上一篇文章讲的是这个问题。

　　● 通过分析Bug获得测试经验。近在看<探索式测试>这本书，书中讲到一些测试方法。比如取消测试法，看看那些提交的tracker， 在安装那一块，我们发现有好几个bug，都是关于“back”按钮不起作用的。再如，强迫症测试法，我们发现的一个类似的是，把我们的一个进程reload十次，crash了，另一个连续敲15次同样的命令，也crash了。我想说的是这些测试方法，测试经验的总结，而这些测试经验的获取应该是通过与Bug的一次次亲密接触获取的。

　　需要整理思考的还有很多，这次先写到这里吧。