1.1.2 应知应会

1.关于软件测试

（1）软件测试概述

软件测试是什么？软件测试就是对项目开发过程的产品（编码、文档等）进行差错审查，保证其质量的一种过程。

软件业的迅猛发展也就是近几十年的过程，时间虽短，但许多误解似乎已根深蒂固，对测试的偏见也是如此。“软件的重点在于需求、在于分析、在于设计、在于开发，而测试容易，没什么技术含量，找一些用户，对照需求尽力去测就行了；有时间多测，没时间就少测。”这种看法在许多项目经理、软件负责人的心中固守着，难以改变。

这种观念的结果有目共睹，是什么？很简单，是大量软件Bug、缺陷的“流失”，从测试人员手中悄然而过，流失到用户手中，流失到项目维护阶段。随之而来的，便是用户无休止的抱怨、维护人员无休止的“救火”、维护成本无休止的增加。这是软件人员的梦魇！噩梦总有醒来时，经过无数教训的重击，在不堪回首而不得不回首的经历中，软件业的管理者发现：是他们错了，软件测试是不可忽视的。

“所有这些问题，假如在项目中测试到，便不会有造成不可收拾的结果了。”——人们终于意识到测试简单而纯真的真谛。

软件测试从直观上来讲是对测试对象进行检查、验证，似乎很简单，但实际不然，它是由许多处理环节构成的。根据测试目标、质量控制的要求，它被划分为以下各类环节，并被设置了不同的准入、准出标准。

（2）软件测试原则

① 尽早和持续不断的测试；

② 彻底完全的测试是不可能的；

③ 软件测试是有风险的行为；

④ 并非所有的软件错误都能修复；

⑤ 反向思维逻辑；

⑥ 由小到大的测试范围；

⑦ 避免测试自己的项目；

⑧ 从用户需求入手。

（3）为什么不能完全测试

① 测试数据输入量太大；

② 输出结果太多；

③ 软件的操作步骤太多；

④ 软件说明书并非“盲人手册”。

（4）并非所有的错误都能修复，Bug不能被关闭的原因

① 不算真正的软件错误；

② 没有足够的时间；

③ 修复的风险太大；

④ 不值得修复。

（5）错误集中发生现象

① 软件开发人员的疲劳，造成大量代码坏块；

② 程序人员往往会犯同样的错误，因为大部分代码都是复制、粘贴而来；

③ 软件的基础构架问题，有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了；

④ 发现缺陷的时间越早，Bug所造成的损失会越小。

（6）避免检查自己的代码的原因

① 程序员从来都不会承认自己写的程序有错误；

② 程序员的测试思路有明显的局限性；

③ 多数程序员没有经过严格正规的职业训练；

④ 程序员无良好的Bug跟踪和回归测试经验。

2.测试过程

测试过程应该建立测试案例，并按严格的流程来进行，如图1-23所示是一个测试案例的使用流程，是严格意义上的测试过程。

正常的测试案例使用方式如图1-23所示，测试设计阶段，相关测试设计人员会对测试对象进行了解、分析，为保证测试顺利进行，保证测试覆盖尽量多的测试对象，会设计测试案例、测试方案，在测试期间进行使用；测试发现错误时，软件技术人员会根据测试的缺陷反馈结果及技术人员的软件修改信息对测试程序进行修改，完毕后再进行回归测试。

但是由于软件测试这个行业本身就兴起较晚，现在仍然处于比较不规范且存在很多问题尚未解决的阶段。传统的测试过程，测试管理不严密，测试人员未建立完整的测试库，未将测试案例、测试程序、测试方案进行有效保存，等到回归测试时，相关测试程序等往往已不知去向，无处可寻了；即使能找到这些程序、案例，可往往因为回归测试过于频繁、项目期限日益迫近，已经没有时间来修改、完善这些程序及案例，只能凭借经验、记忆及技术人员的口述对程序修改过的地方草草重测一遍而已，缺乏正规化的测试过程，造成测试的虎头蛇尾。

3.关于测试计划

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法（最好是能先评审）。

做好测试计划工作的关键是什么？

（1）明确测试的目标，增强测试计划的实用性

编写软件测试计划的重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具具有较高的实用性，便于使用，生成的测试结果直观、准确。

（2）坚持“5W”规则，明确内容与过程

（3）采用评审和更新机制，保证测试计划满足实际需求

测试计划设计完成后，如果没有经过评审，直接发送给测试团队，测试计划可能内容不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

（4）分别创建测试计划与测试详细规格、测试用例

应把详细的测试技术指标包含到独立创建的测试详细规格文档中，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。

4.测试用例的基本格式

软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号定义规则为：WEBLOAD1-ST-001，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入了错误密码，软件的响应情况”。

重要级别：定义测试用例的优先级别，可以笼统地分为“高”和“低”两个级别。一般来说，如果软件需求的优先级为“高”，那么针对该需求的测试用例优先级也为“高”；反之亦然。

测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成。

预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

软件测试用例的设计主要从上述6个方面考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不做赘述。