为什么进行软件测试？
软件存在缺陷，只有通过测试才可以发现缺陷，只有发现缺陷才能把缺陷从产品中清除出去。
软件中缺陷带来的损失是巨大的。
测试是所有工程学科的基本组成单元。
软件测试：验证+有效性确认。
软件质量保证（SQA）（考过）：是通过对软件产品有计划地进行评审和审计来验证软件是否合乎标准的系统工程。对软件工程各个阶段的进展，完成质量及出现的问题进行评审和追踪。
SQA和软件测试的关系：SQA指导，监督软件测试的计划和进行，督促测试工作的结果客观，准确和有效，协助测试流程的改进。
软件测试是SQA的重要手段之一，为SQA提供所需数据，作为质量评价的客观标准。
SQA是管理工作，侧重对流程的评审和监控。测试是技术性工作，侧重对产品进行评估和验证。
软件质量：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和=软件产品满足使用要求的程度。
内部质量：开发人员自己发现的代码或设计缺陷的问题集合。
外部质量：测试人员发现的bug集合。
使用质量：用户角度评价的质量。
软件缺陷：任何程序，系统中的问题，和产品设计书的不一致性，不满足用户的需求。
软件规格说明书缺陷占比最多，一般是开发者和用户沟通困难，对产品理解不同。
静态代码测试通常比动态测试效率更高。
评审：可以更早发现需求工程，软件设计等各方面的问题，减少后期返工。
桌面检查：程序员自己检查编写的程序。
验证和确认：验证：是否正确构造软件？即是否正确地作时，验证产品满足规格说明书。确认：是否构建了用户需要的软件？
主动测试方法：测试人员主动向被测对象发送请求，或借助数据，事件驱动测试对象。
被动测试：测试人员不干预产品运行，而是被动监控产品在实际环境中运行，通过一定被动机制获得系统运行的数据。例如在线测试。
系统非功能性验证：将软件放在整个计算机环境下，在实际环境下进行一系列的测试。包括恢复测试，健壮性测试，安全测试，性能测试。
测试工作流程：测试需求分析-制定测试计划-设计测试用例（开发测试工具或脚本）-执行测试-测试结果分析-提交测试报告
用例全部测试完毕，覆盖率达到标准，缺陷率达到标准或者其它指标达到标准。
软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动
重要的章节，里面的内容是必考的，也是本课程中少有的不太需要背很多概念的章节，但是要注意答题规范。
什么是测试用例？
为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
测试用例是软件测试的核心
注意重点需要掌握：
1.等价类划分和边界值分析法
2.判定表法
3.因果图法
4.逻辑覆盖的所有方法。
其中逻辑覆盖法是需要考虑具体代码的，是一种白盒测试法，而前面的是黑盒测试法，只需要考虑输入和输出是否合理。
其他方法（简单一提）：上下文驱动方法，基于需求验证方法，基于场景的测试方法，基于经验的方法等。
ALAC：一种基于客户使用产品知识开发的测试方法，80/20定律：用户80%的时间都在使用20%的功能。而80%的错误也集中在20%的程序模块中。因为时间有限，所以只对常用功能测试。
自由测试：根据经验测试，不受用例约束。
在需求规格说明的基础上分析等价类。在等价类中每个输入数据的作用是等效的。
需要经过正反的测试。
在规定取值范围的情况下，可以分为一个有效等价类和两个无效等价类。
在规定“必须如何”的情况下可以设计一个有效和一个无效。
在条件是布尔量的时候可以设计一个有效和一个无效。
在规定了一组值且需要分别处理的情况下，可以设计n个有效等价类和一个无效等价类。
例如：计算器，等价类包括：整数，小数点，负数，无效输入等。
流程：
建立等价类表：输入条件，有效等价类，无效等价类。
为每个等价类规定唯一编号。
设计测试用例，使其尽可能多覆盖尚未覆盖的有效等价类。直到所有有效等价类都被覆盖。
设计测试用例，使其只覆盖一个无效等价类。直到所有无效等价类都被覆盖。
许多错误发生在输入或输出范围的边界上，所以可以针对边界设置用例。
确定边界情况，选取正好等于，刚刚大于或小于的边界值作为测试数据。
经典例题：手机号码那道题，包括地区码。
难度不大。
判定表由条件和活动两部分组成，即列出一个测试活动执行所需要的所有条件的组合。
条件桩：列出问题的所有条件。
动作桩：列出可能针对问题采取的操作。
条件项：针对条件的具体赋值。
动作项：在某个条件组合下采取的动作。
规则：在判定表中每一列是一个规则。
例子：
一些规则可以被优化从而减少列的个数，需要确保动作一致，且某些条件的取值不会影响动作的结果。
借助图形，分析输入条件的各种组合，由原因的组合走向结果。和判定表类似，可以依据判定表导出。
找出原因和结果，原因与原因之间的对应关系。
根据因果图，创建判定表。
把判定表每一行作为依据设置测试用例。
条件之间可能存在约束关系。E表示互斥，I表示包含，或，即两个原因至少有一个出现。O表示条件有且仅有一个出现。R-需求，M-屏蔽（基本不用画，能看懂就行）
需要注意，根据因果图导出的判定表可以是横向的，也可以和之前说的判定表一样是纵向的。这两种方法基本上会一起考。
因果图法有时候会让复杂的逻辑更难以看懂，需要规范其形状。
流程：确定因果--画因果图--画判定表（优化）--根据判定表设计测试用例。
因为条件取值过多，实现覆盖所有组合并不现实，可以通过两两组合减少条件的组合数，降低工作量。
可以依据工具自动生成组合，例如微软的PICT
选择测试次数最少，最合适的正交表，利用正交表构建测试集。
从大量测试用例里挑选有代表性的点（条件组合），从而降低测试次数。
重点章节。
设计若干测试用例，使得程序中每个可执行的语句至少被执行一次。
如果是顺序结构，就从头执行到尾。
语句覆盖不能发现条件错误。
设计若干测试用例，使得程序中的每个判断取真和取假的分支至少经理一次，也就是所有判断的真假都各满足一次。
某种意义上也算是语句覆盖（因为在分支结构中想要实现语句覆盖就要通过判定覆盖来执行）
正因如此，语句覆盖发现不了的问题判定覆盖仍然发现不了。
设计测试用例，使得每个判断中每个条件的可能取值至少满足一次。
一定要分清楚判定覆盖和条件覆盖，条件覆盖相当于深入到每个判定里面了（一个判定里当然可能有很多个条件）。
需要列出所有条件，设T1，F1这些字母代表某个条件的取值。
某种意义上也可以和判定覆盖重合。
设计足够的测试用例，使得判断条件中所有条件可能取值至少执行一次，同时判断的可能结果也至少执行一次。二者是可以重合的。
答题格式：
设计足够的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。比如TT，TF，FT，FF
能够覆盖所有条件组合，但是可能无法覆盖所有路径。也就是说条件组合测试中“条件组合”仅仅是限于一个判定中条件的组合，至于不同判定之间的条件组合则无需全部覆盖。
问题：条件组合的效率不高，有些测试没有必要。判定/条件测试则不够强，不能覆盖数据，没有考虑数据域。
每个判定的所有可能结果至少取值一次（判定覆盖）
每个条件的所有可能结果至少取值一次（条件覆盖）
一个判定中每个条件曾经独立地对判定结果产生影响
每个入口出口至少执行一次。
由于每个条件只需要独立影响一次结果（例如A and B，在B取T的情况下，A可以独立影响结果），可以减去一部分条件组合。
设计测试用例，覆盖程序中的所有可能的执行路径。
流程：
1.根据代码绘制流程图。-->控制流图
2.确定圈复杂度
3.确定线性独立路径的基本集合
4.设计测试用例覆盖每条基本路径。
绘制流程图之后可以先简化。
圈复杂度：代码逻辑复杂度的度量。可以由：区域数量（包括图形最外部的区域），连线数量-节点数量+2，判定节点数量+1得到。
独立路径：和其它独立路径相比，至少引入了一个新的处理语句或者一个新判断的程序通路。（例如和之前的独立路径相比多覆盖了一小段之前没有的路径）。圈复杂度=独立路径条数。
由基本集导出的测试用例能保证每行代码语句至少被执行一次。
根据每一条独立路径，根据判断节点给出的条件，设计测试用例使得每一条路径都可以被测试到。
最好每个单元都进行基本路径测试，对于关键组件则是必要的。
对循环结构也需要进行测试
简单循环（迭代n次）：完全跳过；只循环一次；循环两次；循环m次，分别循环n-1，n，n+1次（类似边界值）
嵌套循环：在最里面的循环完成简单循环测试，同时设置外部循环的最小迭代次数。从里到外，逐步测试。
对过去发现的各种具体缺陷进行归纳整理，抽象出共性，生成缺陷模式，然后基于这种模式取预防问题。
错误猜测法：根据测试人的经验，按常见问题进行测试（手工）
常见缺陷：
故障模型：空指针，内存泄漏，数组越界
安全漏洞模型：他人攻击的可能性，缓冲区溢出。
差性能模型：空字符串比较；参数为常数
并发故障模型：对多线程，虚拟机工作机制不了解。
不良习惯模型：垃圾回收，类，方法的命名。
易诱骗代码模型：易引起歧义的代码，没有意义的判定。
通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例。
功能图法是为了解决动态说明问题的一种测试用例的设计方法。（基于状态的测试）
功能图由状态迁移图STD和逻辑功能模型LFM构成。
状态迁移图：有点类似状态自动机，描述系统状态变化的动态信息，用状态和迁移来面熟，迁移表示状态的改变。
功能图法设计测试用例就是如何覆盖软件所表现出的“所有状态”。
从功能逻辑模型（判定表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合。
从状态前意图导出整体测试用例，以覆盖系统控制的逻辑路径。
功能图法是综合运用黑盒方法和白盒方法来设计测试用例，整体上采用白盒，局部上采用黑盒。
注意先列出所有状态，然后根据事件画出状态之间的转移。
然后画出状态图
在状态图中每条基本路径都可以设计一个测试用例。
在测试用例中需要给定预置条件（初始状态），给出输入，操作步骤和预期输出。
构造大量变异数据作为输入，检测系统是否会出现问题。
类似OI的对拍。
缺乏逻辑严密性。
用随机或者半随机的方法产生数据，并发给被测试系统，检查结果是否与预期结果相同，或者是否存在潜在的安全漏洞。
基于数学的方法来描述目标软件系统属性的一种技术。
形式化规范说明语言的构成：语法，语义和一组关系。
相当于用公式描述一个程序，是对软件系统的精确建模。
巴科斯范式BNF
形式化三部曲：形式化描述，形式化开发，形式化验证。
形式化验证：根据某些形式规范或属性，使用形式逻辑方法证明其正确性或非正确性。
无法证明某个系统没有缺陷，因为没法定义“没有缺陷”，只能证明一个系统不存在我们可以想得到的缺陷，以及验证满足系统质量要求的属性。
有限状态机FSM：输入符号，输出符号，状态集合，状态转移函数，输出函数。
EFSM：增加了动作和转移条件，以处理系统的数据流问题。
概念的东西，简单看看即可。
可以用状态转化树生成测试用例（与之前功能图法相当类似）
传统软件测试过程：需求评审，设计评审，单元与集成测试，系统测试，验收测试。（ppt顺序）
上面是V模型，W模型则是对V的扩展，增加了应同步进行的验证和确认活动。相当于一边测试一边修bug
测试过程和开发过程是同时开始，同时结束的，两者保持同步关系。测试过程是对开发过程中阶段性成果和最终产品进行验证的过程，两者相互依赖。前期测试过程依赖开发过程，后期开发过程依赖测试过程。
TMap生命周期模型：一个基于风险的测试方法，基于风险的测试策略，有效分配测试投入。四个部分：计划（建立测试基线，建立测试组织），准备（定义测试单元），说明（开发测试脚本），执行（执行测试），结束。
以人为核心，迭代，循序渐进的开发方法。每个子项目的成果都经过了测试，具备集成和可运行的特征，小项目之间相互联系。
一些敏捷方法（概念）：极限编程，SCRUM，水晶方法。。
敏捷迭代：需求阶段，开发实现，功能测试。
可用的软件，发现并解决问题，拥抱变化，信息的透明化，清晰的迭代目标。
核心理念：适应和以人为本。
Scrum：设定产品优先级。屏蔽外界对团队成员的干扰，保证开发过程按计划进行，组织各会议。主导项目过程的改进。
结对编程：找个水平差不多的程序员配对，用一台计算机，一个人负责输入，另一个人口述，需要不停交流。
ST是基于脚本的测试，先设计后执行，阶段性明显，属于传统的测试方式。过程：分析，设计，执行，报告。
ET是探索性测试：设计和执行同时展开，没有测试用例，一边想一边测试。
ET适合快速测试，测试时间少，开发节奏快，产品某些部分功能复杂， 需要不断探索才能完成测试。
ST：系统性强，容易管理，设计在先执行在后，可以验证思路，具有可预见性。严谨规范，有明确测试标准，关注需求和测试文档。
ET：高效率，适应性强，执行和思考并行，是不断学习的过程。拥抱变化和乐趣，强调个人能力。
认为软件是逻辑性的，将测试看作计算机科学和数学的一部分，侧重利用UML等工具分析建模。技术性强。
从分析学派分离，得到IEEE支持。侧重劣质成本控制，具有可重复标准，旨在衡量项目进度。
是对产品需求的确认，每个需求是否得到验证。
软件质量需要规范。测试就是过程的质量控制，揭示项目的质量风险。确认开发人员是否遵守规范。
测试发现的缺陷都与相关利益者相关，强调人的能动性和启发性思维。探索性测试。
测试就是验证开发工作是否完成，强调自动化测试。
系统的测试进行的越彻底，就能发现越多的剩余缺陷，发现的缺陷越多，被修复的缺陷就越多。风险绝不会降到0.
基于风险的测试是评估测试优先级，先做高优先级的测试，低优先级的可以暂时先不做。
影响因素：对用户的影响？出问题的概率？新功能对该功能是否有高的依赖性。
风险级别计算：风险级别=总的严重程度*总的可能性。先加权求和再相乘。
TMMi（测试成熟度）：初始级（没有文档化和结构化，测试与调试没有本质区别），定义级（具有基本测试方法，测试调试分开），集成的（具有独立测试部门，根据用户需求设计测试用例，没有有效评审制度），管理/度量的（采用数据库管理测试用例，具有缺陷管理系统并划分缺陷级别。没有预防机制。评审作为质量控制的部分），优化的（运用缺陷预防和质量控制措施，自动化程度高，自动化收集缺陷信息）。
TPI成熟度矩阵：可控的，有效的，不断优化的。根据检查点来度量。
CTP：关键测试过程。12个关键过程。
STEP：系统化测试和评估过程。基于需求的测试策略，对缺陷进行系统分析，测试驱动开发。度量：已定义的测试过程使用，客户满意度。
国际标准，国家标准， 行业标准，企业（机构）规范，项目规范。
《计算机软件测试规范》
（概念了解）
单元测试是对软件基本组成单元进行独立的测试。
尽早发现错误，发现问题比较容易，修正问题更容易。
检查代码是否符合设计和规范，有利于代码的维护。
发现越早，修改的代价越小（Terd Mountain）
测试通过的一般准则：
单元功能与设计需求一直，接口与设计需求一致，能正确处理输入和运行中的错误，发现的错误已经得到修改并通过测试，达到覆盖率要求，完成测试报告。
测试任务：独立路径的测试，局部数据结构，单元接口，边界条件，容错性测试，内存分析等。
静态测试技术：不运行程序，通过对代码进行检查，阅读进行分析。三部曲：互查，走查，评审。
编码标准和规范：标准是编码必须遵守的规则，规范是建议的最佳做法。
原因：可靠性， 可读性，可维护性，可移植性。
互查：一次检查少于200-400行代码，速度300-500/hour
走查：采用讲解，讨论和模拟运行的方式进行查找错误的活动。引导小组成员通读设计和编码，发现问题适当记录。非正式会议，主要是开发人员参加。
审查：以会议形式制定目标，流程和规则，按缺陷检查表逐项检查。发现重大缺陷改正后要重新开会。测试人员需要参加。
动态测试：需要真正将程序运行起来，设计系列的测试用例保证测试完整性和有效性。黑盒测试和白盒测试都是动态测试过程。
驱动模块driver：对底层或子层模块进行测试所编写的调用这些模块的程序。
桩模块stub：对顶层或上层模块进行测试时所编写的，替代下层模块的程序（输出结果）。
类测试：对类的成员函数进行测试。不会对类的每个成员和方法进行测试。对于核心或者重要的方法进行全面的单元测试，类似传统软件对单个函数的测试。
代码评审案例：空指针错误，格式化数字错误，数组越界。不当使用synchronized导致系统性能下降。
单元测试常用工具：JUnit（用过，了解即可）
集成出现的问题：接口参数不匹配，数据错误，全局数据结构程序错误。
测试模式：
非渐进式：先分别测试每个模块，再把所有模块按照设计要求放在一起结合成所要的程序。大棒模式。
渐进式：把下一个要测试的模块和已经测试好的模块结合起来测试，测试完之后再加入下一个。
优缺点对比：渐进测试工作量大，发现接口错误早，错误定位更容易，测试更彻底，时间更长。
大棒集成方法：先对子模块进行测试，然后一次性集合起来测试（不推荐，因为不好确定错误的真正位置）
自顶向下和自底向上的集成方法：
自顶向下法：对主控模块测试，每次用一个实际模块代替桩模块。优点：不需要驱动，可以早期验证主要功能，能够发现上层接口错误。缺点：底层错误发现较晚，需要桩程序。
自底向上法：把底层模块结合成某个子功能的簇。写驱动程序，测试子功能。去掉驱动程序，自下向上移动，将子功能结合起来形成更大的簇，直到测试完成。
混合策略：上层自顶向下，下层自底向上。
三明治集成：对中上层使用自顶向下，对下层使用自底向上。可以少些驱动程序和桩程序。缺点是真正继承之前每一个独立模块没有完全测试过。
改进的三明治集成：不仅两头向中间集成，每个模块还要进行单独测试。
持续集成：根据进度将完成的模块尽早进行集成，尽早发现和解决bug。
持续集成测试的支撑基础：CI的文化，CI的流程，良好基础设施，统一的代码库，定期提交代码，自动部署，自动集成测试。
根据产品规格说明书，验证系统是否满足各方面的使用要求。
要点：每项功能符合实际要求，各种状态按照业务流程变化并保持稳定。功能逻辑清楚，符合使用者习惯。
客户需求为导向。
在程序有修改的情况下，保证原有功能正常的一种策略和方法。
回归缺陷：一旦修改某些部分，就可能影响其他区域，导致出现新的缺陷。这就是回归缺陷。
策略：测试全部用例（成本高），基于风险选择测试（选择风险高的），基于操作剖面选择测试（选择针对重要功能或用户频繁使用的测试用例）
发现系统性能问题，获取系统性能相关指标。通过工具模拟实际软件系统运行及其操作，监控各项性能指标，并对测试结果分析确定系统性能状况。
目标：获取系统性能某些指标数据。
验证系统是否达到用户提出的性能指标。
发现性能瓶颈，优化性能。
性能指标：系统资源使用率，请求响应时间，事物响应时间，数据吞吐量。
性能测试类型（根据目的不同）：
性能验证测试：验证是否达到之前定义的系统性能指标，能否满足需求。需要事先明确系统性能指标。
性能基准测试：在系统标准配置下获得有关性能指标。
性能规划测试：在多种特定环境下，获得不同配置的系统性能指标，决定在部署的适合采用什么样的配置。
容量测试：用系统容量作为系统性能指标。
压力测试：检查对异常情况的抵抗能力，找出性能瓶颈或其它不稳定问题。
ST并发性能测试：逐渐增加并发虚拟用户数负载，直到出现瓶颈或者崩溃为止。
ST疲劳强度测试：采用系统稳定运行情况下能支持的最大负载，持续长时间运行，以发现性能问题。渗入测试，峰谷测试。
ST大数据量测试：通过大量数据进行测试。
思考时间：收到响应后下一个请求之间的间隔时间。
必须明确性能需求。
具体指标：数据吞吐量，数据处理效率，请求响应时间，内存和CPU使用率。
Apache Flood：web性能测试工具；Gatling，Siege，DBMonster（用于SQL压力测试）
容量测试：预先分析出反应软件系统应用特征的某项指标的极限值，确定软件系统保持主要功能正常运行的某项指标的极限值。
使伤害或损害的风险限制在可接受水平内。
防止危险状况措施的有效性和在每一个危险状态下的反应。
种类：安全功能测试，安全漏洞测试（从攻击者的角度发现安全漏洞）
功能性测试vs安全性测试：功能性测试是软件要做它应该做的事情，验证正确的输出和不正确的输出。安全性测试是软件不做它不该做的事情，防止不安全的事情发生。
静态测试：对源代码进行安全扫描，将数据里，控制流，语义等与软件安全规则库进行配对，找出潜在的安全漏洞。
动态测试：利用自动化工具或人工方法模拟黑客输入，对系统进行攻击性测试。
渗透/攻击的阶段：预攻击：收集信息，进行进一步决策；攻击：进行攻击，获得系统权限；后攻击：消除痕迹，长期维持一定权限。
其它概念了解即可，考的可能性不大。最多有选择题。
输入验证：每个输入域都可能是一个潜在风险，可能被注入脚本攻击服务器。
XSS漏洞：注入脚本，迫使服务器回显数据。
非持久性跨站点脚本攻击，攻击者将在url中注入脚本将注入的数据反映在响应中。
存储型XSS攻击：将攻击代码存入数据库，客户端打开的时候就执行这些攻击代码，例如留言板。
SQL注入：从客户端提交特殊代码，从而收集数据库的信息。例如根据sql的规则，附加一个永远为真的条件，使得某个认证条件总是成立，从而欺骗系统。
安全测试工具等：FindBugs，CppCheck
可靠性：产品在规定条件下和规定时间内完成规定功能的能力。
成熟性度量：通过DPP（错误发现率）衡量。DPP=测试发现错误的数量/已知全部错误数量。
容错性测试：检查软件在异常条件下自身是否具有防护性措施或者某种灾难性恢复的手段。
故障转移：出现故障时能否成功完成故障转移，从导致数据损失或数据完整性破坏的各种硬件，软件和网络故障中恢复。
数据恢复：一旦发生故障，备用系统将接替发生故障的系统。
硬件兼容，软件兼容，数据之间兼容。向后兼容（可以使用软件的以前版本），向前兼容（可以使用软件的未来版本）
对所有可能的软件组合等价分配，验证软件之间正确交互的最小有效集合。
例：设计测试矩阵表
也叫交付测试
测试内容：和用户一起验收软件系统，在真实环境下运行系统，看是否存在和用户要求不一致的问题。
验收测试完成标准：完全执行了验收测试计划中的测试用例。发现的错误得到了修改并通过测试。完成软件验收测试报告。
注意事项：必须编写正式的验收测试报告，通过验收的产品不代表不存在缺陷。
验收测试必须在实际用户运行环境中进行。
由用户和测试部门共同执行。
α测试：开发公司组织内部人员模拟用户进行测试，发现错误并修正。
β测试：组织外部典型用户在日常工作中实际使用β版本，并汇报异常情况，反馈意见，然后公司再对β版本进行改错和完善。
验收测试报告，也叫发布报告。
产品规格说明说的验证：
审核不是验收期间的主要任务，应该在生命周期初期就完成了。
根据产品规格说明书，逐字逐句验证产品的每一项特征，再验证结束时提交基于产品规格说明书的验证报告。目的是再验收测试初期评测软件特性是否都已实现，是否可以进行验收测试。
文档测试
检查各类文档的正确性，例如用户手册，安装指南和向导，说明书，包装等。
主要检查正确性，完备性，可理解性，一致性（是否自相矛盾）
用户界面和可用性测试：
用户界面要素：符合标准和规范，直观性（功能或响应是否显著），一致性（软件本身的一致性，如字体风格），灵活性，舒适性（适当的表现，合理的安排），正确性（是否有多余或者一楼的功能），实用性（一些特性是否真的实用）。
安装性测试，卸载测试，可恢复性测试。
Localization，L10N
Internationalization，I18N
Globalization，G11N
关系：I18N是L10N的基础和前提，为L10N做准备。
L10N是I18N向本地语言环境的转换。
I18N是软件开发的一个部分。
L10N可以独立于Engineering，由第三方完成。
支持Unicode字符集，双字节字符；返利程序代码和显示内容；支持各个国家的键盘设置；支持文字排序和大小写转换；支持各个国家的度量衡，时区，货币单位格式等。
是国际化向本地特定语言环境的转换，还需要对产品外观，参数设置等进行相应处理。
Unicode为所有字符分配了唯一的数字编号。并没有规定怎么存储。
UTF32：四个字节。
UTF16：使用变长字节表示。
UFT-8：使用变长字节，由1到4不等。
0-127：1字节 0XXXXXXX
128-2047：2字节 110XXXXX 10XXXXXX
2048-65525：3字节 1110XXXX 10XXXXXX 10XXXXXX
65536以上：4字节 11110XXX 10XXXXXX 10XXXXXX 10XXXXXX
国际化标准：运行时可以动态切换某种国家或地区的语言。
在启动前或者启动时可以设置语言。
本地化测试：功能性测试，翻译测试，可用性测试，兼容性测试，文化/宗教/喜好等实用性测试，手册验证。
还需要遵守地方法规和宗教信仰等，避免政治敏感的术语。
数据格式：如时间表示方法不同。
页面显示和布局：例如德语很长，汉语比较精炼。有些空间可能无法完全显示。
UI验证的细节：例如控件遮挡，文字方向问题，左右对齐问题，拉丁语言大小写问题等。
还要对文件保存，打印等类似的功能进行测试，特别注意语言环境特定的组件。
手工测试无法覆盖所有路径，且用例太多，工作量太大。
自动化测试：把人为驱动的测试行为转化为机器执行的一种过程，模拟手工测试步骤，执行程序语言编制的测试脚本，自动完成单元测试，功能测试等。
自动化测试vs测试自动化：自动化测试焦点集中在测试执行，由测试工具自动完成测试。
测试自动化意味着全过程的自动化和测试管理工具的自动化。
代码分析，对象识别。
脚本技术：脚本是一组测试工具执行的指令的集合。可以通过录制测试的操作产生，然后进行修改。
线性脚本：录制手工执行测试用例得到的脚本。
结构化脚本：类似结构化程序设计，具有各种逻辑结构，函数调用等功能。
数据驱动脚本：将测试输入存储在数据文件中，而不是脚本中。
关键字驱动脚本：是数据驱动脚本的逻辑扩张，封装了基本操作，开发的时候可以直接使用定义好的关键字。
自动比较：比较测试输出的数值和期望数值。对于图形化或者自绘窗口特效验证是难点。
静态测试工具：Findbugs，JTest等
动态测试工具：内存检测工具，监控工具，负载测试工具等。
测试自动化项目本质上也是软件开发项目。
对策：正确认识，找准自动化的切入点，进行资源的合理调度，降低投入提高产出等brabrabra
自动化功能测试的基本构成：录制测试脚本，编辑脚本，调试脚本，执行，结果分析。
LoadRunner（性能测试工具）
自动化测试框架
测试件存储与管理，测试脚本开发调试，测试机/资源管理，任务安排等。
