闫涛

飞行测试

Sun, 19 Jan 2020 00:00:00 +0000

Mavic Mini 飞行体验 —— 起飞！

1、机身和遥控

虽然早就知道了Mini以小著称，但在第一次开箱时，我和我的小伙伴还是被这个小东西轻盈的手感和瘦小的体型感到十分惊讶，249g看上去像塑料材质的小弟弟真的经得住飞么？？？之前接触过精灵3、M100、S1000几款无人机，Mavic系列没有操作过，Mavic系列的产品这是我第一次接触，折叠式的设计着实牛B，机臂收起来时整个无人机比我的手机还要小，可以想象，以后出去旅游拍照即使随身携带也不会成为旅途中的负担，桨叶也从快拆改为了螺丝钉固定，大概也是为了减重吧，电池方面重量和体积都很小，从小家伙的后面进入它的身体里，对电池的保护也会更好保证无人机的续航能力。但是这个数据线接口，，，为什么还是Micro USB的，，，新版的遥控器也是我第一次使用，有一说一，之前白色遥控器的重量和体积着实不敢恭维，怕是有两个Mini的重量，但是新款的遥控器节省空间又轻便，摇杆的存放设计也很巧妙。

2、新的App

新的轻量版的APP “DJI FLY”,操作界面十分简洁，相比于DJ GO 删除了一些复杂的无人机设置的选项，和手机拍照的界面差别不大，化繁为简，对新手友好。一键短片功能对我这种拍摄新手来说非常实用，目前只有渐远、冲天、环绕、螺旋四个模式期待之后的固件升级会有添加更多的拍摄方式，Mini没有全景照片，没有智能跟随，没有延时拍摄，不过对于其价位来说已经很良心了。

3、飞行及拍摄体验

开机，还是那同样的启动提示声，经过简单的飞行教程之后开始了第一次飞行，还是简单一键起飞，还是那么稳定的悬停，移动，旋转，云台上下转动，一切都是熟悉的味道，直接上升到100m的高度，由于在学校内飞行周围楼房较多，拉远距离只有100m左右，这个范围图传和画面稳定性表现良好，1/2.3 英寸 CMOS，1200万像素与Mavic Pro 、Air相同，2.7k 30fps的画质结合一键短片功能拍个小视频发发朋友圈绝对够够的。整个飞行过程持续了25min左右，相对于更高价位的spark的16分钟有了很大的提升，之后在室内测试了下GPS和视觉定位的效果。每次拉动无人机后都很很倔强的飞回原来的位置，满分！第二次飞行天气不是很好，有些小雨和四级左右的风，这次主要想看下裸露在外的线圈和超轻的重量会不会收到雨水以及风力的影响，4级的风不算很大在三轴云台的加持下拍摄几乎不受影响，少量雨水也对机身没有造成任何的损坏，在刹车方面，分别在平稳、普通、运动三个挡位的最高速度下进行突然刹车，效果也很好，两次飞行中除了没有避障功能会让人比较紧张外，飞行体验不论是从操作还是拍摄角度来说还是很不错的。总的来说操作简单易用、便携、价格低廉，让每个人都可以飞，符合入门级无人机的标准。

1、基本款中没有充电管家、额外电池、保护罩，还是畅飞套装划算

2、尺寸比手机还要下，十分便携

3、遥控器比以前的大白款式轻便、好看

4、内置电池，在冬天的北方没有电池温度过低不能起飞的问题，也提升了续航能力

5、新的APP界面操作，操作简单

6、一键短片模式较少，没有避障，只有下视系统，新手需谨慎

7、飞行器、遥控器都是Micro接口,配备的遥控与手机的连接线种类齐全、但是连接二者的数据线不好收纳

8、抗风能力4级没问题，配合云台画面无明显抖动

9、续航能力实测25min左右

10、拍摄可调参数较少（曝光时间、光圈大小等都不可设置），只有JPG格式，没有RAW格式

11、拍照与视频画质对于记录风景、拍摄vlog足够

12、wifi图传且只有5.8G的频段，易受到干扰出现图传断开的问题（暂时没遇到）

学校比较小周围都是村子，北方的冬天不下雪着实不太好看，，，拍了几张看下效果~

集成测试

Sat, 18 Jan 2020 00:00:00 +0000

集成测试

增量与非增量测试

非增量测试或“崩溃”测试：软件测试先应先独立地测试每个模块，然后再将这些模块组装成完整的程序 增量测试或集成测试：先将下一步要测试的模块组装到测试完成的模块集合中，然后再进行测试如上图所示的程序可作为一个例子，矩形框代表程序的6个模块（子程序或过程），连接模块间的线条代表程序的控制层次，模块A调用模块B、C和D，模块B调用模块E，模块D调用模块F。非增量测试首先对6个模块中的每一个模块进行单独的模块测试，将每个模块视为一个独立实体，这些模块可以同时或按次序进行测试。最后，将这些模块组装或集成为完整的程序。

测试单独的模块需要驱动模块（driver module）和一个或多个桩模块（stub module）。举例来说，测试模块B，首先要设计测试用例，然后将测试用例作为输入参数由驱动模块传递给模块B。驱动模块是测试人员编写的一个小模块，用来将测试用例驱动或传输到被测模块中。驱动模块还必须向测试人员显示模块B的结果。此外，由于模块B调用了模块E，所以还必须使用一个额外的组件，该组件在模块B调用模块E时接受模块B的控制指令。这就由桩模块来完成，它是一个被命名为“E”的特殊模块，用来模拟模块E的功能。当所有6个模块的模块测试都完成之后，就将这些模块组装成完整的程序。

另一种可选择的方法是增量测试。不同于独立地测试每个模块，增量测试首先将下一个要测试的模块组装到前面已经测试过的模块集合中去。暂且假设从底部开始测试。第一步先测试模块E、C和F，可以并行测试（由三个人进行），也可串行进行。请注意，我们必须要为每个模块准备一个驱动模块，但不是桩模块。下一步是测试模块B和D，但不是单独地测试它们，而是分别将其与模块E和F组装在一起。换言之，要测试模块B，应编写驱动模块并集成测试用例，将模块B和E组合起来测试。将下一个要测试的模块组装到前面已经测试过的模块集合或子集中去，这个增长的过程会一致进行到测试完最后一个模块（本例中是模块A）为止。这个过程也可以自顶向下进行。

增量与非增量测试结论：

