静态测试与测试计划
文章目录
1 静态测试
第二种“包括”：
对软件产品的需求和设计规格说明书的评审、 对程序代码的审查以及静态分析等。
将需求和设计的评审 纳入测试的范畴，可看作是广义测试。
2 评审
2.1 what
评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。
2.2 why
通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。
2.3 形式
①代码检查与走查(walk-through)
②互为评审(Peer review)
③会议评审(Inspection)
2.4 分类
2.4.1 属于软件测试的部分
需求评审、设计评审、代码评审和文档评审
2.4.2 属于软件质量保证的部分：
管理评审和流程评审
3 需求测试
3.1 why
上承2.4.1，其中，需求的测试是重点。如图
3.2 需求中可能存在的问题
• 需求文档编写有问题、功能不明确，流程不清晰， 不正确占50%
• 余下50%是需求的遗漏造成的
3.3 需求文档检查要点
写在前面：
应当对所有的需求要点分配优先级。如果把所有的需求都看作同样的重要， 那么项目管理者在开发或节省预算或调度中就丧失控制*度。
3.3.1 完整性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能 所需的所有必要信息。
3.3.2 正确性
每一项需求都必须准确地陈述其要开发的功 能。
3.3.3 一致性
一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。
3.3.4 可行性
每一项需求都必须是在已知系统和环境的权能 和限制范围内可以实施的。
3.3.5 无二义型
对所有需求说明，读者都只能有一个明确统一的 解释，由于自然语言极易导致二义性，所以尽量 把每项需求用简洁明了的用户性的语言表达出来。
3.3.6 健壮性
需求的说明中是否对可能出现的异常进行了分析， 并且对这些异常进行了容错处理。
3.3.7 必要性
“必要性”可以理解为每项需求都是用来授权你 编写文档的“根源”。要使每项需求都能回溯至 某项客户的输入，如Use Case或别的来源。
3.3.8 可测试性
每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
3.3.9 可修改性(?)
每一项需求都必须准确地陈述其要开发的功能。
3.3.10 可跟踪性
应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项 需求以一种结构化的，粒度好( fine-grained) 的方式编写并单独标明，而不是大段大段的叙述。
3.4 需求文档检查列表
4 测试计划
4.1 测试计划何时做
对需求进行评审之后。
以下是软件测试过程
4.2 应用场景
当产品版本升级后，测试计划中的测试范围变化有哪些：
- 新增功能
- 升级测试
- 系统测试人员要使用原测试用例再测
- 基本功能