微软的软件测试之道——知识总结

Posted 2020-12-09 zhaot1993

一  关于微软

 

测试工程师的能力：有坚实的工程技术基础的人，他们有和初级软件开发工程师一样的编程能力，并具备一个优秀测试人员所需的其他属性，成为被测产品领域的专家。

 

测试管理者的能力：测试经理较少亲自作具体的测试工作事项，他仍需要懂得技术，但会被要求多注重于建立测试的流程和工具。一个测试经理会花很多时间在培养和提高其测试团队的素质和技能上。同时测试经理会和产品部门的管理层一起做质量评估来决定其产品的质量是否达到提供给客户的标准。

 

就像艾森豪威尔（Eisenhower）说的，“在战斗开始时，我总发现那些战前计划是无用的，但计划是不可少的”。 要记住的一点是花一些时间把所有事理一遍，从实现细节到产品的愿景等，这样可以帮助实现结果。

 

二  关于测试

 

1、测试用例设计

    1.1测试设计中最重要的方面之一是能预见用户的需要和期望，然后创建能够恰当地处理这些需要的测试。

    1.2基于模式的方法对于测试设计来说，是一个有用的交流测试想法的系统， 它还可以加速测试设计进程。它也是一种让新来的测试工程师学习关于测试设计、 让有经验的测试工程师分享想法、让测试设计的整个知识库从一个组织传递到另一个组织的简单方法。

    1.3设计测试用例时，需要考虑产品的范畴，用户基数的大小，测试团队的大小以及测试团队的技能。回答与这些因素相关的问题能够帮助你选择一个可以验证产品功能、找出错误并有效处理用户问题的测试集合。

    1.4灰盒测试（有时也称为玻璃盒测试），是指：设计测试首先是从用户关心的角度出发的（即黑盒测试)，然后再利用白盒测试方法保证测试用例能够有效并全面的覆盖被测对象。测试工程师需要从两个方面进行测试：用户角度和确定应用程序的正确性的角度。为了能够有效地涵盖这两个角度，就必须考虑使用黑盒测试和白盒测试两个方法。所以，微软的测试工程师必须对测试有一个完整的观点。同时在设计测试用例的时候，还需要考虑到各个方面。

 

2、功能测试：列举了3个——等价类、边界值与组合方法。

等价类：创建每个合法分类子集的合集，直到测试取遍合法分类的所有子集为止；尔后，再对非法数据子集依次评估。

 

3、结构测试：分为四个——测试一个代码块、测试if决策、测试if条件、测试一个函数的基础路径。

    3.1结构测试技术的目的是支持和加强其他测试方式和方法。通过设计和运行能遍历其他测试方法所不能遍历的代码路径的测试，结构测试还可以提供更深入的信息和降低风险。

    3.2能够帮助测试人员分析代码。

 

4、通过代码复杂度分析风险

    4.1代码复杂度是识别应用程序中可能存在缺陷的一种基本度量，对于识别代码维护性的问题也具有同等价值。如果你不需要度量代码所有部分的复杂度，那么就先从度量最关键的函数或功能开始。慢慢地逐渐扩大复杂度度量的使用范围，并且开始比较组件间或功能领域间的复杂度。

    4.2复杂度也是容易误用的度量，所以重要的是如何聪明地使用这个度量并且监视度量值的变化以保证该度量所指示的情况正是你所期望它能发现的。记住：高的复杂度只能告诉你这段代码可能会有很多缺陷，你仍然需要额外更多的调查来证实这个结果。

 

5、基于模型测试

对功能建立模型，通过模型随机生成测试用例，可以达到更全面的测试范围。

建模只是测试工具箱中众多测试工具之一而已。

 

三  测试工具和系统

 

1、管理缺陷、测试用例

    1.1缺陷：发现的缺陷要好好记录

    1.2测试用例：

        1.2.1好处：历史借鉴、测试进展跟踪、可重复性。

        1.2.2要素：目的、条件、具体的输入和步骤、预测结果。此外还有，测试频率、配置、自动化（分为手动、半自动、自动）

 

用最简单的术语来说，缺陷和测试用例是测试人员的中心世界。一个能允许您跟踪测试创作和执行测试的系统是极为有利的。

 

2、测试自动化

是否使用自动化的影响因素：投入回报率、会运行多少次、多大的价值（或者说用途的范围）、项目开始时加入、由于自动化程序本身错误造成误报。

即：投入、测试的生命期、价值、切入点、准确性。

 

3、非功能测试

     3.1性能测试：在设计过程的早期就积极地介入代码评审和分析性能目标是绝对必要的。