1、非增量测试所需的工作量要多一些。对于图1所示的程序，需要准备5个驱动模块和5个桩模块（假设顶部的模块不需要驱动模块）。自底向上的增量测试需要5个驱动模块，但不需要桩模块。自顶向下的增量测试需要5个桩模块，但不需要驱动模块。增量测试所需的工作量要少一些，因为使用了前面测试过的模块来取代非增量测试中所需要的驱动模块（如果从顶部开始测试）或桩模块（如果从底部开始测试）。

2.如果使用了增量测试，可以较早地发现模块中与不匹配接口、不正确假设相关的编程错误。这是由于今早地对模块组合进行了集成测试。然而，如果采用非增量测试，只有到了测试过程的最后阶段，模块之间才能“互相看到”。

3.如果使用了增量测试，调试会进行的容易一些。我们假定存在着与模块间接口或假设相关的编程错误（根据经验而来的合理假设），那么，如果使用非增量测试，直到整个程序组装之后，这些错误才会浮现出来。到了这个时候，我们就难以定位，因为它可能存在于程序内部的任何位置。相反，如果使用增量测试，这种类型的错误就很容易发现，因为该错误很可能与最近添加的模块有关。

4.增量测试会将测试进行的更彻底。如果当前正在测试模块B，要么是模块E，要么是模块A（取决于测试是从底部还是从顶部开始的）被当做结果而执行。虽然模块E或模块A先前已经进行了完全的测试，但将其作为B的模块测试结果而执行，则会诱发出一个新的情况，可能会暴露出先前测试过的模块E或模块A中存在的一个新缺陷。另一方面，如果使用的是费增量测试，对模块B的测试仅影响到其本身。换言之，增量测试使用先前测试过的模块，取代了非增量测试中使用的桩模块或驱动模块。因此，到最后一个模块测试完成时，实际的模块经受到了更多的检验。

5.非增量测试所占用的机器时间显得少一些。如果使用自底向上的方法测试图1中的模块A，在执行A的过程中，模块B、C、D、E和F也会执行到。而在对模块A的非增量测试中，仅会执行模块B、C和E的桩模块。自顶向下的增量测试的情况也是如此。如果测试的是模块F，那么在执行模块F时还会执行模块A、B、C、D和E，而在对模块F的非增量测试中，仅有模块F的驱动模块与其一起执行。因此，完成一次增量测试所需执行的机器指令，显然多于采用非增量测试方法所需的指令。但此消彼长的是，非增量测试要比增量测试需要更多的驱动模块和桩模块，开发这些驱动模块和桩模块是要占用机器时间的。

6.模块测试阶段开始时，如果使用的是非增量测试，就会有更多的机会进行并行操作（所有的模块可以同时测试）

集成测试之自顶向下、自底向上、三明治集成

以下图为例子阐述三种集成测试的方式，A至L代表程序的12个模块。假定模块J包含程序的I/O读操作，而模块I包含I/O写操作。

1、自顶向下测试

目的：从顶层控制（主控模块）开始，采用同设计顺序一样的思路对被测系统进行测试，来验证系统的稳定性。定义：自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。测试开始之后，挑选哪一个后续模块进行增量测试唯一的原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。第一步是测试模块A，测试要求必须编写出代表B、C和D的桩模块。第二部模块A测试完成之后，就用一个实际的模块代替其中的一个桩模块，而该模块需要的桩模块也被添加进来（如下图）测试完顶部模块之后，接下来可能的测试序列有很多。举例来说，如果我们要执行所有的测试序列，大量可能的模块序列中的四个序列如下：

1.A B C D E F G H I J K L

2.A B E F J C G K D H L I

3.A D H I K L C G B F J E

4.A B F J D I E C G K H L

如果可以进行并行测试，可能还有其他的选择。举例来说，模块A测试结束之后，一位程序员可能会选取模块A，测试模块A-B的组合，另一位程序员可能会测试模块A-C的组合，而第三位程序员可能会测试模块A-D的组合，总的来说，不存在最佳的模块序列，但却有下面可供考虑的两项指南：

1.如果程序中存在关键部分（例如模块G），那么在设计模块序列时就应将这些关键模块尽可能早地添加进去。所谓“关键部分”可能是某个复杂的模块、某个采用新算法的模块或某个被怀疑容易发生错误的模块。

2.在设计模块序列时，应将I/O模块尽可能早地添加进来。

如果模块J和模块I是I/O模块，而模块G执行某些关键操作，那么增长序列可能是：

A B F J D I C G E K H L 类比数据结构中树中深度广度优先遍历

2、自底向上测试

目的：从依赖性最小的底层模块开始，按照层次结构图，逐层向上集成，验证系统的稳定性。定义：自底向上集成是从系统层次结构图的最底层模块开始进行组装和集成测试的方式。对于某一个层次的特定模块，因为它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在测试过程中，如果想要从子模块得到信息可以通过直接运行子模块得到。也就是说，在集成测试的过程中只需要开发相应的驱动模块就可以了。测试开始之后，挑选哪一个后续模块进行增量测试唯一的原则是：要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。第一步是测试E、J、G、K、L和I中的部分或全部模块，既可以串行进行，也可以并行进行。要做到这一点，每一模块都需要一个特殊的驱动模块：既包含着有效的测试输入、调用被测模块且将输出显示出来（或将实际输出与预期输出作比较）的模块。有别于使用桩模块的情况，由于驱动模块可以交迭地调用被测模块，因此不需要为驱动模块提供多个版本。在大多数情况下，开发驱动模块要比开发桩模块更容易些。影响测试序列的因素是模块的关键程度，如果模块D和模块F最为关键，那么应该自底向上增量测试的某个中间状态可能如下图所示。接下来的步骤可能是测试模块E，然后再测试模块B，将模块B与先前测试过的模块E、F和J组装起来进行测试。

3、三明治集成测试

定义:三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法的优点，因此也属于基于功能分解集成。如果借助图来介绍三明治集成的话，就是在各个子树上真正进行大爆炸集成。桩和驱动器的开发工作都比较小，不过代价是作为大爆炸集成的后果，在一定程度上增加了定位缺陷的难度。

方法：一般对软件结构的上层使用自顶向下结合的方法；对下层使用自底向上结合的方法；
步骤：首先，确定以哪一层为界来决定使用三明治集成策略。我们确定以B-C-D模块为分层界；其次，对分层界及其下面的各层使用自底向上的集成策略；再次，对分层界上面的层次使用自顶向下的集成策略；然后，把分层界各模块同相应的下层集成；最后，对系统进行整体测试。

