读书笔记--有效软件测试的50条建议

2015-12-21 10:03:35

一、需求阶段

最有效的测试应该始于项目的开始阶段，远远早于程序代码的编写阶段。消除需求工做中的缺陷可以使昂贵的返工工做降到最低。

（1）测试人员及早进入

（2）验证需求

       正确性：根据用户的需求来进行检验

       完整性：用于保证需求中没有遗漏任何须须的元素

（3）需求就绪后立刻设计测试过程

       和软件工程师根据需求撰写设计文档同样，测试组也须要根据需求来设计测试过程。

（4）确保需求变化的传递

       当测试过程根据需求定义好了之后，在需求发生变动时把这种变化通知到测试组成员是很是重要的。

（5）注意在现存系统上进行开发和测试

       使用肯定的应用程序版本；把现存应用程序文档化；对现存应用程序的更新也要造成文档；今后实现有效的开发过程

二、编制测试计划

测试纲要成功的基石是有效的测试用例。

（6）了解手头的任务和相关的测试目标

（7）考虑风险

       在制定有效的测试策略以前，必须理解测试计划中的假定、先决条件和风险。这包括不利于按照进度实现和执行测试纲要的任何事件、行为和环境。例如：预算批的太晚、测试设备延期到货或者应用程序延期交付到测试部门。

（8）根据功能优先级安排测试工做

（9）牢记软件方面的问题

       当指定测试计划的时候，测试组应该了解影响项目开发和交付的一些软件问题，这是很是重要的。其中包括：Beta或预发行版本，新技术和不完善的技术，分阶段实现，缺陷，补丁和服务包。

（10）得到有效的测试数据

         测试数据的设计必须使得每一个系统级的需求都能获得测试和验证。测试数据的需求评审应该关注数据的几个关键方面，其中包括：深度（测试组必须考虑支持测试工做所需的数据库记录的数量和规模）、宽度（测试工程师必须研究数据数值的变化）、范围（测试数据的范围与数据的精确度、相关程度和完整程度是有关的）、测试执行期间的数据完整性、条件（建立的数据集应该可以反映应用程序所在领域的特定“条件”，这就是说，特定模式的数据并不须要等到必定的时间以后经过执行特定的操做来得到）。

（11）规划测试环境

         测试环境是由支持测试工做的全部物质元素组成，例如：测试数据、硬件、软件、网络和设备，能够结合下面的信息和资源的准备情况来设计测试环境:得到客户环境样本的描述，肯定测试环境是否须要一个归档机制来存储测试后产生的大文件，肯定客户环境中的网络特性，对于客户端-服务器或基于web的系统肯定服务器的操做系统、数据库和其余组件，肯定测试组须要的自动测试工具的许可证数量，肯定执行某些测试过程当中须要的其余软件、考虑对测试数据的需求，考虑配置测试须要的特殊资源等等。

（12）估计测试准备和执行所需的时间

三、测试组

测试组能力的高低会极大的影响测试工做的成败。

（13）定义角色和职责

（14）测试技巧、行业知识和经验三者缺一不可

（15）评估测试人员的有效性

四、系统构架

了解了整个系统的组件和模块，就能够减轻测试组的工做量，并且测试组能够把注意力集中在有缺陷的特定区域或者层次上，从而提升开发人员修正缺陷活动的有效性。

（16）了解系统构架和基本组件

         若是测试工程师对对应用程序的构架和基本组件有所了解，那么这些知识会有助于他们查明产生特定测试结果的应用程序中的各个部分。这些了解能够指导测试人员进行灰盒测试，而灰盒是黑盒测试的有力补充。它能提升缺陷报告的质量，提升进行探索式测试的能力，增长测试的精确度。

（17）确认系统的可测试性

         当应用程序的构架还只停留在文档上面而没有付诸实施时，对构架可测试性的研究，能够极大的减小随后的测试工做中可能出现的意外。

（18）使用日志增长系统的可测试性

         增长应用程序可测试性最经常使用的方法就是实施日志机制即跟踪机制，这种机制提供的信息有:组件正在作什么（包括他们正在操做的数据）、应用程序的状态或者应用程序运行中遇到的错误。在执行测试过程期间，测试工程师能够利用这些信息来跟踪处理流程，他们还能够利用这些信息对系统中发生的错误进行定位。一个形式良好的日志条目会包含如下一些信息：类名和方法名，主机名和进程id，条目的时间戳（最好精确到毫秒），消息。下面是某个应用程序的日志记录的实例，这个应用程序负责从数据库中检索一个客户对象。

