“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测试。因为我们从独立后端供应商那接收的产品中的质量问题（很差的接口规范），所以集成测试的数量只低不高。
持续集成
我们使用带有一个基本的分支模型的Git作为我们的版本控制系统。它明确了一个主分支，发布分支，以及每个功能和bug修改的分支。用户故事完成后，开发者将一个功能作为一个整体合并到主分支中。为了保证不把不完整的功能整合到住分支中去，每个用户故事都生成默认任务。有验收（由产品经理和QA顾问审查）和代码质量（代码审查，静态代码分析，还有自动化测试）的默认任务。持续集成的基础是主分支，因为它应该始终包含一个“随时准备发布”的项目。每次提交（整合功能）都触发一个完整的开发周期，包含以下工作：
??更新/建立依存关系
??建立app（现在有三个不同的构建版本）
??静态分析
??单元测试
??UI测试
??通过内联网进行app分配
图2. 测试级别比例（最好的，典型的移动开发项目）
iOS和Android我们使用Jenkins，因为它是公司默认值，且由IT部门支持。尤其是在IOS开发中，我们遇上了(如果我们能选择Xcode服务器，就可以避免的)Jenkins的初期问题。但是，Jenkins中的额外插件最终使得将我们的IOS系统集成到CI中成为可能，比如，Clang Analyzer和管理环境变量或共享工作间工作空间的插件。
最后的思考：自动化在哪儿不起作用
和描述的一样，我们的流程包含各种帮助我们实现我们客户的高质量期待的因素。整个团队都参与质量流程，每次sprint中的项目都能保证高质量。这多亏了自动化测试的帮忙。但是有的地方必须手动保证质量。团队进行桌面开发时不一定能立即想到这些，它们都列在下面了：
??实用性和用户体验：
这是人们广泛接受的必要的手动测试，但是移动app的客户很重视质量。随着指令的难度增加和方向的变化，我们发现我们必须更加重视质量——测试由团队及客户代表手动执行。此设置中，是由客户来确保不同设备作为其手动验收测试被检测的。我们自动化测试被限制为一个平台一个版本。
??国际化：
多语言桌面app中的正常流程是：让讲本地语言的人检测字符串，在app文本之外。由于显示屏尺寸变小，我们计划的超过15种语言的国际化比桌面app的更耗时间。我们的转换是由外部员工执行的，每次转换都必须手动测试以确保其在显示屏上使用恰当的空间。我们使用我们的UI测试通过创建可以被转换团队审查的自动截图来支持这个。
质量最重要——即使（尤其）是对于app
本文表明：app开发要求至少要有与桌面商用app同级别的测试策略及质量保证工作。在某些方面，因为为两个平台开发一个app的挑战，对于高质量工作的要求更高了。从许多方面来说，我们可以看到移动开发不会改变要求的质量工作。不过能改变的是特定工作的相关性或重要性。对我来说，这在我们单元，集成和验收测试的分配以及在（一个非移动项目中并不重要或并不花费时间的）手动测试中很明显。我们的结论？质量最重要——知道你要测试什么，为什么测试以及如何测试很重要。即使是对于移动app来说。
本文转自：http://www.spasvo.com/news/html/20141224140712.html