光明矢的专栏：《测试之美》--读书笔记
作者：[db:作者]
时间：2021-08-23 16:10
《测试之美》--读书笔记
《测试之美》----Beautiful? Testing??? 业界测试专家揭示如何改进软件
“来自这些测试技术领袖的每一条真知灼见、每一则实用建议或者每一个优雅甚至富有挑战性的想法，被展现得如此清晰而富有
激情。这本包罗万象、动人心魄并且富有生趣的收藏集，应该摆放在每一位专业测试人员的书架上。”
测试之美的三重境界（激越期、磨炼期、顿悟期）。
“测试之美”的融会贯通：
??? 思维流程之美；
??? 探索发现之美；
??? 结构和谐之美；
??? 卓越功能之美；
??? 团队合作之美；
第一部分? 测试者之美
测试是人类与生俱来的活动，即使测试不能思考、无法感受或令人沮丧，也需要有人考虑如何让测试用例变得自动化。
《测试之美》以人类方面的测试为开始，而不管是测试者自己或测试者与广阔世界的相互作用。
? 第1章 这对你有好处吗
??????????????? -------------->以独特视角揭示测试者的心理。
??????? 测试人员接受专门培训来发现并报告问题，他们通过发现和报告软件中的异常问题和存在的风险，进而帮助公司、开发团队、
客户和最终用户。
??????? 测试的角色更像是顾问。实际上，让一个公司把测试人员放在“质量把关人”的位置，操作起来蛮困难的，也不太公平。所谓“质量
把关人”，就是在软件发布前已将该软件看做是一件商品的负责人。大多数测试人员不能很好地权衡风险、必要性、市场需求和成本
开销。评估和承担风险其实是项目管理者或公司管理层的任务。
??????? 在态度方面，难道不应该团队协作吗？千真万确，你的测试人员也愿意扮演好团队成员角色，他们是想帮忙作贡献的，他们很
希望自己得到欣赏，但是他们关注的东西让项目组其他成员难以接受和欣赏他们的贡献。他们的幽默甚至增加了让他们融入团队的
难度。更糟的是，如果你在一个不关注质量的公司工作，并不认同或不解决测试人员辛苦发现的问题，测试团队会认为这是对他们
以及他们的工作缺乏尊重。如果你不给予测试人员他们应得的尊重，很快就会让他们士气低落，然后你就很难留住具有本土市场上
热门技能的人才。
??????? 你会发现如果对测试人员报以对开发人员、数据库管理员等人同样的尊重，就会促进建立一个能吸引和留住顶尖人才的测试
团队。
? 第2章 完美的测试让利益相关者满意
??????????????? -------------->Rex Black有25年使软件利益相关方满意的经历，他解释了“测试之美”的魅力所在。
??????? 测试中到底有什么，做好了能让利益相关者长期满意？哪些人是利益相关者，他们想从测试中获得什么？什么是让人满意的
外在的和内在的测试之美？
??????? 测试人员和测试经理如何建立长期提供较高满意度的测试团队呢？作为测试人员，我们如何在工作中为自己和利益相关者创造
出优雅、有效、高效，甚至是乐趣呢？（这就是这一章要讲的内容）
外在美（为利益相关者的目标期望建立指标和目标）：
一、我们找到了多大比例的缺陷？
衡量指标：
??????? 缺陷发现百分比（defect detection percentage,DDP）
??????? 公式1：缺陷发现百分比（DDP） = 发现的缺陷 / 目前具有的缺陷
??????????????? （若你的测试是用户验收测试和部署前的质量保证的最后一环）
??????? 公式2：用户验收测试和部署前的最后测试的缺陷发现百分比（DDP） = 测试的缺陷 / 测试的缺陷+产品的缺陷
二、我们发现了较高比例的严重缺陷吗？
??????? 公式3：发现缺陷的侧重点：DDP（所有缺陷）< DDP（严重缺陷）
??????? -----实践基于风险的测试。
三、与在正式产品中出故障的成本相比，在测试中发现和解决一个缺陷的成本是多少呢？
??????? 公式4：测试中发现的缺陷的平均成本（Average cost of a test bug,ACTB）
??????? ACTB = 发现成本+内部故障成本 / 测试的缺陷
??????? 公式5：正式产品中发现的缺陷的平均成本（Average cost of a production bug,ACPB）
??????? ACPB = 外部故障成本 / 产品的缺陷
??????? 公式6：计算测试的投资回报率（Test ROI）
??????? 测试ROI = (ACPB - ACTB) * 测试的缺陷 / 发现成本
内在美(为测试的目标期望建立指标和目标)：
一、我们已经自动化了多大比例的回归测试？
??????? 公式7：回归测试自动化的百分比（ Regression test automation percentage,RTA）
??????? RTA = 自动化回归测试 / 手动回归测试 + 自动化回归测试
??????? （测试自动化应保持或降低回归风险。所以，你应该衡量已经覆盖的有关回归的质量风险的比例。）
二、我们覆盖了多大比例有关回归的质量风险？
??????? 公式8：回归风险覆盖率（Regression risk coverage,RRC）
??????? RRC = 已覆盖的回归风险 / 识别出的回归风险
??????? （识别出的回归风险应该是指需要做回归的用例或测试点）
三、我们还能加快多少自动化回归测试？
??????? 公式9：回归测试加速比（Acceleration of regression testing,ART）
??????? ART = 手工回归测试时间 + 自动化回归测试时间 / 手工回归测试时间
??????? （自动化回归测试也应该让回归测试执行得更快。应该衡量回归测试执行的加速比）
? 第3章 创建开源的QA社区
??????????????? -------------->社区支持决定了开源项目的生死。（作者分享建设一个漂亮的测试者社区的经验）
? 第4章 协作是性能测试之美的基石
??????????????? -------------->作者解释了为什么漂亮的性能测试需要高于一切的协调能力。
??????? 性能测试通常是软件开发项目中最无奈、最复杂、最缺人手、时间最紧迫、最易被误解、最好斗以及最吃力不讨好的方面，
但它并不必要如此。
系统性能测试要求：
*性能测试将在多种负载和使用模型下进行，具体负载和使用模型将在系统功能和工作流程建立时确定。
*对于任何内部版本，凡是出现性能测量结果超出以下数据的，必须报告开发组长：
在任意数量的用户条件下，有超过5%的情况加载网页的时间超过5秒；
在任意数量的用户条件下，有超过1%的情况加载网页的时间超过8秒；
超过2%的情况，课程无法完整或正确下载；
在任意数量的用户条件下，有超过5%的情况课程下载所需的时间超过60秒；
在当前最高负荷情况下运转时，系统可以持续1个小时保证95%的网页在5秒或更短时间内加载完毕，9%的课程在60秒或更短的时间
内完全正确下载。
*外部版本将附有性能测试报告，包括：
在任意数量的用户条件下，有超过5%的情况加载时间超过5秒的那些网页；
在任意数量的用户条件下，有超过1%的情况加载时间超过8秒的那些网页；
超过2%的情况无法完全或正确下载的课程；
在任意数量的用户条件下，有超过5%的情况下载所需时间超过60秒的那些课程；
在当前最高负荷情况下运转时，系统可以持续1个小时保证95%的网页在5秒或更短时间内加载完毕，95%的课程在60秒或更短的
时间内完全正确下载；
*项目经理可根据客户、开发团队、性能测试组长的请求或建议，添加其他有益于项目的性能测试。
值得思考的问题：
从承诺达到一定水平的性能，转变为承诺报告在什么样的条件下性能目标将无法实现；
明确指出在获取足够的资料前，无法完全确定具体性能测试细节；
打开性能测试的思路，以支持开发流程，但这些并不直接以性能目标作为评估依据；
性能测试用例：如何写性能测试的用例
性能测试检查点：
??????? 收集系统性能指标基准，并验证系统使用模型中包括的每个功能任务，在一个用户的负荷下，在每一个包含该功能任务的性能
测试构造中，都达到性能需求；
??????? 收集系统性能指标，并验证系统使用模型中包括的每个功能任务，在10个用户的负荷下，在每一个包含该功能任务的性能测试
构造中，都达到性能需求；
??????? 收集系统性能指标，并验证系统使用模型，在以下负荷程度的性能要求下，在每一个实现了该使用模型的性能测试构造中，都
达到性能需求；
??????? 收集系统性能指标，并验证系统使用模型，在开发组长、性能测试人员以及项目经理认为恰当的构造上，通过为期9小时、负荷
为1000个用户的压力测试的性能要求；
对于性能测试人员来说，没有几件事能比呼叫中心代表对你测试的应用程序十分满意更美妙了。
第二部分? 过程之美
作者向我们展示了测试小组做了什么，更重要的是，向我们展示了为什么要做这些。
? 第5章? 用模糊测试让办公软件更可靠
??????????????? ------------>办公套件之美在于隐藏其复杂性。模糊测试即是同一类型的测试技术。
??????? 什么是模糊测试？? 模糊测试是通过对输入数据进行随机修改和破坏来测试程序的方法。虽然这一技术已存在至少20年，但由于
安全测试的日益重视和模糊测试专用工具的增多，它在近十年变得更加盛行。一个程序的模糊化可以是手工或自动化的，但伴以
自动化和测试日志，这一技术会最有效。
??????? 为什么要模糊测试？? 模糊测试为测试人员和编程人员在开发办公软件时面临的棘手问题提供多种优美的解决方案。
??????? 模糊测试的长处之一就是用自动的方式帮助模拟很多这样的场景，把对互操作性允许的无数可能情况的处理变得简单。
常规模糊：构造普通/通用的输入；
自定义模糊：构造某一种类型的输入；
随机模糊：使用没有结构的不规则输入；
???????????
? 第6章? 缺陷管理和测试用例的有效性
??????????????? ------------>作者相信跟踪测试用例和漏洞是很美妙的过程，他们通过OpenSolaris中的经验来阐述这一点。
一、缺陷管理
? 第一个被发现的缺陷
缺陷的两项重要的细节：
??????? 一、该缺陷与一个测试过程紧密关联（即发现这个缺陷的测试过程）；
??????? 说明：包括了缺陷描述、发现缺陷的用例，缺陷重现条件，缺陷出现时的日志记录等等（缺陷对应用例、对应需求项、对应模块
??????????????????? 及代码）。
???????? 二、当根本原因被发现后，一份详细的附件辅助解释了该原因。一段泛黄的玻璃纸胶带仍将两英寸大小的蛾子尸体附在该缺陷
???????????????? 报告的边缘！
??????? 说明：附件--用来阐述缺陷出现的根本原因（如果测试人员能够找到的话），以便让开发人员明白缺陷的具体情况。
管理缺陷的第一步是定义缺陷：
??????? 一个美丽的缺陷跟踪系统，应该是最终用户、技术支持人员、开发和质量保证工程师之间的信息渠道。它应该帮助这些人在缺陷
的解决方案中合作。为了做到这一点，缺陷跟踪系统应该维护关键的信息，并阻止不必要或不正确的信息。一个缺陷的重要方面可以
被归结为侦探调查案件时提问的那几个种类：时间、地点、人物、事件，以及原因。
人物：
??????? 缺陷报告是缺陷的发现者和修复缺陷的专业人士之间的一个沟通渠道。
??????? 所有的缺陷跟踪系统都需要跟踪的有：谁报告了该缺陷，谁修复了该缺陷，以及谁验证了已被修复的缺陷。
事件：
??????? 一个美丽的缺陷报告应以一个简要说明开始，介绍缺陷的症状，以及重现缺陷必要的条件。它通常至少包括以下内容：
a)说明：对缺陷的简要说明。
b)详细说明：这里应该包含足够的细节，以便他人重现缺陷。例如：
* 软件版本（代码库）
* 操作系统环境
* 硬件
* 其他先决条件
* 重现的测试用例（测试人员这样做时，期待某事发生但却发生了其他预料不到的事情）
[注意：要将缺陷与其测试用例关联起来！！]
c)优先级：根据已公布的缺陷政策，该缺陷有多重要。（P1～P5）
d)严重度：该缺陷有什么影响？这可能与缺陷的优先级有关，但并不完全是一回事。
时间：
??????? 同样的工具和流程被用于在整个产品生命周期中跟踪缺陷。然而，“典型的缺陷”的粒度却随着产品生命周期而变化。例如，
单元级别的缺陷在产品开发的早期发现，通常可以直接追溯到缺陷所在的源代码。
??????? 修复一个在产品生命周期较晚时候发现的缺陷比产品发布前发现的缺陷更加昂贵。
地点：
??????? 缺陷在哪里？? 软件缺陷都与独特的软件部件组合形成的系统相联系。
??????? 一个精美简单的缺陷跟踪系统可以围绕如下假设设计：可执行对象代码中的每个缺陷都可以追溯到某几行源代码。
??????? 每个缺陷和包含该缺陷的源代码之间有明确的一对一关系。
标签：
??????? 如果用户在上游或分发数据库中发现与他的问题（缺陷或元缺陷）特别相关的缺陷，他可以为这些缺陷加上标签，使它们能够
通过“标签云”或“标签集”来一起跟踪。
注：按照标签来对缺陷分类。
??????? 标记过的缺陷集（标签云）：原因
??????? 缺陷报告常常包含多个描述理论上可能的根本原因的假说。但是，当一个缺陷关闭以后，经验证过的根本原因应该强调出来。
一个关闭了的缺陷应参考以下内容：
* 缺陷所在的代码库
* 假设的根本原因
* 修复的说明或源代码补丁的链接
* 一个能证明该缺陷的根本原因的确已经修复的测试用例
二、测试用例的有效性
??????? 软件测试的美有时确实很难看出。软件质量保证不像软件开发的其他方面那样具有表面上的魅力，这可能就是它缺乏尊重和资金
的原因。
??????? 什么是测试用例有效性（Test-Case Effectiveness, TCE）的度量？? TCE是一种衡量测试用例有效性的方法。测试软件时，总有
若干作为副作用的缺陷被发现。所谓“副作用缺陷（side-effect defect）”，是指在测试过程中发现的，但却不是写好的测试用例中
断言失败的直接结果。
??????? 基本原理是，这些副作用缺陷没有明确被现有的QA测试用例所覆盖，所以必须检查触发这些缺陷所需要的条件。然后可以开发
新的测试用例，并在后面的测试周期中执行它们。
??????? 由于TCE衡量的是QA测试用例相对于其他手段确定缺陷的成效如何，它可以用来随着时间的推移跟踪测试覆盖率。
??????? 公式：TCE = (Nt / Ntot) * 100%
??????? Nt：是QA发现的缺陷的总数；Ntot是所有发现的缺陷的数量（NT）和测试逃逸（Bug with out test for QA）的和。
??????? 测试逃逸（test escape）是指在正常的QA测试周期之外发现的缺陷。完全覆盖、没有测试逃逸的情况下
??????? TCE= 1.00（100%），所以这个值越高越好。
??????? 我们的目标是用更加有效的测试用例尽可能地减少测试逃逸，以提高TCE。
抓住缺陷严重度的影响：
??????? 为了反映质量保证和测试逃逸发现的缺陷严重程度的高低，可以使用加权的TCE，以每个缺陷的优先级为权重。缺陷的优先级
是分配给该缺陷的表明修复它的相对重要性的权重。
分析测试逃逸缺陷：
为了分析测试逃逸缺陷，将缺陷分为以下几个原因类别：
* 误报的缺陷
* 不完整的测试用例
* 没有测试用例
* 测试执行问题
* 不正确的测试用例
* 不正确的功能规范（当有功能规范实际存在时）
确定测试逃逸的纠正行动，如下表中列出：
-------------------------------------------------------------------------------------------------------
原因??????????????????????? 纠正行动
误报的缺陷??????????????? 将缺陷移至正确的状态。需要强调提交缺陷指南并教育缺陷的提交者如何正确提交缺陷。
不完整的测试用例????????? 审查测试用例的目标功能区域。加强并重新设计测试用例。
没有测试用例????????????? 基于导致缺陷的功能实现测试用例。
测试执行问题????????????? 审查的过程步骤或依赖的硬件/软件。
不正确的测试用例????????? 审查正在测试的功能。测试用例编写之后，它是否已经有了改变？
不正确的功能规范????????? 联系设计/开发人员。检查功能规范审查流程。它是不是太模糊了？
--------------------------------------------------------------------------------------------------------
通过确定测试逃逸来分析测试用例的有效性（测试用例有效性趋势）。
注：
实际应用（给我的启发）：
??????? 银行网上银行的测试任务中，经常会有其他分行（也有客户直接电话过来投诉的）报过来的问题（缺陷）。实际上，这些问题都没有在测试中心
的项目测试阶段被发现，其实这些被用户发现的问题（缺陷）就属于测试逃逸。事实上，测试中心通常并没有对这些测试逃逸进行分析。（而这些测试
逃逸在某些时候，也会搞得我们焦头烂额，忙得不可开交）。基于此，我们就可以借鉴上述（本章）介绍的方法来对项目的测试用例进行有效性分析。
进而，提高用例的有效性，进一步减少测试逃逸的发生。如果想要从根本上解决测试逃逸（提高用例质量！！），这种方式显得很重要。
? 第7章? 漂亮的XMPP测试
??????????????? ------------>作者解释了XMPP协议是如何被测试的，并描述了它们从丑陋到美丽的演变。
协议的测试，即协议怎么进行测试？
? 第8章? 大规模测试自动化之美
??????????????? ------------>作者基于在微软工作的经验（对大规模测试自动化），分享了一些可以使之美丽的秘密。
??????? 自动化测试不仅仅是简单地编写和运行那些不需要人为干预的测试用例。
什么是大规模测试自动化：
??????? 系统必须在每一步（从测试的编写完成的那一刻到得到结果的那一点）都必须被完全自动化。
测试自动化系统基础：
??????? 一个最基本的漂亮的自动化系统可以提高端对端的效率。
一个基本的自动化测试工作流（自动化测试生命周期的流程）：
??????? 编写自动化测试-->选择测试和测试平台-->运行测试-->收集用于报告的测试结果-->报告新的bug/解决已经修复的bug
测试分配流程图：
自动失败分析：
大规模测试自动化：
? 第9章? 美比丑好
??????????????? ------------>作者指出，对于编程语言来说美丽的一部分是稳定的，但要达到这个目标需要一些完美的测试
??????? 更先进的技术：参考泄漏检测，自动连续的构建，运用动态分析工具Valgrind，与静态分析工具Coverity或Klocwork来补充
标准测试。
引用泄漏（refleak）测试(特定类型的内存泄漏)
动态分析：
??????? Valgrind是一个动态的分析工具。这意味着它能在应用程序运行同时分析程序。
??????? memcheck工具，即Valgrind的一部分，能检测内存泄漏和错误，包括无效的内存读取和写入。动态分析工具的能力是非常
强大的，因为它可以探测到很难发现的问题。例如，某个内存访问在100万次中只发生一次，并不总是导致明显的问题。这样的
问题用Valgrind可以不费力就能捕捉到。
??????? Python使用动态工具减少内存泄漏数量。内存泄漏对应用程序是非常不利的，因为利用它们可以制造一个拒绝服务。
??????? Fusil是一个模糊测试工具，它调用公共函数时根据接口的限制使用半随机的参数（也属于动态分析工具）。
静态分析：
??????? 静态分析是一种技术，它使用程序来对源代码进行分析，以找到潜在的问题。类似于一个自动的代码审查。
??????? 静态分析工具：Coverity和Klocwork。
? 第10章 测试随机数发生器
??????????????? ------------>作者将一种基于复杂性和完整性的经典美运用到随机数发生器的测试中去。
根据美的古典定义：能同时展现复杂性和统一性的事物是美的。
什么使随机数发生器的测试这么微妙
均匀随机数发生器
非均匀随机数发生器
逐级的测试:值域测试、平均值测试、方差测试、水桶测试、柯尔莫戈罗夫-斯米尔诺夫(Kolmogorov-Smirnov)测试
在测试随机数生成器中的几个统一原则：
* 测试归纳为指明一些统计数据应经常位于某个范围之内。你期望的“经常”越苛刻，你的范围一定会越广。
* 非均匀RNG转换了均匀RNG的输出。如果你对你的非均匀RNG有信心，那么你只需要测试非均匀RNG的分布属性。继承自均匀
?? RNG的更微妙的随机属性不需要很仔细的测试。
* 对随机序列的精确分析要求更进一步的统计，此外通过下面这个简单的观察我们还能走得更远：一个正态分布的取样经常位于其
?? 均值的两倍或三倍标准差之间。
* 我们不必过于关注测试通过率。一个正确的发生器通常会通过测试，而一个有问题的生成器则通常测试失败。
? 第11章 以变化为中心的测试
?????????????? ------------>作者认为没有变化的测试代码既不是有效的也不是美丽的，然而以变化为中心的测试却是。
??????? 测试的美不在于你付出了多少努力，而在于测试是否有效。知道要测试什么是一种美，知道正在测试什么是一种美。
如何建立由文档驱动的、以变化为中心的测试框架
新项目可以相当轻松地建立以文档驱动的、以变化为中心的测试过程
复杂代码开发模式中以变化为中心的测试
以变化为中心的测试的步骤：
1.了解可执行程序里功能/方法中调用者与被调用者之间的依赖关系。
2.了解源代码文件与测试用例之间的对应关系及其代码覆盖率。
了解调用、被调用的依赖关系和测试用例与源代码文件之间的映射关系
从可执行程序中生成调用与被调用关系图
结论：
? ?? ?? 以变化为中心的测试并不是一项难以完成的任务。一旦很好地了解了现在的测试套件所提供的覆盖范围、可执行文件依赖关系
的调用图，以及给定时间区域源代码所作改动的细节，那么生成能够测试代码改动的动态测试清单就只是一项简单的工作。
? 第12章 软件以用为本
??????????????? ------------>作者分享了她如何测试一个医疗软件，该软件对她工作之余的生活产生了深刻影响。
??????? 探索性测试：“探索性测试”最平白的定义是同时进行测试设计和执行。
??????? 探索性测试探求的是软件在实际环境中如何工作，如何处理复杂和简单状况。测试依赖于测试人员创造测试用例和发现缺陷的
能力。
??????? 测试人员对产品和测试方法的了解越深入，测试质量越有保证。
??????? 随机测试：随机测试通常指即兴的缺陷发现过程。从定义上理解，任何人都可以做随机测试。
??????? 脚本测试：
多用户测试：
??????? 多用户测试与性能测试本身不同。性能测试通常首要侧重于处理事务的时间性。在多用户测试用例中，我们的目标不是时间，
而是测试多用户同时执行特定任务会发生的情况。总体来讲，多用户测试思路是为了防止数据损坏、记录冲突、重复记录或系统
崩溃。
? 第13章 软件开发是创新过程
?????????? ------------>作者在进入测试领域之前是一名音乐家。然而这并不奇怪，作者认为测试之美更多地在于爵士乐队而不是制造工厂
敏捷测试（Agile Testing）
? 第14章 测试驱动开发：驾驭美之新标准
??????????? ------------>作者展示了在软件项目里TDD是如何充当软件之美的催化剂的。
敏捷：新的比例与平衡
??????? 极限编程（eXtreme Programming，XP）敏捷方法的创造者们相信如果一件事情值得去做，就应该及早并且尽心尽力地完成
它。表面上看XP似曾相识，因为它包含着实践的标准集合。实际上所有实践都发生了改变。促使XP发生一系列改变的关键因素
有两个：小型发布和测试驱动开发。
测试驱动开发：
表格1 简要说明了TDDde红-绿-重构循环
图1 TDD 三角
图2 面向易读的说明
图6 XP递增的和演化的生命周期
? 第15章 完美测试是商业成功的基石
??????????????? ------------>作者讨论了测试团队是如何致力于测试之美的，以及它是如何变成企业成功的重要驱动的。
??????? 人们试图用各种各样的方法去量化测试。那么“质量”呢？我想大部分人们应该不会把“美丽”和“测试”用在一起造句吧。但是对于
我来说，测试之美就美在我们的团队对“质量”有着绝对的使命感，做“对”的事情，并把事情做“对”。
??????? 测试是整个软件开发中一个完整的部分，价值和作用等同于代码编写。团队里的每个人都投身于寻找创造更高品质软件的可能
性，这意味着团队中的每一个成员都享受着测试之美。
图1? 思维导图（测试之美-测试驱动商业的成功）
图4 敏捷测试象限
? 第16章 剥析Socialtext的测试
??????????????? ------------>作者在许多不同的公司工作过，作者认为的测试之美。
? 第17章 高效测试之美
??????????????? ------------>漂亮的测试只需要最少的重复测试。作者分享了减少重复测试的三种技巧。
三种进行高效测试的方法：SLIME、脚本、思维导图
SLIME(Security,Language,requirements,Measurement,Existing,安全、语言、必要性、度量、一致性)是一种测试顺序。
安全
互联网应用程序中的安全测试维度：
＊跨站脚本（Cross-site scripting）：
??????? 当进行跨站脚本的测试时，我首先会寻找所有客户端往Web端应用程序提交数据的那些接口。永远不要相信客户端对服务器
提交的数据。在进行数据库操作和处理服务器端指令之前，所有提交的数据必须在服务器端进行校验。尽量使用编码去解析提交的
数据。这些情况下，你需要在服务器端动态生成HTML、JavaScript、CSS等文件，这时候你最好使用白名单而非黑名单来过滤
内容，因为允许什么东西能被记录永远比禁止什么东西能被记录安全得多。
＊SQL注入：
??????? SQL注入也是一种由客户端信任所产生的问题。直接将用户所提供的原始数据对服务器端数据库进行操作是一个致命的错误。
我通常会通过两种方法解决这个问题：
其一是手动将前端操作会调用到的数据库操作全部用代码来实现，这样可以避免用户在客户端提交到服务器并生成数据库操作语句；
其二是用脚本对所有的数据库操作语句中的非法文字进行过滤。
事实上SQL注入已经有了一个众所周知的解决办法：参数化SQL语句或强制转义。
因此代码上的检测是一个避免此类问题的高效测试方法。
＊越权访问：
??????? 当一个用户被授予某个安全权限的时候，他是否可以进行相应的操作？如果可以，他是否只被允许这一安全级别的操作？
＊信息泄露：
??????? 是否用户可以访问、查看、修改他并没有被授权的数据? 设想一个多租户（Multi-tenant）系统，可口可乐和百事可乐公司都是
这一系统的客户。显然，可口可乐公司的员工不应该允许查看百事可乐公司的企业信息，反之亦然。
注：真的只有这四点吗？我们可以参考OWASP组织提供的TOP10
语言
??????? 第二个测试的重点是对语言支持进行测试。总结当时的经验，我认为语言测试最好能在对产品进行第一轮测试的时候就应该被
关注起来。成功的语言测试需要符合以下条件：
1. 允许用户输入任何语言的字符；
2. 能够存储这些字符；
3. 内部处理这些字符；
4. 检索这些字符；
5. 显示这些字符；
注：需要掌握Unicode和字符集的知识；
必要性
??????? 必要性测试是指那些新增加的、之前从来没有测试过的部分。如果你的产品在新版本中要增加一个新的功能--“密码重置”，
那么这就是必须要测试的部分。而不是对那些已经存在的与密码相关的代码进行测试。通常开发小组都是比较小心的，他们都会
测试那些新代码，并开发一系列的单元测试来避免因为他们新增加的代码导致产品其他部分出现问题。当我们在这一环节忽略那些
对于新增功能进行的回归测试时，开发人员的敬业至少可以让我们感觉稍微好一些。在任何情况下，修改一段代码总会有引入问题
的可能，或者暴露一个以前所潜在的问题。特别是当这一改变是设计一个新产品功能的时候，问题出现的概率将大大增加。
度量
??????? 在度量测试方面有许多的优秀的分类方法，我的定义是：
Load（负载）：
??????? 持续使用受限的资源（CPU、内存、网络带宽等）直至系统瘫痪的问题出现。接着修复这一瘫痪的问题并反复使用受限资源
进行系统初始化。直到产品能稳定地在受限的资源下正常运行。
Performance（性能）：
??????? 这是一组数据参数，通常可以描述为“每Y时段内进行X次操作”。例如，每分钟可以进行多少次认证操作。
Stress（压力）：
??????? 压力测试需要衡量一个系统在一段特定的时间内如何进行大量的负载增加、退出等操作。
Scalability（可伸缩性）：
??????? 若系统中的资源得到提升，或者增加一些新的资源，是否可以使得系统的性能得到相应的提升？
一致性
??????? 是对于系统现存的所有功能和行为进行测试。
脚本
??????? 当提及脚本的时候，大多数的测试人员会想起诸如QuickTest Pro或者Selenium等测试工具。尽管这些工具在各自的领域确实
会给予测试者一定的帮助，但是为了提高测试的效率，它们还是不能和Python、Ruby或Perl等脚本语言相提并论。
寻找开发人员的注释
图案化文字
测试准则和测试数据生成
??????? 我结合了测试准则和生成测试数据这两种方法。在前端，我通过一段Selenium RC脚本从数据库中生成合格的测试数据继而进行
UI自动化测试。最后通过测试准则脚本来验证系统后端生成的数据是否正确。
思维导图
??????? 我注意到那些我所钦佩的顶尖测试人员拥有一个共同的习惯：为自己的事情记下笔记并且使用“思维导图（mindmap）”。思维
导图很快成为了我高效测试的秘密武器。
??????? 思维导图是一个进行头脑风暴的思维整理工具。将一个最原始的想法放在图的中央，然后分支处很多新的想法。越是与中央距离
远的想法就越具体。它和传统的测试思维生成方法所不同的是，传统的方法通常会按照等级来生成新的想法。后者的最大问题在于，
