|
大家好!
我是测试新人freedom_me,有半年的测试经历,了解到了一些基础的测试理论(流程,文档,配置测试环境等),以及测试设计,例如测试计划,测试用例,(自动化方面简单的脚本录制),
测试执行方面,例如执行测试用例做预测试,系统测试,回归测试,仅限于黑盒测试,一般情况下就是照着功能需求,作一些功能校验,界面检测,链接检查,及UI检查,易用测试等等.这样的测试工作个人认为,没有很好的测试策略,不熟悉测试对象,随意性很高的手工黑盒,是很难做到高度的覆盖的,但也只能局限于此.
测试总结方面,一是自身惰性等原因,二是接触的项目不多;像测试报告体现测试成果的文档,没有系统地写过,或许也因此让公司高层看不到测试产出,看似不介意测试部门的工作,是否尽职,效率,有价值;这个方面也自觉需要重视,缺陷的总结,对提升手工黑盒测试经验帮助很大,也能从提升软件质量的角度来做测试执行的工作.
还有一个算是测试总结的或许就是产品使用说明书,这份文档在测试开始之初,就是我们的产品策划书,只不过前者的对象是客户,后者是项目组成员;近一项目,由于在需求管理平台上,所提供的测试需求点,是由我录制上去的,个人体会就是,这些是测试的依据;掌握产品功能,可提升测试的效率,
在所做的不长的测试经历中,测试设计(测试计划,测试用例,自动化测试脚本等)或许就是需要点思考空间的工作,所做的唯一一个项目测试计划,进行到测试用例设计后,便以开发进度拖后而停滞,已失去了项目进度控制的功效,O_|||;
测试用例自觉是可以指导测试执行的,也是可以考察设计者的思路,责任心等,目前所处的部门,对是否是一个完善的用例,没有评审机制,好罢,不好也罢.导致后期系统测试,或回归测试期间,随意性高,不能保证,经过了测试之后,需求都是通过了验证的..
问题,太多,就不一一列举,可能是在啰唆,但本意是改变这一切,自己对待测试心态,经验;以及测试部门的地位.
最后,申明下,工作只是生活的一部分,要快乐地生活,自然包括工作了,哪怕目前困境重重.
希望能够得到你的回复,帮助;谢谢! |
|