在每一个函数中，都标明了函数名、产生这个条目的应用程序源代码的文件名和代码行号、主机名、进程ID、以及条目产生的时间。每条信息还包含了有关参与当前活动的全部组件的标识信息，例如，数据库服务是“dbserverl”，数据库是“customer_db”，客户ID是A1000723。

（19）验证系统支持调试和发行两种执行模式

         调试模式的做用是当遇到问题是帮助开发人员和测试人员诊断问题。而发行模式是去掉大对数或者所有与调试相关的特性，并通过优化的系统版本。经常使用的调试方法：源代码检查、输出日志、实时调试。

五、测试设计和测试文档

（20）分而治之

         应该测试什么，什么时候开发测试过程，测试过程应该如何设计，谁应该负责测试开发工做

（21）使用测试过程模板和其余测试设计标准

          为了测试过程的可重复性、完备性和一致性，在适用的时候应该运用测试过程模板，包含如下关键元素：测试过程ID，测试名称，执行日期，测试工程师的名字，测试过程的做者，测试目标，相关用例/需求编号，前置条件/假设/依赖，验证方法，用户动做，预期的结果，跟踪日志信息，实际结果，须要的测试数据。

（22）根据需求获得有效的测试用例

（23）把测试过程当作“动态”的文档

         大对数软件项目采用了迭代式和渐进式的开发方法，测试过程的开发也常用这种方法。在一个迭代式和渐进式的开发生命周期中，根据工做版本开发计划时间表，须要交付大量的软件工做版本，因此想让测试过程保持不变是很困难的。和任何动态的或者发展中的文档同样，测试过程也应该存储在一个版本控制系统中。

（24）利用系统设计和系统原型

         原型有多种用途。它们可让用户预先看到某个功能的实现结果，而且让用户预先对应用程序有所体验。经过原型用户能够提出对正在开发的软件的反馈意见，这些意见能够用于改进原型而且使最终的产品对用户来讲更满意。

（25）设计测试用例场景时采用通过检验的测试技术

（26）在测试过程当中避免包含限制和详细的数据元素

         不管是手动仍是自动测试过程，都应该把数据元素和他们的测试脚本分开保存，在脚本中使用变量而不是使用硬编码的数值。

（27）运用探索式测试

         在当今软件开发环境下，定义了全部关系和依赖的完整而详细的需求是很是罕见的。所以常常要求测试人员运用分析能力来肯定应用程序的本质。有时为了得到高效的测试设计工做所须要的知识，咱们须要进行探索式的测试工做。

六、单元测试

（28）用结构化的开发方法来支持有效的单元测试

（29）在实现以前或者与实现同时开发单元测试

         随着XP开发方式的流行，在实际软件开发以前开发单元测试程序的观念也被证实是有效的。在这种方法中，由于要用需求来指导单元测试的开发，因此它们必须在单元测试开发以前定义。在实现软件组件以前开发单元测试有许多好处:一、强迫软件的开发方式可以知足每一条需求；二、把开发人员的经历集中在解决某一专门的问题上，而不是开发一个也能知足需求的、巨大的解决方案；三、经过单元测试能够推测开发人员的实现目标（对照需求陈述的内容）。若是开发人员对需求的理解有问题，那么这种误解会在单元测试代码中反映出来。

（30）使单元测试的执行成为生成过程的一部分

          把自动执行单元测试加到生成过程当中，使得生成过程增长了另外一种质量保证机制，再也不是语法正确就可以经过编译。它保证了经过自动生成获得的产品是一个真正经过单元测试的系统。软件始终处于可测试的状态，而且因为单元测试已经发现了大多数错误，因此组件中不会再有重大的错误。

七、自动测试工具

（31）了解各种测试支持工具

（32）自主生成一个工具

         在有些状况下，除了制做工具咱们别无选择：操做系统不兼容；应用程序不兼容；专项测试的须要。

（33）了解自动测试工具对测试工做的影响

         自动测试工具只是解决方案的一部分，不能彻底替代手工测试，不能代替指导测试工做的分析能力，不能解决全部测试工做中的问题。

（34）关注组织的须要

         到底哪一种测试工具最佳，这取决于组织的须要和系统工程环境。

（35）在应用程序的原型上对工具进行测试

         验证备选的测试工具可以在正在开发的系统上使用是很是重要的。完成此项工做的最好方法是：让提供商在须要测试的应用程序上演示他们的工具。可是，这一般是不可能的，由于在测试工具评估阶段，须要测试的系统常常还不存在。一个能够替代的可行方法是：开发人员为评估一组测试工具建立一个系统原型。

