测试、测开基础

本篇为笔者学习软件测试时的刷题笔记。

---

测试概念

测试：在规定的条件下对软件进行操作，发现软件存在的逻辑、功能、性能问题。
测试流程：单元测试、集成测试、系统测试、性能测试

1. V模型把测试过程作为需求分析、概要设计、详细设计及编码之后的阶段。

2. 研发需要对自己的代码审核， 检查代码的正确性，这个过程我们称为？(代码走查)【代码走查由编写代码的程序员来进行检查和组织讨论等。】

   代码走查：只检查代码中是否有错误。
   单元测试：是指对软件中的最小可测试单元进行检查和验证。

3. 测试越早介入越好。

4. 测试人员在Windows Server 2003系统下，通过逐步增加用户数对某购物网站进行测试，统计发现该平台在吞吐量超过300页每秒时，系统处于失效状态。该测试内容为：压力测试。

5. 程序调试的任务是诊断和改正程序中的错误。

6. 项目立项前测试人员不需要提交任何工件。💚对

7. 验收测试粒度最大。

8. 使用 语句覆盖 对下列代码进行测试用例设计时，需要设计2个测试用例。

   保证程序中的每一个语句至少被执行一次。
   注：语句覆盖：选择足够的测试用例，使程序中的每条语句至少执行一次。所谓足够的指的是越少越好。

   public  static void Test(int a, int b, int c)
   {
       if ((a > 1) && (c == 0))
           b = b / a;
       if ((a == 1) && (b > 1))
           b = b + 1;
   }
   

9. Junit单元测试

10. 在软件生命周期中，（编码和单元测试）阶段负责“写出正确、易懂，容易维护的程序模块”。

11. 【有争议】一个函数的入参是一个int类型，但是有效输入只有[0,100]范围的数，如果你要测试这个函数，你会选择以下哪组入参，是最全面且最精简的（ -1,0,1,67,99,100,101 ）

    错误选项：-1,0,30,100,101（我选的……）

12. 图书管理系统主要包括系统维护模块、工作人员借还管理模块和读者查询模块。在软件测试过程中，测试人员首先对三个模块进行测试，测试完成后再将系统所有模块集成起来进行集成测试。该测试策略为（ 非增量集成测试 ）。

    • 增量式集成：是逐步集成和逐步测试的方法。【测一个模块，就连接一个模块】
    • 非增量式集成是在对每个单元进行充分测试后、将所有单元全部集成起来，一次性地进行集成测试。【每个模块测试完了再连接】
    • 自顶向下集成：按深度优先越广度优先策略，对各个模块一边组装一边进行测试
    • 自底向上集成：从系统层次结构图的最底层模块开始进行组装和测试的方式
    • 三明治式集成：综合自顶向下和自底向上

13. 某公司现安排测试人员对近期开发的客户资料管理系统进行代码评审【代码评审员一般由开发人员担任】，评审人员找到如下一段提取电话号码的一个方法：
    电话号码由3部分组成：国家编码，区位号码，电话号码。中间用逗号隔开。

    public static String getPhone(String strPhoneNumber)
    {
    if (strNumber == null)||"".equals(strPhoneNumber)
    return "";
    String[] arrivePhone = strPhoneNumber.split(",");
    return arrphone[2];
    }
    

    该程序尽管编译通过，但测试人员认为上述程序会导致异常发生，指出异常会发生的语句：return arrphone[2];。

    解析：直接返回数组中某个位置的元素的前提是要有这个数组，且数组有这各位置的元素。
    假设输入一个不规范的字符串 “123,456”，切割出来的数组只有 [123, 456]。则只有第“0”“1”位置，没有第“2”个位置的元素，会报空指针异常。

14. 系统测试计划属于项目阶段性关键文档，因此需要同行评审。💚对

15. 系统测试用例设计应该从什么时候开始（需求完成） 。 系统测试用例设计应该从需求完成的时候开始。

    设计测试用例越靠近需求阶段，我们就能越早发现需求问题，在软件开发过程问题得到越早的修正，那么所花的代价就会越小。在需求阶段发现问题，我们可能只需要修改下文档。

    软件测试类型按开发阶段划分是？单元测试，集成测试，确认测试，系统测试，验收测试。
    （1）单元测试：
    单元测试又称为模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作，单元测试需要从程序内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。【单元测试能发现约80%的软件缺陷。因为缺陷放大理论，在单元测试阶段发现的bug会在系统测试阶段被放大，放大倍数完全符合80/20理论。】
    （2）集成测试
    又称为组装测试或联合测试，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
    （3）确认测试
    确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般有第三方测试机构进行。
    （4）系统测试
    软件作为计算机系统的一部分，与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，对计算机系统进行测试，目的在于与系统需求比较，发现问题。
    （5）验收测试
    以用户为主的测试，软件开发人员和质量保证人员参加，由用户设计测试用例。不是对系统进行全覆盖测试，而是对核心业务流程进行测试。

16. 系统测试由若干个不同的测试类型组成，其中（性能测试）检查系统能力的最高实际限度，即软件在一些超负荷情况下的运行情况。

    可靠性测试：是为了评估产品在规定的寿命期间内，在预期的使用、运输或储存等所有环境下，保持功能可靠性而进行的活动，侧重的应该是各种不同使用环境的可靠性。

17. 单元测试的测试用例主要根据（ 详细设计 ）的结果来设计。

18. 集成测试的测试用例 是 根据（ 概要设计 ）的结果来设计。

19. 某农产品信息管理发布系统是采用JAVA EE架构开发的B/S系统。 系统性能需求如下：
    （1）主要功能操作在5秒钟内完成；
    （2）支持50个在线用户；
    （3）农产品信息管理的主要功能至少支持20个并发用户；
    （4）在 50 个用户并发的高峰期，农产品信息管理的主要功能，处理能力至少要达到 8trans/s；
    （5）系统可以连续稳定运行12小时。
    该系统性能测试中应测试的关键指标是：（ 交易执行响应时间指标 ）

    看到性能测试选时间！