缺点： 1、在被集成之前，中间层不能尽早得到充分的测试。（针对该缺点可以对分界层使用使用独立测试策略，即对该层模块设计桩模块和驱动模块完成对目标层的测试，充分发挥测试的并行性，弥补三明治集中不能充分测试中间层的缺点） 2、中间层如果选择不适当，可能会增加驱动模块的和桩模块工作量的设计负担。

4、自顶向下和自底向上两种测试方法的优缺点

自顶向下

优点	缺点
1、如果主要的缺陷发生在顶层将非常有利	1、必须开发桩模块
2、一旦引入I/O功能，提交测试用例会更容易	2、桩模块比最初表现得更复杂
3、早期的程序框架可以进行演示，并可激发积极性	3、在引入I/O功能前，向模块引入测试用例比较困难
——	4、创建测试环境困难
——	5、观察测试输出困难
——	6、使人误解设计和测试可以交迭进行
——	7、会导致特定模块测试的完成延后

自底向上

优点	缺点
1、如果主要的缺陷发生在顶层将非常有利	1、必须开发驱动模块
2、测试环境比较容易建立	2、直到最后一个模块添加进去，程序才形成一个整体
3、观察测试输出比较容易	——

单元测试

Sat, 11 Jan 2020 00:00:00 +0000

单元测试

单元测试是对程序中的单个子程序、子程序或过程进行测试的过程，也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在程序的较小模块的测试上面。这样做的动机有三个。首先，由于模块测试的注意力一开始集中在程序的较小单元上，因此它是一种管理组合的测试元素的手段。其次，模块测试减轻了调试（准确定位并纠正某个已知错误的过程）的难度，这是因为一旦某个错误被发现出来，我们就知道它在哪个具体的模块中。第三，模块测试通过为我们提供同时测试多个模块的可能，将并行工程引入软件测试中。

测试用例设计

在为模块测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。模块测试总体上是面向白盒测试的。其中一个原因是如果对大一点的软件进行测试，例如一个完整的程序（其实是后续的测试过程中所针对的对象），白盒测试不容易展开。第二个原因是，后续的测试过程着眼于发现其他类型的错误（举例来说，这些错误不一定与程序的逻辑结构有关，比如程序未能满足其用户需求）。因此，模块测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。无论采用哪种逻辑覆盖方法，第一步都是要列举程序中所有的条件判断。

1、语句覆盖

语句覆盖，顾名思义就是针对代码语句。所有的“语句”都要覆盖一遍，它的含义是我们设计出来的测试用例要保证程序中的每一个语句至少被执行一次。通常语句覆盖被认为是“最弱的覆盖”，原因是它仅仅考虑对代码中的执行语句进行覆盖而没有考虑各种条件和分支，因此在实际运用中语句覆盖很难发现代码中的问题。举个非常简单的例子：

public int foo(int a,int b)

{

return a/b;

}

这是一个求两数之商的函数。如果我们设计如下的测试用例：

TestCase: a = 2, b = 1

这时候我们会发现，该函数的代码覆盖率达到了100%，并且设计的case可以顺利通过测试。但是显然该函数有一个很明显的bug：当 b=0 时，会抛出异常。

2、判断覆盖

判定覆盖也被成为分支覆盖(Branch Coverage)，也就是说设计的测试用例要保证让被测试程序中的每一个分支都至少执行一次。判定覆盖比语句覆盖强一些，能发现一些语句覆盖无法发现的问题。但是往往一些判定条件都是由多个逻辑条件组合而成的，进行分支判断时相当于对整个组合的最终结果进行判断，这样就会忽略每个条件的取值情况，导致遗漏部分测试路径。

3、条件覆盖

条件覆盖于分支覆盖不同，条件覆盖要求所设计的测试用例能使每个判定中的每一个条件都获得可能的取值，即每个条件至少有一次真值、有一次假值。

通常而言条件覆盖比判定覆盖强，因为条件覆盖使得判定中的每一个条件都取到了不同的结果，这一点判定覆盖则无法保证。但条件覆盖也有缺陷，因为它只能保证每个条件都取到了不同结果，但没有考虑到判定结果，因此有时候条件覆盖并不能保证判定覆盖。

4、MCDC覆盖

MC/DC首先要求实现条件覆盖、判定覆盖，在此基础上，对于每一个条件C，要求存在符合以下条件的两次计算：

条件C所在判定内的所有条件，除条件C外，其他条件的取值完全相同；
条件C的取值相反；
判定的计算结果相反;

核心意思是每个条件都要独立影响判定结果。为什么说“两次计算”，而不是“两个用例”呢？当循环中有判定时，一个用例下同一判定可能被计算多次，每次的条件值和判定值也可能不同，因此，一个用例就可能完成循环中判定MC/DC。

MC/DC是条件组合覆盖的子集。条件组合覆盖要求覆盖判定中所有条件取值的所有可能组合，需要大量的测试用例，实用性较差。MC/DC具有条件组合覆盖的优势，同时大幅减少用例数。满足MC/DC的用例数下界为条件数+1，上界为条件数的两倍，例如，判定中有三个条件，条件组合覆盖需要8个用例，而MC/DC需要的用例数为4至6个。如果判定中条件很多，用例数的差别将非常大，例如，判定中有10个条件，条件组合覆盖需要1024个用例，而MC/DC只需要11至20个用例。

5、判定条件覆盖（Decision/Condition Coverage）

判定条件覆盖，说白了就是我们设计的测试用例可以使得判断中每个条件所有的可能取值至少执行一次（条件覆盖），同时每个判断本身所有的结果也要至少执行一次（判定覆盖）。不难发现判定条件覆盖同时满足判定覆盖和条件覆盖，弥补了两者各自的不足，但是判定条件覆盖并未考虑条件的组合情况。

6、组合覆盖（Branch Condition Combination Coverage）

组合覆盖也叫做条件组合覆盖。意思是说我们设计的测试用例应该使得每个判定中的各个条件的各种可能组合都至少出现一次。显然，满足条件组合覆盖的测试用例一定是满足判定覆盖、条件覆盖和判定条件覆盖的。条件组合覆盖能够同时满足判定、条件和判定条件覆盖，覆盖度较高，但是组合覆盖的测试用例数量相对来说也是比较多的。

