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

 

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

1、ST计划

1、组织形式

（1）明确测试组织和周边关联组织之间的职能和权力关系

       - 如果公司的流程的比较规范，则不用太多考虑；

      - 如果公司的流程不是很规范，根据以往的经验，在分配任务以后，会不会遇到障碍；

       - 与管理人员：    解决资源、监督测试结果

       - 与开发部门：    是否需要进行系统预测试；

Bug如何提交给开发人员；

与开发部门之间的相互评审；

双方遇到冲突该如何解决

       - 与QA部门：     从QA部门要软件测试的度量标准；

                                   为QA提供工作量、规模、进度、BUG率及检出率

                                   向QA部门申请进行培训

       - 与配置部门：    确定版本在何时进行发布；

                                   确定版本在何处进行发布；

                                   确定版本以何种方式进行发布；

（2）明确测试部门组织内部之间的关系

2、测试对象

（1）将SRS和质量模型进行对比分析，将分析出来的功能性测试和非功能性测试划分到质量模型当中；

（2）质量特性：内部质量特性、外部质量特性、使用质量特性，

系统测试主要针对外部质量特性进行测试；

（3）软件质量特性和测试类型可以是一对多，也可以是多对一的关系；

（4）一般常见的质量特性和测试类型的对应关系：

       - 功能性：功能测试、安全测试、互联测试

       - 效率性：性能测试、压力测试、容量测试、负载测试、指标测试、内存泄露测试

       - 可靠性：可靠性测试、启动/停止测试、健壮性测试、备份测试、恢复测试

       - 易用性：可用性测试、稳当测试、安装测试

       - 维护性：可维护性测试

       - 移植性：配置测试、兼容测试、安装测试

3、需求跟踪

       - 确定系统测试项与SRS或者软件需求库中的需求之间的对应关系

       - 建立 系统测试项-需求跟踪矩阵表

4、通过/失败标准

       - 用例设计的覆盖率达到多少？等价类、边界值、因果图法……

       - 用例执行的百分比达到多少？1、2级执行率，3、4级执行率……

       - 缺陷数量要达到多少？

       - 残留缺陷数量？

5、挂起/恢复条件

（1）挂起：测试无法进行下去，或者继续测试没有任何意义的情况下进行挂起

（2）恢复：满足可以进行测试条件的情况下，进行恢复

6、任务分配

       做计划最核心的内容就是任务分配

（1）工作量估计

工作量估计是建立在一定经验的基础上的，如果没有相关的工作经验，则需要邀请有相关工作经验的专家或者人员开圆桌会议，进行工作量估计

工作量估计会产生一定的误差，可能原因有评估者的经验丰富程度，测试项划分的粒度和准确性；

（2）资源分配

       主要有人力、物力、时间上的资源分配；

（3）进度安排

（4）风险估计和规避措施

       A．资源上的风险

              人力、物力、时间

       B．技术上的风险

              - 本公司不能够解决的技术问题

              - 整个行业都不能够解决的技术问题

（5）输入/输出确定

7、交付产品

 

二、系统测试方案

 

三、系统测试用例

1．功能测试

       从输入/输出的各个不同角度进行等价类、边界值分析考虑用例设计

思考角度

输入

有效等价类

无效等价类

文件

文件名类型

*.c

非*.c

文件名长度

<=255个字符

>255字符

文件大小

<=1M

大于1M

文件存在性

存在

不存在

文件独占性

未被独占

被独占

文件内容

1）  全空

2）  全代码

3）  全注释

4）  空+代码

5）  空+注释

6）  代码+注释

7）  空+代码+注释

 

文件行数

0行，1行，多行

 

 

 

 

 

 

 

 

 

然后再用错误猜测法，对测试用例进行补充；

错误猜测法只能做为非正常的用例补充方法使用，不能当作正常的方法使用。

主要从软件开发人员的思维盲点和系统的薄弱环节进行猜测；

 

2．性能测试

分析思考思路：

（1）单用户、单业务

（2）多用户、单业务

（3）多用户、多业务

 

性能测试需要重点考虑的问题：

考虑不同的业务场景和业务量组合的情况；

业务场景：不同的业务动作的不同组合，组成不同的业务场景

业 务 量：压力、容量、负载

 

场景→

业务量↓

代码行

统计性能

注释行

统计性能

空行

统计性能

……

……

0K

 

 

 

 

 

100K

 

 

 

 

 

500K

 

 

 

 

 

1M

 

 

 

 

 

 

1）  以业务场景为基础，业务量不断增加

-          代码行统计，0K

-          代码行统计，100K

-          ……

-          注释行统计，1M

-          ……

2）  以业务量为基础，业务场景不断增加

-          100K，代码行统计

-          100K，注释行统计

-          ……

-          1M，代码行统计

-          1M，……

 

3．GUI功能测试

5．……其它类型测试

 

四、系统测试执行

 

重点：怎样书写测试报告？

1． 对测试工作本身进行分析和总结

（1）       测试的充分性

a)         覆盖率           等价类、边界值

b)        用例粒度       用例数/KLOC

c)        工作量           人时/KLOC

（2）       测试的效率性

a)         用例设计效率       设计用例数/人时

b)        用例执行效率       执行用例数/人时

（3）       测试用例的质量

a)         用例发现缺陷数    缺陷数/用例数

b)        用例稳定性           变更用例数/总用例数

2． 对被测试对象的质量进行分析和总结

（1）       静态分析：对当前版本进行测试

a)         功能性：缺陷数/KLOC、缺陷数/需求数

b)        性  能：从不同的业务场景、业务量组合的角度，来对产品的性能指标变化趋势进行分析学，找出系统的瓶颈；

c)        可靠性：MTBF、MTTF

（2）       动态分析：把当前版本放在历史一系列版本中进行测试

3． 在上述结果的基础上，总结经验和改进意见

（1）       总结成功的经验

（2）       总结失败的教训，并且给出改进意见

到底是哪一个阶段，哪一步，哪一天导致问题的产生？为什么？

分析原因，找出改进措施！