今天完成的事情：

今天看了一天的pc端的原型图，看了一下流程，明天应该会pc端的需求讲解
明天计划的事情：

pc端，尽量画一个脑图
遇到的问题：

没有
收获：

动态测试

动态测试：通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标；这种方法包括三部分：构造测试用例、执行程序、分析程序的输出结果。

动态测试分类：可从不同角度进行分类。

从是否关心软件内部结构和具体实现的角度划分，可分为“白盒”测试、“黑盒”测试、“灰盒”测试。

从软件开发过程的角度划分，可分为：单元测试、集成测试、确认测试、系统测试、验收测试、回归测试。

从测试执行是否需要人工干预的角度划分，可分为：人工测试、自动化测试。

从测试实施组织的角度划分，可分为开发方测试、用户测试（β测试）、第三方测试。

白盒测试

白盒测试：“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

白盒测试与调试的区别：

调试和动态白盒测试都包括处理软件缺陷和查看代码的过程，但是他们的目标不同。动态白盒测试的目的是发现问题，而调试的目的是改正缺陷，但他们的共同目的是分离缺陷。

动态白盒测试技术包括：

语句覆盖：语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

判定覆盖：要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。

条件覆盖：不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。

判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。

满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。

路径覆盖：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次

静态白盒测试测试主要包括代码的检查，通过测试人员仔细阅读代码来检代码和设计的一致性，代码的可读性，代码是否循序了相应的标准、逻辑表达是否正确，结构是否合理等。

而动态白盒测试要在Host环境或者Target环境中实际运行软件，并有测试用例的设计与执行，和结果的分析

黑盒测试

黑盒测试：又称功能测试或数据驱动测试，把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性。站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试在软件的接口处进行测试通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖。

黑盒测试基本上都是动态测试

黑盒测试用到的主要方法有：等价类划分法、因果图法、边界分析法、猜错法、随机数法等。

等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值（按区间划分，按数值划分，按数值集合划分，按限制条件或规划划分，按处理方式划分）

划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合

边界值分析是对等价类划分方法的补充，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，采用边界值分析法设计测试用例进行软件测试，常常可以查处更多的错误，取得良好的测试效果。

边界值分析原则：如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据。 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为册数数据。根据规格说明的每个输出条件，使用原则 ；如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。分析规格说明，找出其他可能的边界条件。

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。

因果图生成测试用例的基本步骤：

分析软件规格说明描述：原因、结果、标识符

分析软件规格说明描述中的语义：找出逻辑关系

由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，添加必要的约束条件

把因果图转换成判定表

把判定表的每一列拿出来作为依据，设计测试用例

 猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

猜错法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

经过大量的经验总结，程序中容易出错的情况有：

输入数据为零或输出数据为零往往容易发生错误；

如果输入或输出的数目允许变化，则输入或输出的数目为1或0的情况是容易出错的情况等。

还要仔细分析程序的规格说明书，注意找出其中遗漏或省略的部分，以便设计出相应的测试方案，检测程序员对这些部分的处理是否正确。

测试用例设计

测试用例特点：正确性、完整性、准确性、清晰、简洁、可重用性、可维护性。

测试用例设计原则：

基于测试方法（不同的测试方法）

基于测试需求，兼顾测试充分性和效率

测试用例代表性，测试结果的可判定性，测试执行可再现性

测试执行可再现性

一个测试用例对应一个功能点，测试用例易读

测试用例的执行粒度越小越好，步骤清晰，结果明确

测试用例考虑单次投入成本和多次使用成本

总体思路是先进行基本功能测试，再进行复杂功能测试；

先进行一般用户测试，在进行特殊用户使用测试；

先进行正常情况测试，再进行特殊情况测试；

避免冗长和复杂的测试用例

测试用例的覆盖内容：

正确性测试

容错性(健壮性)测试

完整(安全)性测试

接口测试，数据库测试

边界值测试

压力测试

等价划分测试

错误推测

可理解(操作)性测试，可移植性测试

回归测试，比较测试

测试用例主要元素：测试环境、测试输入数据、测试执行步骤、测试预期结果。如图所示：

软件测试用例设计的误区：

能发现到目前为止没有发现的缺陷的用例是好的用例

测试输入数据设计方法等同于测试用例设计方法

强调测试用例设计得越详细越好

追求测试用例设计“一步到位”

测试用例中不需要明显的验证手段

让测试新人设计测试用例

测试用例不应该包含实际数据

单元测试

测试的对象是代码，一般是由开发来完成对应V模型的编码阶段，方法是逻辑覆盖更多的是属于动态测试，偏向白盒测试，使用语句覆盖，判定覆盖，条件覆盖等逻辑覆盖。有些在动态测试中检查不到使用代码检查。

单元测试的好处：程序最小组成部分，可以并行开展。规模小，复杂性低。做好单元测试后，后续的集成测试和系统测试会很顺利。尽早的发现缺陷，降低测试成本。

集成测试

对象是模块与模块之间的接口，对应V模型的设计，既属于黑盒又属于白盒黑盒针对模块结合在一起的功能，白盒针对模块间接口数据的传送，是由测试人员做的。

自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法：第一：先深度：按照结构，用一条主控制路径将所有模块组合起来；第二：先宽度：逐层组合所有下属模块，在每一层水平地沿着移动。

自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。

确认测试

确认测试基本概念：确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样

确认测试过程：①确认测试流程②有效性测试③软件配置复查④α测试和β测试⑤验收测试⑥确认测试结

系统测试

系统测试设计

测试设计的一般流程——理解软件和测试目标

测试设计的一般流程——设计测试用例

测试设计的一般流程——运行测试用例并处理测试结果

测试设计的一般流程——评估测试用例和测试设计

系统测试手段

典型攻击方法——25种典型攻击

用户接口输入攻击(6种)

用户接口输出攻击(4种)

用户接口数据攻击(3种)

用户接口计算攻击(4种)

文件系统介质攻击(3种)

文件系统文件攻击(3种)

操作系统和软件接口攻击(2种)