20. 对手机软件的压力测试通常可以包括【多选】

    存储压力
    响应能力压力
    网络流量压力

    针对手机应用软件的系统测试，我们通常从如下几个角度开展：功能模块测试，交叉事件测试，压力测试，容量测试，兼容性测试，易用性/用户体验测试等。
    对手机可以施加的压力测试类型主要有：存储压力、边界压力、 响应能力压力、网络流量压力。
    并发压力是针对服务器的，因为每次并发是一个客户端。【手机软件的压力测试不包括“并发测试”】

    移动App性能测试主要测试App在边界、压力等极端条件下运行是否满足客户需求，例如在电量不足、访问量增大等情况下App运行是否正常。下面介绍移动App的性能测试要点。

    1. 边界测试，在各种边界压力下，如电量不足、存储空间不足、网络不稳定时，测试App是否能正确响应、正常运行。
    2. 压力测试，对移动App不断施加压力，如不断增加负载、不断增大数据吞吐量等以确定App的服务瓶颈，获得App能提供的最大服务级别，确定App性能是否满足用户需求。
    3. 响应能力测试，响应能力测试实质上也是一种压力测试，在一定条件下App是否可以正确响应，响应时间是否超过了客户需求。
    4. 耗能测试测试，App运行时对移动设备的资源占用情况，包括内存、CPU消耗，App长期运行时耗电量、耗流量情况，验证App对资源的消耗是否满足用户需求。

21. 测试工程师在软件测试计划阶段依据（ 工作说明书 ）制定指定测试进度。

    工作说明书—SOW 制定测试的进度
    概要设计说明书-HLD 设计测试的用例
    详细设计说明书-LLD 程序员编码实现
    单元测试用例-UTC 单元测试使用

22. 白盒测试是基于代码的测试，通过程序代码或者通过开发工具找出软件的缺陷。白盒测试总体上分为两大类为（ 静态测试和动态测试 ）。

    • 白盒测试：以程序内部的逻辑结构为基础的测试用例设计技术
    • 使用白盒测试方法时，设计测试用例应根据（ 程序的内部逻辑 ）。
    • 单元测试对源程序中每一个程序单元进行测试，检查各个模块是否正确实现规定的功能，从而发现模块在编码中或算法中的错误。该阶段涉及编码和详细设计文档。

23. 软件测试计划评审会需要哪些人员参加？项目经理、客户(可选)、SQA （软件质量保证，SQA-Software Quality Assurance）负责人、配置管理员、测试经理、开发组长等。

24. 下面哪些属于动态分析（模块功能检查、系统压力测试）

    动态程序分析是对计算机软件的分析，该计算机软件是通过在真实或虚拟处理器上执行从该软件构建的程序来执行的。
    .
    代码覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析的基础上。
    数据流分析是一项编译时使用的技术，它能从程序代码中收集程序的语义信息，井通过代数的方法在编译时确定变量的定义和使用。

25. 对于平方根函数而言，无效等价类划分正确的是（ 输入的数值小于0、输入A，%等字符 ）。

    错误选项：非数值数据【如文字、图像、声音等的计算机应用领域。如模式识别、情报检索、人工智能、数学定理证明、语言翻译、计算机辅助教学等】。

26. 软件测试是为了发现错误而执行程序的过程。

27. 在执行集成测试阶段，需要输出的是（ 集成测试报告 ）

28. 用于判断“新引入的变化没有给现有软件造成破坏”的测试方法是回归测试。

    • 回归测试不属于软件测试步骤。【软件测试主要包括单元测试、集成测试、系统测试、确认测试】
    • 确认测试主要是检查已实现的软件是否满足需求规格说明书中确定了的各种需求。

29. 软件测试的目的是为了发现错误而执行程序的过程，并不涉及改正错误。

30. 测试的关键问题是(如何选择测试用例)。【一个覆盖完全的测试用例可以测试出程序是否正确运行，是否有bug等等，是最重要的】。

31. AccessViolationException异常触发后，下列程序的输出结果为（ error2、error3 ）

    	static void Main(string[] args)  
    {  
        try  
        {  
            throw new AccessViolationException();  
            Console.WriteLine("error1");  
        }  
        catch (Exception e)  
        {  
            Console.WriteLine("error2");  
        }  
        Console.WriteLine("error3");  
    }
    

    1.若catch(){}块中，如果有throw 语句，则，try{}catch(){} finally{}块之外的代码不执行；否则，执行。
    2.try{}中有异常，则异常下面代码不执行。
    3.finally{}中代码必执行。

32. 测试驱动开发式（Test-Driven Development，简称 TDD）是一种敏捷开发方法。TDD需求开发人员学习测试相关知识。测试驱动开发可以和结对编程结合使用。TDD是一种不同于传统软件开发流程 的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

    能力成熟度模型（Capability Maturity Model for Software，缩写SW-CMM，简称CMM）。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。此外还是化妆品的名字。
    CMMI（Capability Maturity Model Integration，能力成熟度模型集成）将各种能力成熟度模型（即：Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM）整合到同一架构中去，由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成，以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。这两种方法属于测试驱动开发的方式。

    TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码
    TDD的基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
    TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。
    TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

    举个比较生动的例子，这个例子你一定已经在很多关于TDD的文献资料上都看到过，但它确实是一个不错的比喻。在此我进行了一些加工和扩展。
    盖房子的时候，工人师傅砌墙，会先用桩子拉上线，以使砖能够垒的笔直，因为垒砖的时候都是以这根线为基准的。TDD就像这样，先写测试代码，就像工人师傅先用桩子拉上线，然后编码的时候以此为基准，只编写符合这个测试的功能代码。
    而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。使用传统的软件开发过程就像这样，我们先编码，编码完成之后才写测试程序，以此检验已写的代码是否正确，如果有错误再一点点修改。
    你是希望先砌墙再拉线，还是希望先拉线再砌墙呢？如果你喜欢前者，那就算了，而如果你喜欢后者，那就转入TDD阵营吧。

