我做软件测试有一段不短的时间了，可大量的盲目测试几乎没有增长我的测试经验，每次测试前总有些茫然，不知道自己怎样才能有效的发现软件中存在的缺陷；测试后也不能肯定是否可以放心的发布被测软件。我想可能很多初涉测试的工作者都同我有相似的感觉，我们需要有关测试的理论知识的引导，以下是我读了一些讲解测试技术的书籍后的收获，以及我对我国当前软件业中测试这一领域的认识，希望也能给测试同行点滴的收益。

一、软件测试员的目标是尽可能早一些找出软件缺陷，并确保其得以关闭。

　　或许大家会认为软件测试员的工作目标是不言而喻的：就是找软件缺陷，然而《软件测试》这本书为软件测试人员提出了更确切的目标：尽可能早一些找出软件缺陷，并确保其得以修复。在阅读全书并仔细思考后，我觉得此目标包含三大点含义：

1． 软件测试员的基本目标是发现软件缺陷。

　　我觉得在这里有必要把这不言而喻的事实再次强调一下，因为有时产品的开发小组要测试员只是为了证实软件可以运行，而不是找缺陷。在这种情况下，测试人员也就缺乏不懈努力发现缺陷的探索精神和热情。所以我觉得在心里坚信不移的认为：软件测试员的基本目标是发现软件缺陷，是做好测试的首要条件。

2． 软件测试员追求的是尽可能早的找出软件缺陷。

　　因为软件的修复费用，随着时间的推移，将数十倍的增长，所以软件测试员应尽可能早的找出软件缺陷。对大型的软件，在软件开发的同时，就应该有紧随其后的测试，如果等到产品已经开发完毕才开始测试，非常有可能引起大量耗时费力的返工。而如何尽可能早的找出缺陷？《软件测试》这本书向我们介绍了一些理论上的测试方法：静态黑盒测试、动态黑盒测试、静态白盒测试、动态白盒测试；配置测试、兼容性测试、易用性测试……，怎样才能有效的用这些方法尽早的发现软件缺陷，需要大家在工作实践中不断的摸索、总结，进而不断的提高自己的测试能力。

3． 软件测试人员必需确保找出的软件缺陷得以关闭。

　　请注意，我们这里提的是软件测试人员必需确保找出的软件缺陷得以关闭，而不是要软件缺陷得以修复。我们软件测试员需要对自己找出的软件缺陷保持一种平常心：并不是我们辛苦找出的每个软件缺陷都是必要修复的。可能是由于没有足够的时间、不算真正的软件缺陷、修复的风险太大等原因，产品开发小组决定对一些软件缺陷不作修复。

　　另外，测试员对软件缺陷描述不清楚，也会使软件测试员发现的缺陷被忽略。所以我们测试员必须在描述软件缺陷方面狠下功夫：用简单明了的语句描述软件缺陷；每一件报告尽量针对一个软件缺陷，避免多个缺陷混杂在一起，以致其中一些被忽略或忘却；记录引出软件缺陷的操作步骤，使缺陷得以再现。

　　虽然我们软件测试员需要对自己找出的软件缺陷保持一种平常心，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。关闭软件缺陷的前提可以是缺陷得以修复或决定不作修复。而缺陷是否需要修复的最终决定权在软件的最终负责人，检查缺陷得以关闭的责任在测试人员。

二、测试一个软件最首要也是最重要的是测试其产品功能说明书。

1 概念

　　产品功能说明书：对产品最终需要实现的功能的描述。这些功能是最终确定的需要满足的客户需求，也包括是一些软件必须具备的能力。

　　在规范的软件生成的流程中，产品功能说明书应在用户需求评审会议召开后，进行系统的概要设计前确定。

2 原因

　　（１）很多软件的缺陷都是因为产品功能说明书不够全面，经常更改造成的；

　　（２）只有详细的阅读了产品功能说明书，确认产品需要实现的功能，才能拟定切实可行的测试方案；

3 方法

