前言
处于不同环境,所看所思所想可能会和其他同业软件不一致,如有异议欢迎提出指正。
最后一次编辑删除了太长不看板块,写/读博客本来就是要坐下来细细阅读静静思考。
所以我打算把2019年总结与2020年计划也揉碎到文章中,沉淀过去计划未来。
正文
先提一个问题,说到软件测试,你会想到什么?
我问了一个关系要好且未被科普(洗脑)的软件开发同事,他的回答是:我写出来的软件,你们帮我点点开哪里有bug。
一开始听到这个答案,出于我强大的自尊心使我眉头一皱正要发怒,但又一细细思考,确实如此。
所谓的点点,正好对应着我工作第三年长时间思考的一个词——计划。
凡事豫则立,不豫则废
何谓计划?
举个例子,明天我要去高铁站坐车。
不做计划:第二天出门去高铁站
安排计划:当天晚上准备行李身份证,查看去高铁站的行程信息路况信息,制定几点起床几点出门几点到车站等一系列的活动。
所以,
开发写好的一个软件,要怎么用鼠标点点才能准确并有效地发现bug?
通常软件开发的生命周期:需求、开发、测试、上线
对应测试的生命周期:测试需求、测试计划、测试用例、用例执行、缺陷回归、总结与报告
在理解了概要设计和可行性分析后,针对详细的需求文档或产品原型梳理其中的逻辑细则与流程,及时将不理解或存在疑问的地方提出,并经过讨论产生最终的软件需求。
接着站在测试的角度将软件需求进行第二次分析,分析的过程中保留两个问题,这个功能要测试什么?我要怎么测试?
假设酒店的管理层对厨房有一个对卫生隐患拍照提交的软件待开发,分为手机app拍照扫码与电脑web端查看隐患,该软件已通过最终的需求评审。
首先要了解的是其测试范围,就是刚才提出的问题,这个功能要测试什么?
因此在制定测试范围时,可先拆分为web和app两个方向的测试
web测试:功能测试、接口测试、兼容性测试、性能测试、安全测试
app测试:功能测试、接口测试、兼容性测试、交互测试、网络测试、性能测试、安全测试、环境测试
在明确了大致测试范围后,可以考虑整个测试策略。
测试策略的结构大致也可以分为:
测试级别(单元、集成、系统)、测试角色与职责、测试环境需求、上线与测试工作风险、测试进度、回归测试方法、工作优先级。
具体细节内容不再展开,经过以上一系列的思考后,就可以开展下一步工作,测试用例设计与执行。
设计方面,我曾写过一篇博客,叫《我理解的软件测试用例-开篇》,有兴趣可以跳转过去看看我对整个测试用例的理解。
执行方面,我计划后续写一篇详细的博客内容。
当一个阶段性的工作完结以后,通常是某个软件周期测试完成,也可能是像现在我在对三年的工作进行总结与反思。
过程中可以发现很多有意思的数据,比如说功能点测试用例数量、发现无效/有效bug数量、每个功能出现bug数量。
最简单的说发现无效/有效bug数量,我曾阅读过一篇文章,文章中说怎么去评价一个测试工程师的工作质量,
大致的意思是,
一号工程师测试过程中发现了20个bug,其中有18个有效/2个无效、包括0个高优先级bug;
二号工程师测试过程中发现了19个bug,其中19个有效/0个无效、包括3个高优先级bug;
以此可以评判二号工程师的整个工作效率、质量都会优于一号工程师。
当然以上只是根据表面上的数据推论得出,具体不同测试人员的工作复杂度也不同。也许一号工程师发现了软件设计缺陷,在经过产品、开发、测试三方讨论后决定的暂不处理后续跟进并标记为无效bug。
但是只要得到的数据越多,就可以在更多的维度进行评判,但也需要更多的管理和实践经验。
同时,这些数据可以很好地对过往的工作进行评价,通过数据的挖掘对未来的工作提出更有效的执行与管理。
以上,就是作为软件测试工程师需要具备的基本技能,我不喜欢用导图罗列,虽然图片化更简洁明了。
同时,为了更好地完成测试工作和面对寒冬挑战,我把技术分为了三个层面,
第一个层面,测试基础技术能力,包括Linux、数据库;
第二个层面,测试进阶技术能力,包括postman、wireshark;
第三个层面,测试自动化能力,包括编程语言、jemeter、selenium/appium;
这里为什么我会直接写编程语言而不写Java or Python,因为
作为软件测试工程师,你得会写代码
燃烧秀发输出内容,如果有一丢丢收获,点个赞鼓励一下吧!
整理了一份216页软件测试大厂面试题,以及2020推荐最新的简历模板,送给小伙伴们,关注公众号程序员阿沐回复【简历】自行领取,和一些小伙伴建立一个技术交流群,一起探讨技术,分享技术资料,旨在共同学习进步,如果感兴趣就加入我们吧!
视频课相关资料加群810119819获取,还可领取更多软件测试面试题资料和Python自动化/测试开发学习资料。