写在篇头,本人前端开发攻城狮,结合自己开发过程中和软测的互掰历史,浅显的谈谈我对软测成长的看法。
软件测试成长指北
1.首先了解一下一般企业对软件测试人员的招聘需求,对症下药
大部分的公司要求都是:负责产品的测试工作,包括需求分析、需求评审、制定测试计划、用例设计、缺陷跟踪,质量分析报告等。所以软件测试的核心工作是围绕着产品质量而展开的一系列 研发活动 。
2.在了解了软件测试的招聘需求后就可以开始走上从入门到放弃的道路了
话不多说直接上图
Analyze:软件开发的流程都是从需求出发
简单的说,一个项目拿到手,你得知道它大概是干什么的。尽可能的将这些需求功能切割成若干个大的模块。在每个模块中剖析它的功能点,知道合理的业务逻辑、流程、操作。尽可能挖掘业务上的边际数值,报错阀值。可能出现得错误和用户的非人类操作导致的异常应该如何处理等等。
Plan:项目的测试计划制定,并进行风险分析。
计划的核心就是优先级、重点、难点。软件测试的工作本省冗杂且庞大,要高效完成测试就需要了解软件开发(程序猿)的工作流程(摸鱼史)。了解哪些业务、功能属于项目的基石,需要重点把控。
Develop:开发包括产品的开发和测试方案的开发(含测试用例)
Check:对 待验收的产品进行检查,并给出检查报告。
综上,对于一名合格的软件测试工程师,需要软件测试和软件工程的知识,具备办公类软件技能和软件测试相关的技能,掌握沟通、分析和学习的能力。
下面重点介绍一下软件测试几大法宝:
1.测试用例
测试用例难!难的不是方法,难的是思路。
比如测试用例的设计方法,等价类、边界值、因果图,你看了很多遍,但是写的测试用例仍然是一团糟。
今天我带你手把手的写一下雪球APP登录页面的测试用例,如果看完最后的图解和思维导图,你仍然不会写的,算我输!(测试用例模板放在文末,自行获取)
先思考一个问题,下面这个简单的登录页面,可以写出来多少条测试用例?
答案是100条以上!
不要惊讶,看到后面的拆解分析,你就知道为什么要写这么多
在开始演示之前,必须先了解测试用例编写的基本原则:
- 什么是测试用例
- 测试用例的作用
- 测试用例的组成
- 测试用例的编写思路
什么是测试用例
通俗的来说,测试用例就是指导我们怎么去做测试的文档。在文档中我们提前指明我们的功能点是什么,然后怎么去测这个功能点的步骤,输入的一些测试数据,都写到里面去。当然也包括我们希望的结果。
如果我们有时间能把所有的情况都试一下的话,肯定是不会存在漏测的情况。但是现在的问题就是时间真的是不允许,尤其现在都在走敏捷的路子,大家恨不得一天上一个新功能,所以说能留给测试的时间真的很少。
怎样既能覆盖到所有的测试场景,测试的执行数量又能控制在一个比较合适的数字,这个就是我们设计测试用例的过程。
测试用例的作用
1、理清思路,避免漏测和重复测
2、提高测试效率
3、跟进测试进度
4、告诉领导做过
5、跟进重复性工作
6、更好的记录问题,发现问题,复现问题
互联网行业扔锅大法:防止背黑锅,杜绝扯皮撕逼,扔到自己头上的锅要坚决扔出去。
所以,不要讨厌去写测试用例,这个也是工作流程、步骤的一个记录。
测试用例的组成
其中标题、步骤和期望结果是必须要有的,其余的根据公司的安排就可以了。
测试用例的编写思路(重点来了!)
1、划分功能模块
2、正向功能验证:正常操作功能是否实现
3、单个功能项验证:正向+异常
4、功能之间交互验证:模块之间的数据传递
5、隐形需求:熟悉业务
在掌握了基本的理论之后,按照正确的方法,咱们来图解一下雪球APP的登录界面,应该如何去写测试用例。
汇总一下,雪球APP登录页面,账号密码登录模块的用例编写,见下图思维导图。
总结起来,测试用例并不难,难的是你总是不愿意迈开第一步,你看10篇文章,100个视频,都比不上你亲自写上一次。
迈开第一步,哪怕做的很烂,先模仿,再超越,小步快跑,快速迭代,然后不断纠正,稳步提升。
而不是,
看完了文章,仍然被畏难情绪紧紧束缚。
打败你的
只会是你自己!
2.接口测试工具
postman:这里贴上一位大佬对postman的详解(666)
https://blog.csdn.net/fxbin123/article/details/80428216
3.思维导图
简单的说就是业务流程图,推荐xmind、百度脑图。或者A4自己画(QAQ,脑中有图哪里都是图)
4.敏捷开发,流程跟踪
厂公隆重推荐jira
5.设计稿查看
主流的蓝湖、figma
6.思维导图
简单的说就是业务流程图,推荐xmind、百度脑图。或者A4自己画(QAQ,脑中有图哪里都是图)
最后,作为一名软件测试员,基本的web、h5调试(推荐chrome),微信小程序调试,app调试,各大浏览器的兼容性问题,ios和android的多端适配也是要懂的。