7、路径覆盖

路径覆盖，意思是说我们设计的测试用例可以覆盖程序中所有可能的执行路径。这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。那么这种方法是不是就一定最好呢？当然不能讲得这么绝对，它的缺点也是显而易见的：由于需要对所有可能的路径全部进行覆盖，那么我们需要设计数量非常巨大的而且较为复杂的测试用例，用例数量将呈现指数级的增长。所以理论上来讲路径覆盖是最彻底的测试用例覆盖，但实际上很多时候路径覆盖的可操作性不强。

（3）代码走查

走查和代码检查很相似，但是进行的规格和使用的错误发现技术稍有不同，走查实施的过程中，走查人员对程序进行模拟，一步步演示程序是如何处理相关数据的，在模拟程序的过程中，每个走查组的成员在自己的脑海中也进行着程序逻辑的模拟，这样一来能够高效的发现程序中的错误，并且可以精确的定位这些错误。

（4）同行评审

同行评审是一种通过作者同行来确认缺陷和需要变更区域的检查方法，它涉及的范围比较广，主要分为管理评审，技术评审，文档评审和过程评审等，简而言之，同行评审的对象并不只是程序，而是软件生命周期中可能产生的各类产品，同时，同行评审的技术和方法从非正式的到最严谨的都各不相同，在评审过程中，应该先了解评审经常出现的问题有哪些，然后采取相对应的对策进行解决。

测试阶段的划分以及组织形式（二）

Sun, 05 Jan 2020 00:00:00 +0000

3、代码审查

（1）代码的检查与走查

代码检查与代码走查是两种主要的基于人工测试的白盒测试方法。目的：找出错误，而不是改正错误，是测试而不是调试。优点：能够精确地定位的错误，降低调试成本。可以成批的发现错误，而计算机测试往往是逐个发现错误并改正。

代码检查和走查是对桌面检查过程（再提交测试前由程序员阅读自己的程序的过程）的改进，与原方法相比，代码检查和走查更为有效，因为在执行过程中，除了软件的编写者还有其他人参与进来。使用这些技术能够有效的发现30%-70%的逻辑错误和编码错误

注意：代码检查、代码走查、基于计算机的测试三者是互补的

代码检查：以组为单位阅读代码，是一系列规程和错误检查技术的集合。代码检查小组由小组主导者、代码编写者、设计人员、测试专家组成。代码编写者组逐条语句讲解程序的逻辑结构，小组参考代码检查错误列表分析程序。代码检查错误列表有：数据引用错误、数据声明错误、运算错误、比较错误、控制流错误、接口错误、输入/输出错误、其他错误。

代码走查的概念和代码检查的概念相似，但是代码走查小组中指定的测试人员会携带书面的测试用例来参加会议。这些测试用例必须是结果简单数量少，在代码走查过程中，这是测试用例并不起到关键性作用，测试用例在小组成员脑袋中推演的过程，很多问题是在向程序员提问的过程中发现的，而不是有测试用例本身发现的。

桌面检查是由单人进行的代码检查或代码走查，效率低，但是比没有检查好。

（2）代码检查错误详细列表

数据声明错误	比较错误
是否所有的变量都已声明？	是否存在不同类型变量间的比较？
默认的属性是否被正确理解？	是否存在混合模式的比较运算？
数组和字符串的初始化是否正确？	比较运算符是否正确？
变量是否赋予了正确的长度、类型和存储类？	布尔表达式是否正确？
初始化是否与存储类相一致？	比较运算是否与布尔表达式相混合？
是否有相似的变量名？	是否存在二进制小数的比较？
操作符的优先顺序是否被正确理解？	——
编译器对布尔表达式的计算方式是否被正确理解？	——

控制流错误	输入/输出错误
是否超出了多条分支路径？	文件属性是否正确？
是否每个循环都终止了？	OPEN语句是否正确？
是否每个程序都终止了？	I/O语句是否符合格式规范？
是否存在由于入口条件不满足而跳过循环体？	缓冲大小与记录大小是否匹配？
可能的循环越界是否正确？	文件在使用前是否打开？
是否存在“仅差一个”的迭代错误？	文件在使用后是否关闭？
DO/END语句是否匹配？	文件结束条件是否被正确处理？
是否存在不能穷尽的判断？	是否处理了I/O错误？
输出信息中是否有文字或语法错误？	——

（3）代码走查

（4）同行评审

测试阶段的划分以及组织形式（一）

Wed, 01 Jan 2020 00:00:00 +0000

1、静态分析

静态分析不要求实际运行被测试的对象，通常和软件代码或者系统架构有关，静态分析是静态测试的重要组成部分。静态分析通常通过工具支持来完成，例如各种IDEA中的拼写检查工具，可以发现测试对象文档中的拼写错误，静态分析指的就是这类检查，其并没有运行测试对象。静态测试与评审紧密联系，如果在评审前进行了静态分析，可以减少评审过程中需要检查的地方。由于静态分析通常由工具支持，因此工作量会比评审少很多

静态分析一般包括控制流分析、数据流分析、接口分析、表达式分析。

### （1）控制流分析控制流分析是使用控制流程图系统地检査被测程序的控制结构的工作。控制流按照结构化程序规则和程序结构的基本要求进行程序结构检査。这些要求是被测程序不应包含:

a) 转向并不存在的语句标号;

b) 没有使用的语句标号;

c) 没有使用的子程序定义;

d) 调用并不存在的子程序;

e) 从程序入口进入后无法达到的语句;

f) 不能达到停止语句的语句。

控制流程图是一种简化的程序流程图, 控制流程图由 “节点” 和 “弧” 两种图形符号构成。

（2）数据流分析

数据流分析是用控制流程图来分析数据发生的异常情况, 这些异常包括被初始化、被赋值或被引用过程中行为序列的异常。数据流分析也作为数据流测试的预处理过程。

数据流分析首先建立控制流程图, 然后在控制流程图中标注某个数据对象的操作序列, 通历控制流程图, 形成这个数据对象的数据流模型, 并给出这个数据对象的初始状态, 利用数据流异常状态图分析数据对象可能的异常。

数据流分析可以査出引用未定义变量、对以前未使用的变量再次赋值等程序错误或异常情况。

（3）接口分析

