想想现在，已经辗转流离了两座城市的风景了。
　　对于城市来说，风景一直都在，只是熟悉的地方我们心底比较难以当做风景。
　　很多时候，愈加熟悉的东西我们就越容易不去珍惜，也越容易不去感悟对比。人如是，生活如是，工作亦如是。
　　仅以此文，记录近期所感。
　　最近，公司的项目是越来越多了，多的让人有些惶恐，然而即使多，也要尽自己所能做完才行。
　　之前的一个项目，由于在设计上的失误，导致上线时和线上的数据库中的数据对不上，而重新加做了一个版本：数据同步。然而，因为项目比较多，测试的人力 很少，很多流程要求的又比较严；同时，策划的要求又非常低，低的只要能保证功能实现，至于健壮性、异常处理等都不做要求（因为这个项目的使用者就是策划自 己）。
　　于是，中间关于需求和流程方面出现了很多矛盾，简单整理如下：
　　1.  由于公司在测试流程方面划分比较严，所以要求策划提供的需求要能涵盖正常、非正常的功能点，并且对于程序的限制能够尽可能详尽的提供；然后策划仅仅需要一 个正常的数据导入功能，在满足这个基础的前提下，其他所有的限制不管有无都可以接受。加上策划本身对于程序不是很了解，所以很多地方都是以开发提供的为 主，而开发在提交测试程序前并没有对自己的程序进行详尽测试，一些地方也语意模糊，不能定论；
　　2.  因为这个项目只是在原有项目的基础上做了一个附加的功能，所以主要的测试就是功能测试和回归测试，可以说算是一个快速响应型的二期项目；但是由于资源等限制，需要重新制定测试计划、TestCase修改、重新走一遍测试流程。
　　3.  因为开发提供的一次可接受导入的最大限度的数据条目数量不确定，所以连带的性能测试的指标也不好评估。当然，目前的所谓性能，其实是个坑，只要服务器不挂就没有任何话语权。。。
　　分析下上面的3个问题，其实最关键的也就两个方面：测试范围和测试时间。
　　这个也是大多数项目最纠结的地方。
　　如何更有效的划分测试范围和测试时间呢？之前老大曾经告诉我一些东西，结合自己的一点感触整理如下：测试范围=修改范围+影响功能范围+其他；测试时 间=测试准备时间+测试执行时间+测试报告时间+开发fix时间+bug追踪管理时间+idle时间。所以我们可以大致的得出测试范围和测试时间。
　　但是这个测试时间在很多情况下都只是一种理想情况。如果我们都按照这个公式来安排，在项目紧的情况下，项目经理和需求策划肯定会拍桌子跟你叫板的。于 是，测试人员很多时候都会悲催一些，除非你是老大，还有可能会好一些。既然我们不可能都是老大，那么我们常用的测试时间的估算方式应该是：测试时间=测试 准备时间+测试执行时间+测试报告时间，至于其他的时间就需要我们自己做一些调整和工作上的优化来保证我们的工作能正常进行下去，通常会在实际执行时间上 乘以1.2或1.5来保证其他测试工作正常执行下去。
　　当然，我们的那个项目最后也只能以百分之百的考虑来完善其百分之十的显式需求和若干隐式需求。
　　无论如何，既然我们是一个测试人员，那么我们就得好好做好手中的事情。虽不能保证其完美无瑕，但也要保证其抗摔抗砸。
本文转自：http://www.spasvo.com/news/html/20131211104434.html