软件测试复习大纲

9.专业测试人员的责任和要求P31 优秀测试工程师的素质P33

第三章

1.黑盒方法：错误推测法P38、等价类划分法P39、边界值分析法P41、判定表方法P43、因果图法P45、正交试验法P48、两两组合法P47、功能图法P58、有限状态机P63

2.白盒方法：6种覆盖P49-53仔细看书上例题

3.根据等价类创建测试用例的步骤，详细题目见P67-2作业

a) 建立等价类表，列出所有划分出的等价类： b) 为每个等价类规定一个唯一的编号；

c) 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类 d) 重复c)，最后使得所有有效等价类均被测试用例所覆盖； e) 设计一个新的测试用例，使其只覆盖一个无效等价类。 f) 重复e)使所有无效等价类均被覆盖。 4.判定表元素，同时也是判定表的方法步骤

? 条件桩，列出问题的所有条件

? 动作桩：列出可能针对问题所采取的操作 ? 条件项：针对所列条件的具体赋值

? 动作项：列出在条件项（各种取值）组合情况下应该采取的动作。 ? 规则：任何一个条件组合的特定取值及其相应要执行的操作。 5.为什么使用正交试验法

在许多应用系统的测试工作中，不会象判断三角形那样简单，输入条件的因素很多，而且每个因素也不能简单用“是”和“否”来回答。测试组合会变得很多，如果按照传统的测试方法，会导致很大的测试工作量 6.循环测试 简单循环：完全跳过循环 ；只经过循环一次 ；经过循环两次 ；经过循环m（ m < n ）次 ；

分别经过循环n-1, n, n+1 次

嵌套循环：在最里面的循环完成前面所述的简单循环测试，同时设定外部循环的最小迭代次

数 ；逐步向外循环进行，直到所有循环被测试

串行连接的循环：独立循环? 可以分别看着简单循环测试 ；依赖性循环? 可以看着是嵌套循环

7.基于缺陷的测试，DPBT测试过程步骤P56

预处理/预编译，词法分析(Lexical Analysis) ，语法分析( Parsing) 和语义处理( Semantic Analysis) ，抽象语法树生成，控制流图生成，IP 扫描，人工确认 8.如何设计测试用例

? 功能图法设计测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两

个层次的测试用例

? 从功能逻辑模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合

? 从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径 9.基于场景的测试方法

? 基于Use case或User Story直接进行验证 ? 根据UML的序列图来进行验证

? 列出各种系统事件、观察和分析用户行为，设想各种可能的user scenario来

进行验证

? 分析同类系统和竞争对手的系统

第四章

1.敏捷宣言的原则：

① 时间：尽早和持续地交付有价值的软件来满足客户 ② 变更：欢迎需求变更——即使是在项目开发后期。要善于利用需求变更，帮助客户

获得竞争优势 ③ 周期：要不断交付可用的软件，周期从几周到几个月不等，且越短越好 ④ 协同：项目中，业务人员与开发人员必须一起工作 ⑤ 信任：要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成

任务 ⑥ 沟通：无论是团队内还是团队间，最有效的沟通方法是面对面的交谈 ⑦ 产品： 可用的软件是衡量进度的主要指标 ⑧ 速度：敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持长期稳

定的开发速度 ⑨ 追求：对技术的精益求精、对设计的不断完善将提升敏捷性 ⑩ 简单：尽可能减少不必要的工作——一门艺术 ? 团队：最佳的架构、需求和设计出自于自组织的团队 ? 自省：团队要定期反省如何能够做到更有效，并相应地调整团队的行为 2.敏捷测试的特征和流程P74 3.为什么引入探索式测试

? 开发人员多、测试人员少，测试更关注效率 ? 整个开发节奏很快，测试要跟上这个节奏 ? 测试时间很少，需要快速完成测试

? 对产品或业务不够熟悉，需要操作或使用它来熟悉

? 产品某些部分复杂，需要不断探索，才能很好地完成测试 4.ST vs ET 书P77