33. 大于、小于、等于、不等于、真、假比较和判断错误很可能是边界条件问题，比较判断与控制流常常紧密相关，设计测试用例时考虑是否出现问题不包括（ 正确使用逻辑运算符和优先级 ）。【应该是错误使用逻辑运算符和优先级】

    正确选项：不同数据类型的对象之间进行比较；比较运算或变量出错；迭代发散时不能退出。

    比较判断与控制流常常紧密相关，测试时注意下列错误：

    1. 不同数据类型的对象之间进行比较;
    2. 错误地使用逻辑运算符或优先级;
    3. 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等;
    4. 比较运算或变量出错;
    5. 循环终止条件或不可能出现;
    6. 迭代发散时不能退出;
    7. 错误地修改了循环变量。

34. 负载测试：在一定的工作负荷下，系统的负荷及响应时间。
    强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
    容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。
    容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

35. 集成测试的入口准则（单元测试已经完成，并提交《单元测试报告》、代码走查完成，已进入受控库并完成产品集成）

    顺序：单元、集成、系统、验收。
    注：软件使用指南是最后阶段。

36. 软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
    软件测试的测试目标是发现一些可以通过测试避免的开发风险。
    软件测试的原则之一是测试应该尽早进行，最好在需求阶段就开始介入。
    软件测试主要工作内容是验证（verification）和确认（validation）

    单元测试：验证针对输入和输出数据，检查其内部数据结构、逻辑和边界条件；
    集成测试：验证系统构建是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程；
    功能测试：对系统进行评估，以确定集成的系统是否确实执行需求规格说明中描述的功能。
    验收测试：开发人员确定系统是按照系统描述的理解运行的。根据客户的需求描述对系统进行检查。

    软件测试的原则
    原则一：测试显示软件存在缺陷
    原则二：穷尽测试是不可能的
    原则三：尽早介入测试
    原则四：缺陷具有集群性
    原则五：杀虫剂悖论
    原则六：测试是上下文相关的
    原则七：“没有错误就是好” 是谬误

    关于软件测试对软件质量的意义，有以下观点，其中正确的是：（）

    • 度量与评估软件的质量
    • 保证软件质量【测试是不能保证软件质量的，因为开发人员可以不改bug。能保证软件质量的是高质量的开发。】
    • 改进软件开发过程

    软件验收测试的合格通过准则是：
    软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
    所有测试项没有残余一级、二级和三级错误。
    立项审批表、需求分析文档、设计文档和编码实现一致。
    验收测试工件齐全。

    1.软件测试：（错误解释：为了找出程序中的错误）
    软件测试不仅仅是为了找出程序中的错误，更是在软件研发中为了提高软件的质量活动的总称，包括质量改进和质量评定
    2.软件测试的价值：
    （1）质量检测：尽可能的发现版本缺陷（发现程序中的错误）
    （2）质量改进：完善软件研发的过程
    （3）质量鉴定：证明软件可以发布
    （4）质量督导：提高整体团队人员的成熟度
    3.未发现错误的测试也是有价值的，测试是评定软件质量的有效方法

37. 对桩（stub）函数的描述正确的是？

    桩模块（Stub）是指在单元测试中模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。在自顶向下的集成过程中尤其有效。

38. 测试设计员的职责有哪些？设计测试用例；设计测试过程、脚本

    不包括：

    • 制定测试计划应是测试经理来做的；
    • 评估测试活动是测试经理组织召集开发和测试的相关人员来做。

39. 在游戏或软件开发完成的初期，由游戏公司或软件公司发送限定的激活码或账号给玩家，由玩家测试并向游戏公司反馈使用情况和存在的问题，以促进游戏的进一步完善的环节称为（内测）

    • 公测：公开测试，向广大玩家完全公开，注册的账号数量没有限制，到了公测阶段一般来讲初期是免费的，之后随着玩家数量的多少，游戏运营商会在一定时间之后对游戏开始收费。当然，永久免费的游戏除外。 【公测是仅有用户参与的】。公测完后就要收费正式运营了。
    • 内测：内部测试。经历了封测后，游戏进一步完善。发布出来，让大众玩家可以注册试玩，通过玩家玩后的反应和建议，进一步将游戏的BUG、设置、职业能力等等进行修订。 有的游戏的内测的账号是有限的，比较难注册。一般的游戏内测结束后就把玩家的游戏角色删掉，有的则保留或保留一部分。内测的游戏是免费的。 【内侧是开发人员与用户、测试人员一起进行的】
    • 封测：封闭测试。其版本实为未成熟的，有很多的BUG。在里面玩和正常没分别。就是禁止用户注册，只提供了一些账号分给玩家试玩，如果发现BUG了就一定要告诉官方网站，官方才能进行补丁。【封测只有技术人员针对技术方面进行测试】

40. 在程序片中，所定义的变量未被使用可以通过哪种测试方法进行定位（ 数据流测试 ）。

    数据流测试按照程序中的变量定义和使用的位置来选择程序的测试路径。

    条件测试的作用：对特定的条件进行判断，已决定如何执行操作。
    
    
    

测试用例

1. 编写测试用例前需要做哪些准备工作？（）

   • 阅读产品规格书
   • 阅读已有的bug列表
   • 阅读接口描述
   • 阅读已有的测试用例

2. 下面哪些属于静态分析（）

   • 编码规则检查
   • 程序结构分析
   • 程序复杂度分析

   静态分析不涉及被测软件的动态执行，并且可以在运行程序之前的早期阶段检测可能的缺陷。内存泄漏是在程序运行之后才能得出来。所以错误。
   静态分析可以由机器完成，以自动“遍历”源代码并检测不合规规则。经典的例子是一个编译器，它可以找到词汇，句法甚至一些语义错误。静态分析也可以由审查代码的人执行，以确保使用正确的编码标准和约定来构建程序。这通常称为代码审查，由同行开发人员（编写代码的开发人员以外的人）完成。所以A正确。
   当开发人员分析代码时，分析代码行、适当的嵌套、函数调用次数、循环复杂性……

