日常功能测试中，需要注意的重点还是很多的，比如主流程、分支流程、异常流程的测试占比，容易出错的模块或者功能流程，用例的覆盖程度，整个测试的轮巡次数，对于上线质量的把控等等。
为了能在测试中减少或者避免失误的发生，测试计划的安排与测试用例的编写就成了重中之重。计划的制定是根据项目、研发周期等各种影响因素的变化而变化的，根据自身或者测试组的能力安排就行，尽量空出一些时间作为意外情况的缓冲带就行。
测试用例的大致方法之前已经总结过了，这里说一下我个人写测试用例的流程。
个人而言在熟悉了项目业务流后，比较喜欢使用xmind或者mindmaster之类的思维导图软件，画一个覆盖软件项目的测试图，标注出需要重点注意或者流程比较复杂的测试点。然后根据时间的空余进行一下测试颗粒的细化，细化后如果有人能和你一起评审一下导图是最好，能够查漏补缺、删繁就简。毕竟测试用例对于编写者只是起到一个提醒和避免遗漏的作用，他更多是给其他人一个保证。如果你写的的测试用例，就算给一个刚入公司的新人拿着测试都能保证上线后的软件质量，那么你的表达能力和业务分析能力就已经算得上是行业的上流水平了。后续的不管是自动化测试、性能测试之类的，对你而言就只需要一点专业知识的补足而已。
即使没有人能够一起评审，也可以翻出之前测试编写的测试用例作为对比进行更新，如果连测试用例文档都没或者用例编写时间已经相当久远，作用近乎失效的话，将测试导图中的测试点转化为测试用例也是一个最后保证。在转化的过程中，在软件中进行场景模拟是必不可少的，在场景模拟中导图上没有绘制出的测试点就会大量的展露出来，作为事前准备的最后一个补丁更新上去吧。
当你集齐了设计原型、需求文档、测试用例、测试计划四大件后，就可以准备挑战BOSS了。根据前三大件进行循环输出，最后根据测试计划这一大件进行项目管理，明确每次测试轮巡需要达到的质量标准，用来保证最后上线任务能够保质保量的按时完成。
在测试中意外情况是无法避免的，最常见的就是环境因素影响。为了防止意外情况的发生，一般的公司都会准备三个环境来帮助测试，
一个研发环境，用于开发人员进行研发、联调及冒烟测试；
一个测试环境，用于测试人员进行测试及bug回归；
一个预发布环境，这个环境通常是作为最后一次封包测试，除却数据库数据量方面的差距，其他方面应与线上环境保持同步，最大限度的保证预发布环境测试通过后，上线任务的圆满完成。
虽说有三个环境帮助保证质量，上线完成后的线上环境，最后一轮验收测试自然也不能掉下，但是这轮测试的简繁程度就看公司规章或者上头要求了。