5.风险测试步骤

列出软件的所有功能和特性；确定每个功能出错的可能性；如果某个功能出错或欠缺某个特征，需要评估对用户使用软件产品的影响程度；根据上面两个步骤，计算风险度；根据可能出错的迹象，来修改风险度；决定测试的范围，编写测试方案 6.完整的软件测试规范是怎样的

规范目的 ，范围 ，文档结构，词汇表 ，参考信息 ，可追溯性 ，方针 ，过程/规范 ，指南 ，模板 ，检查表 ，培训 ，工具 ，参考资料等 7.制定测试规范需要考虑的内容

角色的确定，进入的准则， 输入项， 活动过程， 输出项， 验证与确认， 退出的准则，度量

第五章

1.尽早发现错误的原因

? 错误发现越早,成本越低. ? 发现问题比较容易 ? 修正问题更容易

2.为什么要进行单元测试P95，单元测试的目标P96 3.实施代码规范的原因P99 4.走查和会议审查的对比P103 5.JUnit的主要特征P119

? 测试代码与产品代码分开 ? 提供了编写测试类的框架

? 通过与Ant结合，易于集成到程序的构建过程中 ，实施增量开发 ? 源代码公开，易于二次开发 ? 可扩展性强

6.JUnit七个类核心关系图P120 7.开源的单元测试工具P129

? C/C++ 语言单元测试工具：CppTest、CppUnit、…

? Java语言单元测试工具：TestNG、PMD、Checkstyle、Findbugs、Jalopy……

? Mock Object类工具: MockObjects、Xdoclet、EasyMock、MockCreator、MockEJB、

ObjcUnit、jMock等

8.商业单元测试工具P130

? C/C++语言的单元测试工具以商业工具为主，例如Parasoft C++、PR QA?C/C++、

CompuWare DevPartner for Visual C++ BoundsChecker Suite、Panorama C++等

? 内存资源泄漏检查工具，如CompuWare BounceChecker， IBM Rational PurifyPlus等 ? 代码覆盖率检查工具，如CompuWare TrueCoverage， IBM Rational PureCoverage，

TeleLogic Logiscope等。

? 代码性能检查工具，如Logiscope和 Macabe等

9.集成测试的模式P133

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。 各自优缺点

10.三明治集成方法

采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上

11.自顶向下和自底向上的集成P133持续集成P135

第六章

1.功能测试的要点

? 功能逻辑清楚，符合使用者习惯

? 系统的各种状态按照业务流程而变化，并保持稳定 ? 每项功能符合实际要求 ? 系统的界面清晰、美观

? 菜单、按钮操作正常、灵活，能处理一些异常操作 ? 能接受正确的数据输入，对异常输入的容错处理 ? 数据的输出结果准确，格式清晰，可以保存和读取 ? 程序安装、启动正常，有相应的提示框、错误提示等 2.回归测试的目的 （回归测试的策略及方法P150）

? 所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应

新的运行环境等；

? 不影响软件原有功能的正确性。 3.一些常见的性能问题

? 启动系统、打开页面越来越慢 ? 查询数据，很长时间才显示列表 ? 网络下载速度很低

? 资源耗尽，如CPU使用率达到100%

? 资源泄漏，如内存泄漏 ，最终会导致资源耗尽 ? 资源瓶颈，如线程、GDI、DB连接等资源变得稀缺 4.并发性能测试

并发性能测试的过程也是一个负载测试过程，即逐渐增加并发虚拟用户数负载，直到系统出现性能瓶颈或者崩溃为止。

破坏性压力测试，通过不断加载的手段，快速造成系统的崩溃，让问题尽快地暴露出来

5.性能的具体指标

? 数据传输的吞吐量（Transactions）

? 数据处理效率（Transactions per second） ? 数据请求的响应时间（Response time） ? 内存和CPU使用率

? 连接时间（Connect Time）、发送时间（Sent Time）