软件测试之测试用例执行

测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几 个问题：

搭建软件测试环境，执行测试用例

测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试 后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运 行的软硬件环境， 比如要求操作系统系统是 Windows 2000 pack4 版本，数据库 是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书， 包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品， 尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇 到种种问题。

如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试 人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录 下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降 低了开发人员对测试人员的认可程度。

测试执行过程应注意的问题

测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测 试执行中需要注意以下几个问题：

全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与 测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？ 答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品 的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成 功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试 嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出 完全一致， 不过在查询 CPU 占用率地时候， 发现 CPU 占用率高达 90 ％，后 来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察 点单一，这个严重消耗资源的问题就无从发现了。

加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执 行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例 的依据； 如果软件产品提供了日志功能， 比如有软件运行日志、 用户操作日志， 一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日 后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人 员重新搭建测试环境，为开发人员重现问题。

及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可 以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件 缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开 发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人 员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试 执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的 开发环境上重现问题，继续定位问题。

与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开 发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、 有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人 员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员 对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是 否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

及时更新测试用例

测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发 现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例 在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若 干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用 例。

总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试 执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测 试用例。

提交一份优秀的问题报告单

软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出， 是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。 软件测试报告单最关键的域就是 “问题描述” ，这是开发人员重现问题，定位 问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试 用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

软件配置：包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁 版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

硬件配置：计算机的配置情况，主要包括 CPU 、内