持续稳定的交付产品提案No.7
目标：在每次版本发布时，保障产品的稳定可靠。
在软件开发中，从用户需求到交付可用的功能通常需要经过：需求分析、软件设计、需求拆分、任务拆分、编码、测试、验收交付等步骤。由于需求理解的偏差、设计的缺陷、编码错误等等原因，Bug会以各种形式出现在各个阶段出现。
我们如何能最大限度的降低Bug出现的频率和所带来的影响？
什么是TDD
TDD，英文全称Test Driven Development （测试驱动开发），是一套用于敏捷开发的方法论。简单来说，TDD是在编写业务代码之前，先实现测试用例，然后通过编写业务代码来满足测试用例的要求。
TDD的基本流程如下：
ATDD和UTDD都是TDD的实践。
ATDD，英文全称Acceptance Test Driven Development（验收测试驱动开发）
ATDD强调客户、产品、研发和测试之间的相互配合，对需求进行沟通、分解和确认，让团队中所有人对需求的理解达成一致。由测试定义能够满足业务需求的验收标准。再由研发根据验收标准编写业务代码，并确保业务代码能满足验收标准。ATDD的目标是确保交付的功能满足客户的业务需求，与 客户保持紧密的联系和协作。
UTDD，英文全称Unit Test Driven Development（单元测试驱动开发）
UTDD强调在编写业务代码之前先实现单元测试。在UTDD中，同样要求产品、研发和测试参加需求评审，要保证团队所有人对需求的理解达成一致，并对需求进行差分成更小的需求点，由测试根据需求点来编写单元测试，然后研发编写业务代码来实现这些测试要求。通过不断实现可通过单元测试的需求点，团队可以确保每个需求点的稳定可交付状态。UTDD的目标是通过单元测试来驱动业务需求的开发，提高了业务逻辑的稳定性。
ATDD适合满足客户的定制开发需求，保证交付的功能满足客户业务需求。UTDD适合在产品功能持续交付过程中，为业务逻辑的稳定运行提供可靠的保障。
如何使用TDD
在传统的“瀑布式”开发中，测试仅作为软件开发周期中的一个阶段。通常在需求研发阶段之后，交付之前，进行测试工作。一个用户故事转换为需求的过程，由产品经理参与和制定。之后需求交由项目经理，又被拆分成多个开发任务再分派给研发人员。研发人员接到开发任务后，开始编写业务逻辑；由于开发人员缺乏对需求的深刻理解，在业务逻辑的实现细节上存在诸多问题，在测试阶段往往会出现大量BUG，导致无法按时交付。
不同于“瀑布式”开发，在敏捷开发中，测试应该贯穿于整个迭代周期，从需求的理解到任务的拆分，从需求点的实现，再到最终交付，都需要有测试的参与，才能保证早发现早处理。
-
我们面临的问题
- 在需求分解阶段，团队没有参与验收用例的编写，只专注于需求点的拆分和研发任务的拆分。
- 验收用例不够详细，只列出了粗略的验收标准。
- 测试主要集中在研发结束之后，会出现由于对需求的理解不够透彻，导致推倒重做。
- 测试过于粗糙，功能点覆盖不全面。
- 开发新的功能时，影响了原来已经发布的功能，但测试时很难考虑到。
-
如何解决
- 团队中的所有人，参与到需求的评审和分解中，对需求理解达成一致。
- 需求分解过程，用例先行，通过对用例的设计与实现，更深刻的理解需求并推敲需求的合理性。
- 每个需求点完成后都要通过测试用例验证。
- 测试用例要有可维护性，在新增业务时，增加对应的用例，调整业务的同时，更新原有用例。保证新老业务逻辑的稳定运行。
- 在Jenkins流水线中集成测试，保证每次发布的版本都能通过自动化测试的验证，随着用例的覆盖率提高，产品的稳定性也随之提高。
- 使用合适的测试方法：
- 基于API的测试：根据API文档说明，通过HTTP协议，构建并向服务端发送HTTP请求，并对应答数据进行分析以验证接口的有效性。针对API的单元测试，粒度小，覆盖更全面，但实现成本也更高。
- 基于UI的测试：使用测试框架，通过编码实现对UI的操作；通常基 于验收用例，模拟业务使用场景，进行操作实现验收用例的测试。
- 基于SDK的测试：基于SDK提供的接口，通过编码实现验收用例。