摘要：测试用例说明书分成覆盖各个业务流程和预期的输入输出，前者这个有助于与客户沟通，挖掘需求；后者有助于与开发人员的沟通，提高编写符合要求的代码。
正文：测 试用例说明书，通常定义为对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。在软件产品开发中用的非常多，但在项目开发中，重要 性进行经常被忽视，很多项目组都是不做的，或者是为了敷衍编写的。敷衍是有很多原因的，各方不重视测试，需求多变导致测试层本大幅增加、项目时间节点紧， 因此很多测试过程会被简化。很多项目组最后只会有下1-2个左右的测试人员，或者是开发人员做兼职测试，在编码结束后，就上系统点点，然后提交客户了；客 户验收也是同样，验收平台搭建好后，走走流程，可能脑袋里面会想，怎么走流程可以把所有的流程都过一遍么，缺乏系统和专业的考虑。
软件开发，肯定比不上产品开发了，项目的成本、项目结点都是摆在那里的，要说服客户或者领导重视测试不是一朝一夕就能解决的。测试阶段肯定要简化的，但是测试用例说明书还是建议保留的，他的作用不是仅仅停留在测试的。
测试，第一要求的尽可能是测试覆盖业务的所有流程，逻辑分支；第二是测试的依据，不管是覆盖流程、分支还是覆盖页面，都归集为预期输入和预期结果，输入后的结果不是预期的，就是有问题的。
做需求有两个产物：需求规格说明书和页面DEMO，这都是需求静态的描述，你会发现很多客户在项目编码结束测试阶段后会提出很多新增需求和需求变更，有 些程序员会抱怨客户，其实这很大原因就是，静态的需求描述和DEMO很难让客户的思维有所发挥，业务是动态的，做业务的客户的逻辑性和构思不比专业做软件 的，只有等软件动态后才会想到真正的需求，谁都不希望最后一大堆改动，一堆人加班，一大堆风险。测试用例说明书能很好的弥补这个静态的问题，测试用例的业 务流程覆盖测试，动态的描述的业务操作步骤，而且在需求做完确认后就能编写了，因此在需求阶段就做完测试用例说明书，可以有效的改善提高需求设计的质量， 降低后期的需求变更。
上面的作用，是对客户而言，对做需求而言的；而第二个作用是做开发人员而言的。编写好的基本设计交给开发人员开 发，经常会出现最后完成的代码不符合要求，问题可以归咎为开发人员理解有问题或者沟通有问题；也会出现开发人员不负责任，提交的代码问题未经自己测试，测 试的任务推卸给测试人员。问题出在哪里，能不能沟通更加准确，能不能让开发人员更加负责？基本设计有颗粒度到页面级别的，也有到API级别的，但是不管怎 么样，都可以分成预期输入和预期输出，在做完基本设计后，根据基本设计的颗粒度，设计页面或者API预期的输入和预期的输出后，就基本给开发人员定性，编 写完成的代码应该是怎么样的了，这个预期都是测试用例，明确告知开发人员，编写的代码只有达到这个预期后才算完成，可以提交给测试人员测试。通常，开发人 员在明白了预期的输入和输出后，对要编写的代码理解就更加深刻了。
至于测试用例说明书如何写，到底是怎么样的颗粒度，这个我以后在整理，这篇只是说要它的价值所在和重要性。
软件工程中明确写过，测试用例说明书编写在需求阶段和设计阶段，是经过无数项目的总结出来的，只是没体会到而已，这只能说自身功力的问题。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/