《微软的软件测试之道》读书笔记

《微软的软件测试之道》读书笔记

第一部分  关于微软
    第1章  微软的软件工程

        偏重于产品独立发布的模式通常称为PUM（Product Unit Manager）即产品部门经理模式。

    
    第2章  微软的软件测试工程师

        测试工程师的主要职责：制定测试计划、设计测试用例、分析缺陷的根本原因、参与程序代码的审查和产品设计的审查、开发测试自动化 程序

        我们（微软）在软件测试上面临着两种挑战：一是我们要培养测试工程师成为被测试的产品领域的专家； 二是培训他们怎样去测试。
        
        SDET培训路线图
        
        测试职种的发展道路： 测试架构师(一种角色而非一个职位) 、测试独立贡献者

        成为管理人员并不意味着升职(这是一个“平级”的变化)

        
    第3章  工程生命周期
        微软的软件工程：
               瀑布模式：  图 3-1
               螺旋模式：  图 3-1
               敏捷开发
               里程碑模式  图 3-2
               图 3-5 软件生命周期的工作流程


第二部分  关于测试
    第4章  软件测试用例设计的实用方法

        实践良好的软件设计和测试设计 --> 软件设计包括制定计划和解决难题

        测试设计和好的软件设计有很多相似处，甚至可以说，和好的设计都有相似之处。测试设计需要从计划和问题解决方面来决定做哪些测试，

以及哪种测试在验证功能和确认错误路径处理得当上是最有效的。测试设计中最重要的方面之一是能预见用户的需要和期望， 然后创建能够 恰当地

处理这些需要的测试。良好的测试设计通常从对软件设计的审查或批评开始。通常，对待设计审查和对待代码审查 是很相似的，也就是 设计者对设计

进行解释，参与者提出问题并提供反馈。一个好的设计审查会对所有主要的设计决策中的各种备选 方案做深度比较。比较的目的 是要就建立什么、

怎样去建立、还有更重要的，如何去测试它们等方面，达成共识。良好的设计和良好的 执行在成功的软件开发工程中占举足 轻重的地位。

        
        使用测试（设计）模式
                测试模式共享的常用形式是模板。测试设计模板包括10个属性：名称、问题、分析、设计、预言、用例、缺陷和局限、相关的模式
                基于模板的测试设计方法：交流测试想法、加速测试设计进程、构建测试设计的知识库
         
        估计测试时间 --> 测试需要多少时间?
               估计一个功能或是应用程序的测试时间的方法：拷贝开发时间。

        如果某个开发任务计划需要一个人工作两周，那么估计写自动化测试和描述手工测试用例也需要一个人工作两周。这在实际实践中只是一个

出发点，因为有太多因素可以影响到测试的进程，所以在估计测试时间时应该把这些因素都考虑 在内。         

        如果需求（功能规格）写得不好或没有，那么最好的测试设计的出发点就是问问题。如果程序已经可以运行，那么最好的测试设计的方法就是

运行程序。
        很多在测试过程中被错过了的软件缺陷都是因为测试人员没有问足够多的问题或者他们没有问对问题。问问题是测试设计阶段获得需要的

知识以进行检查的最好的方法。

         好的测试策略：一个测试策略引导着测试设计，而且可以为测试团队的测试设计提供方向。

         思考可测试性：早点思考可测试性。 可测试性是指软件可以被完全有效测试的程度。
                       测试人员可以用来提高可测试性的最普遍方法是在需求或设计评审中简单地问，“我们怎么来测试这个东西?”
                       一种提高软件可测试性的简单模式：SOCK-->简单、可见、可控制、知识
 

        测试设计规格说明： 测试设计规格说明描述了测试过程中的方法和意图，所以它就成为整个测试过程的不可分割的一部分并贯穿整个产品的

生命周期。

         
        数据测试--用好的和坏的：测试用例一般包括验证测试（使用期望的输入来验证产品功能的测试）和错误避免测试（使用预期之外的数据来检验

产品是否适当处理的测试）

         
        在测试用例设计中要考虑的其他因素：进度，资源以及质量是可以影响软件测试的依赖属性。

 
        黑盒测试和白盒测试： 

        黑盒测试：一种设计测试用例的方法。不需要知道任何关于应用程序内部是如何实现各种功能的知识。根据一个应用程序 的用户只关心这个 应用

程序是否满足了他们的需求，而不关心这个应用程序是如何被设计和实现的原理，黑盒测试的方法是一个有效的方法去模仿 和预估用户会如何使用这个

