平时在公司做开发时间比较长，也有做大量测试相关的工作，关于如何更好的权衡二者的关系，如何更高效地去提高二者共同的效率，这成了我必须要面对的一个问题。今天就这个问题，我来讲述一下自己的一些观点。
在之前的瀑布模型中，团队成员一般都是先编码，然后进行测试的工作，但是这样的工作流程会带来一定的问题，很多东西其实在需求和设计阶段就应该提早发现的，现在测试阶段才发现，太晚了，修复的成本变得非常的大，消耗的人力物力也比较大，所以我们应该将测试放在软件开发的每一阶段，每一阶段都进行相应的评估，发现问题可以及时解决，让修复的成本降低。后面出现了敏捷开发的模型，也正好顺应了这个变化，可以做到系统的快速迭代。
在敏捷开发模型当中，整个软件开发流程大致分成下面几个：需求分析、系统设计、功能设计、编码，这每一步是对应着一个测试步骤，需求分析对应验收测试，系统设计对应系统测试，功能设计对应集成设计，编码对应单元测试。整个流程处于测试驱动开发的模式下，这样的前提下，重构的风险就比较低了。比如说，在打算添加某项新功能的时候，先不着急写代码，而是将各种特定条件、使用场景等想清楚，，为待编写的代码先写好测试用例和测试脚本。然后在集成开发环境去跑这些脚本，结果自然是通过不了，了解到没有通过测试用例的原因，有针对性地逐步添加代码。直到代码完全符合测试用例的要求，获得通过。测试用例全部执行成功，说明新添加的功能通过了单元测试，可以进入到下一环节。
另外在需求拆分和功能设计的阶段，最容易出现的一个问题是，用户、产品经理、开发与测试之间存在理解的不一致，导致后期的沟通成本较高，对于这样一个问题，我们要做的是明确需求，统一各方面人员的认知。比较好的一个方式是将需求实例化，比如登录功能，在什么时候才会触发验证码的出现，什么情况会锁定账户，出现锁定之后，哪些功能不给该用户使用，以及解锁的方式有哪些，各种方式的具体步骤是怎么样的，这些东西最好是用一个表格的形式去列出，去做进一步的说明，令各方的人员有一致的理解。
还有一个很重要的概念出现—DevOps，它的理念也可以很好的顺应我们这种敏捷开发的模式，DevOps讲究的是持续构建、持续集成、持续交付，它强调沟通、协作、集成、自动化和度量来帮助团队快速的开发软件产品，并有一定的质量保障。从研发周期扩展到部署、运维，不仅打通了研发的需求、开发与测试各个环节，还打通了研发和运维，适合SaaS和PaaS这样的应用领域。
开发、测试与运维紧密相连，互相依赖，当他们很协调地运作起来，整个软件开发的效率和质量就会有一个质的飞跃。
