一、被测功能在系统中的地位
在一个软件内部，不同功能模块的质量标准一般来说也会有差异。客户最关注的功能显然应该得到测试的重视，需要投入较多的精力对其进行验证。除此之外，对那些非核心功能、但对核心功能产生影响的模块，我们也不应该忽视，至少要保证这些模块在一般情况下能够正常运转，在遇到异常情况时能够做出令人接受的合理反应，不会导致核心功能发生超出耐受度的错误。
二、客户能够容忍哪些错误存在
从另一个角度看，客户对不同模块中发生的不同错误的接受程度是不一样的。某些模块不允许出现任何功能错误，但少量的不严重的界面问题可以容忍，而另一些模块偶尔出现功能错误也可以接受，但必须保证界面显示正常。某些功能必须满足长期运行的要求；而有些软件允许在运行期间重新启动，甚至可以允许有轻微的内存泄漏。
针对客户能够接受和不能接受的错误，我们可以相应地确立测试的侧重点。比如：对功能要求高于界面要求的模块，可以加强功能测试，减少界面测试用例个数或者减少界面测试用例的执行次数。
三、被测功能的使用频率
使用频率高的功能发生意外的可能性相对要高一些，而且，这些功能中一些小问题所造成的影响可能会随着使用次数的增多而被扩大。对于这样的模块，测试的标准不能设置得太低，特别是核心功能中使用率最高的模块，一般情况下应该重点测试。
比如银行操作中：取款>存款>开户>销户
四、发生异常情况的可能性
用户输入错误数据的可能性有多大，他们不太可能输入什么样的错误数据？用户操作时可能会改变通常的执行顺序吗？为当前功能提供输入数据的其他模块的出错机率高吗？当一个功能需要多个模块共同协作才能完成时，这些共同协作的模块是否都足够稳定？当前功能并发操作的可能性是否高？系统运行的相关软硬件是否安全和健壮？有很多的因素我们需要考虑。
与不太可能出现的错误情况相关的测试用例，我们是否可以试着将其执行优先级设置低一些？例如：在多种错误输入数据中，优先尝试最有可能出现的错误数据；如果使用者一般不会对同一数据进行操作，那么对并发操作可以暂时不进行测试。
比如：用户上传视频支持flv、avi。则异常可以是其他格式、图片、文件、压缩包….所以在异常中最可能出现的错误是传其他格式文件，则将其优先级提高
四、错误所造成的影响
不同模块出现的错误造成的影响是不同的，这些影响可能是数据丢失、系统的异常退出等等。例如：某个操作数据库的模块出现异常后，有可能对数据库造成死锁，阻碍其他模块的正常运行。对这样的模块，需要进行仔细的验证。
五、被测功能是否是一个错误易发的功能
在执行测试的过程中，我们会发现某些模块在几轮测试中总是比其他模块出现的错误多。这些模块应该引起测试的注意，因为它们在以后的测试中仍然可能会出现很多错误，我们不能减少对它们的测试，如果这些模块属于核心功能或者是用户常用的功能，可能还需要增加测试用例以更多地发现隐藏缺陷。对于那些错误少且错误数量已呈收敛趋势的模块，如果其本身功能未发生改变或者其他模块的修改对其不造成影响，我们不妨适当减少对这些模块的测试次数，例如：在后面的几轮回归测试中不对其进行测试，直至最后的回归测试。
在同一模块中也存在类似问题。如果一个模块在前几轮的测试中都没有发现存在某些方面的错误，为检查这些错误而设计的测试用例在后面几轮回归测试中可以减少执行次数。
测试是否足够充分和合理与软件交付时间和软件质量直接相关，这不仅仅是测试组的责任。对于一个项目来说，测试工作的目的不是为了寻找错误而寻找错误，或者发现软件的所有错误，而是在允许的人力条件下，保障项目组在规定时间内交付一个客户能够接受的软件产品。
转自：http://www.51testing.com/?7622