码迷,mamicode.com
首页 > 其他好文 > 详细

17年工作总结

时间:2018-07-17 16:23:58      阅读:181      评论:0      收藏:0      [点我收藏+]

标签:简单   生命周期   准备   用例   2017年   过程   包括   关心   状态   

  2017年从学校毕业到参加工作一年时间,一直在从事着软件测试的工作,先后通过两位测试同事的合作与学习,再加上这一年来大大小小的软件测试经验,总结了一些心得。
 
  首先是测试流程,流程相对于工作不光是规范,同时也是在告诉我们每个阶段需要做什么。
 
  然后是测试用例,主要是说明测试用例的必要性和编写的方法。
 
  第三是缺陷管理,包括了缺陷的生命周期以及录入一个缺陷生命周期需要哪些要素。
 
  第四是测试报告,简要说明测试报告应该包含的内容。
 
  第五是其他测试。
 
一、测试流程
 
  1)项目启动时,项目经理根据项目的需求,向测试部门提出测试人员需求,应该包括以下内容:项目周期、项目目标以及完成标准;
 
  2)测试部门在接到项目组的测试需求后,进行需求评审,需要给出相应的团队信息,团队人员、分工;
 
  3)测试主管需要写测试计划,对整个项目的开展进行排期,同时也包括了测试人员的分工和工作排期;
 
  4)测试人员在接到工作任务安排的时,
 
    4-1)首先要详细阅读需求文档和原型,分析需求时,可能会遇到需求文档描述的不清晰或者功能逻辑遗漏的情况,所以在写测试用例之前,最好要有一份测试分析文档,测试分析针对系统功能拆分进行粗略的书写,在测试分析时就要找产品部门进行需求核对,把不符合逻辑的地方讨论清楚;
 
    4-2)测试分析完成后,参照已有的测试分析,就可以进行测试用例的书写,测试用例和开发写程序的时间是并行的,可能提早;
 
    4-3)完成测试用例编写后,测试部门内部需要对测试用例进行评审并修改;
 
  5)在开发将war包提交给测试部门后,测试部门可以将已经准备好的测试环境搭建发版,首先收到开发人员的邮件说明(需@项目组),哪些页面哪些功能可以进行测试,然后测试人员有正对性地对相应的功能进行一轮冒烟测试,查看是否达到测试准入的规范,
 
    5-1)不通过测试准入,鉴于没有引入相应的奖惩措施,可以回复开发的转测邮件,说明问题影响测试工作;
 
  6)执行测试用例过程中,进行日程bug管理、回归测试;
 
  7)测试通过,输出测试报告;
 
  8)项目上线,正式环境测试;
 
二、测试用例
 
1)简述:用文字描述出系统测试时的操作步骤
 
2)好处:
 
    2-1)清晰思路、避免遗漏
 
    当系统功能多且复杂时,根据系统每个模块,拆分功能点,花点时间思考并整理成文档,尽可能结合功能与业务,模拟不同场景,从根本上避免了直接测试系统的“手忙脚乱”。
 
    2-2)明确测试进展
 
    参考测试用例,可以清晰看到哪些用例执行了,哪些用例没有执行,从中看到测试进行到哪一步,以及结合问题管理平台,直观地从测试角度,分析项目进展。
 
    2-3)系统模块缺陷率
 
    根据测试用例发现的问题,可以看到哪个功能模块出现的bug较多。
 
3)方法:
 
    3-1)等价类划分:输入的子集中选择,假如输入要求输入数字1到10,那么输入4和7去验证;
 
    3-2)边界值:输入支持的最大值,假如一个文本输入框最大值为100,输入的内容超过101;
 
    3-3)因果图:判定表,通过因果关系判定;
 
    3-4)错误推测法:基于测试经验推测系统在什么样的操作可能会出现错误;
 
4)元素:
 
    4-1)目录
 
    根据拆分的系统功能点,每个功能点可以用目录的方式区分,如一个系统的系统管理-用户管理-用户添加,那么系统管理就是一级目录,用户管理就是二级目录,用户添加就是三级目录;
 
    4-2)测试项
 
    同上,根据三级目录,一般用户添加包括的元素有用户名、密码输入框、保存按钮、取消,那么每个元素都可以分成一个测试项;
 
    4-3)操作步骤
 
    每一个测试项,都对应相应的操作步骤,可以分成操作步骤1、操作步骤2,操作步骤可以细化到,点击添加用户的按钮、输入框输入某某用户名密码点击保存按钮;
 
    4-4)预期结果
 
    操作步骤,在完成一系列动作之前,都要有对应预期结果作为参考,这个参考就是最初业务部门提供的需求分析文档,根据需求分析文档来告诉我们每一个功能要有什么样的结果;
 
    4-5)实际结果
 
    操作步骤,完成之后,需要记录实际的情况,如果与预期结果不符,就可以归于bug;
 
    考虑是否可以将实际结果改成注释,避免与预期结果一一对应关系,解耦合。
 
    4-6)优先级
 
