软件测试从零开始学习

 

【关键词】软件测试、测试用例、测试需求、测试结果分析

 

引言

       郑人杰《计算机软件测试技术》

 

测试准备工作

       在测试工作伊始，软件测试工程师应该弄清楚软件测试工作的目的是什么？

向有经验的测试人员学习

       a、在运作规范的软件公司，积极向有经验的测试人员请教，寻求测试指导；

       b、在运作不规范的软件公司，充分发挥网络资源优势，寻找软件测试资料进行自我学习。

阅读软件测试的相关书籍

       可以考虑去www.chinapub.com或者www.cnforyou.com查找软件测试类的书籍，购买后进行阅读，另外最好能看看国外的软件测试经典之作。

走读缺陷跟踪库中的问题报告单

       无论是采用ClearQuest、TestDirecter商用工具，还是采用Bugzilla、Mantis等开源工具的软件缺陷跟踪库。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，也是软件产品问题的集中体现。

       一般来说，缺陷报告单中最关键的几个部门包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分进行仔细分析，从中掌握了软件产品最常见的基本问题，并吸收了其它软件测试人员的工作经验。

走读相关产品的历史测试用例

       通过测试用例管理系统【如TestManager】走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读其它软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

学习产品相关的业务知识

       软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。

识别测试需求

       识别测试需求是软件测试的第一步。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。

主动获取需求

       需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。

       把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境。

       软件输入： 与某个需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。

       处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

       软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机、文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。

       性能要求： 与某个需求相关的性能要求，比如“用户登陆系统，10秒钟之内应该登陆进入系统”。 10 秒钟这一限制，就是对需求的基本性能要求。

       运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

确认需求的优先级

       在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，放弃优先级低的需求项；If进度允许，那么再测试优先级低的需求项。

加入开发小组的邮件群组

       如果公司没有变更控制系统，可以考虑采用加入开发小组的邮件群组，及时知晓开发人员通过邮件讨论问题、通过召开技术会议，如有必要，可以参加开发人员的技术会议。

与开发人员为邻

       良好的人际关系是打通部门墙的手段之一，在工作开展的过程中有很大的便利。

测试用例设计

       需求收集完毕后，开始设计测试用例。测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

       1、测试用例的基本格式

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

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

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

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

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

              操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

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

              软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。

       2、重用同类型项目的测试用例

              如果我看得远，那是因为我站在巨人的肩上－－牛顿。

              一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如B/S 架构的软件、 C/S 架构的软件、嵌入式软件等。参考同类型软件系统的测试用例，会有    很大的借鉴意义。“拿来主义”可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

       3、利用已有的软件 Checklist

              对于同类型的软件，在设计测试用例时，可以去网上搜索相关的同类型的checklist，找份粗糙的checklist，然后在设计测试用例的时候不断去完善，作为下次测试用例设计的基础。

       4、加强测试用例的评审

              测试用例设计完毕后，最好能够增加评审过程。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

       5、定义测试用例的执行顺序

              在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把 这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时 间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

测试用例执行

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

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

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

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

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

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

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

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

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

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

       3、及时更新测试用例

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

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

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

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

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

       硬件配置：计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参 数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。

　　测试用例输入 / 操作步骤 / 输出：这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

　　输出设备的相关输出信息：输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相       关的输出，在问题报告单中提供描述。

　　日志信息：规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

　　根据被测试软件产品的不同，需要在“问题描述”中增加相应的描述内容，这需要具体问题具体分析。

测试结果分析

       软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节，“编筐编篓，全在收口”，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的“测试准备工作”中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。