接口分析主要用在程序静态分析和设计分析，接口一致性的设计分析涉及模块之间接口的一致性以及模块与外部数据库之间的一致性，程序的接口分析涉及子程序以及函数之间的接口一致性, 包括检査形参与实参的类型、数量、维数、顺序以及使用的一致性。

（4）表达式分析

表达式错误主要有以下几种: 括号使用不正确, 数组引用错误, 作为除数的变量可能为零, 作为开平方的变量可能为负, 作为正切值的变量可能为π/2 , 浮点数变量比较时产生的错误。

此外, 静态分析还可以完成下述工作： a) 提供问接涉及程序缺陷的信息:

1) 每一类型语句出现的次数;

2) 所有变量和常量的交叉引用表;

3) 标识符的使用方式;

4) 过程的调用层次;

5) 违背编码规则;

6) 程序结构图和程序流程图;

7) 子程序规模、调用/被调用关系、扇入/扇出数。

b) 进行语法/语义分析, 提出语义或结构要点, 供进一步分析。

c) 进行符号求值。

d) 为动态测试选择测试用例进行预处理。

静态分析常需要使用软件工具进行，例如C++Test、Jtest、TestBed等单元测试工具，静态分析是在程序编译通过之后, 其它静态测试之前进行的，一般静态分析测试报告中会描述违反编码规则数、扇入扇出数大于X的个数等。

2、文档审查

一、软件文档的类型

软件测试员通常不限于进测试软件，而要负责组成整个软件产品的各个部分。保证文档的正确性也在职责范围之内。

文档测试：保证该文档包含应有的额所有材料，全部内容从技术角度讲准确无误，还要进行拼写检查和磁盘病毒扫描（为了得到好的评价）。

以下是可以归类于文档的软件组成部分：

包装文字和图形 。包括盒子、纸箱和包装纸。文档可能包含软件的屏幕抓图、功能列表、系统要求和版权信息。
市场宣传材料、广告以及其他插页。是指用于促进相关软件销售的重要工具，同时提供补充内容和服务联系方式等。
授权/注册登记表。这是客户注册时填写并寄回的卡片，也可以作为软件的一部分，显示在屏幕上让用户阅读、认可，并完成联机注册。
EULA。代表最终用户许可协议。这是要客户同意条款的法律文书，其中要求用户同意不得复制软件，如果受到软件缺陷的侵害，也不得向生产厂商起诉。
标签和不干胶条。可能出现在媒体上、包装盒或者打印材料上。它们还包括序列号不干胶条和EULA信封的标签。
安装和设置指导 。有时信息直接打印咋磁盘上，也可以印在CD袋或者查到超薄型CD盒中，对于复杂软件，还可以是完整的手册。
现在大多数软件附带简明的“入门”类小手册。而详细信息变成了联机形式。两级手册可以发布在软件媒体、网站或者两者都有。
联机帮助。联机帮助一般可以和用户手册互换使用，有时甚至取代用户手册。联机帮助有索引和搜索功能，用户查找多所需信息更加容易。
指南、向导和CBT（计算机基础训练）。这些工具讲编程代码和书写文档融合在一起。它们一般是内容和类似宏的高级编程的混合体，通常混绑在联机帮助系统中。用户可以提出问题，然后由软件一步步引导完成任务。
样例、示例和模板 。
错误提示信息 。

二、文档测试的重要性

好的软件文档以下述3种方式确保产品的整体质量： 1、提高易用性。 2、提高可靠性。可靠性是指软件稳定和坚固的程度。 3、降低支持费用。用户有麻烦或者遇到意外情况就会请示公司的帮助。这是很贵的。好的文档可以通过恰当的解释和引导用户解决困难来预防这种情况。

三、审查文档时要找什么

注意：仔细阅读、按照每个步骤操作，检查每个图像，尝试每个示例。如果有简单的代码，测试代码是否按照描述的方式运行。以下是构建文档测试用例基础的简化检查清单：

1、通用部分：听众、术语、内容和主题。

2、正确性：是否紧扣事实，逐步进行。

3、检查的内容：图表和屏幕抓图、样例和示例、拼写和语法。

测试理论（二）

Fri, 27 Dec 2019 00:00:00 +0000

（一）软件质量度量指标及方法

指标名称	定义	度量范围
工作量偏差	（（实际工作量-计划工作量）/计划工作量）*100%	进度
测试执行率	（实际执行的测试用例数/测试用例总数）*100%	测试进度
测试通过率	（（执行通过的测试用例数/测试用例总数）*100%	开发质量
测试覆盖率	（已设计测试用例的需求数/需求总数）*100%
需求（测试用例）覆盖率	（已设计测试用例的需求数/需求总数）*100%	测试设计质量
需求通过率	（已测试通过的需求数/需求总数）*100%	进度
测试用例命中率	（缺陷总数/测试用例数）*100%	测试用例质量
二次故障率	（Reopen的缺陷/缺陷总数）*100%	开发质量
NG率	（验证不通过的缺陷/缺陷总数）*100%	开发质量
缺陷有效率	（无效的缺陷/缺陷总数）*100%	测试
缺陷修复率	（已解决的缺陷/缺陷总数）*100%	开发
缺陷生存周期	缺陷从提交到关闭的平均时间	开发、测试
缺陷修复的平均时长	缺陷从提交到修复的平均时间	开发
缺陷关闭的平均时长	缺陷从修复到关闭的平均时间	测试
缺陷探测率	（测试者发现的缺陷数/（测试者发现的缺陷+客户发现的缺陷））*100%	测试质量

（二）软件质量指标

软件内部/外部质量指标外部质量因素影响用户，内部质量因素影响软件本身和它的开发者，外部质量取决于内部质量

1、外部质量

正确性(Correctness)：按照spec（规格）执行，得到正确的结果，软件的行为要严格符合规约中定义的行为保证正确性：测试和调适、防御式编程，形式化方法（形式化语言） encapsulation, decentralization 封装、分散化
健壮性(Robustness)：针对异常情况的处理：出现规约定义之外的情形，软件做出恰当的反应（出现异常时不要崩溃），未被spec覆盖的情况即为”异常情况”encapsulation, error handling封装、异常处理
可扩展性(Extendibility)：是否容易使软件适应规约的变化提升可扩展性的两个原则：简约主义设计，分离主义设计 encapsulation, information hiding封装，信息隐蔽（结构良好的对象有简单的接口，并且不向外界显漏任何内部机制。）
可复用性(Reusability) ：一次开发，多次使用，发现共性 modularity, component, models, patterns模块化、组件、模型、模式
兼容性(Compatibility )：不同软件系统之间相互可容易的集成保持设计的同构性：标准化文件格式，标准化数据结构，标准化用户接口 Efficient 性能
可移植性(Portability) ：软件可方便的在不同的技术环境之间移植：硬件、操作系统
易用性(Ease of use) ：易学、安装、操作、监控，给用户提供详细的指南，结构简单
及时性(Timeliness) ：及时发布等其他质量：可验证性(verifiability)，完整性(integrity)，可修复性(repairability)，经济性(economy)