5)探索性测试
 
      在设计测试用例时,并不能完全保证每个功能每个场景都设计到位,而且单纯执行测试的时候非常枯燥,那么加入一点发散性思维,进行一些非常规性操作,以用户的心态去使用系统,或是尽情地“破坏”系统,发现系统的问题。
 
      真正的探索性测试需要对产品的深入了解,以及软件开发技术有一定的深度和宽度。
 
  6)用例评审
 
      测试用例编写完成后,需要在测试内部进行一次评审,评审的内容包括:功能是否完整、需求是否符合,使每一个测试人员在系统测试过程中,不存在主体思维的偏差。
 
      同时用例评审也是一个很好的学习过程,每一位测试人在介绍系统时,能够意识到各自设计用例时的不足,包括自动化、性能都可以进行技术的探讨。
 
7)不需要用例情况:
 
    7-1)功能过于简单
 
    7-2)急于交付,弊端就是不能保证测试的覆盖率。
 
三、缺陷管理
 
  1)缺陷生命周期:
 
    1-1)提交bug、指派解决人员、确认问题、处理问题、回归测试、关闭问题
 
    1-2)确认问题时,如果开发未发现问题情况,需要测试进一步验证,验证完后再次提交;
 
    1-3)回归测试时,如果测试未通过,需要打回处理,相关措施可以参照准入流程邮件发送;
 
  2)缺陷要素
 
    2-1)重现环境,需要注明操作系统、什么浏览器及版本、还有在测试环境下哪个数据库;
 
    2-2)问题类型,redmine有系统异常、操作指导、新需求;
 
    2-3)缺陷等级,等级可以由低——>中——>高——>紧急来划分,高优先级的任务必须要求开发人员优先处理;
 
    2-4)缺陷状态,有新建、处理中、已解决等;
 
    2-5)操作步骤,描述发现问题时的操作场景;
 
    2-6)预期结果,描述发现问题时的操作步骤,应该是什么样的结果;
 
    2-7)测试结论,简要说明问题情况以及结论;
 
    2-8)截图,tomcat的log日志;
 
四、测试报告(第四点copy百度百科)
 
   1)测试结论(测试是否通过/是否满足发布要求/是否能够发布)
 
   2)罗列发现的主要问题(或者说该版本存在的主要风险)
 
   3)测试版本(客户端,服务器)(如果允许发布,附件发布包或其链接,包大小,以及md5校验码)   
 
   4)测试内容(测试范围)
 
   5)测试用例执行情况(一共多少,执行了多少,未执行多少,通过多少,失败多少)
 
   6)发现的严重缺陷有哪些(仅仅罗列最严重级别的bug)
 
   7)邮件的附件是测试计划执行结果文件
 
五、用户容忍度与易用性测试
 
很多时候,项目组对待软件的质量会与用户容忍度有一定的关系,像是交付性的软件,只需要做完之后然后交付给用户,甚至UAT不需要测试部门内部进行,那么这样的情况下,我们更关心的应该是功能的实现。
 
    举个不恰当的栗子,当你很口渴的时候有个水壶,你需要一个杯子,那么你关心的只是这个杯子能不能装水能不能喝,此时杯子需要的特性就是:能用、干净。
 
    但是如果这个杯子被放在商城的展柜上时,那么需要的特性就非常的多了,如下拆分:
 
    1)功能测试。杯子是否能装水,还能否装下其他液体,杯子的容量如何,是否有刻度,能支持最大的热量和最低的温度是多少;
 
    2)界面测试。杯子的外观如何,颜色和形状怎么样,重量如何,是否有异味;
 
    3)性能测试。能否装100°以上的水,泡茶泡面,能否放在冷藏柜里冰冻,杯子盛水后长时间是否会漏水,是否会被压碎;
 
    4)安全性测试。杯子是否有毒,是否易碎,碎后时候会割手,易生细菌,会不会爆炸或融化;
 
    5)易用性测试。杯子形状在手上好不好拿,导热如何会不会烫手,是否防滑,形状设计是否容易被喝到;
 
     有时候不要为了测试去测试,为了体现自己的价值,非揪着某个问题不放,对项目进展没有帮助性的工作。对此,我并不是说测试人员可以放弃自己的测试原则,只是说当前的环境并不支持或适合你去开展测试工作。
 
    为贡献产品的发展测试远比为了测试了测试所带来的价值大得多;所以站在产品的发展上去看待测试工作更能体现自己的价值。
 

17年工作总结

标签:简单   生命周期   准备   用例   2017年   过程   包括   关心   状态   

原文地址:https://www.cnblogs.com/zxylock/p/9323127.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!