2015-12-21 10:03:35
1、需求阶段
最有效的测试应该始于项目的开始阶段，远远早于程序代码的编写阶段。消除需求工作中的缺陷能够使昂贵的返工工作降到最低。
（1）测试人员及早进入
（2）验证需求
正确性：根据用户的需求来进行检验
完整性：用于保证需求中没有遗漏任何必须的元素
（3）需求就绪后马上设计测试过程
和软件工程师根据需求撰写设计文档一样，测试组也需要根据需求来设计测试过程。
（4）确保需求变化的传递
当测试过程根据需求定义好了以后，在需求发生变更时把这种变化通知到测试组成员是非常重要的。
（5）注意在现存系统上进行开发和测试
使用确定的应用程序版本；把现存应用程序文档化；对现存应用程序的更新也要形成文档；从此实现有效的开发过程
2、编制测试计划
测试纲要成功的基石是有效的测试用例。
（6）了解手头的任务和相关的测试目标
（7）考虑风险
在制定有效的测试策略之前，必须理解测试计划中的假定、先决条件和风险。这包括不利于按照进度实现和执行测试纲要的任何事件、行为和环境。例如：预算批的太晚、测试设备延期到货或者应用程序延期交付到测试部门。
（8）根据功能优先级安排测试工作
（9）牢记软件方面的问题
当指定测试计划的时候，测试组应该了解影响项目开发和交付的一些软件问题，这是非常重要的。其中包括：Beta或预发行版本，新技术和不完善的技术，分阶段实现，缺陷，补丁和服务包。
（10）获得有效的测试数据
测试数据的设计必须使得每个系统级的需求都能得到测试和验证。测试数据的需求评审应该关注数据的几个关键方面，其中包括：深度（测试组必须考虑支持测试工作所需的数据库记录的数量和规模）、宽度（测试工程师必须研究数据数值的变化）、范围（测试数据的范围与数据的精确度、相关程度和完整程度是有关的）、测试执行期间的数据完整性、条件（创建的数据集应该能够反映应用程序所在领域的特定“条件”，这就是说，特定模式的数据并不需要等到一定的时间之后通过执行特定的操作来获得）。
（11）规划测试环境
测试环境是由支持测试工作的所有物质元素组成，例如：测试数据、硬件、软件、网络和设备，可以结合下面的信息和资源的准备状况来设计测试环境:获得客户环境样本的描述，确定测试环境是否需要一个归档机制来存储测试后产生的大文件，确定客户环境中的网络特性，对于客户端-服务器或基于web的系统确定服务器的操作系统、数据库和其他组件，确定测试组需要的自动测试工具的许可证数量，确定执行某些测试过程中需要的其他软件、考虑对测试数据的需求，考虑配置测试需要的特殊资源等等。
（12）估计测试准备和执行所需的时间
3、测试组
测试组能力的高低会极大的影响测试工作的成败。
（13）定义角色和职责
（14）测试技巧、行业知识和经验三者缺一不可
（15）评估测试人员的有效性
4、系统构架
了解了整个系统的组件和模块，就可以减轻测试组的工作量，而且测试组可以把注意力集中在有缺陷的特定区域或者层次上，从而提高开发人员修正缺陷活动的有效性。
（16）了解系统构架和基本组件
如果测试工程师对对应用程序的构架和基本组件有所了解，那么这些知识会有助于他们查明产生特定测试结果的应用程序中的各个部分。这些了解可以指导测试人员进行灰盒测试，而灰盒是黑盒测试的有力补充。它能提高缺陷报告的质量，提高进行探索式测试的能力，增加测试的精确度。
（17）确认系统的可测试性
当应用程序的构架还只停留在文档上面而没有付诸实施时，对构架可测试性的研究，可以极大的减少随后的测试工作中可能出现的意外。
（18）使用日志增加系统的可测试性
增加应用程序可测试性最常用的方法就是实施日志机制即跟踪机制，这种机制提供的信息有:组件正在做什么（包括他们正在操作的数据）、应用程序的状态或者应用程序运行中遇到的错误。在执行测试过程期间，测试工程师可以利用这些信息来跟踪处理流程，他们还可以利用这些信息对系统中发生的错误进行定位。一个形式良好的日志条目会包含以下一些信息：类名和方法名，主机名和进程id，条目的时间戳（最好精确到毫秒），消息。下面是某个应用程序的日志记录的实例，这个应用程序负责从数据库中检索一个客户对象。
在每个函数中，都标明了函数名、产生这个条目的应用程序源代码的文件名和代码行号、主机名、进程ID、以及条目产生的时间。每条信息还包含了有关参与当前活动的所有组件的标识信息，例如，数据库服务是“dbserverl”，数据库是“customer_db”，客户ID是A1000723。
（19）验证系统支持调试和发行两种执行模式
调试模式的作用是当遇到问题是帮助开发人员和测试人员诊断问题。而发行模式是去掉大对数或者全部与调试相关的特性，并经过优化的系统版本。常用的调试方法：源代码检查、输出日志、实时调试。
5、测试设计和测试文档
（20）分而治之
应该测试什么，何时开发测试过程，测试过程应该如何设计，谁应该负责测试开发工作
（21）使用测试过程模板和其他测试设计标准
为了测试过程的可重复性、完备性和一致性，在适用的时候应该运用测试过程模板，包含以下关键元素：测试过程ID，测试名称，执行日期，测试工程师的名字，测试过程的作者，测试目标，相关用例/需求编号，前置条件/假设/依赖，验证方法，用户动作，预期的结果，跟踪日志信息，实际结果，需要的测试数据。
（22）根据需求得到有效的测试用例
（23）把测试过程当做“动态”的文档
大对数软件项目采用了迭代式和渐进式的开发方法，测试过程的开发也经常使用这种方法。在一个迭代式和渐进式的开发生命周期中，根据工作版本开发计划时间表，需要交付大量的软件工作版本，所以想让测试过程保持不变是很困难的。和任何动态的或者发展中的文档一样，测试过程也应该存储在一个版本控制系统中。
（24）利用系统设计和系统原型
原型有多种用途。它们可以让用户预先看到某个功能的实现结果，并且让用户预先对应用程序有所体验。通过原型用户可以提出对正在开发的软件的反馈意见，这些意见可以用于改进原型并且使最终的产品对用户来说更满意。
（25）设计测试用例场景时采用经过检验的测试技术
（26）在测试过程中避免包含限制和详细的数据元素
无论是手动还是自动测试过程，都应该把数据元素和他们的测试脚本分开保存，在脚本中使用变量而不是使用硬编码的数值。
（27）运用探索式测试
在当今软件开发环境下，定义了所有关系和依赖的完整而详细的需求是非常罕见的。因此经常要求测试人员运用分析能力来确定应用程序的本质。有时为了获得高效的测试设计工作所需要的知识，我们需要进行探索式的测试工作。
6、单元测试
（28）用结构化的开发方法来支持有效的单元测试
（29）在实现之前或者与实现同时开发单元测试
随着XP开发方式的流行，在实际软件开发之前开发单元测试程序的观念也被证明是有效的。在这种方法中，因为要用需求来指导单元测试的开发，所以它们必须在单元测试开发之前定义。在实现软件组件之前开发单元测试有许多好处:1、强迫软件的开发方式能够满足每一条需求；2、把开发人员的经历集中在解决某一专门的问题上，而不是开发一个也能满足需求的、巨大的解决方案；3、通过单元测试可以推测开发人员的实现目标（对照需求陈述的内容）。如果开发人员对需求的理解有问题，那么这种误解会在单元测试代码中反映出来。
（30）使单元测试的执行成为生成过程的一部分
把自动执行单元测试加到生成过程中，使得生成过程增加了另一种质量保证机制，不再是语法正确就能够通过编译。它保证了通过自动生成得到的产品是一个真正通过单元测试的系统。软件始终处于可测试的状态，并且由于单元测试已经发现了大多数错误，所以组件中不会再有重大的错误。
7、自动测试工具
（31）了解各类测试支持工具
（32）自主生成一个工具
在有些情况下，除了制作工具我们别无选择：操作系统不兼容；应用程序不兼容；专项测试的需要。
（33）了解自动测试工具对测试工作的影响
自动测试工具只是解决方案的一部分，不能完全替代手工测试，不能代替指导测试工作的分析能力，不能解决所有测试工作中的问题。
（34）关注组织的需要
到底哪种测试工具最佳，这取决于组织的需要和系统工程环境。
（35）在应用程序的原型上对工具进行测试
验证备选的测试工具能够在正在开发的系统上使用是非常重要的。完成此项工作的最好方法是：让提供商在需要测试的应用程序上演示他们的工具。但是，这通常是不可能的，因为在测试工具评估阶段，需要测试的系统经常还不存在。一个可以替代的可行方法是：开发人员为评估一组测试工具创建一个系统原型。
8、自动测试：选择最好的实践
（36）不要过分依赖记录/回放工具
只通过记录/回放直接创建的脚本有一些严重的局限和缺点：硬编码的数值；非模块化的、不易维护的脚本；缺乏可重用性的标准。
（37）必要时自制开发一个测试工具
定制的测试工具可以提供比自动测试工具脚本更强有力的测试手段。虽然生成一个定制的测试工具可能是很耗时间的，但是它也具有很多优点，例如：对应用程序的敏感部分可以有更深的覆盖、具有比较两个应用程序的能力，而这些是单个现成的测试工具无法完成的。
（38）使用经过考验的测试脚本开发技术
（39）尽量使回归测试自动化
回归测试确定的是：在修改先前的错误或者向应用程序添加新功能时，是否引入了新的错误，这些错误影响以前运行正常的功能。
（40）实现自动生成和烟雾测试
自动生成通常每天执行一次或者两次（可能在晚上），它们会使用最新的和稳定的代码。开发人员可以每天从负责生成的机器上取得组件，或者在迫不及待的情况下在本地重新生成。
烟雾测试是回归测试套件的精简版本。它主要是对应用程序关键的高层功能进行自动测试。当拿到一个软件的新版本时，烟雾测试不是手动的反复执行所有测试，而是有针对性的验证软件中的主要功能是否任然能够正常运转。
9、非功能性测试
是否满足非功能性需求决定了应用程序是勉强实现了它的功能，还是不仅最终用户和技术支持人员对它的接受程度很高，而且系统管理员也愿意对它进行维护。
（41）不要事后才考虑到非功能性测试
有关非功能性的事宜，最好早在应用程序的构架和设计阶段就开始研究。如果不能及早的关注这方面的实现，那么以后为了满足非功能性需求而修改或者添加组件就很困难，甚至是不可能的。当规划一个软件项目时，需要考虑下列非功能性风险：糟糕的性能，非兼容性，缺乏安全性，缺乏可使用性。对测试组来说，如果一个应用程序的非功能性需求，能在开发过程的需求阶段和功能性需求一起考虑，那么这是最理想的情况。
（42）用产品级数据库进行性能测试
如果一个应用程序的功能是管理数据，那么随着应用程序中存储的数据的增加，测试组必须了解其性能的下降程度。数据库和应用程序的优化技术能够极大的降低这种性能的退化。
（43）为预期受众定制可使用性测试
可以通过下面几种方法确定目标受众的需求：行业专家，专题组，调研，对同类产品的研究，观察用户的操作。
（44）特定需求和整个系统都需要考虑安全性
（45）研究系统对并发性测试计划的实现
在应用软件领域，并发性指的是对多个用户试图同时访问相同数据的处理。处理并发性问题有以下若干方法：保守方式（数据加锁），开放方式（在模型中，允许用户读取数据，甚至允许更新数据，但在保存时，系统会检查自从这个用户检索数据以后是否有其他人更新过数据，如果数据发生了变化，那么更新就失败了），没有并发保护（胜利属于最后一个用户）。
（46）为兼容性测试建立高效的环境
10、管理测试的执行
（47）明确定义测试执行周期的开始和结束
不管是哪个测试阶段，为软件测试周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是十分重要的。
（48）隔离测试环境和开发环境
测试环境必须要和开发环境隔离开来，这是避免测试期间的严重疏忽和无法追踪软件的变化。如果没有独立的测试环境，那么测试工作会遇到下面的一些问题：环境的变化，版本的管理，操作环境的变化。
（49）实现缺陷追踪生命周期
（50）追踪测试工作的进行
一个软件项目所涉及的所有人都希望知道测试何时结束。为了能够回答这个问题，需要对测试的执行进行有效的跟踪。为了完成这项工作，我们需要收集数据或者度量来显示测试进度。有关进度的度量包括：测试过程执行情况（%）=已经执行的测试过程数量/测量过程总数；缺陷持续时间=从发现缺陷到改正缺陷的时间跨度；从缺陷纠正到返测的时间=从缺陷被修正并且在新版本中发布的时间到缺陷被返测的时间跨度；缺陷趋势分析=在测试生命周期内，随着测试工作的进行，发现缺陷的数量的变化趋势；修改的质量=修改后剩余的缺陷数量（在以前已经正常工作的功能上新引入或者重新出现的缺陷）；缺陷密度=一个需求中发现的缺陷总数/为这个需求执行的测试过程数量。