测试基础总结

第一到三章 

1.软件测试的基本要素

1）UI

2）功能

3）性能

4）安全

5）易用

6）兼容

1. 为什么要评审需求文档

答：需求文档是一个文字描述性文档，正如一千个人眼里有一千个哈姆雷特，如果开发人员对需求文档的理解出现了偏差，那做出来的成果一定不是产品人员想要的；如果测试人员把需求文档理解偏差了，那么设计出来的测试计划和测试用例也是错误的，那么测试人员按照错误的标准去测试软件，结果可想而知。

所以不能想当然的去理解它，对于有疑问的地方要让产品人员解释清楚。最终消除歧义，达成公式，完善需求细节，最终形成一个标准的统一的软件需求规格说明书。

1. 如何评审需求文档

1）正确性

2）明确性

3）完整性

4）限制性

5）优先级

6）一致性

 

1. 面试常见问题。

1）测试工作从什么时候开始？

2）需求评审的目的是什么？

3）如何评审需求文档？

 

总结：对于需求文档的WHY和HOW

 

第五章-软件测试计划

 

1. 范围
2. 环境（软件：操作系统、浏览器、分辨率； 硬件：CPU，内存）
3. 策略

 

1）测试依据

 

a) 需求文档

 

b) 测试用例

 

2）测试的准入标准（冒烟测试）

 

3）准出标准

 

4）测试工具（BUG管理工具）

 

5）测试重点以及方法

 

a) 重点模块

 

b) 优先级

 

c) 黑白盒测试

 

1. 管理

 

1）测试任务的分配

 

2）时间进度的安排

 

3）沟通方式

 

1. 风险

 

1）理解

 

2）执行

 

3）时间预估不足

 

4）其他

 

1. 面试常见问题

 

1）软件测试计划模板应该包括

 

a) 文档标识

 

b) 测试目的

 

c) 范围、环境、策略、管理、风险

第六章-测试用例的设计

 

6.1测试用例的格式

 

1.序号

 

2.模块

 

3.前置条件

 

4.环境

 

5.步骤与数据

 

6.预期结果

 

7.实际结果

 

8.是否通过

 

9.备注

 

6.3功能测试的用例设计方法

 

1.等价类划分法

 

2.边界值分析法

 

3.错误推断法

 

4.正交表分析

 

5.场景法

 

6.因果图判定表

 

6.5测试用例的评审工作

 

1. 是否依据需求文档来写
2. 步骤是否清晰、简洁；重复度的是否进行了简化
3. 测试用例是否有明确的预期结果
4. 是否存在冗余用例
5. 是否覆盖了所有功能点

6.6用例设计的结束标准（评审-修改-维护）

6.9面试的常见问题

1. 测试用例的格式中包含哪些元素？
2. 如何设计测试用例？（需求文档、经验、参考、网络）
3. 测试用例是如何评审的？
4. 如何保证测试用例的质量？
5. 没有需求文档，如何开展工作？（建立需求文档、寻助测试经理和开发人员、工作经历和测试文档）

 

第七章-测试环境的搭建

7.3面试常见问题

1. 测试环境是如何搭建的
2. 与开发人员共用一套环境吗？
3. 做前台还是后台测试？（前台-UI,功能 后台-接口）
4. 网页的兼容性测试是怎么做的？（浏览器、分辨率）

 

 

总结-关于评审：

如何设计测试用例或者提出一个高质量的测试用例（测试计划、BUG）或者如何评审一个测试用例都可以从测试用例（测试计划、BUG）的格式来描述。

 

评审需求文档要从正明完限优一性；

测试用例的评审要附加一条：是否覆盖了所有功能点；

测试计划不用评审。

第八章-软件测试报告

8.1软件测试报告的定义

1. 测试过程（时间、地点、人物、版本）
2. 测试环境（操作系统、浏览器、分辨率）
3. 功能点测试范围（模块-功能点-是否通过）
4. BUG数量汇总以及分布情况（BUG数量汇总：致命、严重、一般、轻微、建议、总数； BUG分布情况：模块、数目；）
5. 系统存在的风险
6. 测试结论（是否可上线）
7. 附件清单
8. （实际测试报告还要加上）编写目的以及模块功能描述

8.3 面试常见问题

1.一份测试报告都包括哪些内容？

2.软件测试结束的标准?(

1）完成测试计划中的所有工作

2）执行了所有测试用例

3）95%BUG都关闭并且没有严重以及严重以上等级的BUG

4）回归测试全部执行完毕，没有发现影响产品上线的BUG、软件具备上线标准

5）每个测试人员所负责测试报告已完成，并提交给了测试经理。

3.软件的测试流程是怎样的？

1）需求评审

2）测试计划制定

3）测试用例设计

4）用例评审

5）环境搭建

6）测试执行（提交BUG、回归测试）

7）写测试报告

4.软件测试遵循原则。（80/20原则）

 

第八章-测试执行

 

9.1如何记录一个BUG（记录一个BUG的格式）

 

1. BUG编号
2. 软件名称和版本号
3. 测试环境
4. BUG等级（致命、严重、普通、轻微、建议）
5. 概要
6. 具体描述
7. 优先级
8. 提交人
9. 发现时间
10. 处理人
11. 附件
12. 状态
13. 备注

 

 

 

9.5回归测试的策略

 

1. 重要或者常用的功能点、与BUG相关联的功能点
2. 时间充足的情况下选择性的测试

 

 

 

9.6面试常见问题

 

1. 一个完整的BUG的应该包括什么元素？
2. BUG一般有几种状态？（激活、解决、关闭）
3. BUG的处理流程（激活、解决、关闭或者回归-关闭）
4. 如何提一个高质量的BUG？（环境、摘要、具体描述、优先级、附件。从BUG的元素来说）
5. 发现一个测试用例中没有提到的BUG怎么办？（写入测试用例，提交测试经理、共享BUG）
6. BUG难以重现怎么办？（截图、尽量重现、留意与观察、反映给测试经理）
7. 用什么测试管理工具，有什么模块？(禅道；需求管理、测试计划管理、测试执行管理、缺陷跟踪管理）
8. 禅道是如何搭建的？
9. 一个软件要测试多长时间？（三到五轮不等。也会受到需求规模、测试人员、测试技术、软件质量等因素的影响，根据实际情况而定。）
10. 回归测试的策略。