软件测试设计的模式
直达列车模式
在铁路运输上，为了适应不同旅客的需求，有站站停的慢车，也有号称“贼快”的直达列车。前面介绍过的吃甘蔗模式要求把软件功能分拆成尽可能小的功能单元，同时，我们同样需要直达列车模式，设计出一些测试用例，把主要功能串起来，以实现在最短的时间内做完测试，了解和掌握软件质量的状态。
再以12306.cn为例，下面是根据直达列车模式设计的两个测试用例：
1.
（1）
（2）
（3）
（4）
（5）
（6）
2.
（1）
（2）
（3）
（4）
（5）
暴力拆迁模式
对于软件系统的核心功能，测试工程师一定不能仁慈，要下得下去手，敢于“暴力拆迁”。
12306.cn的核心功能毫无疑问是预定，就是抢票，如果你是这个功能的测试工程师，你怎么做测试设计？
这个“预定”在功能规模上是个简单的功能，但是在春运的背景下，一切都不再平常：
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
以上仅是我个人的一些临时的测试思路，相信读者朋友还会设计出更多的测试用例。从春运时抢票的惨烈程度来看，我们不必担心自己的测试是否过于暴力。
地久天长模式
有的软件是在桌面上运行的，例如微软的Office办公软件，用户不会长年累月持续地用；有的软件是要长期运行的，特别是服务器端，例如运营商的通信软件，根本没有停下来的机会。软件在长期运行后，可能会遇到几个方面的挑战：
1.
2.
3.
4.
5.
6.
7.
8.
测试工程师要本着“地久天长”的思想，往远处想，设计出这方面的测试用例，更加深入地测试软件产品。
下跳棋模式
如果测试的设计仅仅按照红宝书和吃甘蔗模式来做，虽然完成了基础性的工作，但是还是不够的。例如，有功能A和B，无论谁做测试设计的时候都不会漏掉它们。在测试的时候：测试A，通过。测试B，通过。但是，如果做完A之后再做B有bug，或者B之后再执行A有bug，这是往往容易漏掉的。
实际测试工作中的场景要比上面所说的A、B复杂多倍。面对着几十个功能点，互相之间有不同的关联，如何去做测试设计？我推荐的一种模式是——“下跳棋”：分析和总结出软件中存在的多个状态，找出这些状态相互转移的可能性，画出图来。做测试设计的时候，就以这幅状态变迁图来做。在术语中，这种标示状态和变迁关系的图叫做状态机（图）。
软件测试设计的模式
在火车票网购系统中，有哪些状态呢？
1.
2.
3.
1.
2.
3.
这种模式有一个好处，会让软件产品中复杂的逻辑简单化和形象化，弥补人的思维的局限性。记得有一个统计说，如果一个人要同时记住超过7件事情，就会开始犯糊涂。
下跳棋模式也可以用于测试用例的精简。例如，在一个测试用例中覆盖多个状态的变化，就好像跳棋连续跳几步。
地方紧跟中央模式
任何软件系统都有自己的架构和风格，子模块的开发应当遵循这些公共的规定，否则做出来的东西“不像一家人”，用户体验不好。对于这些公共要求的遵循，我称之为“地方紧跟中央”。这一点对于迭代式开发的软件特别重要，测试工程师也要注意这一点。测试工程师根据这个模式设计一些测试用例，往往就能比较容易地发现后开发的模块上的一些bug。
例如，软件产品A中有下面这些公共的要求：
1.
2.
3.
4.
5.
6.
7.
子模块 | 公共要求1 | 公共要求2 | 公共要求3 | 公共要求4 | 公共要求5 | 公共要求6 | |||||||||||||||||||||||||||||||||||||||||||||||
模块A |
TAG: 标题搜索日历
我的存档数据统计
RSS订阅 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