3. 编写测试用例的目的是什么？（）

   • 从测试用例追溯回功能需求以确保没有需求被疏忽
   • 用测试用例来验证产品需求模型的正确性
   • 通过测试用例以确认是否达到了产品期望的要求

   后人哀之，而不鉴之，亦使后人而复哀后人也。 ——《阿房宫赋》
   后人只会大喊 “ 悲哀 ”！而不会借鉴。所以，我们不需要为后人提供借鉴。

4. 高质量软件应该具备的条件是（ ）

   • 满足软件需求定义的功能和性能
   • 文档符合事先确定的软件开发标准
   • 软件的特点和属性遵守软件工程的目标与原则

   对于相对复杂的产品或系统来说，没有缺陷是不可能的。
   有句话说的好，zero-bug是一种理想，good-enough是我们的原则 。

5. 软件测试的基本标准

   • 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭
   • 尽量避免测试的随意性
   • 完全测试是不可能的，测试需要终止

6. 软件验收测试的合格通过准则是：()
   正确答案: A B C D 你的答案: A B C D (正确)
   软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
   所有测试项没有残余一级、二级和三级错误。
   立项审批表、需求分析文档、设计文档和编码实现一致。
   验收测试工件齐全。

文档测试

1. 做好文档测试需要注意的点有哪些?
   • 仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例
   • 检查文档的编写是否满足文档编写的目的
   • 内容是否齐全，正确，完善
   • 标记是否正确

白盒测试

白盒测试的覆盖标准：

• 逻辑覆盖是白盒测试法常用的技术。主要的覆盖标准有6种，强度由弱到强依次是：

  • 语句覆盖【特点：可执行语句至少被执行一次】
  • 判定覆盖【特点：每个判定所有可能结果至少出现一次】
  • 条件覆盖【特点：判定中每个条件获得所有可能的结果】
    • 判定/条件覆盖（MC/DC --Modified Condition/Decision Coverage，锁定其他的条件不变，改变一项条件，必引起整个表达式变化）【特点：判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次】
    • 条件组合覆盖【每个条件的所有可能都至少出现一次，并且判定结果至少出现一次 】
      • 条件组合覆盖与条件覆盖的区别：他不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次；
  • 路径覆盖【单元测试、集成测试涉及到路径测试】【特点：覆盖程序中所有可能的路径】

  如果某测试用例集实现了某软件的路径覆盖，那么它一定同时实现了该软件的判定覆盖。

• 循环覆盖

• 基本路径测试【路径测试执行了每个路径，每个判定的结果肯定经历过一次。】

判定覆盖是每个判定的真假一次，就会导致所有的结果路径会实现；
条件覆盖是每个判定里的条件各取一次，不一定会产生所有的结果；

路径测试属于白盒测试，而在单元测试和集成测试中用到了白盒测试。

1. 现有程序段如下：

   switch ( value )
   {
   case 0:
   other = 30;
   break;
   case 1:
   other = 50;
   break;
   case 2:
   other = 300;
   case 3:
   other = other / value;
   break;
   default:
   other = other * value;
   }
   

   请问需要（ 4 ）个测试用例才可以满足语句覆盖的要求。
   case2没有break，可以执行case2、case3，所有需要的case就是0，1，2，10（其他）总共4个。

2. 以下程序至少需要（ 2 ）个测试用例，才可以满足判断覆盖

   if（x && y）{....}
   else{....}
   

   判定覆盖要求每个分支都至少被执行一次

3. 条件组合覆盖：在白盒测试法中，选择足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。

   • 好的测试要追求对代码的“覆盖率”，条件组合覆盖对代码的覆盖率最高。
   • 语句if（a>5 && b<0）满足条件组合覆盖需要设计测试用例的个数为（ 4 ）【&&有短路，可以只考虑“真真”“真假”“假假”“假真”四种情况】。
   • 设有一个判断语句

     if(!(ch >= '0' && ch <= '9'))
     printf("This is not a digit!\\n")；
     else
     printf("This is a digit!\\n")；
     

     为实现判定—条件覆盖，需要设计的测试用例个数至少应为：3。【ch<0，0<=ch<=9，ch>9】

4. 下图用基本路径法测试需要覆盖几条路径？（ ）
   

   1）（iRecordNum–>0) False —>只有1条路径
   2）（iRecordNum–>0) True —>共有3条路径
   2.1）0iType —>1条
   2.2）1iType —>1条
   2.3）其他的状况 —>1条

5. 如果我们可以通过覆盖率检测来判断我们是否对所有的路径都进行了测试，但是仍然可能存在未被检测出来的缺陷，原因是（）

   程序可能因为缺某些路径而存在问题
   穷举路径的测试可能不好暴露数据敏感的错误
   就算穷举路径测试也不能保证程序符合需求

6. 针对程序段：IF（A||B||C）THEN W=W/X，对于(A,B,C)的取值，（(T,F,F) (F,T,F) (F,F,T) (F,F,F)）测试用例能够满足MCDC（修正条件逻辑判定）的要求。

   每个条件独立影响判定结果，设计如下：
   100
   000
   010
   000
   001
   000
   去掉重复的，就是4个用例。

黑盒测试

1. 测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求和功能规格说明，检查程序的功能是否符合它的功能说明，这种测试是（ 黑盒测试 ）

2. 白盒测试关心的是内部代码，依据是设计文档。黑盒测试只关心输入输出，依据的是需求文档。

3. • 黑盒测试的方法有：

     • 边界值法、
     • 正交试验法（也称正交分析法）、
     • 等价类划分、
     • 错误推测法、
     • 综合策略法、
     • 因果图法。【等值分析测试=等价类划分+边界值分析测试】

   • 其中边界值法既属于黑盒测试也属于白盒测试方法。【黑盒是边界值分析方法，白盒是边界值测试】

4. 黑盒测试在设计测试用例时，主要需要研究(需求规格说明与概要设计说明)。

5. 单元测试在设计测试用例时，主要需要研究（详细设计说明）。

6. 系统测试使用黑盒测试

7. 为验证程序模块 A 是否正确实现了规定的功能，需要进行（单元测试） ；为验证模块 A 能否与其 他模块按照规定方式正确工作，需要进行（集成测试） 。

