软件测试基本知识

心情87

软件测试的基本概念

  偶然间听朋友说了这个软件测试的论坛，上来看了看，真的感觉相当的不错，特别喜欢浏览别人的个人空间觉得可以在里面学到很多的东西，今天在图书馆借了本关于软件测试的书来看了看，了解了一下基本的概念，来记录一下自己的学习内容，也同时激励自己一直学下去~~~~~

1.什么是软件测试？  
     软件测试指使用人工和自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需要或者弄清楚预期结果与实际结果之间的差别。
2.什么是软件缺陷？
     符合下列五个条件规则才能叫软件缺陷。
     （1）软件未达到需求规格说明书中指明的功能。
     （2）软件出现了需求规格说明书中指明不会出现的错误。
     （3）软件功能超出需求规格说明书中指明的范围。
     （4）软件未达到需求规格说明书中虽未指出但应达到的目标。
     （5）软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
3.什么是测试用例？
      测试用例是一组测试输入、执行条件和预期结果的集合，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。  
4.什么是测试环境？
     测试环境就是软件运行的平台，即进行软件测试所必需的工作平台和前提条件，可用如下公式来表示。
            测试环境=硬件+软件+网络+历史数据
      其中，硬件环境指进行测试所必需的服务器、客服端、网络连接设备、以及打印机、扫描仪等辅助设备所构成的环境。
            软件环境则指被测试软件运行时的操作系统、数据库以及其他应用软件等构成的环境。
            网络环境则主要是针对C/S和B/S构建的软件。
            历史数据是指测试用例执行所需初始化的各项数据。

文章摘于：《软件测试技术基础》华中科技大学出版社

[ 本帖最后由 心情87 于 2010-8-14 23:45 编辑 ]

zhangting85

首先不建议初学者阅读这篇回帖，可能给你带来概念上的混乱和迷惑，假如你已经有了一定的基础，那么可以思考一下下面提的问题。

概念定义这个问题本身是有很多种答案的，我认为，这个文章里的定义有很强的局限性。

比如说，“软件测试指使用人工和自动手段来运行或测试某个系统的过程，目的在于检验其是
否满足规定的需要或者弄清楚预期结果与实际结果之间的差别。”这个定义把软件测试局限在了发现bug上，而忽略了软件测试的很多其他目的。比如说，项目管理人员通过阅读软件测试的产出物可以对软件产品的质量状况得到一个整体的了解。又比如说，项目初期通过分析前期的软件测试结果来发现软件产品的潜在质量风险。这些都属于软件测试的目的，而不仅仅局限在验证预期结果与实际结果之间的差别上。



再比如关于什么是软件缺陷的定义，文中定义为符合这五种规则：
     （1）软件未达到需求规格说明书中指明的功能。
     （2）软件出现了需求规格说明书中指明不会出现的错误。
     （3）软件功能超出需求规格说明书中指明的范围。
     （4）软件未达到需求规格说明书中虽未指出但应达到的目标。
     （5）软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
首先，什么叫做符合五种规则，是“与”的关系还是“或”的关系，以学术文章的角度来看，这个用词是暧昧不清的。并且其中的定义也都很不清楚。
比如，什么叫做“软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好”，这句话里面存在着非常明显的逻辑问题。
假如软件测试员认为某软件运行缓慢，但是最终用户认为运行速度可以接受，那算不算缺陷？假如软件测试员认为软件难以理解，但是最终用户认为可以理解，算不算缺陷？软件测试员的想法凭什么依据可以成为判断是否是缺陷的标准，凭经验还是凭个人猜测？

这五条规则本身还暗含矛盾，比如：
什么又叫做“最终用户认为不好”，是指易用性上不好，还是指功能性上不好？假如最终用户认为需求规格说明书不好，那算不算缺陷？
假如，最终用户认为软件不好，缺少了他需要的功能，那么算缺陷吗？但是需求规格说明书里没有这一项用户需要的功能，还能算缺陷吗？假如算，那么违反了第三条，假如不算，那么违反了第五条。
更进一步来探讨，假如软件实现了需求规格说明书里未定义，但是同时最终用户很需要的功能，算不算缺陷，假如这个功能是因为需求规格说明书不完整才导致开发人员实现的功能超出需求规格说明书的范围的，那算不算缺陷，假如这个算缺陷，把这个缺陷修复了，也就是把这个功能移除了，会导致用户认为软件不好，结果又根据第五条变成了新的缺陷，那么到底算不算缺陷，算软件的缺陷还是算需求规格说明书的缺陷？

