测试心得(一)

2014年12月1日,我卖身到凯通,终于工作了,虽然工作的用到的和课堂上学到的会有不同,但也算学有所用!

在这边上班,管理流程是规范的,毕竟是中型公司,但刚工作的人,心还是自由,没办法完全适应这里的规章制度。

岗前培训的一周,我学到了每家软件开发公司都会有自己测试的流程,学校教的是主要部分:

参与需求分析-> 撰写测试计划->编写测试用例->录制测试脚本->执行测试-> 验收测试-> 维护

凯通扩展为:

协助制定版本计划-> 参与需求评审-> 编写测试计划-> 编写测试需求和测试用例-> 组织测试需求和测试用例评审-> 跟进版本开发-> 组织集成评审-> 搭建/更新测试环境-> 内部测试-> 编写测试报告

上班以来,除了开头那几天熟悉环境,其他时间都要写测试用例。要写好测试用例不容易,特别是像我这种文笔不好的人!写测试用例犹如写文章,看久写久了,就会有自己的风格,我写了半个月,也基本形成了自己的风格:

阅读需求分析和测试计划等文档-> 编写测试需求-> 编写测试用例

首先,阅读需求是最重要的,我们的活动都是围绕需求开展的,不清楚需求就无法进行开发,更别说测试了。清楚理解需求才知道开发出来的功能是否符合需求,是否符合需求也是需要我们测试的。其次,作为初级测试工程师(美其名曰),测试计划就不是你写的,要清楚知道测试计划,按测试计划进行测试,测试才能有条不絮地进行。下一步的编写测试需求其实不是必须的,只是为了更好的进行测试;如果有了测试需求,测试用例就可以按照测试需求,一点一步地去编写了。如果按前面的步骤,一步一个脚印地去进行,最后编写测试用例也就不难了!注意的是,要细心,有的测试是在编写测试需求时没想到的,也要进行测试,最好是修改测试需求后,再写测试用例。这就是为什么凯通的测试过程要先写测试需求的原因了吧!

在学校,我们会学习TD(TestDirector)这个测试管理工具,老师也说了,在公司不一定会用到,结果,承老师贵言,还真的没用到(我还暗自高兴,还好没听课)。公司用的是SVN(版本迭代工具)和公司自己的系统,原理都是差不多的,所以,我也后悔自己没听课,后面要补习,不过,提前学习一下SVN,也是可以的。

公司是一个企业,企业做事就不能和个人一样,用盗版可是要负法律责任的!既要成本低,又要合法,公司综合考虑(我也不知道综合什么因素考虑),就没有用SQL Server,而用了Oracle,其实除了部署平台和部分语句不相同,其他的都差不多!还好我的SQL语句学得还行(因为老师太严),在公司还算是有用武之地!

公司的服务器果然如老师所说,用的是Linux系统,这我还真的没学好咧!就是学好了,也还不一定能用的上,because老师教的是图形化界面的,这里用的是比纯牛奶还纯的纯命令行界面,所以,奉劝那些每节课都在装Linux系统的童鞋,还是好好学命令行语句吧!

公司对测试的趋势是测试需求相结合,这么说来,当上需求分析师,成为项目经理将不再是梦想(想想都有点小高兴)!这就是我继续做测试的目标,希望现在在学测试或做测试的同学或同事不要觉得不如开发,好好学,好好干,早日迎娶白富美!!

时间: 2024-11-05 14:50:50

测试心得(一)的相关文章

基于微信小程序的电商平台——测试心得

经过连续两周半的紧张编程,我们第二次迭代版本也新鲜出炉了,至此我们这个小程序的所有功能基本已经实现完毕,按照计划,我们进行了小程序的测试. 由于小程序的有一个比较特殊的情况就是,若不上线就只能功内部开发人员使用,而又由于上线需要比较多的流程和手续,经过协商之后,我们决定在测试阶段不上线,于是测试的用户只有我们这一个小组的成员,充当测试用户. (1)测试方法:系统测试: (2)测试手段:手工测试:将整个小程序分成五大部分,也就是我们的那几大功能,每一个测试人员测试一块,若有BUG及时提出,能修复则

测试心得——噪声小分队

心得 作为PM兼职开发人员,在开发过程中就充满了矛盾: 在测试过程中,更是要把自己的身份转换成用户(还是那种近乎无理取闹的奇葩用户),用比PM更加刁钻的眼光去看待产品. 我们小组用了一个词去描述测试过程--挑刺,感觉非常形象.测试点设置的核心思想就是全面,在两个维度上考虑,一个是功能要覆盖全面,另一个是场景要考虑全面. 功能覆盖比较容易,可以对照需求,场景要想尽可能全面,就要对每个功能的影响因素有哪些.以及这些因素分为几种情况. 在这里举几个测试过程中修复的BUG作为例子: 1.我的客服聊天框中

