如何做好系统测试

gztester · 发表于 2011-9-7 15:08:30

我一直感觉系统测试总像马拉松总是测试不完，什么时候上线，什么时候算终点。虽然提交客户了，可是对于质量仍然心里没底，对于测试的效果没有评价的依据。后来经过高人指点，终于领悟到至关重要的精髓：明确测试目标！

MILY: 宋体">一套软件做完了，在给客户上线之前，我们自己要进行完整的系统测试，这个工作听起来好象没什么，但其实是很不好做的，这要求测试人员要熟悉业务、熟悉系统的各个功能项、还要有一套完整的测试方法。我们软件销售部从开始做系统分析工作，现在又开始担当系统测试的角色了，没办法，公司人手不够，只能担当多种角色了。不过对于我们来说也有一定好处，系统分析设计是我们做的，现在做好的系统由我们来测试，一是我们对业务比较熟悉，二是对我们来说也是一种自我的检验，检验一下自己设计的系统是否合理，为以后更好的系统分析打好基础。

好了，言归正传，讲一下我们在测试工作中的一点体会吧，写出来一面为自己理一下思路，二也是为自己做工作的一个总结。

如果要将系统进行全面测试，那么就要有一套完整的测试阶段，每个阶段都以测试目标为标准，科学、有序地进行测试，那么测试效率也就会自然而然跟着提高。

测试阶段分为：测试前准备、需求分析、测试计划、测试设计、测试执行、测试结果。

1.测试前准备阶段

主要是相关业务的学习。业务知识是测试的根本依据，只有业务过关了，以后才能有效的进行测试工作。

了解业务步骤：

a、了解业务名词；

b、对现有系统的学习：功能点、业务场景等；

c、分析现有系统数据库，了解数据的走向。

2.需求分析阶段

需求是项目开发的基础，也是测试的依据。所以需求分析一定要做。但是很多公司是没有详细的需求文档的，那如何进行需求分析呢？

此时分析数据库就是一个非常好的方法：

a、每张表的索引和约束条件；

b、数据的来源、走向；

c、数据的存储、变化；

d、数据间的关联；

e、表与表间的关系；

这些分析都可以为了解业务场景和之后的测试用例设计打好基础。

3.测试计划阶段

我们总是觉得被测试进度紧逼、计划失控、测试不完全等等状态，其实解决这些情况的最好方法就是：制定测试目标。

在计划初期先明确测试目标，制定不同层次目标的执行标准，指导后期设计不同级别的测试用例，跟踪不同级别的缺陷修改。在测试时间较紧情况下，至少可以先把保证所有功能正常操作的最低目标版本先提交给客户，不会再有手忙脚乱，心里没底的状况。

测试目标分为：

         最低目标

         基本目标

         较高目标

         最高目标等级别

可以使用表格形式来规范目标准侧，例如：

测试目标准则表

目标

测试范围

需求覆盖率

最低目标：

正常的输入+正常的处理过程，有一个正确的输出



（明确的功能点全部列出来）

1.       功能：

正常功能

异常功能

单功能

业务场景

非功能：16种测试类型



2.       输入覆盖率：

有效无效

处理过程：基本流

      备选流

状态变化：正常、异常

输出

SRS00001

SRS00002

SRS00003

基本目标：

对异常的输入有错误的捕获，并进行相应提示或屏蔽







较高目标：

对隐式需求进行测试







根据公司规模不同，确定测试目标级别也可不同。一般小公司有最低标、基本目标即可，大公司可以提高目标标准，直接从基本目标开始，直至最高目标。

4.具体的ST用例的编写以及执行

测试用例设计的粒度一直是个讨论对象，很多时候总会强调时间很紧啊，如果时间再多点，我的用例肯定会设计的再细一些！！

是不是设计的越细就一定越好呢，不一定，测试是无穷尽的，使用穷举方法来进行测试是不科学的。

因为制定了测试目标，那么就应该根据测试目标，在设计测试用例时也要制定设计用例目标。

比如：按照最低目标选择测试用例

输入—>有效

处理—>有效

输出—>有效

按照最低目标的宗旨，只要是设计出来的测试用例足以覆盖和验证系统基本功能可以正常使用，那么这些测试用例的粒度就足够细了！从而提高了设计用例效率，同时也提高了测试效率。

5.测试之后的评估

实现一级测试目标之后都要进行评审工作，根据评审结果进行系统版本发布。例如：

1.保证所有需求都有测试用例

2.保证所有功能的正常操作和正常操作有对应的测试用例          V1.0版本

3.保证所有功能的异常校验有对应的测试用例                   V2.0版本

4.各功能组合形成的业务流有对应的测试用例                   V3.0版本

5.各功能或整体软件所需满足的非功能性需求有对应的测试用例    V4.0版本

这样做既可以对代码版本进行控制，也可以应对需求变更的问题。

也许“确定测试目标”还不能彻底解决复杂测试工作中出现的问题，但是我觉得这最起码可以让你的测试工作变得有条理；跟领导汇报工作的时候业绩和工作效率有凭可据；面对需求变更的时候有理可依！