从用例角度来分析系统测试（横向）

一、从用例角度来分析系统测试（横向）

 

针对ST用例，使用横向思考方式进行计划、方案、设计、执行活动。

横向思考方式得到的结果是 测试项、测试子项、测试用例。

下面将针对如何实现每一步，进行描述：

 

1、ST计划 → 测试项

 

做计划最重要的不是写文档，而是之前所进行的活动（思考和沟通），

文档只不过是过程的结果而以，最重要的是那个思考的过程！

 

 

举例：手机功能测试

手机产品SRS	测试 需求 分析	ST测试项
SRS001:发短信、收短信、存储短信		测试项1:发短信、收短信、存储短信
SRS002:打电话、接电话		测试项2:打电话、接电话
		测试项3:测试电话和短信并发进行的情况
测试项3:如果在计划中没有分析出来，则在以后的活动中，更难分析出来，最终导致漏测， 所以说在计划阶段对测试需求项分析得越透彻越周全越好.

 

设计思路：

根据ISO9126质量模型，对SRS进行分析，得到测试需求项

Quality Attribute	SubCharacteristic	Test Requirement Item
Functionality	suitability	1）  统计代码行功能 2）  统计注释行功能 3）  统计空行功能 4）  统计总行功能 5）  组合统计 ……
	accuracy
	interoperability
	security
	functionality compliance
Reliability	maturity
	fault tolerance
	recoverability
	reliability compliance
Usability	understandability
	learnability
	operability
	attractiveness
	usability compliance
Effiency	time behaviour	1）0~ 1M 文件代码行统计效率 2）0~ 1M 文件注释行统计效率 3）0~ 1M 文件空行统计效率 4）0~ 1M 文件总行统计效率 5）……
	resource utilization
	efficiency compliance
Maintainability	analysability
	changeability
	testability
	stability
	maintainabililty compliance
Portability	adaptability
	installability
	co-existence
	replaceability
	portability compliance

一定要在这里，根据ISO9126质量模型，将系统的所有测试项全部归纳分析出来，

如果在这里都没有发现的测试项，在后面将更难发现，最终导致漏测，结果可能很严重。

 

ST计划活动的主要目的是任务分配，并且进行合理的分配任务；

以上所做的事情都是为了进行更好的分配任务，为做计划做铺垫；

 

任务分配：

1）  功能测试任务分配：将所有功能的任务作为一项任务进行分配

2）  易用性不能单独的进行测试，需要与其它功能组合起来进行测试，比如GUI测试

3）  性能测试任务分配

4）  ……

 

 

2、ST方案 → 测试子项

1）对测试项进行归纳，确定需要进行何种类型的测试，然后把各测试项归纳到测试类型中。

Ø         功能测试

功能测试是根据SRS和测试需求列表，验证功能的实现是否符合SRS

主要是为了发现以下几种错误：

-          是否有不正确或者遗漏的功能？

-          功能的实现是否满足用户的需求或者系统设计的需求？

-          是否能够进行正常的输入和正确的输出？

Ø         安全性测试

Ø         性能测试、压力测试、容量测试

Ø         GUI测试、可用性测试、文档测试、在线帮助测试

Ø         安装测试、配置测试

Ø         异常测试、备份测试、健壮性测试

Ø         网络测试、稳定性测试

 

2）对每个测试类型下的需求测试项进行划分，得到测试子项

ST测试项	ST测试子项
测试项1：测试短消息的接受，发送等	测试子项1：
	测试子项2：
	测试子项3：
测试项2：测试打电话、接电话等
测试项3：测试通话和短消息并发情况

 

3）明确各测试子项应该达到的覆盖率标准

需求覆盖！！！难啊难！！！怎么搞啊？？？

SRS-001                      CASE-001

ERROR!

SRS-002                      CASE-002

……                            ……

SRS-100                      CASE-100

脑子里都是屎啊？难道就不会变通一点嘛？猪！！

 

参考逻辑覆盖率的方法，把覆盖按照类进行划分，然后进行覆盖。

逻辑覆盖：    不要说成逻辑覆盖率是80%，猪！

                     要说成语句覆盖100%，条件覆盖90%，路径覆盖……

 

需求覆盖：   

（1）       等价类法覆盖率达到：100%

- 等价类划分的粒度跟成本有关系，可以划分的很细，也可以划分的很粗

（2）       边界值法覆盖率达到：%

（3）       因果图法覆盖率达到：%

根据组合情况可以使用全组合设计用例如果组合情况较小，或者项目很小可以使用全组合覆盖法

（4）       正交试验法覆盖率达到：%

如果全组合设计用例的数量太大，考虑使用正交法进行精简

（5）       输出域覆盖法覆盖率达到：%

（6）       状态迁移法覆盖率达到：%

（7）       流程分析法覆盖率达到：%

（8）       错误猜测法覆盖率达到：%

 

并不是每一个需求项都一定要采用以上的每一个用例设计方法！！

我们采用以上的需求覆盖的思路来指导我们进行ST用例设计

在企业里，高级工程师在这里已经分析很好了，后面就可以做机械运动了J

 

3）软件和设计测试环境

用一个网络的框图把这些画出来，形成组网图

 

4）自动化测试框架的设计

 

 

3、测试用例

       测试方案的（1）和（2）是为了指导系统测试用例而做的，非常重要！！

1）按照ST的子项划分和覆盖率要求选取数据构造测试用例，达到方案中各自向对覆盖率的要求；

为什么企业里面感觉测试用例很难写？ 前面该做的事情做得太少了或者根本就没做。

站在我的角度，如果没有前面的计划和方案过程，则自己自主写计划，方案，然后用例

 

 

4、测试执行

       测试方案的（ 3 ）和（ 4 ）是为了指导系统测试 执行 而做的，非常重要！！