使用风险分析，确定测试的重点
由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。
这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：
对于该项目的用途而言，哪种功能最重要?
哪种功能对用户最明显?
哪种功能对安全影响最大?
哪种功能对用户最有用?
对客户来说，该应用软件的哪个部分最重要?
在开发过程中，该应用软件的哪个部分可以最先测试?
哪一部分代码最复杂，容易导致出现错误?
哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?
哪一部分程序与过去项目中引起问题的部分相类似/有关?
哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
需求和设计的那些部分不清楚或不容易读?
开发人员认为在应用软件中哪些部分是高风险的?
哪些问题能造成最差的发行?
哪些问题最能引起用户抱怨?
哪些测试可以容易地覆盖多种功能?
哪些测试在覆盖高风险部分的测试时使用时间最少?
如果需求一直在变化怎么办?
这是一个常见的令人头疼的问题。
如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。
如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。
好的代码注释和好的文档有助于开发人员作出相应的改变。
只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。
在项目的时间表中应当留出余量，以应付可能出现的变更。
尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。
通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。
要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。
在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。
在设计自动测试剧本时，试图使其有一些灵活性。
在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。
对变更进行适当的风险分析，以减少回归测试的要求。
在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。
少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。
面向对象的设计如何影响测试?
好的面向对象的工程设计使得从代码追溯内部设计、再到功能测试，最后追溯到需求，成为一件容易的事。
因为它对黑盒测试的影响很少 (不需要了解应用软件的内部设计) ，而白盒测试只需针对该应用软件的对象。如果该应用软件设计得好，就可简化测试设计。