产品。 另一方面，单纯的黑盒测试方法也经常会导致过度测试一个应用程序的某些部分而对另一些部分没有足够的测试。

        

        白盒测试：通过对应用程序内部代码或者用户看不到的模式进行分析，并以此设计测试用例。单一凭借白盒测试方法设计的测试用例一般

                          都非常详尽，但无一例外的总是会错过关键的终端用户使用场景。

        

        解决这个设计测试用例的两难处境就是使用灰盒测试。设计测试首先是从用户关心的角度出发的（黑盒测试），然后再利用白盒测试方法保证
        测试用例能够有效并全面的覆盖被测对象。

        测试工程师需要从两个方面进行测试：用户角度 和 确定应用程序的正确性角度。为了能够有效涵盖这两个角度，必须考虑使用黑盒测试和

                                                                    白盒测试两个方法。

        
        探索性测试(微软)：探索性测试是一种手工测试方法，每一步的测试和验证都是基于前一步的操作。
                                       结对测试 --> 探索性测试方法。

    第5章  功能测试相关技术

        功能测试的需求： 探索性测试--主要关注于行为测试。 然而探索性测试总的来说不能适应大型复杂的项目，或是任务非常关键的软件。

        使用黑盒方法进行软件行为测试，仅能企及所有测试能够覆盖范围的35%～65%之间。 从用户界面出发进行软件行为测试的确很重要，
        但如果它被用作唯一或主要的测试途径，我们就很有可能浪费时间在效果不佳的测试上，并且会漏过产品的某些重要的领域。

                        图 5-1 演示黑盒测试有效性的文氏图

        三角形测试： 大多数测试工程师只写了一个针对合法整型值导致非法三角形的测试、一个针对等边三角形的测试、一个针对不规则三角形的

                              测试、一个针对等腰三角形的测试。这四个测试仅仅覆盖了软件中最关键路径的50%而已。
        
        等价类划分
                等价类划分，简单地说就是一种工具，使得测试工程师能够以系统化的方式评估一个功能点中每个参数的输入和输出变量。不过，

        要等价类划分技术发挥出最大功效，就要求我们针对特定系统的上下文中的每个参数的变量数据实施全面的分析。所以在设计测试之前，

        有必要仔细为每个输入和输出参数涉及 的变量数据实施解耦和建模以将其模塑成分离的合法及非法分类子集。

        等价类测试的导出：  创建每个合法分类子集的合集，直到测试取遍合法分类的所有子集为止； 再对非法数据子集依次评估。
        等价类划分技术的整体效率主要依赖于测试人员的变量分解能力。(把变量数据建模为等价类子集需要对给定上下文环境系统的认识和理解。)
                  
        变量分解：等价类划分中最困难、且最具挑战性的方面是把数据分解为唯一合法和非法类子集。

        强化实践：在每一个等价类数据集合中使用多个元素来增加覆盖的宽度并减少错误功能的可能性。(一个等价类内抽取多个元素，以增加覆盖宽度)

                      

                      把数据分解为在合法和非法类中的离散集合的四个启发式方法： 值的范围、变量相似组、唯一值、特殊值 。
                      范围 ： 在数据的邻近集合中最小值和最大值间的任何数据点应产生相同的结果。
                          例子：假设要从1到999间输入一个整数。合法的等价类是 >=1 和 <=999       

                                                                                      非法的等价类范围是 <1 和 >999的整数

                      

                      组： 只要元素被等价地处理，那么元素组是允许的。

                          例子：车辆的类型决定了征税的类别，包括：卡车、小汽车、摩托车、房车、拖车等。属于相同的征税类别，那么这个元素组认为

                                     是 等价的。

                             
                      唯一值：在类或子集中的数据可能以不同于同一类或子集中的其他数据的方式被处理。
                          例子：数据 1月19日，2038，3:14:07在处理时间日期数据的应用中是唯一的。它应被分解为离散的子集。
                      
                      特殊值：条件必须提供或必须不被提供。
                          例子：在SMTP协议中，字符"@"是一个特殊字符，不应该作为E-mail名称或域名的一部分。
            
            等价类划分实战 ---> 帮助你更好地理解如何把参数变量划分为离散的合法和非法数据子集。  
            参数子集分析
            等价类划分测试
            等价类划分小结

            边界值分析---->最著名的功能性测试技术
            边界值分析：一个全新的公式(用于基本边界值分析的测试数量可以用4n+1来计算(或者6n+1 包括边界最小值-1 和 最大值+1) )，n等于独立

                                 参数的个数。 结合公式，可以更好地估计所需边界测试的数量，可提供更广泛的测试集合。

            边界值分析是个以介于特定边界值上下的数据作为研究目标的功能性技术。历史经验和递归问题的根本原因分析表明异常总是发生在独立输入

    输出参数的边界 条件附近。对处在边界条件的变量进行系统分析增加测试的有效性，提供更优的信息，增加检测特定类缺陷的可能性。这种缺陷

    可能在早期测试周期中，源于 输入或输出参数的线性变化。

    
    组合分析
            一个参数的输出状态取决于输入参数可变状态的各种组合。
            为了系统地测试几个相关参数可变状态间的相互作用，相对其他可选策略而言，组合分析是最优方法。

    第6章  结构测试技术

        块测试
        决策测试
        条件测试
        基础路径测试

    第7章  用代码复杂度分析风险

    第8章  基于模型的测试

第三部分  测试工具和系统
    第9章  缺陷和测试用例管理

    第10章  测试自动化

    第11章  非功能测试

    第12章  其他工具

    第13章  用户反馈系统

    第14章  测试“软件加服务”

第四部分  关于未来
    第15章  今天解决明天的问题

    第16章  建设未来

注：
        微软的软件测试之道  How we test software at Microsoft    Alan Page  Ken Johnston  BJ Rollison著 机械工业出版社 2009