作为测试人员，编写测试用例是我们的核心，他最重要的作用就是让我们跟着测试用例测试，不会遗忘一个测试的功能点。在现实的设计用例环节来说，做到很好的测试用例对我个人来说是很难的。尤其是场景测试用例设计。
本文不以概念和一些教科书似的例子来讲解场景测试和业务测试的相互关系。以一个轻松交流的方式来总结场景测试的流程。当今很多产品不再是单一的互联网或者是独立产品作为测试的对象，往往跟多个模块进行配合测试。即使有严格的规格说明书，事件流的测试也是不能忽视。
为什么要用场景测试用例：
因为用等价，边界等设计方法对于一些流程较多或者对于没有需求规格书来说，是非常难做到的，尤其是逻辑性比较强的嵌入式产品。他的边界值往往都要到性能测试的性能kpi和压力2个测试点才能够观察到。
测试阶段中什么时候用场景测试：
在产品开发阶段和测试阶段同步进行时（说正规点是敏捷，说不正规点是赶工，个人意见），还有单元测试或者单个模块测试完毕后。
场景测试用例设计的困难点：
1、需求不足和逻辑关系较多的时候。这里需要展开来讲。很多时候我是不得不用到场景测试法。因为需求规格书不足和该产品从等价，边界等测试用例方法是设 计不出有效的测试用例。流程和涉及产品较多，对比网上的场景用例实例，现实中使用场景用例的流程往往复杂很多，单单了解流程都很吃力。
2、设计事件流的过程中很容易设计出沉余的测试用例，因为就算每个流的条件不一样，但是你实际测试过程中使用的手法和观察点确是一样的。难就难在这用正交法是很难瘦身这类的用例，只能通过测试来慢慢优化该用例，流程关注点越多，重复的几率就更多。
为什么我既爱又恨场景测试法：
对于我来说，场景测试法既是我用最多的测试法也是我最不想用的设计方法。作为测试人员在长期的测试过程中，你会慢慢变得很懂内部原理，尤其是你转化为自动化测试后，甚至做到一个确定键报错都会联想到这是数据库和web的存储过程入参不一致导致的境界。好处是你可以测试出很多底层的东西，坏处是经过你测试的产品，功能很多，但是却不好用。因为我忽略了我是一个用户的角度去测试，而是一个开发测试开发的东西。
场景测试让我找到了平衡点，我知道了这东西的流程，可以在了解中提出改进建议，对产品有了很深的了解。让我从自动化测试中拉回来一点点。为什么我会不想 用的此种设计方法。他很考你的经验和总结能力，同上面所说你缺乏需求规格书的时候，你就是用想来写用例。所以当别人表扬我测试不少用例以外的关键Bug的时候，我是高兴我的有好的测试经验还是我写出了差的测试用例。
对于做测试有一定年头的人，项目组对你的要求不再是了解普通的测试流程，还有很多里面的原理，设计，方案，进度。场景测试设计的时候你就要把关，我设计 的是多深入的测试用例？能否根据你项目的期望来测试出关键的bug。好比我测试的是web的流程，但是项目关注的后台的处理流程。实际情况中，你设计场景 用例的时候不再是培训那套理论和”真理”。
通过以上可以看出，为什么有些业务测试工程师比自动化，性能，甚至开发的地位都要高。例如银行，无线通信业务中，手工的测试手法非常多，同样的产品不同的人测出的效果不一样。体现出现的就是业务流程的能力，部分情况下就是场景测试设计的功力。
总结，作为一个测试人员的我的目标测试周期，第一了解产品的应用架构，第二了解产品使用的业务流程，第三总结业务流，第四根据业务流跟各个开发组了解设计流程，第五写出按需求的自动化测试的架构，第六写出场景测试用例，第七进行系统测试，第八进行细节的自动化用例编写，第九进行自动化测试，第十出测试报告和测试周期的自我”性能调优”总结文档。
这篇就是我的场景测试总结文档。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