2、内部质量

代码相关：lines of code（LOC）代码数量、cyclomatic complexity 循环复杂性结构相关：coupling耦合度（多个模块间联系），cohesion聚合度（一个模块；高内聚，一个程序只执行一种功能）（应当高内聚低耦合，单一责任原则）

Readability 可读性

Understandability 可理解性

Clearness

Size

最重要的几个质量因素： Correctness and robustness: reliability（可靠性）

Extendibility and reusability: modularity（模块化）

测试理论（一）

Mon, 23 Dec 2019 00:00:00 +0000

一、软件开发模型

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

几种常用的软件开发模型

（1）瀑布模型（V模型）

V模型又称为瀑布模型，是一种普遍的软件开发模式，旨在改进软件开发的效果和效率，反映出测试活动与分析设计活动的关系。每个测试环节都是按照步骤来进行的，一种测试完毕后，才能开始下一种测试。优点：迫使开发人员采用规范化的方法。严格地规定了每个阶段必须提交的文档。缺点：实用性不高，而且如果后期发现问题，修复成本大，前一阶段完成后，才能开始后一阶段，前一阶段的输出文本为后一阶段的输入文本，从开始就需要确定需求。

（2）W模型

相对于V模型，W模型增加了软件各个开发阶段中应同步进行的验证和确认活动，W模型由两个V字模型组成，分别代表测试与开发的过程，其强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样需要测试，测试与开发是同步进行的，W模型有利于尽早的全面的发现问题，例如，需求分析完成后，测试人员应及时参与到对需求的验证和确认活动中，尽早找出缺陷所在，减少总体测试时间，加快项目进度。

优点：开发伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理。缺点：开发和测试依然是线性的关系，需求的变更和调整，依然不方便；如果没有开发测试文档，无法执行w模型。

（3）螺旋模型

适应于内部的大规模软件开发，螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义)，软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险。模型核心：不需要在刚开始的时候就把所有事情都定义的清清楚楚。在定义最重要的功能时，去实现它，然后听取客户的意见，之后再进入到下一个阶段，如此不断轮回重复，直到得到最终产品，自我感觉是在开发过程中不断满足需求的改变。优点:

设计上的灵活性，可以在项目的各个阶段进行变更。
以小的分段来构建大型系统，使成本计算变得简单容易。
客户始终参为保证了项目不偏离正确方向以及项目的可控性。
客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。

缺点: 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足新的用户需求。

（4）喷泉模型

该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限。优点:

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程。

缺点:

由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

（5）快速原型模型

快速原型模型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。　　缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

（6）增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。优点:

短时间内向用户提供可完成部分工作的产品
逐步增加产品功能可以使用户有时间了解和适应新产品
开放结构的软件拥有的维护性明显好于封闭结构的软件

缺陷：

容易退化为边做边改模型，从而使软件过程的控制失去整体性
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析

python异常处理,文件I/O

Wed, 04 Dec 2019 00:00:00 +0000

一、异常处理

1、Python常见标准异常

异常即是一个事件，该事件会在程序执行过程中发生，影响了程序的正常执行。一般情况下，Python无法正常处理程序时就会发生一个异常。异常是Python对象，表示一个错误。当Python脚本发生异常时我们需要捕获处理它，否则程序会终止执行。

异常名称	说明
BaseException	所有异常的基类
Exception	常规错误的基类
OverflowError	数值运算超出最大限制
IOError	输入/输出操作失败
Warning	警告的基类
KeyboardInterrupt	用户中断执行
StandardError	所有的内建标准异常的基类
ArithmeticError	所有数值计算错误的基类
FloatingPointError	浮点计算错误
AttributeError	对象没有这个属性
IndexError	序列中没有此索引(index)
KeyError	映射中没有这个键
MemoryError	内存溢出错误
NameError	未声明/初始化对象
RuntimeError	一般的运行时错误
SyntaxError	Python 语法错误
TypeError	对类型无效的操作
RuntimeWarning	运行时行为的警告
TabError	Tab 和空格混用
IndentationError	缩进错误
UnboundLocalError	访问未初始化的本地变量
ImportError	导入模块/对象失败

2、异常处理语句

（1）使用except带异常类型

try:
<语句>        #需要被检测的代码
except <名字>：
<语句>        #except语句捕获同名异常信息并处理
except <名字>，<数据>:
<语句>        #except语句捕获同名异常信息并处理，获得附加的数据（异常参数）
else:
<语句>        #如果没有异常发生

如果当try后的语句执行时发生异常，python就跳回到try并执行第一个匹配该异常的except子句，异常处理完毕，控制流就通过整个try语句（除非在处理异常时又引发新的异常）。
如果在try后的语句里发生了异常，却没有匹配的except子句，异常将被递交到上层的try，或者到程序的最上层（这样将结束程序，并打印默认的出错信息）。
如果在try子句执行时没有发生异常，python将执行else语句后的语句（如果有else的话），然后控制流通过整个try语句。
（2）使用except不带异常类型

try:
    正常的操作
   ......................
except:
    发生异常，执行这块代码
   ......................
else:
    如果没有异常执行这块代码

try-except语句捕获所有发生的异常。不能通过该程序识别出具体的异常信息。因为它会捕获所有的异常。

（3）使用except而带多种异常类型

使用相同的except语句来处理多个异常信息

try:
    正常的操作
   ......................
except(Exception1[, Exception2[,...ExceptionN]]]):
   发生以上多个异常中的一个，执行这块代码
   ......................
else:
    如果没有异常执行这块代码

（4）try-finally 语句

try-finally 语句无论是否发生异常都将执行finally中的代码。

try:
<语句>
finally:
<语句>    #退出try时总会执行
raise

二、文件I/O

1、读取键盘输入

str = input("请输入：")
print ("你输入的内容是: ", str)

