下面一节介绍解释了上面的活动图中每个环节的具体工作。
4.1.1 编写一个测试用例
启动项目时，我们就开始写测试用例，那么，我们从编写一个测试用例开始。这一步很明显是一个简单的过程，会进行一些机械化的工作。毕竟，在这一步，如果我们对问题的概貌和细节不了解，无论是否进行测试，都不可能写出代码来的。通常，这一步你需要接触到你不理解的问题的各个方面，并且你需要领悟待测模型，然后再去写自动化测试的代码。
4.1.2 执行所有的测试用例
测试用例编写完工之后，跟所有的测试用例一起执行，需要执行以下几步：
首先，最重要的是带有编译支持的IDE环境，这个会节省很多开发的时间。当然，由于我们还没有写任何代码，所有测试执行肯定会失败。
为了完成我们的测试用例，我们需要编写一些额外的代码并且考虑一下设计。这些附加的代码是为了让我们的用例编译通过。因为编译不通过也会失败。
当我们编译通过并且可以执行的时候，测试用例如果失败的话，我们需要最小代价调整代码让测试用例成功执行。这点可能听起来很恶心，但是下面一节的例子会帮助你理解这一过程。
还有一种方法，不需要执行所有的测试用例，你可以单独执行一个刚添加的测试用例，这样可以节省很多时间，因为在模拟器上执行用例十分慢。在一个个调试执行完用例之后，可以再一起全部执行一次，确保一切都可以正常运作。我们不希望加一个新功能导致历史用例执行失败，引入新bug，这种情况经常会出现。
4.1.3 调整代码
当测试用例顺利执行之后，我们调整代码修bug一定要干净利落，控制它的影响面最小。重构之后，一定要所有的测试用例成功通过，没有引进新问题。如果我们的测试用例都通过了，代码就不需要再调整了，也就是说，已经完成，可以收工了。
重构完代码之后，执行所有的测试用例是一种比较安全的做法。假设你重构了一个算法，提取一些变量，引进几个参数，签名方式变了，或者其他内容，这时候如果出现一个bug的话，通过执行自动化回归用例，就会发现问题。还有，如果重构的接口对应的自动化接口用例没有覆盖到优化点，我们还可以通过应用系统的自动化测试用例来发现。
4.1.4 优势在哪里
TDD的优点，个人觉得，在于你可以快速专注于重要的功能，不会去做那些可做可不做的功能，或者不会被用到的功能。不重要功能会浪费开发和测试的时间和精力。大家都知道，在项目实施过程中，有效管理人力资源对是否能成功完成项目有重要的影响。当然，TDD模式也不能不分青红皂白地用于所有的工程。我觉得跟其他技术一样，你应该用自己的经验判断和识别是否该使用这种模式。记住：没什么方案是一劳永逸的。
另外一个优点就是，这种方式可以保证你改代码之后，有一张安全网在后面做保障。每次你改一小段代码，只要有测试用例，并且逻辑没有变化，那么通过这些用例可以检查出来对其他部分有没有影响。
4.1.5 理解需求
在写测试用例之前，你必须充分了解被测对象。
我们之前提到，测试驱动开发这种方式，可以让你快速专注于核心目标功能，而不是在周边需求中打转。
将这些需求翻译成测试用例，在这个翻译的过程中，可以更加深刻地了解需求。当然，确保你做的这些需求都是最后会实现和验收的。我们经常会在项目进展的过程中发生需求变更，这时，就需要更新对应的测试用例，然后再去变更实现。确保项目实施过程中每个需求都测试和开发代码理解一致。
本文选自《Android应用测试指南》第四章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
