测试驱动指引.docx

《测试驱动指引.docx》由会员分享，可在线阅读，更多相关《测试驱动指引.docx（6页珍藏版）》请在课桌文档上搜索。

1、测试驱动指引概念测试马区动开发(Test-DrivenDevelopmentzTDD),用一句话讲，就是写代码只为修复失败了的测试。我们先写一个测试，然后再写代码让测试通过。当我们在当前结构中找出最佳设计时，由于有足够的测试做保障，我们可以放心地改动现有设计而不必担心破坏已完成的功能。使用这种开发方法，我们可以让设计更加优良，能编写出可测试的代码，同时还能避免在不切实际的假设基础上过度地设计系统。要得到这些好处，只需不断添加可执行测试，一步步地驱动设计，从而最终实现整个系统。这种短开发周期的开发方式与旧方式有很大不同。我们习惯于先设计，然后编码实现，最后做一些并不完备的测试。(我们都是优秀的程

2、序员，很少犯错，所以稍加测试即可，不是吗？)TDD完全颠倒了整个过程。我们会先写测试描述出目标，然后写代码达到这个清晰的目标，最后再设计一一在已有代码的基础上找出最简单的设计。随着TDD不断深入到开发领域，这种测试先行的思想也不断向上深入到需求阶段，衍生出来ATDDxBDD等相关方法。目标通过TDD提高应用程序内部质量，通过ATDD/BDD确保交付客户的软件符合用户需求。即在编码层面，我们用TDD方法以测试驱动的方式编写代码。在需求层面，我们使用类似的BDD方法以测试驱动的方式构建系统。原则.先写测试代码，然后编写符合测试的代码。至少做到完成部分代码后，完成对应的测试代码。.测试代码不需要覆盖

3、所有的细节，但应该对所有主要的功能和可能出错的地方有相应的测试用例。 发现bug,首先编写对应的测试用例，然后进行调试。 不断总结出现bug的原因，对其他代码编写相应测试用例。 不断维护测试代码，保证代码变动后通过所有测试。 不断维护测试代码，提高测试代码的可读性与可维护性。 遵从测试金字塔,数量上来说UTBDD手工测试。规范综合必须：测试代码也是代码，需要源代码管理。必须：测试代码不需要再写测试代码，但需要代码评审。必须：单元测试、BDD测试的代码和项目代码放在同一个代码工程里，用不同目录区分。必须：用于回归的E2E测试代码可以放到与项目代码不同的工程中。必须：单元测试、验收测试以及BDD可

4、以自动化执行。必须：不同技术栈可以采用不同的自动化测试框架，但是都需要能够接入DevOps平台。即可以由平台触发测试，并反馈测试状态和结果。必须：每次push都会触发单元测试，并反馈测试结果。建议：每次push都会触发BDD测试，并反馈测试结果。建议：每日运行一次全量回归的E2E测试，并反馈结果。单元测试建议：工程名：ProjectNameUnit.Tests0如：项目工程为abc.service,那么单元测试工程为abe.service.unit.testso建议：文件名：ClassNameTestso如：bookService.javaz测试类为bookServiceTests.javao

5、建议：方法名：由三部分构成，name_oLmethod_scenario_expected_behavior,如：Add_SingleNumber-ReturnsSameNumbero必须：方法结构：遵从Act-Arrange-Assert结构。如unittestmethodstructure展开源码BDD必须：不要尝试用BDD取代单元测试！开发人员应该先干好自己的单元测试。建议：当项目中的BDD完整执行需要超过15分钟，改进测试代码。必须：BDD测试使用Gherkin风格的描述语言，即Given-With-Theno 建议：feature都放置在项目的srctestsfeatures文件夹，

6、可以按照不同功能集合，建立不同子目录。 建议：step定义放置在项目的SrCtestsfeaturessteps中，子目录结构与保持与features/子目录一致。 建议：每一组近似功能的测试，放到同一个.feature文件中。如：srctestsfeaturesseraccountsignup.feature,放入注册相关的测试。 建议：每一个feature包含的特性集，必须能够独立运行。不同的feature测试之间不互相影响。 建议：不要尝试通过文件名建立feature和用户故事的关联关系。如：features/SOtry_3897Llog_in.featureo推荐实践开发阶段QA为用户

7、故事编写BDD用例，完成后须于SDE/TPM确认。SDE编写单元测试与业务代码，并且协助QA编写BDD代码。.测试！每一次codecommit,DevOps产出2个结果：1-本次提交的UT结果；2-本次提交对测试覆盖率的影响。mergerequest产生后，每一次commit,还会多1个结果：BDD测试结果。建议每日夜间进行回归测试,并将测试报告推送给全体团队成员。QA协助TPM为下一冲刺的故事编写验收条件，只有验收条件通过BDD编写完成并通过BPM认可，用户故事才可以进入Ready状态。指标 覆盖率指标：包括方法覆盖率，分支覆盖率以及最后的行覆盖率 部署到生产系统的代码必须达到100%测试通过率 冲刺周期内每日构建的BDD测试通过率变化曲线。