结论1，这篇文章中读对软件测试的定义，仅仅是在特定条件下的狭义定义，并不能广泛适用。

结论2，这篇文章中对软件缺陷的定义，其中1234条是属于在做基于需求规格说明书的测试时，对软件缺陷的定义，第5条是作者对可用性易用性的理解，而第5条和前面4条很容易地产生很多逻辑矛盾，把他们放在一起给人带来了逻辑上的混乱。

心情87

首先谢谢楼上对于该贴的评论，鉴于本人对于软件测试方面知识的欠缺，有很多地方需要大家来指导，希望你们可以帮助我，O(∩_∩)O谢谢。

关于软件测试的定义问题：该定义是IEEE软件工程（1983）的标准术语，也许对于当今关于软件测试的定义有局限性，下面从五个方面分别展开讨论。（PS：如有问题，请大家指正(*^__^*) ）

1）过程
“运行或者测试某个系统的过程”明确说明了软件测试是一个过程，且是一个持续的过程，而非一个时间点上发生的动作。因此，软件测试与软件开发一样需要过程管理，即需要制定良好的测试计划，根据计划做好测试前的准备工作，如测试环境的搭建、测试用例的设计、测试工具的准备等，应按照计划要求执行测试和记录发现的缺陷，最终对测试结果进行分析。
2）动态和静态
从“运行或测试”可以看出，软件测试往往需要实际执行软件系统，那么要解决的一个棘手问题就是如何设计被测试软件动态执行的过程，使得测试能够最大可能地揭示软件缺陷，同时减少动态执行占用的人力和物力。这是设计测试用例的目标。“测试某个系统”则包含了对软件系统的静态检查，如对代码和文档的检查，静态检查不需要动态运行程序，可以在一定程度上降低测试的工作量。
3）满足需要
“软件测试的目的在于检验其是否满足规定的需要”，这句话明确指出了测试的最终目标、测试的依据以及判断缺陷的根据。在测试过程中，只要发现不满足规定的需要，都认为是缺陷。那么，应该满足谁的需要？以什么形式来规定这些需要？我们知道，软件测试的最终目的是满足用户的需要，用户的需要如何来规定？答案当然是写在需求规格说明书中，那么，确保需求规格说明书的先期验证是确保最终的软件产品符合用户需求的关键。

标准定义的局限性
1）过程：定义指出测试是个过程，但并未说明测试的流程究竟是怎样的，如何才能达到规范的，良好的流程管理，该定义未给出指导性的意见。
2）选取：定义仅指出测试可能需要动态运行系统，但并未说明动态执行的技巧，即该过程应通过选取合适的测试数据来进行。而实际上，不同的测试方法的区别在于如何选择有限的测试集。针对特定条件确定最合适的选取准则是测试的难点，实践中需要运用风险分析技术和测试工程的专门知识。
3）有限：定义中没有体现测试的有限性，即选取的测试输入是有限的，测试中能观察的执行数量也是悠闲地。
   总之，从标准定义中可以看出，软件测试需要进行过程管理，软件测试包含动态测试和静态测试，软件测试分为人工测试和自动化测试，软件测试的主要工作是设计测试用例、执行测试用例、分析测试用，也是发现缺陷、记录缺陷和关闭缺陷的过程。

关于软件缺陷的定义问题：
第（1）条规则对应于一个遗漏缺陷，且应该是一个很严重的缺陷，因为连基本的功能都没有全部实现。通常情况下，这样的缺陷应该是立即修复的，即将遗漏的功能补充实现。
第（2）条规则对应一个过错缺陷，它只要是指软件的容错能力。例如，需求规则说明书指出的在任何情况下都不会发生死机，结果测试过程中却出现了死机的情况，这就对应着这类缺陷。
第（3）条规则看似很奇怪，既然是需求规则说明书中没有提到的功能，是属于不给钱的部分，开发人员为何会去实现呢？这里可能有两种可能性。第一：开发人员认为需求规格说明书不完善，某些实用的功能用户没有考虑到，或者需求分析不彻底，开发人员因此会添加这部分功能。第二：开发人员为了自己开发和调试的方便而加入的功能，如一些快捷键功能等。对于这部分多余的功能容易造成测试的遗漏问题。
第（4）条规则更让人摸不着头脑，有哪些目标是需求规则说明书没有指出，而实际有应该达到的呢？这部分功能主要是指软件对意外情况的处理，尤其是指那些硬件故障所导致的意外情况，如意外断电等。
第（5）条规则是从软件的易用性去考虑的。软件开发追求的最终目标就是要满足用户的需求，只要是用户认为不好的，都应该视为缺陷。造成这种局面的主要原因往往是沟通不畅，未能充分站在用户的立场，根据用户的业务流程去进行软件的开发。

