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