我们遵循敏捷开发模式，八月以来，尝试调整测试的重心和方法，目标是做到敏捷测试，测试要向开发行进！
开发和测试
- 测试和开发具有同等重要的作用
从一开始，测试和开发就是相向而行的。测试是开发团队的一支独立的、重要的支柱力量。 - 测试要具备独立性
独立分析业务需求，独立配置测试环境，独立编写测试脚本，独立开发测试工具。没有独立性，就没有一切。 - 测试要有编程能力
测试独立性必然要求测试要有编程知识，要懂代码（能看代码，会写代码），代码是开发团队的沟通利器！
能看代码，就可以直接看开发人员写的代码逻辑，有点 Code Review 的意思了；
会写代码，测试自动化就不是问题。
持续交付是我们的方向
- 自动化测试
- 持续集成
- 自动化部署
自动化测试金字塔
- UI Tests
也称 GUI 测试，我们暂时不涉猎这部分的自动化测试。 - API Tests
这是重点。我们当下提供的都是 HTTP API，相对稳定，适合自动化测试。 - UNIT Tests
在 iOS 团队有实践基础，随着测试自动化进展，后端会自然接入进来。
据 Google软件测试之道 介绍，谷歌的经验比例是70/20/10，即：70% 的 Small Tests，20% 的 Medium Tests，10% 的 Large Tests（对应UNIT / INTEGRATION / SYSTEM | End-to-End）。
自动化测试
- 如同业务功能测试是测试的基本能力一样，自动化测试也正在成为测试的基本能力。
- 在深刻理解需求的基础上，自动化脚本测例要能体现如同文本测试用例的基本编制要求：“精炼表达、主次分明、渐进可用”；
测试分类
- 前端 App 功能以手工测试为主；
- 前端 App 性能以工具测试为主；
- 后端接口拟全部实现自动化测试；
- 后端性能暂时通过静态分析在设计时予以考虑。
App 功能以手工测试为主
App 功能测试以手工为基础，可以继续实施以测试用例为核心的策略。
前端重在交互和展现，所以功能逻辑和 UI 测试必不可少。
App 性能以工具测试为主
对于App，则要使用工具进行性能测试，性能在用户体验中是蛮重要的，而性能的改善需要开发长期的努力。
要不断发现、开发和学习使用各类工具，以帮助我们更有效率地完成任务。开发工具时鼓励使用 PHP 和 Python来实现。
服务端接口自动化测试
对于服务端提供的 HTTP 接口，建议使用 PHPUnit 技术实现自动化测试。
- 测试用例
接口测试用例的设计思路直接体现在测试类和方法前的描述即可，不再需要在禅道上体现。 - PHP 测试脚本
测试人员要学习 PHP 脚本语言，进行测试开发编程，逐步提高编程水平，在人员招聘上也要有意识地搜寻测试开发人才。 - 测试类和方法的设计开发是逐步精化的
每个方法实现一个测试用例，每个方法都可以随着开发代码的完善而逐步完善，和开发相向而行，要体现尽早测试理念。 - 测试套件（test suite）的编写要满足不同测试类型的需要
要能体现：smoke testing、sanity testing、regression testing等等。 - 鼓励就 PHPUnit 和开发人员进行深度沟通、互相学习
PHPUnit 不仅仅可以用来进行接口测试，其本意是基于代码的单元测试。开发人员应当使用 PHPUnit 对重要的类和组件进行充分测试，切实提升拟交付测试的API接口的质量。
自动化测试的ROI
敏捷开发条件下，迭代模式使得代码量逐步累加，越靠后的迭代我们所面临的整合测试压力、测试任务就越大。
敏捷测试需要测试人员能够随时启动自动化的回归测试对马上发布的迭代代码进行快速验证。
持续集成
一旦实现服务端接口自动化测试脚本，则可以逐步实现持续集成。svn上服务端代码的任何变化，都可以自动启动接口自动化测试，对于任何错误都即时通知开发人员。如果测试通过，则自动和 App 进行集成测试。
自动化部署
有了自动化测试和持续集成这两个作为前提，经过自动化部署，就可以达到持续交付。本文不展开讨论此话题。
尽早测试理念
什么时候是合适的测试时机？答案是：尽早测试。扩展开来就是：
- 尽早测试 Test early
尽早测试，尽早集成，逐步集成，Small Tests 做的越多越主动。 - 经常测试 Test often
这时候，自动化测试的成本效益优势就体现出来了。 - 充分测试 Test enough
从产品构想开始，一直到线上运营、用户反馈，随时都是测试的好时机。只不过，不同的阶段，测试内容有所不同。
测试开发人员的基本要求
1、有理念：理解测试开发，会反向思维、探索测试
2、懂业务：了解用户，会澄清需求
3、懂代码：能看代码，会写代码
4、用工具：善用工具，会开发工具；
5、讲策略：手工和自动测试并用，讲求成本效益（手工测试是基础，自动化测试支持持续集成和持续交付）
注：微软的实践经验也深刻影响了业界对于测试的理解和探索。
** Sanity Test **
A sanity test is intended to provide quick assurance that a system change hasn't broken any key functionality. You normally do a sanity test only in situations where you have to fix something quickly and you can't afford substantial down time to do a full regression test - in which case you would typically deploy directly into production upon successful completion of the sanity test.
