“对于移动互联网软件测试来说，一个什么样的版本才可以提交测试呢？有没有一个规范或标准？准不能提交上来测试了连最基本的功能都无法正常使用，让测试如何进行OR情何以堪？”
这点我简单说下我的看法。
首先其实并非有一个规范或标准，家家都有难念的经。就如同测试技术、流程本身没有标准或者规范一样，任何东西都只有参考性。最近的一些书，包括《打造facebook》《google是如何测试》的等，都是仅仅是可以获取启发，参考，并不能完全的复制。就是这个道理。
移动互联网迭代周期越来越短，意味着dev开发feature的时间被大大压缩，tester测试的时间也被压缩到了极限。在这种情况下，开发往往迫于各种原因会给出一个所谓的“feature complete”的版本，但是这个版本并不一定是象他们所说的真正完成。其实业界的测试们，你们拿到版本之后安装之后直接crash的现象相信也是屡见不鲜了。
标准和规范虽然是没有，但是就如我开始说的，可以借鉴，参考，启发，所以我这里抛砖引玉，大家一起讨论讨论。
首先我认为没有完成feature的版本可以测试，但需要保证经过了以下几个过程。
1.开发的自测。
这点可能每个企业做不同，根据具体的情况下而定吧。一般而言是需要测试功能的基本case或用户最常用功能路径测试等。但到底case是由开发自己定还是测试提供，这个婆说婆有理，公说公有理的事情。可随机应变。个人还是偏向于测试提供。毕竟很多时候开发认为的feature complete和测试认为的feature complete从原点上来讲就是不同的东西。当然开发的自测说的只是一种方式，最终到底是用automation还是manual的方式呈现没有定论，达到dev自测的目的即可
2.当然，上面一点至少可以确保安装之后不会crash，或者目前完成的功能不会在最基本的路线上“扑街”。但从我看来依然不是一个能够进行测试的版本。此时测试需要进行需求的确认，也就是说完成的功能和设计是否吻合，是否达到了计划的期望值？需求确认完毕后，需要从用户体验角度去提出一些疑问，虽然在设计阶段开发和测试已经质疑过一遍，但是当完成真正使用之后，肯定还会有一些体验不妥，或者反人类的地方（这个也许更多的和android，ios，wp等用户习惯，系统特性有关）。那么这个时候需要及时和设计或者需求方进行沟通，总之这样可以让测试和开发减少去做无用功
3.现在cs的app越来越多。如果是单纯的app，那么可能经过1和2就足够了。但现在往往server和client开发都是不同的人员。当他们对自己的server code和client code信心满满的时候，从他们各自的角度来讲的确没有问题，因为的确都完成了。但是版本是否可以进行测试，还需要测试验证很重要的一点，就是将app和server相关的功能串起来测试一遍（当然这里指的是最基本的功能的路径）。很多人会说第1点不是有了么？但往往第1点开发会去关心自己做的东西，集成在一起的话估计就要想到就比较难。所以这里还是需要测试去进行相关的验证
当然，总体来讲，很多开发会抱怨为什么要做测试，而测试也会抱怨，为什么开发出来的东西一坨屎，看都不看就扔过来。其实没有谁吃亏，谁不吃亏的。以上3点其实都很简单，浪费不了多少时间，但却可以将需求，体验上的问题极早发现，不会变成在项目最后阶段做无意义的反攻。
PS：这里还需要提到一点，测试做相关验证的时候，需要自己很明确哪些是bug，哪些是需求问题、体验问题。不要在bug上面和pm或dev纠缠不清，这样浪费大家的时间，最终导致项目delay就得不偿失了。
不知道有没有帮助到提问的朋友。引来更多的玉就好拉～～～～
By Monkey陈晔晔
