测试用例

2015-08-25  本文已影响0人  ElkWrestling

新公司似乎没有专门的测试人员,产品的一部分工作就是测试测试测试。

昨天领导安排给我三个任务,测试三个功能:

1. 转发送红包

2. 收货地址改为4级

3. 客户端push

这才想起来应该快点把测试用例捡起来。

这是上次写的Android App测试用例,只写了一部分,其实也是一知半解的实验之作。

今天了解到,这里面的story并不是随便写的一个单词。有明确的定义:

Story就是一个可测试的小功能点(Story:功能点=1:1)、或者是多个继承性的小功能点组成的一个Story(Story:功能点=1:N)、或者是一个无法再分割的功能点(再分割这个功能点就无法进行测试了)包含多个Story(Story:功能点=N:1)。

1、Story

Story最原始的目的是指导开发工作量的划分,Story是将一个大的特性划分成小颗粒度的功能块,方便分配工作量,以便获得快速反馈;

2、特性:

敏捷中的特性类似于在双V模型或者其他模型中的子系统、子模块或者说是较大的功能模块,是由很多的功能块组成的,一个特性是耦合度很高的子模块;

3、功能块:

敏捷中的功能块类似于双V模型或者其他模型中的较小的模块,从子模块里划分出来的较小的功能模块,是由很多的功能点组成的;

4、功能点:是不可再分割的可测试的小功能模块;

5、特性团队

特性团队是指由设计人员、开发人员、测试人员、资料人员、特性团队组长等人一起组成的一个完整的团队(7人左右),特性团队是按特性进行划分的团队,团队成员对该特性的交付全权负责

6、头脑风暴

由特性团队中所有成员一起就一个Story的方案、设计、用例设计验收标准等内容而进行的团队中的讨论会,以澄清Story的设计,用例,测试验收标准等;

7、Story验收标准

每一个Story都需要在进行头脑风暴时,由团队里的人一起制定该Story的验收标准;

Story划分时以测试功能点作为依据,实现Story与功能点的融合,测试时基于功能点进行设计测试用例,开发基于Story进行开发。

——

好的开始写测试用例了。

上一篇下一篇

猜你喜欢

热点阅读