测试人员设计测试用例的时候，面临的第一个问题是测试用例的步骤是否越详细越好？或者如何把握测试用例的详细步骤？在这个问题上，赞成测试用例详细化的人肯定有不少，因为详细测试用例可以提供如下优点：

　　1）缺乏经验或者技能的测试人员，可以按照测试用例的步骤顺利开展测试执行工作。这是脚本化测试实践中的思维：有经验与技能的测试人员设计测试用例，而缺乏经验的人员去执行测试用例。

　　2）缺乏经验的测试人员，按照详细测试用例的步骤执行的过程，不仅可以帮助他们了解测试对象的功能与业务知识，也可以帮助他们了解测试设计技术与方法。

　　3）更好的一致性。由于设计的测试用例提供了详细了步骤，每个测试人员按照这个步骤可以得到一直的测试结果，因此保证测试一致性。

　　4）有助于测试用例的自动化。因为详细的测试用例提供了详细的步骤和期望的结果，因此将它们转化为自动化测试用例会相对比较简单。

　　5）有时候提供详细的测试用例，是为了满足法律法规的要求，特别是针对安全关键系统，在有审计的情况下。

　　尽管详细化测试用例可以有上述的优点，但是反对测试用例详细化的也大有人在，因为详细化测试用例也会导致一系列的问题：

　　1）设计成本高：测试人员需要花费大量的时间投入到测试用例的编写上面。同时测试用例文档的页数越多，被完整阅读的可能性越少。

　　2）效果差：穷尽测试不可能，好的测试用例设计是从无穷的测试中选择合理测试输入、测试组合、测试数据等，以相对有限的测试用例数目尽量达到理想的覆盖率。而详细的测试用例设计很难完全定义这些组合和场景，实践中需要测试设计不断迭代和更新。

　　3）维护成本高：测试用例的输入参考，例如：需求文档是经常变更的，这会导致测试用例越详细，其维护的工作量更大。

　　因此，测试用例的详细程度要求，并没有一个标准的答案，尽管我是轻量级测试用例设计的拥护者。测试用例详细与否，会受到各种因素的因素，例如：

　　1）测试目标。测试人员测试该产品或者系统的目标是什么。假如测试用例文档不能支持这个目标，或者无助于达到这个目标，那么这样的测试用例设计文档价值会降低很多。

　　2）测试用例文档是产品还是工具。假如测试用例文档是软件系统或者产品的一部分，那么这些文档是需要发布给客户使用的，这时候测试用例文档需要按照客户的要求遵循某种表尊。而假如它们只是内部使用的工具，那么不必太完整、太整齐，能够在低限度上有助于达到目标即可。

　　3）软件设计变更是否频繁。如果软件设计变更很频繁，则不要将许多细节写入测试用例文档中，因为这些细节很快会过时。这种情况下，不要编写大量的测试用例文档，它们被修改或者放弃的速度太快，不值得在测试用例文档上投入太多。

　　4）采用的测试方法。假如目前采用的软件开发模型是V模型之类的线性模型，那么采用的测试方法通常是依赖于预先定义的测试，这时候需要详细的测试用例的操作和维护文档。假如采用的是探索性测试，则更需要策略方面的文档，例如：关于某个测试领域的想法，但不是具体的测试用例。

　　5）测试用例文档给谁看。假如测试用例文档是主要给新的测试人员或者没有经验的测试人员看，那么需要足够详细使得他们能够正常开展工作。