测试工作的起点是什么？要回答这个问题，需要先梳理一下一个完整的测试任务的生命周期。
因此在编写测试计划的时候，是已经做过需求评估的。需求评估即评估此次需求的影响范围、关联系统、潜在风险等内容。等走到编写测试计划的时候，需要将前一步的一些考虑落实成具体的时间节点和任务执行步骤。
但除此之外，在编写测试计划时还是有一些需要主要的问题。我认为一个好的测试计划不应该是一个死板的流程指令，等到了deadline就拼命赶进度。这样勉强赶出来的项目往往会忽略一些隐蔽的问题。
好的测试计划应该应该既有原则性的deadline，也要有可以灵活处理的空间。总而言之，一个好的测试计划应该要抓住几个重要的时间节点，比如什么时候做分析评审、什么时候冒烟必须通过、什么时候必须出总结。然后其他的事项，比如数据准备、环境验证等环节的时间节点就可以灵活处理。
那在编写测试计划时，我最看重哪些问题呢？
（1）是否有新人参与开发。新人往往会因为业务不熟练，或者技能相对陌生，导致一些约定俗成的功能未进行开发。所以如果有新人参与开发，不仅分析设计要做得细致一些，在编写测试计划是也要预留一定的容错时间。
（2）关联系统的复杂程度。这个很好理解，业务系统本身较复杂或牵涉的上下游系统较多、流程较长的测试任务，必须先确定好上下游的排期。尽量将各自的测试任务排期安排重叠，尽量验证全流程。如果出现上下游系统延期，不能参与测试的情况，会对测试质量产生影响。
（3）测试资源是否充足。这里主要考虑的是测试人力和测试环境。测试人力很好理解，而测试环境资源却是千变万化的。很多时候开发部署的测试环境不满足测试条件，就匆匆提测了。这种情况应该是极力避免的。很多开发自测通过的项目，并不代表测试环境就一定是畅通的。这种潜在的阻碍和风险必须在编写测试计划时提前识别出来。
目前日常工作中考虑到在编写测试计划时需要注意的问题就是这些，后面在补充。
posted on
