标签:
如何做好系统测试
目录
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
本文旨在分享自己的测试心得,探讨如何作出高质量的系统测试工作,为测试员提供工作指导。对项目管理者来说,可以参考本文档评估测试工作量,检查测试员的工作质量。
初、中级测试工程师。项目管理者。
提高产品质量,是涉及全员、全流程的管理,在实际操作中困难重重。而本文此次只探讨四个方面,以后再陆续跟大家探讨其他流程。
为便于给读者建立和巩固测试技能体系,便于依据本文开展测试工作,本文按照项目发展阶段进行论述。
该阶段项目经理会跟客户进行需求调研,中间会开会讨论客户的需求,并进行评审。此时测试人员就需要进行参会讨论。这个阶段,测试人员工作主要是:
u 理解需求,特别是思维导图和业务流程图VISIO;
u 理解项目背景,这有助于制定测试计划,安排测试重点;
u 理解公司的业务,这点很重要,如果能从客户业务层面提出问题,会得到客户深深的认可;
u 找类似产品和行业背景参考。
制定测试计划
在项目启动会为止,项目经理已经需求调研完毕,且完成了开发任务排期。这时测试经理或者主管即需制定测试计划。。。公司现在的项目来看,测试时间是没法由测试自己选择的,所以,只能配合项目在既定的时间内提高测试质量吧。测试计划中的重点:
u 划分各个阶段的时间安排(单元测试阶段、集成阶段、系统测试阶段、回归阶段等)
u 测试工作安排(测试的内容,如功能测试、性能测试、兼容性测试、数据完整性测试、排他性测试等安排)
加深业务理解
加深业务的理解,根据需求说明书绘制系统测试visio图。要点:根据数据流向,绘制完整数据流,注意限制条件。
设计测试用例
根据《需求规格说明书》和Axure原型图进行测试设计。工作要点:
u 根据《测试工作指南》、《测试框架》和《测试用例库》编写功能测试用例;
u 根据《web安全测试规范》裁剪安全测试用例;
u 根据《APP测试用例大纲》裁剪APP测试用例;
u 准备测试数据
该阶段开发人员按照WBS进行开发,测试人员按照开发计划进行测试(功能测试阶段)。测试工作要点:
u 整理测试过程中遇到的系统疑问,记录到《XX系统业务疑问与解答》中;
u 填写《每日测试记录》并汇报;
u 重点检查需求实现的一致性,其次检查《GUI测试指南》;
u 整理并提交《每日测试报告》;
测试原则:遵循优先保证系统逻辑走通的原则。但测试过程中发现的bug,无论大小都提交到禅道中。
集成测试和系统测试的区别:
集成测试重点关注各个功能模块的数据联动、传输是否正确。系统测试在此基础上,还需要关注软件的安全性、稳定性、兼容性、性能等。
实际工作中,限于项目周期,一般会将两者结合测试。
为提高测试的质量和效率,将测试工作分为四轮执行,每轮测试工作的重点如下:
第一轮测试:
u 关注流程是否走通?主要关注正常流程和场景,即需求中定义的流程和场景。
第二轮测试:
u 存在性测试;
u 排他性测试
u 连续点击测试;
u 数据完整性测试;
u 安全性测试;
u 兼容性测试;
第三轮测试:
u 存在性测试(深度排查);
u 探索式测试;
u 安全性测试(深度排查);
u 兼容性测试(深度排查);
u 性能测试
第四轮测试:
u 对外接口测试
u 需求变动测试(系统测试阶段末期,一般客户会查看系统并提出部分修改意见,此时重点关注新需求)
测试汇报工作:
u 在该阶段需每周提交《阶段性测试工作汇报》,汇报该阶段中系统发现的问题、bug发现趋势、bug状态等。
u 在系统测试结束后提交《系统测试报告》,评价系统是否具备上线资格。
配合项目组,准备系统验收资料,如《UAT测试报告》。
bug是测不完的,特别是急于上线的项目,可能漏测得bug更多。所以运维阶段需要注意收集项目上线后反馈的问题,建立《系统运维问题跟踪表》 。对运维阶段发现的bug总结分析原因,在下个项目中重点关注。
以上是作为一个测试员的基本工作,如果想真正做好系统测试工作,还有更重要的工作要补充。
正所谓温故而知新,平时把《黑盒测试框架》多看看。
好奇心就是多问问为什么,质疑精神就是要敢于质疑系统设计不合理,举一个较典型的例子。
这是一个分销系统的页面,图一是店铺管理中的上架商品列表,图二是下架商品列表页面,图三是选择商品的页面。实现的逻辑是,在选货页面(图三)选择商品上架,之后选择的商品会显示到上架商品列表(图一),可以对上架商品进行下架和删除的操作。 商品下架后显示到下架商品列表里。而把商品从上架或下架列表中删除后, 商品回归到选货页面。
测试这个页面时,习惯性的问自己,这个页面显示什么数据,为什么这么显示?然后就找到了一个有争议的地方:即选货页面(图三)是不显示下架商品的。为什么觉得有争议呢? 因为假设我是一个用户,我把商品下架后,可能以后我都不会再主动关注已下架的商品,而在这个时间已下架的商品若有特殊的变动,我也难易得知(因为我更多的会去看选货页面)。 这样一来,日日顺商城做的一些推广可能就传到不到分销商那里。毕竟,商品数据还是不少的。
不过反过来说基于该分销平台的特点,可能会让用户 不会做下架的操作---预测大多数用户都会把全部商品选择上架,所以选货页面不加载下架的商品对应用影响并不大。
这个地方的争议,无论怎么实现,可以说是公说公有理婆说婆有理,不一定哪一种是最好的。
不过拿这个例子来讲,就是要为了说明如果测试过程中不多做思考,不多问一些为什么,不敢质疑系统的话,很多bug就会被漏测!
多数测试员做的质量保障方面的工作都是事后的补救工作(检测),bug预防是让测试员充分发挥事前和事中的的质量控制作用。
bug预防的必要性显而易见,bug越到后期发现,修改的成本越高,所以防患于未然肯定要优于亡羊补牢。
bug预防的方法主要是通过制定开发规范和测试规范。开发规范方面有《UI规范》、《编码规范》、《数据库规范》,其他包括《安全性开发规范》、《性能调优指导》、《兼容性开发规范》,并完善技术复用库(设计、组件、类库、代码)。 测试规范方面有《功能界面的检查指南》、《BUG管理规范》、《测试工作流程规范》、《安全性测试规范》,涵盖BS架构和APP,后续需要完善的是性能和自动化(自动化能解决的问题)方面的测试技术。
除了上面说的这些规范,每个项目测试过程中发现bug之后,也会通过分析找到具体原因和解决方案,做一些总结归纳,尝试建立该类问题的预防方法,补充到流程规范中,贯彻到全公司,最后监督执行。(世界级大公司对待bug的态度,谷歌的绩效考核,考核该类bug在本项目中出现的比率是不是比上一个项目小了,考核测试员在bug预防方面做得工作)
软件测试体系:
二、测试流程
版本发布控制制度。
三、测试规范
测试员工作的依据(检查标准),包括了bug分级标准,界面设计规范和web安全测试规范。
四、测试框架
工作指南(测试要点,或者说一个功能要做哪些测试)
五、开发框架
输入验证的完善等。
每次项目启动会,我都会对 项目团队的成员要求以下三点:
开发后期,数据库改动较少。这个时候对数据库结构的改动都用脚本执行。并在发版时一并发送测试员。---曾经多次遇到因为数据库改动不规范,导致测试时间增加,项目拖期的项目事故。
在bug预防中提过,代码集成要慎重。建议由条件的时候做一下code review,避免出现功能倒退等严重项目事故。同时发版和禅道上的bug要对应,因为测试人员会检查发版时间之前的bug。
bug解决后,在禅道可以做个解释。如此一来测试人员可以积累定位bug根源的经验,在之后的项目中,遇到类似的项目可以直指根源,给开发人员提供检查思路,缩短开发人间排查问题的时间。
我在文章里留了很多文件,这里保存不上。有想要的我给你word版。
标签:
原文地址:http://www.cnblogs.com/scios/p/5129449.html