8. 某程序要求每次输入只能是正整数，并且每次输入的数值要求必须是100的倍数且小于等于500，则下列哪个是正确的无效等价类( （-∞，100）、（100，200）、（200，300）、（300，400）、（400，500）、（500，+∞）; )

功能测试

1. 手机发送短信长度限定在70个汉字以内（包括70），若对该功能进行等价类测试，无效等价类为（短信内容长度为0）。

2. 用边界值分析法，假定1<X<10，那么X在测试中应该取的边界值是(X=1，X=2，X=9，X=10)

3. 在一个软件测试用例中，有一个字符串数据，若首字符必须是C和D，其余字符必须是0-9的数字，在此情况下是正确的，若首字符不正确，则输出message1，若其余字符不正确，则输出message2。这种情况下最好采用（因果图）。
   
   
   

4. 某购物中心电梯限坐15人。在电梯中安装计数器来统计乘客数量。如出现超出规定人数以外的任何情况，会有不同的警示音。软件编写后进行边界值测试，应选取的边界值是：（0，1，15，16）

性能测试

1. loadrunner 包括以下哪几个部分？

   • 脚本编辑工具
   • 测试执行工具
   • 结果分析工具

2. 测试工程师小刘在对某软件项目进行疲劳强度测试过程中，最先发现以下哪些问题( 内存泄漏 )。

   性能测试中的疲劳强度测试：通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。因为疲劳强度测试强调持续执行一段时间业务，故对于软件系统来讲，最容易暴露的性能故障是内存泄漏，以及内存是否不足。
   .
   通过增加短时间的交易量，而缩短测试时间来达到既定的测试目标，尽可能在短时间内完成规定的所有交易量。

3. 若某典型基准测试程序在机器A上运行时需要20s,而在机器B运行时需要25s，那么，机器A的平均CPI是机器B的1.25倍。

   A的平均CPI：1/20=0.05，B的平均CPI：1/25=0.04，机器A的平均CPI是机器B的0.05/0.04倍。
   CPI（Clock Cycles per instruction）：每条指令的平均时钟周期个数，在相同时钟周期下，CPI越小，程序速度越快。但一个程序在一台机器上CPI小也不一定对所有程序都在这台机器上运行的快，CPI的大小和程序本身有关，不同程序在不同机器上可能有不同的运行速度。

4. 负载测试是验证要检验的系统的能力最高能达到什么程度。💚对

   • 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式，来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。所以可以检验系统的最高能力。
   • 压力测试是在高负荷（大数据量、大量并发用户等）下的负载测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。所以是检测超出负荷下的行为。压力测试是侧重于观察资源耗尽情况下的软件表现的 系统测试。
   • 强度测试：为了确定系统在最差环境下的工作能力，在非标准工作环境下，不断人为降低系统工作所需要的资源，以测试系统在资源不足的情况下的工作状态。
   • 容量测试：是性能测试的一种，测试系统的最大容量，为系统扩容，为性能优化提供参考。

5. 采用等价类划分方法，为手机号码设计测试用例，应该划分（3）个等价区间（不考虑非数字情况）
   附：手机号码测试标准：手机号码是否为11位即可。

   小于11位，等于11位，大于11位，答案是3个等价区间。

6. 自顶向下测试：是从程序的初始模块开始测试。
   （1）该方***在早期发现顶层的错误。
   （2）早期的程序框架可以进行演示
   （3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。模块集成时首先集成主控模块。能及时发现设计上的错误。
   （4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
   优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
   缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。【缺点不包括：驱动的开发工作量大、设计上的错误不能及时被发现】
   不是自顶向下增量式集成测试特点（需要开发驱动模块）

自底向上测试：是从程序的底层模块开始测试。
（1）I/O操作可以提前测试，更好提交测试用例。
（2）测试后比较容易观察输出。
（3）需要开发驱动模块。
（4）直到最后一个模块提交，程序才能完整的系统测试。
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
自底向上集成需要测试员编写驱动程序。💚对
自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象，需要开发驱动模块。

集成测试的基础策略有很多，通常分为两种：非增量式集成测试策略和增量式集成测试策略
集成测试分为渐增组装测试和非渐增组装测试。
第一种：非增量式集成测试策略
非增量式集成测试策略也叫做大爆炸集成、一次性集成；
即在最短的时间内把所有的系统组件一次性集成到被测系统中，并通过最少的用例来验证整个系统，不考虑各组件之间的相互依赖性或者可能存在的风险。
优点：
容易理解，比较简单
可以多人并行工作，对人力物力资源的利用率较高。
缺点：
问题定位和修改都比较困难
即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。
适用场景：
适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改
适用于测试系统比较小，并且各个组件都经过了充分的单元测试。
第二种：增量式集成测试策略
增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。
该策略最大的特点就是：支持故障隔离、定位问题
1，自顶向下集成:(个人理解：随着底层不断增加，测试越来越难以全面。)
自顶向下集成首先要集成主控制模块，然后从软件控制层次结构向下逐步集成，可以采用深度优先或者广度优先进行集成测试，主要验证接口的稳定性。
优势：
能够较早的验证主要的控制点和判断点，如果主控制出现问题能够及时发现。
深度优先：首先实现并验证一个完整的功能需求的正确性
缺点：
桩的开发和维护是该方法的最大问题，底层模块增加，系统越来越复杂，底层模块从测试会越来越不充分。
使用场景：
接口变化比较小的项目并且控制结构比较清晰。
2.自底向上集成
对底层模型的行为进行较早的验证，早期可能出现并行的测试。
缺点：
对顶部的验证推迟了，设计上的错误不能被及时发现，随着顶层的集成，对产品底部的异常越来越难发现。
使用场景：
顶层接口变化比较复杂的，变化比较频繁的系统
3.三明治集成
三明治集成属于混合式集成，综合了自顶向下和自底向上集成的优缺点；测试的时候，将被测软件分成三份，中间一份为目标层，目标层的上部分采用自顶向下集成策略，下部分采用自底向上集成策略。最后在目标层进行会和。
缺点：
最大的缺点就是对中间层的测试不够充分；
使用场景：
适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。
4.基于功能集成
基于功能角度出发，按照功能的关键程度对功能模块进行集成。
缺点：
对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试
5.基于风险集成
是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。
优点：
加速系统的稳定性。
关键点：
风险的识别和评估。
通常跟基于功能集成合用
6.基于分布式集成
主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。
使用场景：
主要用在分布式系统中。

