测试思路的整理
当接触到的一个完全新的需求，自己的测试思路：
1，功能测试：主要功能：核心功能、进入功能、退出功能、通信功能（平台如有）、附加功能
2，UI测试：轮廓、logo、视觉（颜色）、翻页、跳转
3，易用性：使用门槛（前置条件），使用体验
4，兼容性：测试环境（不同浏览器，不同系统）app/小程序 不同机型，不同的使用环境
5，性能：负载，性能，弱网
6，安全性：sql注入
有幸了解过一种很牛逼的测试模式：测试驱动开发
接口测试模式--TDD-开发质量的验收由测试的决定
***********************************************************
百度百科：测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
步骤：
测试驱动开发的基本过程如下：
① 快速新增一个测试
② 运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
③ 做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法
④ 运行所有的测试，并且全部通过
⑤ 重构代码，以消除重复设计，优化设计结构
简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。
**********************************************************
看了大概的介绍就是在说，是一种比较有效管理质量的方式，但是其中一点：先写测试代码，再写功能代码去满足测试代码，感觉还是有局限性，前置时间太多了，测试太赶反而会本末倒置，毕竟开发设计接口也是需要考虑业务的兼容性，或者开发可以做的更全面的设计，所以可以两路并发实现，只是要团队能力、质量意识、规范等条件事先做好规划
后来听过一个案例，感觉适合很多，讲的是一个在联想的测试做过，用在一个试点产品
步骤：
1，测试开发并行工作，开发写完代码、单元测试，测试则要完成接口自动化测试用例代码
2，开发先运行自己的单元测试用例，然后运行测试的自动化用例，
3，全部通过，则完成；如果没通过，转测失败。重新修改后，重复第二步，直到成功
要求：需要开发测试紧密合作，接口相关数据都要提供到，需要流程规范，能力匹配，质量意识高，双方出具测试报告
好处：回归快，新需求质量高，新需求对就需求的影响是否有遗漏点很快找到，架构问题很早发现
两方同时进行，过程持续沟通，也是一个可以提早发现问题的途径。
