如何做好系统测试

如何做好系统测试

 

 

目录

1       目的... 2

2       目标读者... 2

3       说明... 2

4       Part1 项目各阶段工作... 2

4.1        需求调研阶段... 2

4.2        项目启动阶段... 2

4.3        项目开发阶段... 3

4.4        集成和系统测试阶段... 3

4.5        项目上线... 4

4.6        运维阶段... 4

5       自我提升... 5

5.1        总结学习... 5

5.2        保持好奇心... 5

6       bug预防工作... 6

7       需要开发人员配合的工作... 6

7.1        数据库更新要求... 6

7.2        代码提交问题... 6

7.3      bug做解释... 7

 

 

 

 

1           目的

         本文旨在分享自己的测试心得,探讨如何作出高质量的系统测试工作,为测试员提供工作指导。对项目管理者来说,可以参考本文档评估测试工作量,检查测试员的工作质量。

 

2           目标读者

         初、中级测试工程师。项目管理者。

3           说明

         提高产品质量,是涉及全员、全流程的管理,在实际操作中困难重重。而本文此次只探讨四个方面,以后再陆续跟大家探讨其他流程。

  1. 项目各个阶段的测试任务,任务指导
  2. 自身素质
  3. bug预防
  4. 需要开发人员配合的工作

        

4           项目各阶段工作

为便于给读者建立和巩固测试技能体系,便于依据本文开展测试工作,本文按照项目发展阶段进行论述。

4.1          需求调研阶段

         该阶段项目经理会跟客户进行需求调研,中间会开会讨论客户的需求,并进行评审。此时测试人员就需要进行参会讨论。这个阶段,测试人员工作主要是:

u  理解需求,特别是思维导图和业务流程图VISIO;

u  理解项目背景,这有助于制定测试计划,安排测试重点;

u  理解公司的业务,这点很重要,如果能从客户业务层面提出问题,会得到客户深深的认可;

u  找类似产品和行业背景参考。

4.2          项目启动阶段

制定测试计划

         在项目启动会为止,项目经理已经需求调研完毕,且完成了开发任务排期。这时测试经理或者主管即需制定测试计划。。。公司现在的项目来看,测试时间是没法由测试自己选择的,所以,只能配合项目在既定的时间内提高测试质量吧。测试计划中的重点:

u  划分各个阶段的时间安排(单元测试阶段、集成阶段、系统测试阶段、回归阶段等)

u  测试工作安排(测试的内容,如功能测试、性能测试、兼容性测试、数据完整性测试、排他性测试等安排)

 

加深业务理解

         加深业务的理解,根据需求说明书绘制系统测试visio图。要点:根据数据流向,绘制完整数据流,注意限制条件。

 

设计测试用例

         根据《需求规格说明书》和Axure原型图进行测试设计。工作要点:

u  根据《测试工作指南》、《测试框架》和《测试用例库》编写功能测试用例;

u  根据《web安全测试规范》裁剪安全测试用例;

u  根据《APP测试用例大纲》裁剪APP测试用例;

u  准备测试数据

 

4.3          项目开发阶段

该阶段开发人员按照WBS进行开发,测试人员按照开发计划进行测试(功能测试阶段)。测试工作要点:

 

u  整理测试过程中遇到的系统疑问,记录到《XX系统业务疑问与解答》中;

u  填写《每日测试记录》并汇报;

u  重点检查需求实现的一致性,其次检查《GUI测试指南》;

u  整理并提交《每日测试报告》;

 

测试原则:遵循优先保证系统逻辑走通的原则。但测试过程中发现的bug,无论大小都提交到禅道中。

 

4.4          集成和系统测试阶段

集成测试和系统测试的区别:

         集成测试重点关注各个功能模块的数据联动、传输是否正确。系统测试在此基础上,还需要关注软件的安全性、稳定性、兼容性、性能等。

         实际工作中,限于项目周期,一般会将两者结合测试。

为提高测试的质量和效率,将测试工作分为四轮执行,每轮测试工作的重点如下:

第一轮测试:

u  关注流程是否走通?主要关注正常流程和场景,即需求中定义的流程和场景。

第二轮测试:

u  存在性测试;

u  排他性测试

u  连续点击测试;

u  数据完整性测试;

u  安全性测试;

u  兼容性测试;

第三轮测试:

u  存在性测试(深度排查);

u  探索式测试;

u  安全性测试(深度排查);

u  兼容性测试(深度排查);

u  性能测试

第四轮测试:

u  对外接口测试

u  需求变动测试(系统测试阶段末期,一般客户会查看系统并提出部分修改意见,此时重点关注新需求)

 

测试汇报工作:

 

u  在该阶段需每周提交《阶段性测试工作汇报》,汇报该阶段中系统发现的问题、bug发现趋势、bug状态等。

u  在系统测试结束后提交《系统测试报告》,评价系统是否具备上线资格。

 

