今天完成的事：

写小强的测试用例

1.软件测试的侠义观点和广义观点

G.J.Myers给出了测试定义—“程序测试是为了发现错误而执行程序的过程”，实际上这是一个狭义的概念，因为他认为测试是执行程序的过程，也就是传统意义上的测试—在代码完成后，通过运行程序来发现程序代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求及设计上的问题的，把需求、发现设计上的问题遗留到后期—最 终在代码中体现出来，这样就可能会造成设计、编程的部分或全部返工。需求阶段和设计阶段的缺陷在开发过程中会产生扩大效应，缺陷的严重性随时间发展越来越 严重，其结果会大大增加软件开发的成本、延长开发的周期等。这种狭义的观点主要是受软件开发瀑布模型的影响，而且非常不利于保证软件质量。 

延伸后的软件测试，被认为是软件测试的一种广义概念。这就引出了广义的软件测试的两个概念“静态测试”和“动态测试”。这样，静态测试和动态测试就构成了一个全过程的、完整的软件测试，而且静态测试显得更为重要。

说明：静态测试的主要活动是评审，即通过对需求、设计、配置、程序和其他各类文档的审查来检验相应的内容是否满足用户的需求。由于静态测试不需要运行程序，所以测试对象是属于静态的. 

动态测试通过运行程序来发现软件系统中的问题，在程序运行过程中发现缺陷，它具有动态性。

2.软件测试的辨证观点

G.J.Myers的第2个观点是“测试是为了证明程序有错，而不是证明程序无错误”，引出了软件测试的另外一个争论: 

软件测试究竟是证明所有软件的功能特性是正确的，还是相反—对软件系统进行各种试探和攻击，找出软件系统中不正常或不工作的地方，就我个人理解，这两个方面都有一定道理，前者(证明或验证所有软件的功能特性是正确的)是从质量保证的角度来思考软件测试，后者(证明程序有错)从软件测试的直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，可以认为测试不是为了证明所有的功能都能正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的问题，也就是说，测试的工作就是发现缺陷(detect bug )，即在软件开发过程中，分析、设计与编码等工作都是建设性的，唯独测试带有“破坏性”， 它想方设法发现软件所存在的问题。软件测试就是在这两者之间获得平衡，但对于不同的应用领域，两者的比重是不一样的。例如，国防、航天、银行等软件系统， 承受不了系统的任何一次失效，因为任何失效都完全有可能导致灾难性的损失，所以强调前者，以保证非常高的软件质量。而一般的软件应用或服务，则可以强调后 者，质量目标设置在“用户可接受水平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张。 

(1)验证软件是“工作的”，以正向思维方式，针对软件系统的所有功能点，逐个验证其正确性。 

(2)证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入及系统的弱点.试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。其代表人物就是上面多次提到的G.J.Myers。他强调，一个成功的测试必须是发现缺陷的测试，不然就没有价值。

3.软件测试的风险观点

测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就引出软件测试的风险观点。软件测试自身的风险性是大家公认的，测试的覆盖率不能做到100%;另 外一方面，软件测试的标准有时不清楚，软件规格说明书是测试中的一个标准，但也不是唯一的标准。因为规格说明书本身的内容完全有可能是错误的，它所定义的 国内特性不是用户所需要的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测试，除了发现程序中的错误，还要发现需求定义的错误、设计规格说明 书的缺陷。但是，测试在大多数时间/情况下是由工程师完成的，而不是客户自己来做，所以又怎么能保证工程师和客户想得一样呢? 

有人把开发比作打靶，目标明确，就是按照设计规格说明书去实现系统的功能。而把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞:如果只捞大鱼(严重缺陷)，网眼就可以大些、撒网区域相对比较集中(测试点集中在主要功能上)。如果想把大大小小的鱼都捞上来，网眼就要小，普遍撒网，不放过任何一块区域(测试点遍及所有功能)。 

在“风险”观点的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试完全可以看作是软件质量控制的过程。 

对应这种观点，产生基于风险的测试策略，首先评估测试的风险，每个功能出问题的概率有多大?根据Pareto原则(也叫80/20原则)，哪些功能是用户最常用的功能(约占20%)?如果某个功能出问题，其对用户的影响又有多大?然后根据风险大小确定测试的优先级。优先级高的功能特性，测试优先得到执行。一般来讲，针对用户最常用的这20%功能(优先级高)的测试会得到完全地、充分地执行，而低优先级功能的测试(用户不常用的功能，约占80% )就可能由于时间或经费的限制，降低测试的要求、减少测试工作最，这样做风险性并不是很大。

4.软件测试的经济学观点

一个好的测试用例在于它能发现至今未发现的错误”， 这体现了软件测试的经济学观点。实际上，软件测试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商业性目 标。同样，商业性目标是否正确，直接决定了企业是否盈利。在多数情况下，软件测试是在公司内执行的。正是公司的行为目的，决定了软件测试含义或定义经济性 的一面。正如对软件质最的定义不仅仅局限于“和客户需求的一致性、适用性”，而且要增加其他的要求—“开发成本控制在预算内、按时发布软件、系统易于维护”等。 

软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单，缺陷发现得越早，所付出的代价就越低，例如在编程阶段发现一个需求定义上的错误，其代价将10倍于在需求阶段就发现该缺陷的代价。这就是从经济学的观点来说明测试进行得越早越好这样一个道理。

5.软件测试的标准观点

从标准观点来看，可以定义为“验证”和“有效性确认”活动够成的整体，即软件测试=V&V 

“验证”是检验软件是否已正确地实现了软件需求规格说明书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求(如正确性、完整性、一致性、准确性等)一致。相当于以软件产品设计规格说明书为标准进行软件测试的活动。 

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。一切从客户出发，理解客户的需求，并对软件需求定义和设计存疑，以发现需求定义和产品设计中的问题。主要通过各种软件评审活动来实现，保证让客户参加评审和测试活动。 

当然，软件测试的对象是产品(包括阶段性产品，如市场需求说明书、产品规格说明书、技术设计文档、数据字典、程序包、用户文档等)，而质量保证和管理的对象集中于软件开发的标准、流程和方法等上。

明天计划的事：

写测试用例