写论文思路被堵之后，上网翻看别人的博客空间，学习别人的测试经验。在新浪上发现了MonkeyTest写的东西，很是心动。
一个毕业才三四年的测试同行，居然已经出书并做出一定的成就，让我这个测试很受打击。不过也好，知道人外有人，天外有天，未必是件坏事。
这篇博文也是受他的文章所启发，想到的。
在移动应用的测试中，往往属于轻量化的开发。在模块功能完成之后，会提供版本给质量控制部门进行测试工作，但是问题在于怎么样叫模块的完成。
从我的角度来看，需要注意以下几点：
1. 开发自测
因为开发每出品一个版本，第一责任人是开发，简单的说，对于该模块，开发是否有信息进行交付？
所以自测的过程是必不可少的，不期望在自测过程中发现更多的潜在问题，因为那时测试团队的职责所在。但是作为团队的成员之一，开发要首先对功能模块中最重要的功能有个把控，达到了自己的要求，才能发包。
讨厌的是盲目的发包或者毕竟过自测的发包，对于团队，产品都会形成不良的影响。
其实这里是有个误区的，因为太多的开发觉得，我为什么要做测试的工作？其实在阮建工程，特别是敏捷开发的理念中，开发测试的工作时可以互换的，开发有时间可以去做测试，测试有时间可以去做开发的工作，一个团队，讲究的是快狠准，而不是其他。但是国内目前。。。
2. TDD 先行
在敏捷的团队中，TDD的模式如果用起来可能会好点，测试用例中需要实现的10个功能点，如果有6个是重要级别的功能点，4个是轻量级的功能点，如果开发在完成6个重量级功能点之后，其实已经满足了测试要求，可以发布版本进行测试。
但是必须强调的是，如果6个功能点完成之后，整个模块的系统没有串联起来，发包测试将是一种灾难。所以找到主干，并完成主干才是测试开始的关键。
3. 接口的稳定
在工作中，我也想达到一种的境界：在开始测试的时候，后台接口其实已经完成了测试，并稳定下来。这样测试的准确性和问题追踪的准确性才大大增加。
但是很可惜的是，目前还不能达到这样的境界。我在努力，团队也在努力。
总的来说，并没有一个完整的需求或者说可以测试的标准的界限，每个团队都不同，开发的经验不同，测试的流程不同，所以经验不可以套用。最重要的是自己分析。