10. JMeter: 基于JAVA的压力测试工具，Badboy用来进行脚本的录制
    Junit: 白盒测试工具：针对代码测试
    LoadRunner:负载压力测试
    TestLink: 用例管理工具

    LoadRunner-负载压力测试：预测系统性能。
    JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
    功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
    Junit：白盒测试工具：针对代码测试
    测试管理工具：对测试需求、计划、用例、实施进行管理
    测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
    负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
    功能测试： QTP(quicktest professional):自动测试工具
    白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
    缺陷管理工具：Mantis、BugFree、QC、TD
    用例管理工具：TestLink、QC
    测试辅助工具：SVN

11. 以下哪些工具属于单元测试工具（）

    • PureCoverage
    • Purify
    • Quantify

12. 以下属于软件调试技术的是（）

    • 强行排错法
    • 回溯法
    • 原因排除法

13. 设计系统测试计划需要参考的项目文挡有哪些？

    • 软件测试计划
    • 软件需求规范
    • 迭代计划

    注：可行性研究报告，在软件开发前做好啦，在开发前项目经理已召开进行评估，通过后才开始开发此软件，所以在测试过程中，不再需要参考此报告

单元测试

单元测试是最基础的测试。单元测试是对软件设计的最小单元进行正确性检测的测试，将可能存在的错误在最小范围内发现解决。

1. iOS单元测试框架有哪些？
   • XCTest
   • GHUnit
   • OCMock

单元测试的目的

单元测试目的：发现模块内部逻辑，语法，算法，功能等错误。

单元测试的方式

• 代码级别测试
  • 熟悉模块功能，内部逻辑与接口，编写测试用例
  • 1. 接口测试：确保接口实现正确，符合设计文档规范或约定
  • 2. 数据结构测试，确保数据结构可用，例如数据库、文件、自定义数据结构
  • 3. 边界测试：对于边界值进行检测
• 模块功能测试：通过黑盒，对模块进行功能测试
  • 单元测试其他测试项：性能，代码规范等。

代码的需求

最简单的需求：测试加法、减法、sum（内置方法）

代码实现：

# 加法：add(x, y, *arg)  # 支持两个或多个数相加
def add(x, y, *arg):
	x += y
	for val in arg:
		x += val
	return x
	
# 减法：sub(x, y, *arg)  # 支持两个或多个数相加
def sub(x, y, *arg)):
	x -= y
	for val in arg:
		x -= val
	return x


def div(x, y):
	return x/y

sum是内置方法直接测试

if __name__ == "__main__":
	print(add(1, 2))
	print(add(1, 2, 3))
	
	print(sub(1, 2))
	print(sub(1, 2, 3))

	print(div(1, 2))

如何简单地理解Python中的if name == ‘main’

unittest 单元测试

是一种单元测试框架（主要用于做单元测试，一般单元测试是开发做的）。

安装

python中自带的单元测试框架，不需要单独安装。即：只要装了python就行。

导入

import unittest

unittest完整测试用例

1. 测试环境准备
2. 测试代码执行
3. 测试环境还原
4. 测试结果分析

unittest测试用例编写基本结构

import unittest

# dir(unittest) -- 查看unittest的方法
# help(unittest.TestCase)

class TestCase(unittest.TestCase):
		def setUp(self):
			pass  # 初始化
		def tearDown(self):
			pass  # 恢复测试环境
		def runTest(self):
			pass  # 测试
	
if __name__ == "__main__":		
	demo = TestCase()
	demo.run()

使用add，sub使用类实现：

1. 定义Count类
   接口：

   • add(self, x, y)
   • sub(self, x, y)
   • sum(self, data)

   class Count(object):
   	def add(x, y):
   		return x + y
   	
   	def sub(x, y):
   		return x - y
   	
   	def div(x, y	):
   		return x/y
   
   if __name__ == "__main__":
   	c = Count()
   	print(c.add(1, 2))
   	print(c.sub(10, 5))
   

2. 使用unittest对Count接口进行测试

   测试用例设计：

   class CountAddCase(unittest.TestCase):
   	def setUp(self):
   		self.obj = Count()
   	def addTest(self):
   		self.obj.add(1, 2)
   

   测试用例运行：
   addcase = CountAddCase()
   addcase.run()
   add, sub测试用例编写

   import unittest
   
   from count import Count
   
   class TestAdd(unittest.TestCase):
   	def setUp(self):
   		self.obj = Count()
   	def tearDown(self):
   		self.obj = None
   	def runTest(self):
   		print(self.obj.add(10, 20) == 30)
   
   class TestSub(inittest.TestCase):
   	def setUp(self):
   		self.obj = Count()
   	def tearDown(self):
   		self.obj = None
   	def runTest(self):
   		print(self.obj.sub(10, 5) == 5)
   
   if __name__ == "__main__":
   	demo_add = TestAdd()
   	demo_add.run()
   	demo_sub = TestSub()
   	demo_sub.run()
   

是否可以简化代码，将两个类合并成一个类？

import unittest

from count import Count

class TestCount(unittest.TestCase):
	def setUp(self):
		self.obj = Count()
	def tearDown(self):
		self.obj = None
	def add_test(self):
		print(self.obj.add(10, 20) == 30)
	def sub_test(self):
		print(self.obj.sub(10, 5) == 5)
if __name__ == "__main__":
	demo_countadd = TestCount('add_count')
	demo_countadd.run()
	demo_countsub = TestCount('sub_count')
	demo_countsub.run()

能否将两个Case使用一个测试集unittest.TestSuite

添加测试用例方式：

• addTest(self, test): 添加一个测试用例
• addTest(self, tests): 添加多个测试用例
• __init__方法直接添加测试用例

