Felix Krüger在德国布伦瑞克的BREDEX股份有限公司担任一名软件工程师。他在科特布斯的勃兰登堡科技大学研究计算机科学。他参与了各种移动和桌面客户端对企业软件系统的开发。在过去的八年，他在自动化软件开发的不同领域工作过。他对应付（基于Java和Eclipse的）客户端服务器系统，以及测试自动化系统和嵌入式软件很有经验。

　　“app”一词表示我们在处理“小的应用程序”。尽管在一些情况下这或许是真的，但本文中它是指用于远程监控一个机器不同部分（比如：灯，气流和位置）状态的相当大的应用程序。机器使用一个可用后端服务器访问的（我们的app通过因特网访问的）移动通信网络。总之，其复杂程度和一个桌面app相同。app的一个重要方面体现在不同的管理上。不同的客户群接受不同的功能设备，而不同的机器类型需要特定的数据陈述。这形成了一个充满变数的app——构建和运行期间其组件都是如此，这取决于我们想用哪一种机器。因此，这不是一个“小”项目。它不是一个伴随现有业务应用程序的移动app，它是这个业务流程的解决方案。会有一个更长的维护阶段来支持产品改进，新功能及更多的版本。App是机器的一个内在组成部分，且必须要有同样好的质量，实用性和用户体验。本文提供了一份该项目的概述，以及我们关于QA和测试自动化，持续集成和项目管理的决定和经验。

　　项目设置：一个概念，两个app，两个团队
　　项目使用SCRUM敏捷软件开发框架。一次sprint要花上两周，包括的sprint综述，回顾和规划。sprint综述是由整个开发团队，一两个客户代表，有时还有来自QA或基础设施部门的利益相关者执行。综述后客户会将规范细化。在sprint规划的第一部分——用户故事选择中，一名客户代表也要参加。这样开发人员可以规范细节提问，有时提出规范变化以允许app更多的“本地”行为。
　　重要的开发阶段计划要花上九个月。期间，团队规模会在8-13人之间变化，包括产品负责人和Scrum专家。波动一部分是跟了这个项目一段时间的学生，部分是因特殊原因暂时加入团队的专家。我们的目标设备是iPhones 和Android手机，尤其是iPhone 3GS及以上–(iOS 6+)，还有Android 4及以上。机器将被控制，服务器后端已存在，因此，我们的任务是开发app，包括用户界面，后端通信，变量管理以及特定平台服务（比如推送通知，地图或社交网络）的集成。为了保证佳用户体验，我们不会使用跨平台工具包；反之，我们正在开发两个独立的本地app。
　　开发人员被分到子团队中，子团队中都有各自的专家和平台。为了促进沟通，两队在一个网站上进行合作。因为这两个团队，产品积压由多数用户故事构成了两次，一个版本用于一个支持的平台。对于大多数用户故事，两个版本都是根据与iOS和Android不一样的开发流程而在同一次sprint中计划的。
　　实施了一个故事时，其结果会被拿来与其他平台的app相比。在sprint概述中，我们更愿意为iOS和Android平行呈现一个功能。通过这么做，我们可以确保我们为两个平台都实现了功能相同的app和相似的用户体验。除了用户体验，Android and iOS app还有相类似的软件结构，尽管是分开进行的。一个常见的软件结构文件中详细规定了数据模型，分层设计，屏幕流管理，变量管理以及特定域算法。因此，为第二个平台执行一个功能时，很容易理解模板，因为它是在同样的基础上执行的。因为不同部分和用户集成概念，这对视图实施却行不通——在这儿，开发是有特定平台的。

图1. 从移动设备到机器的通信设置

　　自动化测试
　　我们测试QA的挑战是：对每个app进行多个级别（单元，集成，验收，UI测试）的测试。因为我们想尽可能地自动化，所以我们有一个QA顾问，他是团队一员，推动我们的测试自动化。他负责测试规范和测试执行的审查。自动化测试的实际执行是由开发者完成，由一个为每个用户故事默认生成的测试任务触发。根据执行功能，，还有验收测试（自动化UI测试），单元测试和集成测试。测试总是特定平台执行的。在UI测试中，他们同步使用一样的验收标准。对于一个（UI相关的）用户故事中定义的每一个验收标准，都至少有一个UI测试。为了实现所有这些不同的自动化测试，我们使用特定平台框架。我们低水平的测试是分别使用SenTest或JUnit实现的。关于ios，额外的函数库像nocilla和JRSwizzle则被用于模拟。对于UI，我们iOS用KIF，Android用Robotium。Robotium Recorder（商用产品）已被证明可以帮助获得更稳定的Android测试并消除“假阴性”结果。尽管很重视app功能相同，但iOS和Android的导航和用户体验间的区别表明：取得并使用每个功能所需的步骤是不同的。不像在桌面领域，只是理论上有可能使用一个UI测试来覆盖超出简单概念的跨平台app。这有不利之处，会增加技术和精力；但是也有好处，能够使用特定工具解决特定问题。关于比例，人们常说UI测试应该是测试中小的一块。这部分是因为执行时间，也因为它们仍被视作难写和难维护的。我们的经验是：好要重新评估特定测试等级在每个项目中的比例。随着对客户验收越来越重视（敏捷项目和移动领域中都是），UI测试工具的稳定性越来越强，UI测试和GUI逻辑测试不该被忽视；确实，测试中单元测试的比重要高于UI测试。对于这个项目，我们有10%的单元测试，40%的集成测试以及50%的UI测试。因为我们从独立后端供应商那接收的产品中的质量问题（很差的接口规范），所以集成测试的数量只低不高。