八、自动测试：选择最好的实践

（36）不要过度依赖记录/回放工具

         只经过记录/回放直接建立的脚本有一些严重的局限和缺点：硬编码的数值；非模块化的、不易维护的脚本；缺少可重用性的标准。

（37）必要时自制开发一个测试工具

 

         定制的测试工具能够提供比自动测试工具脚本更强有力的测试手段。虽然生成一个定制的测试工具多是很耗时间的，可是它也具备不少优势，例如：对应用程序的敏感部分能够有更深的覆盖、具备比较两个应用程序的能力，而这些是单个现成的测试工具没法完成的。

（38）使用通过考验的测试脚本开发技术

（39）尽可能使回归测试自动化

         回归测试肯定的是：在修改先前的错误或者向应用程序添加新功能时，是否引入了新的错误，这些错误影响之前运行正常的功能。

（40）实现自动生成和烟雾测试

         自动生成一般天天执行一次或者两次（可能在晚上），它们会使用最新的和稳定的代码。开发人员能够天天从负责生成的机器上取得组件，或者在火烧眉毛的状况下在本地从新生成。

         烟雾测试是回归测试套件的精简版本。它主要是对应用程序关键的高层功能进行自动测试。当拿到一个软件的新版本时，烟雾测试不是手动的反复执行全部测试，而是有针对性的验证软件中的主要功能是否任然可以正常运转。

九、非功能性测试

是否知足非功能性需求决定了应用程序是勉强实现了它的功能，仍是不只最终用户和技术支持人员对它的接受程度很高，并且系统管理员也愿意对它进行维护。

（41）不要过后才考虑到非功能性测试

         有关非功能性的事宜，最好早在应用程序的构架和设计阶段就开始研究。若是不能及早的关注这方面的实现，那么之后为了知足非功能性需求而修改或者添加组件就很困难，甚至是不可能的。当规划一个软件项目时，须要考虑下列非功能性风险：糟糕的性能，非兼容性，缺少安全性，缺少可以使用性。对测试组来讲，若是一个应用程序的非功能性需求，能在开发过程的需求阶段和功能性需求一块儿考虑，那么这是最理想的状况。

（42）用产品级数据库进行性能测试

         若是一个应用程序的功能是管理数据，那么随着应用程序中存储的数据的增长，测试组必须了解其性能的降低程度。数据库和应用程序的优化技术可以极大的下降这种性能的退化。

（43）为预期受众定制可以使用性测试

         能够经过下面几种方法肯定目标受众的需求：行业专家，专题组，调研，对同类产品的研究，观察用户的操做。

（44）特定需求和整个系统都须要考虑安全性

（45）研究系统对并发性测试计划的实现

         在应用软件领域，并发性指的是对多个用户试图同时访问相同数据的处理。处理并发性问题有如下若干方法：保守方式（数据加锁），开放方式（在模型中，容许用户读取数据，甚至容许更新数据，但在保存时，系统会检查自从这个用户检索数据之后是否有其余人更新过数据，若是数据发生了变化，那么更新就失败了），没有并发保护（胜利属于最后一个用户）。

（46）为兼容性测试创建高效的环境

十、管理测试的执行

（47）明肯定义测试执行周期的开始和结束

         无论是哪一个测试阶段，为软件测试周期定义入口标准（测试开始时间）和出口标准（测试完成时间）都是十分重要的。

（48）隔离测试环境和开发环境

         测试环境必需要和开发环境隔离开来，这是避免测试期间的严重疏忽和没法追踪软件的变化。若是没有独立的测试环境，那么测试工做会遇到下面的一些问题：环境的变化，版本的管理，操做环境的变化。

（49）实现缺陷追踪生命周期

（50）追踪测试工做的进行 

         一个软件项目所涉及的全部人都但愿知道测试什么时候结束。为了可以回答这个问题，须要对测试的执行进行有效的跟踪。为了完成这项工做，咱们须要收集数据或者度量来显示测试进度。有关进度的度量包括：测试过程执行状况（%）=已经执行的测试过程数量/测量过程总数；缺陷持续时间=从发现缺陷到改正缺陷的时间跨度；从缺陷纠正到返测的时间=从缺陷被修正而且在新版本中发布的时间到缺陷被返测的时间跨度；缺陷趋势分析=在测试生命周期内，随着测试工做的进行，发现缺陷的数量的变化趋势；修改的质量=修改后剩余的缺陷数量（在之前已经正常工做的功能上新引入或者从新出现的缺陷）；缺陷密度=一个需求中发现的缺陷总数/为这个需求执行的测试过程数量。