unittest.makeSuite自动构建测试集

类实例化后，self即代表着实例（对象）本身。

断言：判断预期结果与实际结果是否相同。

pytest

安装

第三方框架，需要单独安装。pip install pytest

导入

import pytest

集成测试

1. 集成测试计划在需求分析阶段末提交。❌
2. 集成测试的过程包括有以下哪些？
   • 构建的确认过程
   • 系统集成测试测试组提交过程
   • 测试用例设计过程
   • Bug的报告过程
3. 接口测试属于集成测试阶段

系统测试

系统测试的16个策略：功能测试，性能测试，压力测试，容量测试，安全性测试，GUI测试，可用性测试，安装测试，配置测试，异常测试，备份测试，健壮性测试，文档测试，在线帮助测试，网络测试，稳定性测试
题目中：负载测试属性性能测试，易用性测试属于GUI测试，强度测试属于性能测试，安全测试属于安全性测试，所以以上所有都是系统测试的策略

单元测试主要依据是详细设计文档
集成测试主要依据是概括设计文档
系统测试主要依据是系统设计文档。

1. 风险暴露又称风险曝光度，测量的是资产的整个安全性风险。某公司软件团队计划项目中采用20个可复用的构件，每个构件平均是100LOC（ Line of Code，源代码行数），本地每个LOC的成本是150元人民币。下面是该团队定义的一个项目风险： 1．风险识别：预定要复用的软件构件中只有50%将被集成到应用中，剩余功能必须定制开发； 2．风险概率：60%； 该项目风险曝光度正确的是：（ ）

   风险曝光度（riskexposure）=错误出现率（风险出现率）X错误造成损失（风险损失）：
   风险成本 = 20 x 100 x 150 x 50% =150000元
   风险概率 = 60%
   风险曝光度 = 150000元 x 60% = 90000元

2. 单元测试主要技术手段有（）

   • 驱动代码【驱动函数：调用被测函数，给被测函数传参】
   • Stub代码【桩函数是代替某些被调用了但是没有编写代码，一般再增量迭代自底向上的过程中不用编写。再自顶向下的过程中需要编写】
   • Mock代码【对代码中某些不容易获取的对象创建虚拟对象来测试】

3. 压力测试
   功能测试
   安全测试
   性能测试

压力测试

功能测试

安全测试

性能测试

1. loadrunner 包括以下哪几个部分？

   • 脚本编辑工具
   • 测试执行工具
   • 结果分析工具

2. 测试工程师小刘在对某软件项目进行疲劳强度测试过程中，最先发现以下哪些问题( 内存泄漏 )。

   性能测试中的疲劳强度测试：通常是采用系统稳定运行情况下能够支持的最大并发用户数或者日常运行用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。因为疲劳强度测试强调持续执行一段时间业务，故对于软件系统来讲，最容易暴露的性能故障是内存泄漏，以及内存是否不足。
   .
   通过增加短时间的交易量，而缩短测试时间来达到既定的测试目标，尽可能在短时间内完成规定的所有交易量。

3. 若某典型基准测试程序在机器A上运行时需要20s,而在机器B运行时需要25s，那么，机器A的平均CPI是机器B的1.25倍。

   A的平均CPI：1/20=0.05，B的平均CPI：1/25=0.04，机器A的平均CPI是机器B的0.05/0.04倍。
   CPI（Clock Cycles per instruction）：每条指令的平均时钟周期个数，在相同时钟周期下，CPI越小，程序速度越快。但一个程序在一台机器上CPI小也不一定对所有程序都在这台机器上运行的快，CPI的大小和程序本身有关，不同程序在不同机器上可能有不同的运行速度。

4. 负载测试是验证要检验的系统的能力最高能达到什么程度。💚对

   • 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式，来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。所以可以检验系统的最高能力。
   • 压力测试是在高负荷（大数据量、大量并发用户等）下的负载测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。所以是检测超出负荷下的行为。压力测试是侧重于观察资源耗尽情况下的软件表现的 系统测试。
   • 强度测试：为了确定系统在最差环境下的工作能力，在非标准工作环境下，不断人为降低系统工作所需要的资源，以测试系统在资源不足的情况下的工作状态。
   • 容量测试：是性能测试的一种，测试系统的最大容量，为系统扩容，为性能优化提供参考。

5. 采用等价类划分方法，为手机号码设计测试用例，应该划分（3）个等价区间（不考虑非数字情况）
   附：手机号码测试标准：手机号码是否为11位即可。

   小于11位，等于11位，大于11位，答案是3个等价区间。

6. 自顶向下测试：是从程序的初始模块开始测试。
   （1）该方***在早期发现顶层的错误。
   （2）早期的程序框架可以进行演示
   （3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。模块集成时首先集成主控模块。能及时发现设计上的错误。
   （4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
   优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
   缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。【缺点不包括：驱动的开发工作量大、设计上的错误不能及时被发现】
   不是自顶向下增量式集成测试特点（需要开发驱动模块）

自底向上测试：是从程序的底层模块开始测试。
（1）I/O操作可以提前测试，更好提交测试用例。
（2）测试后比较容易观察输出。
（3）需要开发驱动模块。
（4）直到最后一个模块提交，程序才能完整的系统测试。
优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
自底向上集成需要测试员编写驱动程序。💚对
自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象，需要开发驱动模块。