　　（１）参照需求说明书，检查产品功能说明书描述的产品将要实现的功能是否已经完整、准确、一致、合理的描述了产品的功能，并确保这些功能是可测试的

　　（２）研究产品说明书是否符合现有的软件设计开发的标准或规范；

　　（３）研究同类软件，预测产品的最终结果；

　　如果测试人员发现产品说明书不符合以上几点，该怎么做？

　　测试人员需要明白，我们的责任是反映产品的缺陷，我们不需要也不能修正产品，所以同发现软件的其它缺陷一样，在发现产品说明书的缺陷后，应该把它们如实并详细的记录下来，呈报给此软件的最终负责人，对并此缺陷的处理情况进行跟踪。

　　注意同发现的软件其它缺陷一样，缺陷列表应该呈报给软件的最终负责人，而不是给相关技术人员或技术主管，因为技术人员可能会以在技术的实现上有难度为推托，拒绝对缺陷的修改。

4 目前的可执行度

（１）很多软件在开发前并没有书面形式的产品说明书

　　目前我国的许多软件公司都是小型的手工作坊式的公司，在程序开发前都没有一个正式的、完整的、确定的产品说明书，即便是这种情况，产品说明书也是存在的，它存在在软件设计人员、项目负责人的脑海里，在他们心中都有一个软件的轮廓，假定了软件将要实现的功能。我们的测试人员可以在同他们的交流和不断的询问中获得这个非正式的产品说明书，值得注意的是在我们得到这些信息后还需要以书面的形式把它们一一列举出来，再向相关人员请教，最后做到能完整、准确、一致、合理的描述了产品的功能。

（２）测试人员一般不会在项目初期就参与项目

　　当前还存在着这样一种问题，公司一般不会让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。对这种情况，测试人员可以通过已经建立的软件的雏形，揣摩产品说明书，然后也是同上段所说一样，向相关人员请教，拟定一份书面的完整的、准确的、一致的、合理的产品说说明书。值得注意的是，测试人员在运行软件的雏形时，往往会发现一些软件缺陷，这时千万不要局限在这些缺陷上耗费经历，以致忘了拟定产品说明书的主要任务，一定要记住：测试一个软件最首要也是最重要的是测试其产品说明书，在产品说明书明确后，再制定具体的测试案例。

　　以上两点是指在公司体系不太正规的情况下给测试员的建议，但我认为要能更好的保证软件的质量，或许规范生成软件的整个运作流程更为有效：产品说明书由项目负责人来主持定版比较好，因为他把握着产品发展的方向；在产品说明书定版时的会议应请负责测试的人参加，使他们对产品有一个宏观的认识，我也不赞成测试人员过早的局限于某一项目，如果那样他们会觉得无所事事。

三、完全测试软件是绝不可能的，必须对测试的各项进行等价划分。

1 概念

　　等价分配：软件有无限的测试案例，我们要想办法把软件的相似输入、输出、操作分成一组，来使无限的测试案例减小到同样有效的小范围，这个过程称为等价分配。

　　边界条件：软件计划的操作界限所在的边缘条件，即如果超出这个边界条件，就可能会引出错误。

2 原因

　　输入量太大

　　输出结果太多

　　软件实现途径太多

　　软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同。

3 方法

（１）数据测试：

　　1） 确定输入的边界条件，对边界线上的及边界线两边的数据进行测试；

　　2） 边界线可能是2的乘方，默认值、空白值、零值等；每一个软件测试问题各不相同，可能包含格式各样边界的不同数据。

（２）状态测试（软件的状态是指软件当前所处的情况或者模式）

　　1） 每种状态至少访问一次；

　　2） 测试看起来最常见最普遍的状态转换；

　　3） 测试状态之间最不常用的分支；

　　4） 测试所有错误状态及其返回值；

　　5） 测试随机状态转换。

4 目前的可执行度

　　如果为了减少测试案例的数量过度进行等价分配，测试漏掉软件缺陷的风险就会增加。对初涉软件测试者，一定要请经验丰富的测试员审查预定的等价类别。