2、打开和关闭文件

#打开一个文件
fo = open("foo.txt", "w")


```python
在这里插入代码片

#关闭打开的文件 fo.close()

3、write()和read()方法

write()方法可将任何字符串写入一个打开的文件，创建foo.txt文件，并将收到的内容写入该文件，并最终关闭文件。

#打开一个文件
fo = open("foo.txt", "w")
fo.write( "DJI\n")
 #关闭打开的文件
fo.close()

read（）方法从一个打开的文件中读取一个字符串。需要重点注意的是，Python字符串可以是二进制数据，而不是仅仅是文字。

#打开一个文件
fo = open("foo.txt", "r+")
str = fo.read(10)
print "读取的字符串是 : ", str
#关闭打开的文件
fo.close()

4、重命名与删除文件

Python的os模块提供了执行文件处理操作的方法，比如重命名和删除文件。要使用这个模块，必须先导入它，然后才可以调用相关的各种功能。 rename()方法： rename()方法需要两个参数，当前的文件名和新文件名。

import os
#重命名文件test1.txt到test2.txt。
os.rename( "test1.txt", "test2.txt" )

remove()方法你可以用remove()方法删除文件，需要提供要删除的文件名作为参数。

import os
#删除一个已经存在的文件test2.txt
os.remove("test2.txt")

python面向对象

Sun, 01 Dec 2019 00:00:00 +0000

面向对象

java接触过面向对象，主要学习下语法和与java的差异

1、创建类

使用 class 语句来创建一个新类，class 之后为类的名称并以冒号结尾

class Student:
    "学生基类"
    studentCount = 0;

   def __init__(self,name,score):
        self.name = name
        self.salary = salary
        Student.studentCount += 1

    def displayCount(self):
        print("Total Student %d" %Student.studentCount)

    def displayStudent(self):
        print("Name:",self.name,",Score:",self.score)

studentCount 变量是一个类变量，它的值将在这个类的所有实例之间共享。可以在内部类或外部类使用 Student.studentCount 访问。
第一种方法__init__()方法是类的构造函数或初始化方法，当创建了这个类的实例时就会调用该方法
self 代表类的实例，self 在定义类的方法时是必须有的

2、创建实例对象

Python 中没有new这个关键字，类的实例化类似函数调用方式。以下使用类的名称 Student 来实例化，并通过 init 方法接收参数

"创建 Student 类的第一个对象"
stu1 = Student("yantao",100)
"创建 Student 类的第二个对象"
stu2 = Student("dji",100)

3、访问、添加、修改、删除属性

stu1.displayStudent()
stu2.displayStudent()

stu1.age = 2;添加对象属性
stu1.age = 26;添加对象属性
del stu1.age ;添加对象属性

输出结果：

4、python对象销毁(垃圾回收)

引用计数法+循环垃圾收集器在 Python 内部记录着所有使用中的对象各有多少引用。一个内部跟踪变量，称为一个引用计数器。当对象被创建时，就创建了一个引用计数，当这个对象不再需要时，也就是说，这个对象的引用计数变为0 时，它被垃圾回收。但是回收不是”立即”的，由解释器在适当的时机，将垃圾对象占用的内存空间回收。

5、类的继承

通过继承创建的新类称为子类或派生类，被继承的类称为基类、父类或超类在python中继承中的一些特点：

如果在子类中需要父类的构造方法就需要显示的调用父类的构造方法，或者不重写父类的构造方法。
在调用基类的方法时，需要加上基类的类名前缀，且需要带上 self 参数变量。区别在于类中调用普通函数时并不需要带上 self 参数
Python是首先查找对应类型的方法，如果它不能在派生类中找到对应的方法，它才开始到基类中逐个查找。（先在本类中查找调用的方法，找不到才去基类中找）
python支持多继承

语法：派生类的声明，与他们的父类类似，继承的基类列表跟在类名之后，多继承格式如下： class SubClassName (ParentClass1,ParentClass2, …):

class Parent:  # 定义父类
    parentAttr = 100

    def __init__(self):
        print("调用父类构造函数")

    def parentMethod(self):
        print('调用父类方法')

    def setAttr(self, attr):
        Parent.parentAttr = attr

    def getAttr(self):
        print("父类属性 :", Parent.parentAttr)


class Child(Parent):  # 定义子类
    def __init__(self):
        print("调用子类构造方法")

    def childMethod(self):
        print('调用子类方法')


c = Child()  # 实例化子类
c.childMethod()  # 调用子类的方法
c.parentMethod()  # 调用父类方法
c.setAttr(200)  # 再次调用父类的方法 - 设置属性值
c.getAttr()  # 再次调用父类的方法 - 获取属性值

输出结果：

6、方法重写

子类中重写父类方法

class Parent:  # 定义父类
    def myMethod(self):
        print('调用父类方法')


class Child(Parent):  # 定义子类
    def myMethod(self):
        print('调用子类方法')


c = Child()  # 子类实例
c.myMethod()  # 子类调用重写方法

输出结果：

7、类属性与方法

单下划线、双下划线、头尾双下划线说明：

foo: 定义的是特殊方法，一般是系统定义名字，类似 init() 之类的。
_foo: 以单下划线开头的表示的是 protected 类型的变量，即保护类型只能允许其本身与子类进行访问，不能用于 from module import *
_ foo: 双下划线的表示的是私有类型(private)的变量, 只能是允许这个类本身进行访问了（self. _foo）。
类的方法
在类的内部，使用 def 关键字可以为类定义一个方法，与一般函数定义不同，类方法必须包含参数 self,且为第一个参数

 class JustCounter:
    __secretCount = 0  # 私有变量
    publicCount = 0  # 公开变量

    def count(self):
        self.__secretCount += 1
        self.publicCount += 1
        print(self.__secretCount)


counter = JustCounter()
counter.count()
counter.count()
print(counter.publicCount)
print(counter.__secretCount)  # 报错，实例不能访问私有变量

输出结果：

Python函数、模块、包

Wed, 20 Nov 2019 00:00:00 +0000

一、函数

1、函数定义

函数代码块以 def 关键词开头，后接函数标识符名称和圆括号()。
任何传入参数和自变量必须放在圆括号中间。圆括号之间可以用于定义参数。
函数的第一行语句可以选择性地使用文档字符串—用于存放函数说明。
函数内容以冒号起始，并且缩进。
return [表达式] 结束函数，选择性地返回一个值给调用方。不带表达式的return相当于返回 None。

 def funcationname(parameters):
    "funcation description"
    function_suite
    return [expression]

2、函数调用

3、参数传递

可更改(mutable)与不可更改(immutable)对象在 python 中，strings, tuples, 和 numbers 是不可更改的对象，而 list,dict 等则是可以修改的对象。

不可变类型：变量赋值 a=5 后再赋值 a=10，这里实际是新生成一个 int 值对象 10，再让 a 指向它，而 5 被丢弃（python回收机制？），不是改变a的值，相当于新生成了a。
可变类型：变量赋值 la=[1,2,3,4] 后再赋值 la[2]=5 则是将 list la 的第三个元素值更改，本身la没有动，只是其内部的一部分值被修改了。

python 函数的参数传递：

不可变类型：类似 c++ 的值传递，如整数、字符串、元组。如fun（a），传递的只是a的值，没有影响a对象本身。比如在fun(a)内部修改 a 的值，只是修改另一个复制的对象，不会影响 a 本身，类似值传递。
可变类型：类似 c++ 的引用传递，如列表，字典。如 fun（la），则是将 la 真正的传过去，修改后fun外部的la也会受影响，类似引用传递。

4、参数

必备参数必备参数须以正确的顺序传入函数。调用时的数量必须和声明时的一样。

调用printme()函数，必须传入一个参数，不然会出现语法错误：
关键字参数函数调用使用关键字参数来确定传入的参数值。使用关键字参数允许函数调用时参数的顺序与声明时不一致，因为 Python 解释器能够用参数名匹配参数值。输出结果说明使用关键字参数后，参数输入顺序并不重要
不定长参数函数能处理比当初声明时更多的参数。这些参数叫做不定长参数，和上述2种参数不同，声明时不会命名。基本语法如下：

  def functionname([formal_args,] *var_args_tuple ):
   "函数_文档字符串"
   function_suite
   return [expression]

如下例，预定义参数输出后，多余参数记录到不定长参数中

二、模块

Python 模块(Module)，是一个 Python 文件，以 .py 结尾，包含了 Python 对象定义和Python语句。模块能够更有逻辑地组织 Python 代码段，使得代码更好用，更易懂。模块能定义函数，类和变量，模块里也能包含可执行的代码。

模块定义好后，使用 import 语句来引入模块

命名空间和作用域

每个函数都有自己的命名空间。类的方法的作用域规则和通常函数的一样。Python 会猜测一个变量是局部的还是全局的，它假设任何在函数内赋值的变量都是局部的。因此，如果要给函数内的全局变量赋值，必须使用 global 语句。global VarName 的表达式会告诉 Python， VarName 是一个全局变量，这样 Python 就不会在局部命名空间里寻找这个变量。例如在全局命名空间里定义一个变量 Money。再在函数内给变量 Money 赋值，然后 Python 会假定 Money 是一个局部变量。

然而，并没有在访问前声明一个局部变量 Money，结果就是会出现一个 UnboundLocalError 的错误。

取消 global 语句前的注释符就能解决这个问题。

正确输出结果：

globals() 和 locals() 函数

根据调用地方的不同，globals() 和 locals() 函数可被用来返回全局和局部命名空间里的名字。

如果在函数内部调用 locals()，返回的是所有能在该函数里访问的命名。

如果在函数内部调用 globals()，返回的是所有在该函数里能访问的全局名字。

两个函数的返回类型都是字典。所以名字们能用 keys() 函数摘取。

三、包

包是一个分层次的文件目录结构，它定义了一个由模块及子包，和子包下的子包等组成的 Python 的应用环境。简单来说，包就是文件夹，但该文件夹下必须存在 init.py 文件, 该文件的内容可以为空。init.py 用于标识当前文件夹是一个包。

#__init__.py代码
if __name__ == '__main__':
    print ('作为主程序运行')
else:
    print ('package_yt 初始化')


#yt1.py代码    
def yt1():
   print ("I'm in yt1")


#yt2.py代码
def yt2():
   print ("I'm in yt2")



#main.py代码
from package_yt.yt1 import yt1
from package_yt.yt2 import yt2

yt1()
yt2()

运行结果：

闫涛

飞行测试

Mavic Mini 飞行体验 —— 起飞！

1、机身和遥控

2、新的App

3、飞行及拍摄体验

集成测试

集成测试

增量与非增量测试

集成测试之自顶向下、自底向上、三明治集成

1、自顶向下测试

2、自底向上测试

3、三明治集成测试

4、 自顶向下和自底向上两种测试方法的优缺点

自顶向下

自底向上

单元测试

单元测试

测试用例设计

1、语句覆盖

2、判断覆盖

3、条件覆盖

4、MCDC覆盖

5、判定条件覆盖（Decision/Condition Coverage）

6、组合覆盖（Branch Condition Combination Coverage）

7、路径覆盖

（3）代码走查

（4）同行评审

测试阶段的划分以及组织形式（二）

3、代码审查

（1）代码的检查与走查

（2）代码检查错误详细列表

（3）代码走查

（4）同行评审

测试阶段的划分以及组织形式（一）

1、静态分析

（2）数据流分析

（3）接口分析

（4）表达式分析

2、文档审查

一、软件文档的类型

二、文档测试的重要性

三、审查文档时要找什么

测试理论（二）

（一）软件质量度量指标及方法

（二） 软件质量指标

1、外部质量

2、内部质量

测试理论（一）

一、软件开发模型

几种常用的软件开发模型

（1）瀑布模型（V模型）

（2）W模型

（3）螺旋模型

（4）喷泉模型

（5）快速原型模型

（6）增量模型

python异常处理,文件I/O

一、异常处理

1、Python常见标准异常

2、异常处理语句

（1）使用except带异常类型

（2）使用except不带异常类型

（3）使用except而带多种异常类型

（4）try-finally 语句

二、文件I/O

1、读取键盘输入

2、打开和关闭文件

3、write()和read()方法

4、重命名与删除文件

python面向对象

面向对象

1、 创建类

2、创建实例对象

3、 访问、添加、修改、删除属性

4、python对象销毁(垃圾回收)

5、类的继承

6、方法重写

7、类属性与方法

Python函数、模块、包

4、自顶向下和自底向上两种测试方法的优缺点

（二）软件质量指标

1、创建类

3、访问、添加、修改、删除属性