软件测试基本知识

zhangting85

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

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

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



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

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

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

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

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年）讲到的一些关于需求文档的内容，其他是我自己总结的，来源就一下子找不到了。