设计阶段就加以考虑。

        3.1.1下面是一些在设计阶段能帮助发现潜在的性能问题的技巧：

            3.1.1.1提出疑问：找出有潜在性能问题的地方。对网络交通的拥塞状况、内存管理的效率、数据库设计的合理性、或其他任何有关地方提出疑问。即使你并没有性能设计的解决方案，而只是通过让其他团队成员考虑性能问题，测试工程师也一样能够产生很大的影响力。

            3.1.1.2考虑全局：不是片面地考虑局部的优化，而是考虑全面的用户场景。你将会在整个开发过程中有相对充足的时间深入性能场景的细节，但是在设计阶段的时间最好是花费在考虑从头到尾的（end to end）场景上。

            3.1.1.3明确目标： 象“响应时间应该很快”这样的目标是不可度量的。应用SMART（Specific-具体的, Measurable-可度量的, Achievable-可实现的, Relevant-相关的, Time-bound – 有时限的）标准来设计目标。举个例子，“每个用户操作的执行时间必须不超过100毫秒，或上一版本的10%的时间之内将控制权返回应用程序”。

         3.1.2无论何种情况下，以下是一些很有益的性能测试的技巧：

             3.1.2.1建立基线 早定义、早测量的一个重要方面是建立基线。如果性能测试开始得晚，那么瓶颈发现后，要确定是开发阶段的什么时候引入了该瓶颈就会有难度

             3.1.2.2经常运行测试 一旦你建立了基线，就尽量经常地测量。当需要精确诊断哪些代码改变导致性能下降时，这些测量就是最好的帮手。

             3.1.2.3测量响应效率 用户并不关心程序在后面用了多长时间来执行。他们关心的是应用软件响应是否够快。性能测试必须着重于测量用户响应时间，而不管该操作的后台计算需要耗费多少时长。

             3.1.2.4测量的是性能 我们常常忍不住想在性能测试中加入功能或其他类别的测试。但是，既是性能测试，就要专注于测量性能。

             3.1.2.5充分利用性能测试 由上一个技巧的另一面可知，性能测试所采用的方案经常在其他测试场合是非常有用的。只要有可能，就要把自动化的性能测试方案用在其他自动测试系列中（例如压力测试系列）。

             3.1.2.6预估瓶颈 针对延迟会发生的地方做性能测试，比如文件和打印I/O，内存程序，网络操作，或其他任何不响应行为可能发生的地方。

             3.1.2.7使用工具 与上一技巧相联系的是，使用工具来模拟网络或I/O延迟，以确定该应用软件在非常规条件下的性能特征。

             3.1.2.8合理使用资源很重要 响应时间和延迟两者都是性能的关键标识，但不要在性能测试中忘记检查CPU的负荷，磁盘或网络I/O，还有内存。例如，假如你正在测试多媒体播放器，除了响应时间，你还要检查网络I/O和CPU使用率，以确保该软件的资源占用不会导致其他软件不工作。

             3.1.2.9 “干净机器”：用还是不用 让一部分性能测试运行在干净机器上(新安装的操作系统和所测软件)，而其余部分在基于顾客配置的机器上运行。干净机器对于产生一致的数据很有用，但如果性能会被其他应用软件、外接程序(Add-ins)或其他扩展严重影响的话，这些数据就会起误导作用。在干净

             3.1.2.10机器上运行性能测试可以给你产生最好的数据，但是在一台装满了软件的机器上产生的数据会更加接近你的顾客所体会到的。

             3.1.2.11避免改变 克制住给你的性能测试小修（或大修）的冲动。长远来看，测试本身改动得越少，所得数据就越精确。

     

    3.2压力测试

归属于性能测试，

广义上，压力测试经常包括了负载测试、平均无故障时间(MTBF - mean time between failure)测试、低资源测试、容量测试、或重复性测试。这些不同测试的方法和目的之间的主要区别是：