PS：上面是对原有文章的补充，还有什么不完善的地方，请大家指出来，让我们共同学习。O(∩_∩)O~

zhangting85

好，我来说下我的看法吧。一家之言，我先申明下面的话不一定对，初学者最好不要照单全收。

恩，简单来说，IEEE的标准里包括软件工程和软件测试相关的部分，早在大学时我已经学过一部分，可能不全面，不过其中包含的最大问题已经很容易地发现出来，就是太过于理想化。也就是说IEEE定义的标准全部是针对传统的瀑布式软件工程流程的，他在这个流程中假设各阶段都能够按照他的标准出文档，然后才能往下走，也就是说，他对与测试的隐含条件是假设已经有了一个完整的需求功能说明书。从你列出的对缺陷的定义上就可以看到必须有一个完整的需求规格说明书你才能按照这个来定义缺陷。

那么事实上是我们有时候有一个需求规格说明书，有时候却没有，而且，即使有，通常也是不完整的。这一点不管国内还是国外，都是一样的。这是理想化的软件工程在实际应用中遇到的问题。也是IEEE标准仅能作为参考，而鲜有公司实际按照他去做的原因。（另一个原因是IEEE方法的高成本）所以后来，在IEEE的基础上发展出了很多的质量模型，比如CMM,CMMI之类，他们期望通过定义流程上的一些具体活动和标准来使现实的软件工程能够更规范，但同样也是强调过程的的一种方法。对软件测试的来说，这类方法的意义在于降低缺陷的出现率，和及早发现缺陷，以应对项目后期修复缺陷的高成本问题。

那么在此之后又出现了很多新的方法，比如敏捷开发，极限编程等等，直到2005年，这些新方法的创始人们决定把这些方法合并，并且称之为敏捷方法。敏捷方法对软件测试的意义就是他直接降低后期修复缺陷的成本，以此来解决这个缺陷修复的成本问题。而不会去对需求过程做过多的控制。

那么，不是说IEEE标准不对，也不是说IEEE标准不好，就像相对论不会威胁到牛顿定律在普通物理学里的地位一样。IEEE作为一个参考是很好的。另外按照瀑布模型开发的成功案例也是有不少的，当然现在这些公司也在由瀑布转向迭代。这里只是介绍一下整个软件测试发展的历史走向，那么参考了pnsqc（中文译名可能叫西北太平洋软件质量会议）上2009年的一个由Elisabeth Hendrickson做的演讲Agile, Testing, and Quality: Looking Back, Moving Forward，里一些关于敏捷测试的历史的内容以及Cem Kaner 和James Bach在BBST黑盒软件测试课程上（04-06年）讲到的一些关于需求文档的内容，其他是我自己总结的，来源就一下子找不到了。

chengning

先谢谢楼主的分享
不过楼主的好多概念定义的都有点片面

Bretty

其实楼主说的这些定义啊，之类的，我相信很多人都知道，但是问题就是理论与实际差别很大。我也是刚参加工作，刚刚经历了一个从学校向社会的转变。很多时候需求并不明确，根本没有形成真正的文档，也有很多时候需求都是跟客户直接交谈的过程中产生的，所以也不可能严格的按照理论上一步一步的执行。我个人认为，只有在一个比较规范的公司，而且时间允许的情况下才会严格按照理论上的流程来执行。

心情87

嗯，你说的很正确，在中国的很多软件公司对于需求部分的文档都不是足够的重视，而客户需求又不断变化，也导致了为什么我们做出的软件一改再改。再加上进度的压力，所以很多的流程都得不到很好的执行，并且对于软件测试方面也不够重视，这些因素都导致了我们做出的很多软件都不是足够的good enough！！！
也许这都是一个过程吧，要想让中国的IT产业达到美国IT产业的成绩，应该还有一段路要走。

心情87

嘿嘿~~~ 就是很多不明白~ 学习中学习中。。。