1、工作阶段
第一阶段:从学校毕业后的第一份工作,是从理论转换为实践,从跟老师学习到跟工作中的师傅学习,把想法和知识放到工作中实现。
第二阶段:换工作的阶段,从软件测试到网页测试,重新学习网页测试的知识与测试方向,并把之前学到的东西通过提炼应用到新的工作中(配 HOST,兼容性,面包屑,title,返回等)
第三阶段:也是公司的发展最迅速的阶段,需要快速让版本上线,一对多人,不需要用例,手动测试偏重,BUG 也较多,但是能保证让新东西及时上线。差不多每天都需要改线上 BUG。
第四阶段:公司已经进入平稳阶段,更看重质量。工作重点从手动测试向用例驱动测试发展,辅助工具出现,帮助节省测试时间。不是为了快速上线,而且这个项目给我们带来了什么样的效果,更注重结果。当然 BUG 前置,BUG 数量减少。也是我们现在的阶段,也是我迷茫,不知所措的阶段。
2、项目阶段
创业阶段:没有迭代,排期。需求文档测试,开发,产品三方宣讲。
特点:需求细致,不需要提供用例,测试在开发完成后介入测试。
一个项目的周期大概就是开发,提交测试,测试,改 BUG,测试完成,上线。
平稳阶段:有迭代排期,需求邮件确认,排期会宣讲。
特点:保证项目按迭代提交测试,提供测试用例,前期测试进行验证,后期开发执行测试用例。没有大的项目进入基本能按迭代交付用户使用。
平稳 + 新项目阶段:有迭代排期,需求邮件确认,排期会宣讲。
特点:优秀保证新项目的测试资源,老项目的正常优化提供测试用例,开发测试,测试抽测。
测试人员与开发人员的比例:8:1,新项目开发 4 人,旧项目开发 4 人。新项目的周期长,旧项目保证用例及时提交开发,新项目不按迭代走,旧项目按迭代排期
3、工作中的学习阶段
功能测试:功能测试一直持续到今天,唯一担心的,按现在公司的发展思路,怕手动测试慢慢给放下了。
性能测试:公司创业阶段用的多一些。工具:loadrunner:页面与接口的性能测试,录制,回放,检查点,集合点,场景设置,分析响应时间,CPU 等。工具:SQL Server Profiler:主要是刷新性能差的页面,监控页面中的 SQL,CPU,Reads,是否加 with(nolock)等。
安全测试:公司创业阶段用的多一些。工具:AppScan:配置后自动跑,会自动生成报告。
UI 自动化测试:公司创业阶段用的多一些。语言:C#。专门有一个新来的测试技术手把手的教我们,留作业强制学习的。当时项目忙,加班学习。后来不用了,因为页面样式变化频繁,脚本维护成本过高,投入大于产出。
接口自动化测试:两个阶段,第一个是测试技术开发的接口平台,一个是现在用的 python 脚本编写,当然我们都是用现成的框架。接口平台简单,把接口录入,加检查点,保证接口是通的就行。python 要实现的是逻辑测试,把手动需要测试的测试点全部用脚本实现。python 还在学习中。弊端:脚本中实现的主要是业务逻辑,我们还比较看重页面样式,交互,兼容性,需要开发给出详细的接口文档。
用例驱动开发:现在公司的工作模式,重点是提供用例,对用例的要求比较高,由开发执行用例,测试人员抽测,提交测试后的 BUG 明显减少。写用例的时间占了每周的一半时间,还有一部分时间是接口自动化的脚本。目标:用例可以不用执行,接口自动化脚本和项目同步完成。
4、总结
这几年不管是性能还是自动化都不如功能测试做的多。功能测试是自己的,性能和自动化是向别人学习的并且会的也只是皮毛。
我一直不太相信的就是自动化,总觉得不管是哪种测试方法都应该是一步到位的。
手动测试:样试,兼容,逻辑全部能覆盖到。
UI 自动化,只能跑跑样式,简单的逻辑,兼容性不能跑。
接口自动化,只能测试业务逻辑,样式,兼容,页面上某个提示内容等都不能覆盖到。
以上只是我个人能力不足的情况下的个人感受。


↙↙↙阅读原文可查看相关链接,并与作者交流