集成测试的基础策略有很多，通常分为两种：非增量式集成测试策略和增量式集成测试策略
集成测试分为渐增组装测试和非渐增组装测试。
第一种：非增量式集成测试策略
非增量式集成测试策略也叫做大爆炸集成、一次性集成；
即在最短的时间内把所有的系统组件一次性集成到被测系统中，并通过最少的用例来验证整个系统，不考虑各组件之间的相互依赖性或者可能存在的风险。
优点：
容易理解，比较简单
可以多人并行工作，对人力物力资源的利用率较高。
缺点：
问题定位和修改都比较困难
即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。
适用场景：
适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改
适用于测试系统比较小，并且各个组件都经过了充分的单元测试。
第二种：增量式集成测试策略
增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。
该策略最大的特点就是：支持故障隔离、定位问题
1，自顶向下集成:(个人理解：随着底层不断增加，测试越来越难以全面。)
自顶向下集成首先要集成主控制模块，然后从软件控制层次结构向下逐步集成，可以采用深度优先或者广度优先进行集成测试，主要验证接口的稳定性。
优势：
能够较早的验证主要的控制点和判断点，如果主控制出现问题能够及时发现。
深度优先：首先实现并验证一个完整的功能需求的正确性
缺点：
桩的开发和维护是该方法的最大问题，底层模块增加，系统越来越复杂，底层模块从测试会越来越不充分。
使用场景：
接口变化比较小的项目并且控制结构比较清晰。
2.自底向上集成
对底层模型的行为进行较早的验证，早期可能出现并行的测试。
缺点：
对顶部的验证推迟了，设计上的错误不能被及时发现，随着顶层的集成，对产品底部的异常越来越难发现。
使用场景：
顶层接口变化比较复杂的，变化比较频繁的系统
3.三明治集成
三明治集成属于混合式集成，综合了自顶向下和自底向上集成的优缺点；测试的时候，将被测软件分成三份，中间一份为目标层，目标层的上部分采用自顶向下集成策略，下部分采用自底向上集成策略。最后在目标层进行会和。
缺点：
最大的缺点就是对中间层的测试不够充分；
使用场景：
适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。
4.基于功能集成
基于功能角度出发，按照功能的关键程度对功能模块进行集成。
缺点：
对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试
5.基于风险集成
是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。
优点：
加速系统的稳定性。
关键点：
风险的识别和评估。
通常跟基于功能集成合用
6.基于分布式集成
主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。
使用场景：
主要用在分布式系统中。

10. JMeter: 基于JAVA的压力测试工具，Badboy用来进行脚本的录制
    Junit: 白盒测试工具：针对代码测试
    LoadRunner:负载压力测试
    TestLink: 用例管理工具

    LoadRunner-负载压力测试：预测系统性能。
    JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制
    功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。
    Junit：白盒测试工具：针对代码测试
    测试管理工具：对测试需求、计划、用例、实施进行管理
    测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备
    负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。
    功能测试： QTP(quicktest professional):自动测试工具
    白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试）
    缺陷管理工具：Mantis、BugFree、QC、TD
    用例管理工具：TestLink、QC
    测试辅助工具：SVN

11. 以下哪些工具属于单元测试工具（）

    • PureCoverage
    • Purify
    • Quantify

12. 以下属于软件调试技术的是（）

    • 强行排错法
    • 回溯法
    • 原因排除法

13. 设计系统测试计划需要参考的项目文挡有哪些？

    • 软件测试计划
    • 软件需求规范
    • 迭代计划

    注：可行性研究报告，在软件开发前做好啦，在开发前项目经理已召开进行评估，通过后才开始开发此软件，所以在测试过程中，不再需要参考此报告

界面测试【非功能测试】

1. 影响 WEB 前端页面性能的一般包括（）

• 服务器数据返回延迟
• 网络传输速率
• 页面渲染

2. 小李测试一款新开发的手机APP应用界面，那么，属于界面元素测试内容的是：
   • 文字测试
   • 菜单测试
   • 窗口测试

自动化测试

1. 关于自动化测试的说法，错误的是（自动化测试可以大幅度降低工作量）
   • 自动化测试不一定适合所有的测试
   • 自动化测试不一定比人工测试更能保障系统的可靠性
   • 自动化测试不能完全覆盖到所有的测试类型
2. 使用软件测试工具的目的包括哪些？（　　）（非软件测试的目的）
   正确答案: A B D 你的答案: A B C D (错误)
   • 帮助测试寻找问题
   • 协助问题的诊断
   • 提高设计质量❌
   • 节省测试时间
3. 软件测试对于一个软件开发项目的成功与否具有十分重要的意义，但是在实际的项目开发与管理中仍然存在很多管理上或者技术上的误区，其中包括（ ）
   • 期望用测试自动化代替大部分人工劳动
   • 忽视软件测试人员在需求阶段的项目参与

验收测试

1. 软件验收测试包括哪些？
   • 正式验收测试
   • alpha测试
   • beta测试
2. Beta测试：是一种验收测试。产品通过Beta测试后，即可正式发行。
   • Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。β测试就是在软件公司外部展开的测试，可以由非专业的测试人员执行的测试。
     • Beta测试是用户公司组织各方面的典型终端用户在日常工作中实际使用beta版本，并要求用户报告异常情况，提出批评意见。
     • beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。
   • Alpha测试在Beta测试之前，由开发人员模拟真实环境进行的，也叫做验证测试。alpha 测试是验收测试的一种【不属于系统测试】，需要用户参加。
   • alpha测试是在用户组织模拟软件系统的运行环境下的一种验收测试，由用户或第三方测试公司进行的测试，模拟各类用户行为对即将面市的软件产品进行测试，试图发现并修改错误。

linux

1. 网络管理员编写了shell程序prog1.sh,测试时程序死循环无法结束,可以通过下列方式结束程序（ ctrl+C【强制中断程序的执行】）

   • ctrl-d 不是发送信号，而是表示一个特殊的二进制值，表示 EOF。
   • ctrl+z : 把当前进程转到后台运行，使用’ fg ‘命令恢复。
   • Ctrl+x同上但再按一次会从新回到原位置

2. 在软件测试中，圈复杂度（Cyclomatic complexity）：代码逻辑复杂度的度量，提供了被测代码的路径数量。圈复杂度可通过系统控制流图的判断节点数目算出。
   某人事管理系统能管理员工的基本信息、家庭信息、学历信息、职称信息等。其中，家庭信息管理模块导出的控制流图中包含9个判断节点，那么，该模块的圈复杂度为_____10_____。

   圈复杂度的计算还有另外一种更直观的方法，因为圈复杂度所反映的是“判定条件”的数量，所以圈复杂度实际上就是等于判定节点的数量再加上1。对应的计算公式为：V (G) = P + 1