开发管理 CheckLists(14) -敏捷开发-故事验收测试

注： 开发管理 CheckLists-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     开发管理 CheckLists   专栏

接着上篇 "估算故事"讲，故事估算完成以后就要开始考虑如何进行验收测试了，只有验收通过故事才算开发完成.

对于一个故事，开发人员和客户可能会讨论很多，讨论的内容可以以测试用例的形式记录下来，这样就为我们故事测试做了铺垫，目前敏捷开发中测试大约有如下2个步骤

 

    1、将测试要点记录到敏捷的故事卡的背面，任何时候发现新的测试，都可以记录到故事卡背面

    2、将测试要点变成全面测试，这些测试用来演示故事已正确、完整的实现

 

下面说一下什么时候写测试用例，以及测试的方法。

 

 在编写代码之前写测试

      验收测试可以为程序员提供大量的有用的信息，经常的看验收测试说明可以保证程序员不去写那些不符合测试说明的代码,应该在如下时候写测试 
      1、开发人员和客户讨论故事且需要记录明确的细节时
      2、在迭代开始时候、在写代码前作为一项专门的任务
      3、在开发中或者任何时候发现新的测试时

      可以使用如下提问的方法来收集测试用例 
      1、关于这个故事、程序员还想知道什么？
      2、对怎么实现这个故事，我的想法是什么？
      3、有没有特殊情况会使这个故事有不一样的行为？
      4、这个故事什么情况下回出错？
 
客户定义测试 

      客户可以和程序员与测试人员合作创建测试、但是客户至少应该给我们详细的指出一些测试，用以验证故事的实现是正确的

   

  1、测试是过程的一部分

      测试是开发过程的一部分，而不是编码完成后要做的事，这点对使用用户故事非常的重要。

  2、多少测试才算多?

      只要这些测试还在继续为故事增加价值和是它更加清晰，客户就应当继续写测试。

  3、测试类型

       1、用户交互测试，保证所有的用户交互组件如期工作
       2、可用性测试，确保程序好用
       3、性能测试，测试应用程序在各种负荷下的工作状态
       4、压力测试，使应用程序在用户和事物的极限值情况或其他任何让应用程序处在压力下的运行情况运行
验收测试总结

       1、验收测试可以用来记录客户和开发人员讨论的工作细节
       2、验收测试即可了有关故事的一些假设，这些假设可能还没有和开发人员讨论过
       3、验收测试提供可检查故事是否被完整实现的基本标准
       4、验收测试应有客户来写而不是开发人员
       5、验收测试应该在程序写代码之前就写好
       6、如果新的验收测试对阐明故事的细节活意图没有任何帮助，就不用再写
开发人员的职责

     若团队觉得有需要，则负责实现自动化验收测试
     开始开发一个新的故事时，负责考虑更多的验收测试
     负责为代码做单元测试，使验收测试就不必估计故事的每个细节
 客户职责

     负责编写验收测试
     负责执行验收测试

       关于敏捷 验收测试的详细信息大家可以参考《用户故事与敏捷方法》

    <开发管理 CheckLists> by dyllove98 @开发管理 CheckLists