压力测试 一般来说，压力测试的目的是要通过模拟比预期要大的工作负载来让只在峰值条件下才出现的缺陷曝光。压力测试是要发现软件的弱点所在。内存泄漏、竞态条件、数据库中的线程或数据行之间的死锁条件、和其他同步问题等等，都是压力测试能发掘出来的常见缺陷。

        3.2.1负载测试 负载测试是要探讨在高峰或高于正常水平的负载下，系统或应用软件会发生什么情况。例如，一个网络服务的负载测试会试图模拟几千名用户同时连线使用该服务。性能测试一般都包括测量峰值负荷下的响应时间。

        3.2.2平均无故障时间（MTBF）测试 MTBF测试是测量系统或应用软件在出错或当机前的平均运行时间。这一测试有几个变体，包括平均无错时间(MTTF)或平均无当机时间(MTTC)。技术含义略有不同，但实践上，这些词汇都是一个意思。

        3.2.3低资源测试 低资源测试是要确定当系统在重要资源（内存、硬盘空间或其他系统定义的资源）降低或完全没有的情况下的状况。重要的是要预估将会发生什么，例如为文件存盘而无足够空间、或一个应用程序的内存分配失败时将会发生什么。

        3.2.4容量测试 与负载测试非常相似，容量测试一般是用来执行服务器或服务测试。目的是要确定一台或多台计算机能支持的最多用户数目。容量模型通常建立在容量测试数据基础上。有了这些数据，营运团队(Operations)就能定计划什么时候增加系统容量：要么增加单机资源，如RAM、CPU和磁盘空间等；要么干脆增加计算机数目。

       3.2.5重复性测试 重复性测试是为了确定重复某一程序或场景的效果而采取的一项简单而“粗暴” (brute force)的技术。这个技术的精髓是循环运行测试直到达到一个具体界限或临界值，或者是不妙的境况。举个例子，一个操作也许会泄漏20字节的内存。这并不足以在软件的其他地方产生任何问题，但如果测试连续运行2000次，泄漏就可以增长到4万字节。如果是提供核心功能的程序有泄漏，那么这个重复性测试就抓到了只有长时间连续运行该软件才能发现的内存泄漏。通常有更好的办法来发现内存泄漏，但有时候，这种简单“粗暴”的方法也可以很有效。

     

    3.3兼容性测试

应用程序兼容性测试(Application compatibility testing)一般注重于应用程序之间或所测试的

目标系统与其他应用程序之间的交互。其他应用程序可能包括内部和外部两种。

 

    3.4可达性测试

可达性是指为每个人提供接触信息和工具的相等机会，软件可达性的根本点是让用户有一种感觉, 他有能力创造和维护应用程序、网站或者文件，并且有能力与之互动。

可达性测试要设置不同角色。

 

    3.5可用性测试

可用性和可达性很相似，但我们所考虑的这两者有一个很大的区别。可达性是指任何一个人都能够使用用户界面，而可用性是指用户能不能很容易的理解和与用户界面互动。 可达性特性能够带来更高程度的可用性，但可用性包含更多。有用的文档、工具提示、容易找到的功能，还有很多其他的标准都对提高软件的可用性有帮助。

 

    3.6安全测试

这个内容得再看几本书。

 

4、其他工具

 

文本比较工具（diff tool--用于比较两个文件内容差异的工具）

 

我注意到一个优秀的测试工程师的其中一个资质就是他们能在测试中保持特别高的效率。他们并不急于采取行动。而总是能清楚地知道软件工具在哪些地方能比他们的大脑更快地解决问题。当软件可能解决当前的问题时，他们能够找到现有的工具或是在现有的工具上增加功能来满足自己的需要，如果必须的话，他们可以自己开发测试工具来解决问题。

测试工程师为了更有效地工作，需要在适当的时候使用新的工具，也应该到工具库里来重新查询。就如同源程序管理控制一样，测试工程师也应该检验他们的工具， 看已有的工具是否可以有另外的用法。一个丰富的工具库，加上正确使用工具的知识和技能，是测试工程师拥有的最大财富之一。

 

5、对交付使用的软件建立反馈机制。

通过使用本章介绍的这些反馈机制，微软的测试工程师们能够发现漏掉的测试场景，找到测试漏洞，并直接针对用户的使用模式设计出新的场景测试。开发高质量软件的一个关键因素是，如何平衡使用用户反馈方法还是使用通过功能测试和代码覆盖分析等深入的技术分析方法。

 

6、测试“软件+服务”

 

SaaS主要是指连接到互联网时使用一项服务，它并不具有脱机功能。在SaaS中大部分的处理发生在“云”中的服务器，客户端通常仅提供用户体验的呈现。

 

四  关于未来

 

1、自动失败分析系统  

就象测试自动化是解决测试无穷多的产品配置的一种方法一样，自动失败分析（AFA – Automatic Failure Analysis）是一种处理有很多测试失败的解决方案。

它可以通过日志自动匹配失败，防止测出的问题过多，导致分析不完，梳理重复，提高分析bug的效率。

2、机器虚拟技术

    2.1快照：

快照能帮助减少重新产生需要运行几小时甚至几天才会发生的缺陷的时间。例如，测试工程师能够编写脚本每小时给虚拟机照一个快照。当脚本运行时，测试会在虚拟机中运行。当失败发生后，测试工程师能够调查并找到失败发生前的快照。然后，测试工程师能够回到那个快照，并从那一点启动虚拟机，在60分钟之内遇见那个缺陷。快照使得测试工程师能反复的这样做，而不用等待几小时甚至几天来重新产生缺陷。用这种方法有些非确定性的缺陷可能不会马上重现，但对于过了特定的一段运行时间就出现的缺陷就管用。

 

微软测试中心（ https://blogs.msdn.microsoft.com/）