测试心得:微图书销售小程序

前言 这个学期差不多也将近结束,经过大半个学期,从项目需求的确认和项目文档的编写,到一步步的设计与实现,现在终于到了测试阶段,但是我们在测试阶段也暴露出了很多bug,但是每一个bug的修复都需要进行回归测试,虽然花时间但是这是必要的工作. 模块说明(我负责的部分) 模块 子模块 模块编号 留言模块 查看留言 13 - 1 发送留言 13 - 2 删除会话 13 - 3 模块 子模块 模块编号 销量和数据分析模块 月销量排行榜 12 - 1 周销量排行榜 12 - 2 总销量排行榜 12 - 3

项目测试心得

经过差不多两个月的努力(只算写代码的时间),项目基本算是告一段落,在经过千辛万苦部署到服务器上之后就进入了测试的环节. 1.web界面测试 作为web的开发人员之一,其中的辛酸一言难尽,尤其是第一次设计的界面"由于缺少设计灵感导致web界面不符合用户体验"被舍弃,最后采用web模板对其进行修改 但是登录界面依旧采用原来的设计,虽然有点简陋,有些部分看起来有些别扭,但整体还是可以接受的 2.web功能测试 整个功能的实现是没问题的,但存在一类问题,这也是我在开发时就发现的问题,由于web

快易需求文档编辑系统——测试心得

一.项目背景 软件需求文档是软件开发与维护的重要基础,本项目希望通过建立一个专业的需求文档编辑系统,为软件开发人员提供一个便捷的协作文档编写工具,推动需求文档编写的规范与文档重用工作.同时,也为广大软件公司提供一个随时可以访问的平台,推广快易文档编写系统. 二.测试对象 快易需求文档编辑系统致力于帮助需求分析工程师快速编写需求文档,提高工作效率和文档质量.类比代码重用将需求文档中可重用,模式化的部分提取封装起来,形成"构件",也是该子系统的核心. 三.测试过程 与需求文档中的功能点覆盖

小程序测试心得

这篇博客,记录下我测试小程序的一些心得: 一.测试前准备: 1.环境搭建,环境配置,前端页面,必要的时候可以下载微信web开发工具,参考文档如下, https://www.jianshu.com/p/4d3190111eb0 2.管理后台,准备数据,准备账户 二.测试范围: 1.权限测试: 未授权登录小程序--未授权的时候,进行业务的操作,一般使用这个都会弹出框,提醒你先授权在登录小程序:ps:在这一块,特别注意小程序的分享,分享打开后,没有授权情况,业务是你能查看:还有就是老用户,小程序被ki

LoadRunner压力测试心得总结

一.虚拟用户迭代一次的时间对整个压力场景的影响. 1.虚拟用户迭代一次的时间大于等于压力场景的上行周期. 此种情况,在压力场景的上行周期中,所有虚拟用户根据压力场景设置的策略全部依次运行.压力场景的上行周期过后,进入虚拟用户运行的稳定期,因为此时第一个运行的虚拟用户尚未退出迭代.当第一个运行的虚拟用户退出迭代时,即进入运动期.在运动期中,会不断的有虚拟用户上线和下线,此起彼伏,但当前运行的总虚拟用户数与总虚拟用户数接近,实际中会有所偏差,偏差的数量与压力场景步长的设定以及脚本的睡眠时间有关.当场

兼容性测试心得分享

有多少朋友做过浏览器兼容性测试?怎么做的,效率怎么样,是在不同的机器上下载不同的浏览器进行效果确认?有多少人对浏览器的兼容性测试犯过愁? 本人曾经也对浏览器的兼容性感到头痛,后来到网上找了些资料和工具,虽然未能彻底解决所遇到的问题,不过多少有些帮助,特此分享给大伙,若大伙有什么更好的工具或是经验方法还希望能拿出来晒一晒. 鄙人主要尝试过这几个工具:IETester, SuperPreview,Browsershots,Browser Sandbox.下面分别说一下. IETester 估计工作两

WEB网站测试心得整理

一.输入框: 1.正常的字母/文字/数字(正常流程的测试): 2.重复提交(输入内容后,重复点击提交按钮): 3.纯异常字符/正常输入夹杂异常字符(!@#¥%--&**等等): 4.长度限制(边界值测试,假设最小长度为N,最大长度为M,则测试N-1,N,M,M+1): 5.重复输入(已经存在记录,重复输入): 6.空提交(什么都不输入直接提交,看程序如何处理): 7.含有空格(开头,中间,结尾): 8.含有回车(输入内容中含有回车,查看如何处理,如何保存,以及如何显示): 9.复制粘贴操作(如密