首先来说一下个人对于测试类型的几个理解吧，如果要保证一个软件产品可以被正常使用，如下几个测试是少不了的：
1 功能测试（单元测试）
2 可交互测试（集成测试）
3 自动化测试（持续交付测试）
4 性能测试（压力测试）
在编写测试过程中，对于测试如何写，写多少用例算是足够的，不同的人有不同的理解，根据《用户故事》介绍的内容和自己的一些理解，整理如下：
关于测试用例的责任主体可以分为两个，一个是客户团队，一个开发团队
1 客户团队需要完成什么样的测试呢？ 客户团队掌握需求，需要定义可交付的测试用例的编写。此时的测试用例既是需求的验收标准，也是对需求的进一步解释澄清。开发团队可以通过对于用例的阅读，进一步的明确客户的实际需求，也就不至于做成的产品和客户的期望有偏差。
比如用户期望做一个招聘网站中供HR输入招聘信息的页面，客户期望可以录入的信息包括岗位名称，工作地址，薪资范围等等，求职者可以查看这些信息。 对于开发人员来说，会把所有的信息录入到界面中进行展示，很有可能要求每个信息都是必填的。但客户的实际希望是某些信息（比如薪资范围）是可以不录入的，对于不录入的条目，对于求职者也是不需要展示的。 像这样的信息，如果通过测试用例的方式明确标记出来，会极大的减少后期返工的成本。
客户团队的测试用例一定要在开发之前写，可以由客户团队来完成或者客户团队和开发团队共同完成，在开发之前就完成测试用例的做法，也就是TDD所要求的工作方法。
2 开发团队需要完成什么样的测试呢？开发团队更多的关注于功能的实现方法，理所当然的就是单元测试的编写了。关于单元测试是在开发之前写还是开发之后写，我个人的看法是需要分两半，一半在开发之前写，一半在开发之后写。
开发之前写的内容是把客户团队提供的测试用例转换为可执行的单元测试代码，可以在此基础上再增加一些设计方案中涉及到的细节的描写（需求在转换为设计方案的过程中，会有一些更加细化的内容，这些内容对客户来说可以认为是透明的）。
开发之后写的内容是把在具体编码过程中涉及到一些内部逻辑的判断进行一些边界测试或者健壮性测试，避免出现空指针异常等一些低级的错误。
之前在摩洛哥项目实践过类似的处理方式，整个流程是这样的：一个需求过来之后，首先会召集设计，开发，测试等相关的同事进行需求评审，让大家对需求的内容有所了解。 之后设计同事就可以开始设计方案，测试同事就可以根据需求来编写测试用例了（一定要按照需求来写测试用例，而不是按照开发同事给的逻辑来写）。开发同事按照测试同事提供的用例进行自测（在自测的过程中会根据代码的实际编写情况增加一些单元测试的场景并反馈给测试同事），自测完成后提交代码。 测试同事根据最终的测试用例进行集成测试。
这个做法的好处是使测试同事有更多的精力来关注业务本身并设计更多的测试用例，开发人员根据测试同事的用例完成自测之后，代码质量会有明显的提高，返工率降低了很多，从而释放了测试同事的精力，促成了一个正向循环。
关于测试用例应该写多少的问题，书中给出的答复是：只要测试用例还可以继续为故事增加价值和使其更清晰，就应该继续编写。 所以这个问题没有一个可以量化的答案，只能是在实际工作中进行平衡，通过不同团队同事的协调沟通，大家获取一个可以接受的平衡值。
书中给了一个例子，比如要支持多种信用卡的支付，如visis，master等等，其中一个场景是需要校验卡片的失效日期，我们可以为visia写一个卡片失效的用例，但如果跟开发人员沟通后发现：所有卡片的失效日期都是用同一个函数校验的，那其实就没有必要为其他的每种卡片增加这样的用例。
暂时先写这么多了，除了功能测试和可交互测试外，我还对自动化测试非常的赶兴趣，这是一个可以极大提高版本质量的手段，后面我们再找时间慢慢聊吧。
