移动开发团队的测试实践

     测试是软件工程过程的一项重要活动，其重要性、必要性无需多言，但是，在移动开发团队中，认真执行测试工作的却少之又少，没时间往往成为最有份量的理由。但这个理由在一个注重质量、注重代码长期演进的项目当中就站不住脚了，不久以后的几个bug、几次重构就要花费更多的时间。那么在移动开发中的测试要做些什么呢？下面就介绍一下一个Android开发团队的测试实践。 

     先来说 单元测试，这个最基础的测试却被用得最少，原因是要花时间写测试代码。但是，当做了单元测试以后，相信工程师会很快看到收益并主动爱上这个活动的。Android为单元测试提供了测试框架，即android.test包，像junit一样，具体的使用方法可以在SDK和互联网上找到很多资料。通常这个单元测试是由开发工程师负责编写、执行与维护的，对业务逻辑、数据模型等都非常有效。在Android的测试框架中还提供了Mock接口，也可以使用一些第三方的框架，都可以方便的进行单测。利用这类白盒测试，通过控制覆盖率，可以把很多集成测试中不利于触发的逻辑分支覆盖到，更早的发现问题，增强代码的健壮性。

     除了单元测试以外，测试工程师通常会使用Monkey测试，一般执行8小时左右，用于随机性的模拟用户行为，对产品进行 压力测试。

     其他更多的测试方法就是黑盒了，在移动开发团队中用到了准入测试，功能测试，体验测试，回归测试。

      准入测试用于开发工程师开发完的功能提交给测试工程师之前的自我检查，通过执行预先得到认可的最基本的功能测试用例，确认自己开发完成的部分符合需求。这一测试用于开发人员对照测试用例进行自我检查，防止功能遗漏，也是提高代码质量的方法之一。

      功能测试通常由测试工程师执行，对照更详细的测试用例进行细节测试，由于大块的功能逻辑已经在准入测试时被执行过，所以在进行此项测试时更加关注细节，关注非主线逻辑。

      体验测试是敏捷团队全员要做的事情，产品经理、交互设计师、视觉设计师等都要参加，属于随机型测试，测试内容自由决定，但需要输出测试结果，把发现的问题进行归类汇总，以供后续处理。由于不同的角色参加，每个角色更关注在自己的领域，所以易于发现策略问题、交互问题和界面的细节问题，包括动画效果、颜色字体等等，经过多轮的体验测试，也可以发现很多待调整的问题或bug。

      回归测试是由测试工程师在产品上线前的检查，把要上线的新功能的高优先级用例再测一下，同时过一遍历史积累下来的Check List，确认调试开关、混淆开关等非用户可见功能的状态。

     上述实践同样适用于iOS、WP等移动开发团队。

     总之，测试和开发是相辅相承的，角色职责要分离，质量目标要统一。人人都测试，质量有保障。（此句绝对是给测试做推广的！）

——欢迎转载，请注明原文出处  http://blog.csdn.net/caowenbin  ——
——欢迎关注微信号“曹文斌的软件思考”，共同探讨软件人生——