4.5          项目上线

配合项目组,准备系统验收资料,如《UAT测试报告》。

4.6          运维阶段

bug是测不完的,特别是急于上线的项目,可能漏测得bug更多。所以运维阶段需要注意收集项目上线后反馈的问题,建立《系统运维问题跟踪表》 。对运维阶段发现的bug总结分析原因,在下个项目中重点关注。

 

以上是作为一个测试员的基本工作,如果想真正做好系统测试工作,还有更重要的工作要补充。

5           自身素质

5.1          总结学习

         正所谓温故而知新,平时把《黑盒测试框架》多看看。

5.2          保持好奇心和质疑精神

         好奇心就是多问问为什么,质疑精神就是要敢于质疑系统设计不合理,举一个较典型的例子。

   

 

         这是一个分销系统的页面,图一是店铺管理中的上架商品列表,图二是下架商品列表页面,图三是选择商品的页面。实现的逻辑是,在选货页面(图三)选择商品上架,之后选择的商品会显示到上架商品列表(图一),可以对上架商品进行下架和删除的操作。 商品下架后显示到下架商品列表里。而把商品从上架或下架列表中删除后, 商品回归到选货页面。

         测试这个页面时,习惯性的问自己,这个页面显示什么数据,为什么这么显示?然后就找到了一个有争议的地方:即选货页面(图三)是不显示下架商品的。为什么觉得有争议呢? 因为假设我是一个用户,我把商品下架后,可能以后我都不会再主动关注已下架的商品,而在这个时间已下架的商品若有特殊的变动,我也难易得知(因为我更多的会去看选货页面)。 这样一来,日日顺商城做的一些推广可能就传到不到分销商那里。毕竟,商品数据还是不少的。

         不过反过来说基于该分销平台的特点,可能会让用户 不会做下架的操作---预测大多数用户都会把全部商品选择上架,所以选货页面不加载下架的商品对应用影响并不大。

         这个地方的争议,无论怎么实现,可以说是公说公有理婆说婆有理,不一定哪一种是最好的。

         不过拿这个例子来讲,就是要为了说明如果测试过程中不多做思考,不多问一些为什么,不敢质疑系统的话,很多bug就会被漏测!

6           bug预防工作

         多数测试员做的质量保障方面的工作都是事后的补救工作(检测),bug预防是让测试员充分发挥事前和事中的的质量控制作用。

         bug预防的必要性显而易见,bug越到后期发现,修改的成本越高,所以防患于未然肯定要优于亡羊补牢。

 

         bug预防的方法主要是通过制定开发规范和测试规范。开发规范方面有《UI规范》、《编码规范》、《数据库规范》,其他包括《安全性开发规范》、《性能调优指导》、《兼容性开发规范》,并完善技术复用库(设计、组件、类库、代码)。 测试规范方面有《功能界面的检查指南》、《BUG管理规范》、《测试工作流程规范》、《安全性测试规范》,涵盖BS架构和APP,后续需要完善的是性能和自动化(自动化能解决的问题)方面的测试技术。

 

除了上面说的这些规范,每个项目测试过程中发现bug之后,也会通过分析找到具体原因和解决方案,做一些总结归纳,尝试建立该类问题的预防方法,补充到流程规范中,贯彻到全公司,最后监督执行。(世界级大公司对待bug的态度,谷歌的绩效考核,考核该类bug在本项目中出现的比率是不是比上一个项目小了,考核测试员在bug预防方面做得工作)

软件测试体系:

二、测试流程  

    版本发布控制制度。

三、测试规范

测试员工作的依据(检查标准),包括了bug分级标准,界面设计规范和web安全测试规范。

四、测试框架

工作指南(测试要点,或者说一个功能要做哪些测试)

五、开发框架

输入验证的完善等。

7           需要开发人员配合的工作

         每次项目启动会,我都会对 项目团队的成员要求以下三点:

7.1          数据库更新要求

         开发后期,数据库改动较少。这个时候对数据库结构的改动都用脚本执行。并在发版时一并发送测试员。---曾经多次遇到因为数据库改动不规范,导致测试时间增加,项目拖期的项目事故。

7.2          代码提交问题

         在bug预防中提过,代码集成要慎重。建议由条件的时候做一下code review,避免出现功能倒退等严重项目事故。同时发版和禅道上的bug要对应,因为测试人员会检查发版时间之前的bug。

7.3       bug做解释

         bug解决后,在禅道可以做个解释。如此一来测试人员可以积累定位bug根源的经验,在之后的项目中,遇到类似的项目可以直指根源,给开发人员提供检查思路,缩短开发人间排查问题的时间。

 

我在文章里留了很多文件,这里保存不上。有想要的我给你word版。

posted @ 2016-01-14 10:44  张老师的小黑屋  阅读(1985)  评论(1编辑  收藏  举报