软测笔记-索引

==================================

静态测试(Static Testing)：
评审(Review)：从非正式到非常正式，有数个阶段。
可用于文档、需求设计、数据库建立，等。

图表常常会将隐藏于文字中的问题表露出来。
一个难看的图例通常表示该设计充满bug。

基于需求设计的测试分析和设计是一种结构化评审的形式。
测试分析和设计通常可以发现很多问题。

静态测试工具：
有问题的措辞：拼写/语法检查器。
有害的代码：J-Test, Safer C, lint…
计量工具：复杂度分析器。

通用仿真系统(General Purpose System Simulator)。
性能建模/运筹学工具。
电子制表软件(Spreadsheet)。

成本评审：
对于投入的时间及人力的评审，用于改善过程。

收益评审：
有效率地将bug移除，导致进度缩短。
测试周期的缩短，测试成本的降低。
开发人员的生产力显著。
产品质量的改进，导致下阶段成本的降低。

静态测试与动态测试的异同：
相同点：寻找可识别的缺陷，当所有风险相关者都参与时会做得更好，节约钱和时间。
不同点：不同的技术可以有效地寻找不同的缺陷的。
静态测试寻找缺陷而不是系统运行时候的失效情况。

==================================

评审的种类：
非正式评审(Informal)：没有实际的过程，大众化、便宜、实用。
同行评审(Peer)：有同行、有经验的专家参与移除文档记录的缺陷，没有经理级别人员参与。
走查(Walkthrough)：程序员、架构师集中讨论、评审代码。
视察(Inspection)：由第三方的专业审查组，对项目过程进行正式的评审工作。

确实的需求说明背后可能隐含了不完全的意义与歧义。
评审时，需要与需求所描述的内容保持一致。

评审过程：
计划、动员(Kick-off)、准备、评审会议、缺陷修复、跟踪。

角色与职责：
主持人(Moderator)：主持评审会议。
记录员(Scribe)/秘书(Secretary)：记录所发现的缺陷、问题。
作者(Author)：描述、解释、回答缺陷、问题。
评审人员(Reviewer/inspector)：寻找缺陷。
经理(Manager)：计划、分配资源、培训、支持、评审过程中的数据。

需求设计中常见的bug：
有歧义的(Ambiguity)：含糊不清的语句、观点。
不完整的(Incompleteness)：对于接下来的内容未描述。
不可被测试的(Untestability)：所描述的部分不可被检查、测试。
过度复杂(Complexity)：寻找丑陋的图例和难以理解的需求。

==================================

静态分析(Static Analysis)：
寻找软件源代码、模型中的缺陷。
静态分析不需要真正地运行系统。
必需借助工具来分析系统及其组件。
可以发现动态测试中发现不了的缺陷。

评审对象：
程序代码，包括控制流、数据流。
程序模型，静态输出(如HTML，XML)，需求设计文档，等。

静态分析的优势：
尽可能早地发现缺陷，节省成本。
标注动态测试会遗漏的bug存在的位置。
发现软件模型中的矛盾和相互关联的问题。
发现导致系统有害及高复杂度的缺陷，提出警告。
改进代码和设计的可维护性。
从分析中获得教训，防止缺陷的产生。

静态分析中bug的类型：
引用了一个未定义值的变量。
模块/组件间存在不稳定的接口。
未使用到的可变因素。
代码中存在不可能覆盖的语句。
违反程序标准。
安全性不足，存在易被攻击的弱点。
代码和模型不符合规范。

使用静态分析工具：
使用者包括单元测试和集成测试期间的程序员、设计阶段的设计师和架构师。
在最初被引入到一个已存在系统的时候，分析工具通常会产生大量的警告信息。
编译器可以做一些静态分析，但通常我们会用到一些更为精密的分析工具。

==================================

这一章好少啊，泪流满面…… T T

请允许我下一篇跳过4、5，先6吧……