测试用例编写_转发

测试用例设计可以从两个思路入手：按功能点和按业务流。这两则的主要区别是一个是从单个功能点考虑进行测试用例设计，一个是从把各个功能点串联起来形成业务流方面考虑进行测试用例设计。当我们要对一个模块进行测试用例设计时，要首先分析该测试模块的特点及业务，确定是按功能设计测试用例好点，还是按业务流设计测试用例好点，还是一个为主，一个为辅？从功能点进行测试用例设计容易把各个模块独立出来，减小了各模块之间相互的影响，各模块之间的交互可能考虑的较少，但是我们提交给用户的是整个产品，各模块之间必然有数据交互，所以只从功能方面考虑是不足的，需要业务流做补充。我惯用的测试思路是先以功能点设计为主，就是以单个功能点作为设计切入点，覆盖到测试模块各个独立的单个功能点，然后用业务流进行补充，把各个功能点串起来。这样的好处是能够尽可能的覆盖测试模块的各个点及各个功能点之间的交互，借用一个前辈的话：“把每条业务流程比作竖线，功能线比作横线，那么功能点就是横线和竖线的节点，这样整个用例就是一张大网，我们可以随时向网中添加横线或竖线，使得覆盖率不断增加，“漏网之鱼”越来越小。”但是这种策略比较耗时。这里要考虑测试用例颗粒度问题，相信只要设计过测试用例的人员都考虑过这个问题，也是设计测试用例前必须要确定的问题，个人感觉测试用例的颗粒度取决于时间和可重用性。时间比较好理解，可重用性最好的例子就是多个build的项目。

其实关于按功能点或业务流进行测试用例的设计，我感觉是人为的划分，有时候想想一个流程走下来肯定完成的是一个功能，那这是不是从功能点考虑的体现呢？验证一个功能时，也应该是一系列操作，走多个业务，那这是不是业务流的体现呢？所以个人感觉设计测试用例时，非要说你是从业务流考虑的还是从功能点考虑的没有意义，有意义的就是设计出高水准的测试用例，而不是从语义上争得的死去活来（工作中遇到过），要有自己的设计思路。

最近设计测试用例发现使用思维导图是个不错的方法（强烈推荐使用），用思维导图罗列出测试点（从需求中提取），寻找思路及策略，编写测试用例，不断完善细化测试用例，扩大测试用例的覆盖面。

最近跟测试同行讨论，设计测试用例时经常遇到学习的测试用例设计方法应用不到实际的测试用例中。我也遇到过这个问题，现在测试用例设计中也存在这个问题，我们知道测试用例设计方法的目的就是减少测试用例，使测试活动处在可控的范围之内，但是这是有风险的，好多领导为了避免风险就要求我们尽可能的用穷尽的方法设计测试用例以及执行测试用例，遇到这种情况也没有办法，听领导的呗，但是有时你也会发现使用穷尽的笨方法可以发现使用减少测试用例的方法发现不了的问题以及相关的注意点，感觉这个对新员工特别有帮助，能够全面详细的了解一个产品。有时候想想要是我是领导，时间允许的情况下，我也会要求自己的组员尽可能的详细的测试产品，呵呵。当然也有些模块或者产品的确不需要使用测试用例设计方法，只需要考虑特殊场景即可。个人认为不应该让这些方法理论什么的束缚住自己的思维，不要为了使用而使用，也应该考虑测试模块特点，实际测试环境，时间等等。