持续交付四——测试策略的实现

如果从一开始测试人员和开发人员以及客户就能够一起写好自动化测试，测试就成了可执行的且从系统行为角度描述的规格说明书。如果编写的测试能够全部通过，也就表明所需要的功能已经全部实现了 。

关于测试的分类

• 业务导向且支持开发过程的测试：
  通过测试来证明已经得到了想要的功能
  Happy Path根据用户的动作，一定会找到应用程序中的执行程序。“given-when-then”的方式告诉我们我们需要通过现有的状态经过处理之后再达到我们想要的另外一个状态。
  Alternate Path 用例的初始状态，被执行的动作以及执行后的状态会有所不同，这些变化有时候形成不同的用例
  Sad Path用例或者动作的变化导致了错误
  最重要的应该写的自动化测试应该是Happy Path的测试，每个用户故事或者需求都应该至少有一个。
  如果应用程序比较稳定，首选Alternate Path ，通过用户定义的场景来进行测试
  如果应用程序不稳定的话，尝试使用Sad Path测试

• 技术导向且支持开发过程的测试
  单元测试，组件测试，部署测试都属于这一部分。并且由开发人员创建并维护。

• 业务导向且评价项目的测试
  通过手工测试验证交付给用户的应用软件是否符合要求。
  使用演示的方法来进行测试，每个迭代结束之后都进行演示，尽快发现错误。
  探索性测试通过测试的数据设计更好的测试
  易用性测试用来判断用户是否能很好的实用软件完成工作

• 技术导向且评价项目的测试
  对软件的非功能需求进行测试，保证安全性或者并发性。在特殊的环境下运行测试。

小结

对于不同的情况使用不同的测试方法，有确定的预期的情况下使用Happy Path测试，对于通过不同操作会产生不同结果的情况使用Alternate Path，对于非常不稳定或者需要处理错误的用例使用Sad Path测试。
在网上看到了另外一种解释的形式