- 测试计划
接到任务的第一时间,需要快速建档,准备测试计划。测试计划主要有几个侧重点:
第一,该项目的截止时间和团队是否确定的阶段时间交付;
第二,模块分析图。这一块由于公司小,缺少原型图,常常导致滞后产生。并且这一块花费的时间,笔者发现常常超时,导致开发空窗,等待BUG提交。滞后会影响整体测试计划和团队开发计划,这一直是去年测试的难点所在。因为功能测试主要在后期,需要开发们整体搭建起来,才有办法去做较为完整的模块分析图。模块是经常根据需求更改,模块分析图也是根据需求走。去年常常做一段改一段,这是笔者所在小公司的常态。
第三,需求分析报告。每一次会议,最好录音下来,开会时记录关键点。有些需求通过模块分析图去提炼会准确多。需求分析是比较困难的阶段。小公司常常只有粗略的需求分析报告,按照笔者经验,需求理清楚一些细节,常常会导致漏测。笔者去年就被甲方举报过几次,说BUG都没测出来,被领导开会批了几次,都是血泪史
第四,测试按模块进行,需要把控时间。怎样高效执行,我觉得时间是块大问题,最后开始测时,常常时间是不够。这是功能测试最大的挑战之一。
- 冒烟测试
跑通程序,中途出现的BUG,发协作群里或者发布到公司的协作平台上并@相关人员。
- 快速测试
不设计测试用例的文档,但是要按着用例的思路来,进行快速测试,满足软件上线的需求。这一步在测试用例之前,主要是为了避免测试用例文档书写和执行缓慢的特征,会耽误开发修复BUG的时间。快速测试能找出大部分的功能性BUG,但是还需要后续根据测试用例进行细致地测试。主要还是为了应付公司上级的需要,笔者所在小公司是这样的,要求一俩天看结果。爆肝通宵,都测不完。
- 测试用例建立及执行
这一段基本上是项目中期到末期了,这一段需要加班。过往的经验是这一段执行得不完全,因为时间不够用。然后执行得不彻底,又会导致交付服务评价很低,客户会抱怨和投诉。现在笔者采用ones这个工具管理测试用例,效率提高不少,许多用例都能复用。之前有大佬说用禅道,笔者是小公司,没有去使用过。ones用起来还不错,又是免费的。正常来说,应该是第一次整理写用例文档时执行过一次,然后再拉入测试计划再测试一次。这样顺便可以核对一下测试用例的文档。另外,交互测试最好另外再设计一块专门的用例去执行,这部分的BUG很容易遗漏,甲方使用时很经常出现,交付时很痛苦。
- 回归测试
这是最后一段。一般是俩种思路: 第一,执行已过的测试用例;第二,执行回归测试上的缺陷报告,再写些新的用例并执行。
特别要防止的情况是交付前,开发私下调整代码而不告知的情形。到了交付的日子,出现卡BUG的情形,相当尴尬。这种事也不会有人承认,最后只能默默背锅。所以交付前,必须重点进点浏览一下各个页面,防止各种BUG跳出来斩杀你。
回归测试还需要查验界面元素。其中包括字体大小,颜色,图片,图标,排列等元素的测试校验,消除低级错误。这也是之前小白测试开始时的教训。
- 制作用户手册
制作文字版的用户手册,做好之后还需要进行测试。这块看公司需要,小公司正常都是打杂工,需要的最好做一下,避免被领导突袭。临时弄,真是难产!
- 制作演示的PPT
同手册,按照自己公司需要来,也是要避免突袭难产的情况。
- 交付时需要观察和沟通用户的新需求,并且了解客户是否还有别的软件需求
- 作个测试报告和交付分析总结报告。
这一块新手是比较缺失。这一块还是需要重点去做,总结一下经验,复盘提升经验。ones可以直接导出测试用例报告和执行情况,以及缺陷报告。其他工具应该也都有这种导出功能。
小公司除了功能测试,常常还要打杂,所以测试计划的时间完成预估,都得比预期提前几天,最好能提前一周完成,防止中途打岔。这是去年常常出现的情况,还有自己的状态需要多调整,防止因为作其他事导致厌倦,注意力分散等浪费时间的行为,使测试计划无法按时完成。作为一个新手小白,只能慢慢苟着学技术。
希望新的一年,笔者到年底能升级成自动化测试,懂得使用自动化工具,摸到自动化测试的门槛。