软件测试促进软件开发规范化

【#第一文档网# 导语】以下是®第一文档网的小编为您整理的《软件测试促进软件开发规范化》，欢迎阅读！

软件测试促进软件开发规范化

郎宇征 秦长贵

（北京图形研究所，北京 100029）



《构建基于HPLH6000服务器的软件测试系统》是刊登在中国计算机用户协会成立二十周年记念大会出版的“中国计算机应用论文精选”论文集上的一篇文章，关于这篇文章的内容我就不再重述，也许有些同志还有印象。

这个测试系统建成后，我们利用这个系统对在Alpha系列机上开发的应用软件或其它软件进行白盒、黑盒的测试，使开发出来的软件产品更规范化、产品化，软件产品质量更高。下面介绍一下利用这个软件测试系统对应用软件的开发带来的好处及存在的问题。 1、对于提高软件开发部门的技术水平有明显的作用，主要表现在以下几点：

（1）从软件规范开发的全寿命环节上，迅速补上了软件测试这一不可缺少的重要一环。 由于我们早期的软件开发，从重要性上没有认识到软件测试的必要性，软件测试只是简单地由开发部门内部完成，甚至是由用户完成，造成开发的软件产品规范化、市场化不够，软件产品水平低，存在较多的BUG和缺陷，用户意见较大。

有了规范化、系统化的软件测试，测试人员使用专用工具对软件产品进行测试，软件产品的问题得以提早暴露，有助于开发人员在软件产品交付用户前加以改进，软件产品的质量得以提高。

（2）由于测试环节的存在，反过来促进了软件开发人员在开发部门内部对软件测试的重视，开发组的单元测试和集成测试也受到重视，可以提早发现软件问题并及时改正，测试部门进行验收测试时问题相应减少，从而提高了软件产品的质量。

在测试部门成立前，开发部门内部的单元测试和集成测试不够认真，没有相应的正规化流程，测试深度和重视程度不足，某些测试流于形式，测试的成效不明显。

有了专职的测试部门，他们认真负责的完成验收测试，可以说，发现的问题越多，对于软件开发部门的压力和促进作用越明显，当测试部门提交软件缺陷时，开发部门意识到应该及早地发现和改正这些软件问题，以免在提交验收测试时带来问题和被动。

因为在软件生命周期中发现软件问题的时间越晚，改正的成本和难度就越大，占用的时间就越多，越不利于软件维护，从这个意义上，也促进了开发部门重视早期测试，做到软件缺陷的“早发现、早隔离、早改正”。

（3）科学地使用各种专用地测试工具，软件测试从早期的人工测试，向结合测试工具的专业测试、系统测试发展，测试水平随之提高，可以发现原来难以发现的软件缺陷和问题，测试更加规范。

在软件测试初期，主要以人工测试为主，测试过程难以复现，对于部分问题不易发现。有了专业的测试工具，测试人员可以在测试中，随时重复对某个过程的测试，而无须繁琐的手工重复，大大减轻了测试人员的工作量，测试人员可以专注于更加复杂的测试方法研究，尤其是压力测试、并发测试等专业测试，发现更深层次隐含的问题，从而提高软件测试的水平。

同时，软件测试人员可以量化测试结果，复现测试出的存在各种问题，在白盒测试等方向，对于软件的开发进行规范，提高测试的广度和深度，这些都是具有非常重要的意义。 2、当前软件测试存在的部分不足，主要表现在以下几点：

（1）测试规范化不够，测试报告用词不够准确。

测试结论应给开发部门和上级领导以全面和准确的印象。对于测试中发现的问题，测试报告应该分为致命性错误、一般性错误、警告性错误等多种类别，分门别类地列出，对于不


同类别的错误，给出不同的改正建议，而不应混作一团，流水帐般地罗列在一起，这种方式只会造成开发部门的反感，同时，上级部门领导会误认为开发的软件一无是处，问题成对，事实上，错误的分级、分类，不仅是非常必要的，同时，也是客观认定开发部门工作成果的一种方式。

我们难以想象，你使用任何开发工具编译时，产生的编译报告没有分为致命、一般、警告错误是什么样子，同样，测试提交的测试报告也应达到这个基本的要求，对于开发部门可以首先改正严重的错误，提高对错误的认识程度，有重要的意义。

（2）测试报告中，对于发现问题的环境和过程描述不细，不利于软件改正。 有些测试部门提交的测试报告，只有各软件发现的问题和缺陷列表，测试的条件和环境，尤其是发现的过程描述不细致，不利于开发部门对照改进。

在测试工具的支持下，测试过程中发现的问题应该准确复现，并提交给开发部门，以便开发部门能方便地改正问题，这是正规化测试和开发的要求。

（3）测试认定的缺陷原则不明确，又没有事前告知被测方，很容易造成测试人员与开发人员对于错误和缺陷的认定不一，引起对测试结果的误解。

测试过程中发现的问题，应该无二义性，得到测试和开发双方的认可，这点应该非常明确。测试以软件需求为依据，由于部分软件需求对于功能描述不细，使用手册对于部分细节也没有定义，当测试人员发现一个问题或疑义时，由于没有规范化的测试法规和原则，容易造成双方对于测试结论存在分歧。

例如：MIS软件中，当用户保存数据成功时，开发人员将保存的结果显示在记录列表中，而测试人员则认为应该显示提示窗口，告诉用户：“保存成功！”，这两者就存在明显的分歧。

测试人员认为开发方的软件存在缺陷，而开发方认为他们的工作方式已经可以满足用户的要求，而且，频繁的显示提示窗口，会打乱用户的处理流程。

此时，若没有事先明确的测试规范和细则认定，这类错误就无从认定。测试人员在未经认定的情况下，片面地将这类错误认定为缺陷，罗列在测试报告中，对测试结论是非常不严谨的。对于开发方也是非常不公平的。

对于这类问题，可以在测试规范中加以明确说明，事前公之于众，做到开发和测试双方的认可，避免在测试中对于问题认定的歧义。同时，对于部分无法认定的情况，应该和开发方商定后加以定性，并对测试规范和细则随时加以修订，以便开发方日后的改进和完善，共同提高软件开发和测试的水平。

（4）对于多次测试过程中发现的问题，开发方和测试方都应有倒查机制，及时发现问题的出处，以便提高软件开发和测试的规范化水平。

现在，测试人员对于同一软件的多个版本进行多次测试时，有时会发现不同的问题和缺陷，这些新的缺陷，有些是由于开发方在改正前期的错误时引起的新错误，有些是在前期版本中就已经存在的错误，只是由于测试方在早期的测试中测试不认真而遗留的问题，对于这两种情况，应该区别对待。

对于开发方后期改正引起的新错误，是开发方新产生的，应该视为开发方修改错误造成的问题，视为新的软件错误。对于前期就已经存在的问题，应该认定为由于测试部门前期测试不认真而忽视所遗漏，对于测试方应该予以警告和批评，督促其加强测试的重视和认真程度，而不应简单地认定为开发方的错误（当然，开发方还是应该认真改正这类问题）。

否则，这类问题地隐藏，会导致测试部门对测试重视不足，不利于提高测试方的测试水平。同时，倒查机制的建立，对于双方都有明显的鞭策和激励作用，于各方都有好处。

对于这些问题的确认认定，从开发方提供的各种版本的软件产品中，可以很容易地发现问题确切出处，同样，倒查机制的贯彻，也可以促进软件配置管理地实施和完善。

（5）在可能的情况下，测试部门应该将测试工具提供给开发部门，以便其在早期建立

本文来源：https://www.dy1993.cn/n5ix.html