-
-
手机阅读
——给技术部的开发人员和其它同仁
一个新的程序编完了，一个新的装置开发出来了，开发人员松了口气：哦，终于完成了。烧程序，连装置，做实验，看数据。OK，功能很正常，任务结束了。
且慢，任务真的结束了吗？
调试人员经常跑来，诉说装置某项功能无法实现；现场反馈回来信息，某些数据的显示超出了范围；用户偶偶抱怨说，装置时间显示为不正常的值；销售人员出差回来发牢骚，说公司装置的某些功能达不到用户要求，以至招标失败。
我们的开发人员是敬业的，听到这些意见的第一个反应是：真的是这样？是不是我的程序在此处确实没有考虑到？打开程序检查一下，看看是否程序有问题？哦，是的，原来某个地方的逻辑确实少考虑了；哦，是的，确实没有考虑到现场的电流会有这么大；哦，是的，某项功能确实没有实现；哦，是的，原来这样；哦，是的，原来那样。
知道问题的所在，解决问题应该不成问题，我们的开发人员都是高手，改吧，烧程序，连装置，做实验，看数据。OK，功能很正常，任务又结束了。
且慢，你难道就愿意这样不断地对程序修修补补，不断地吸取经验教训，不断地重复新一次改动？
你有没有想过，采取一种比较系统的方法对自己的工作做一次完全的检测？
办法肯定有：完整地全面地细致地测试！
但你肯定会说：那好呀，到事业部叫两个熟练的调试人员，让他们对系统作一个详细的测试。
但是，开发过程中的测试和工程项目中的测试是完全不一样的。你是开发人员，你不是调试人员，你不能以开发人员的标准来衡量一个调试人员。也就是说，对你系统的功能测试，应该由你自己提供一个完整的测试方案。你不应该要求一个调试人员提供一个针对你新开发装置的测试方案，除非他达到了一个系统测试员的标准！
不要小瞧了测试！如果轻视了他，他带给你的报复也许是致命的！
但是，测试到底该如何做？它到底有没有规律？它有没有可以遵循的方法？
有！测试是一项系统工程，是一门专门的学科。如果你不是一个好的测试员，那你只能是一个普通的低能的开发人员！！！
测试的精华用一句话来说：宁可错杀一千，不能放过一个！测试应该把握的原则有如下几点：
计划性
测试不是针对功能的简单试验，也不是一种随心所欲的操作。你做测试的对象具体有哪一些功能必须实现？具体应该设计一些什么样的实验条件？应该记录一些什么样的数据？测试的方案是否能满足装置功能的所有要求？在你做测试之前，你必须对此有明确的计划，并且要将此计划通过书面的形式确定下来，让调试人员能够明白，你的真实想法是什么？你所担心的问题主要有哪一些？你为测试准备了哪一些项目？
规范性
你测试的工具有哪些？你测试的步骤有哪些？你测试的数据该如何记录？所有这些内容，你都应该通过一种标准的格式固定下来，以一种别人能够理解的方式记下来，这就要求测试前的方案编写、测试中的数据记录、测试后的改进总结等等，都需要规范的记录。
重现性
你通过实验，发现了一个问题，你能描述这个现象吗？你能重现这个现象吗？你能保证做了某个实验之后，再次重做这个实验，一定会出现你所记录的现象吗？
还有，根据你的实验记录；别的调试人员能够重新做一次相同的实验，并且能否得到相同的结果？
完整性
如果只是完成常规的实验，也许实验很快就能结束了。不过，你所做的实验是不是包括了现场所有的情况，甚至包括了一些百年难遇的情况？你的实验是不是考虑了很多不同的情况？
好了，你明白了测试工作在开发过程中的重大意义，也明白了测试工作的一些原则，但是，对一个项目的测试来说，具体应该测试哪一些内容呢？作为一个系统的工程，测试应该包括如下内容：
单个功能的测试
根据开发计划和目标，测试每一个需完成的功能项。记录好每一次实验时，功能是否能正确完成，完成的物理量精度，完成的时间精度，完成的结束情况，最后，多次实验的结果是否一致。
单个功能的实验应该包括开发目标的全部内容。应该通过测试前的计划，决定每一项测试的内容，并通过多人（包括专家）验证：是否全面？是否没有遗漏？
边缘条件的测试
单个功能的测试都验证过了。但是，这只是我们测试工作的一部分，而且是很少的一部分。接下来的测试，可能大量做的都是无用功，而且，许多情况下是枯燥乏味的重复工作。对很多希望干大事情的开发人员来说，这些工作简直是要命。但是，考验你是否是一个合格的开发人员，从这些事情就能看出。
边缘条件是许多开发人员容易忽视的，但往往是很容易出问题的地方；举例说明可能的一些边缘条件：
1、 当定值的设定为一个很小的值，或是一个很大的值；能不能正确地整定下去？
2、 当功率为一个很小的值，或是一个很大的值，能不能正确地显示？
3、 当保护条件在一个很小的值，或是一个很大的值，能不能正确地动作？
还有很多很多，对这类问题的测试很简单：加大常规功能测试的内容，将每个单功能测试的值的范围扩大到最小和最大，并在其区间抽取几个点。抽取实验点是非常有技巧的，你需要抽取的实验点应该包含所有可能的情况，特别应该注意如下一些点：
1、 符号由正变负或由负变正时的变换点；
2、 角度由90度以下变为90度以上等的变化点；
3、 定值由非动作值变为动作值的临界点；
还有很多很多，对这类取点很大程度取决于测试方案编制人员的经验。
异常情况测试
我们的系统在正常情况下，一切功能正常，但是，我们的系统并不是工作在真空中。实际上，我们的系统工作在一个条件非常复杂的现场环境。我们必须保证系统能在各种非正常情况下，能够处理正常，而且，在异常情况消失后，能够重新正常工作。也就是说，我们必须通过实验保证，我们的系统是稳定的可靠的，不会因为现场的异常情况而导致整个装置的问题。
应该在测试计划中，列出所有可能想到的异常情况，并针对这些异常情况，作严格的实验。可能的一些异常情况有如下一些：
1、 通讯因线路异常而产生误码，装置对误码的处理是否正确？这里的误码是指：所有可能的误码组合；
2、 所有可能异常的电压波动、雷击、直流接地、外部异常、强电压干扰；
3、 变送器损坏，元器件损坏；
4、 环境温度高，或是环境温度低；
5、 谐波量非常大；
6、 定值丢失；
7、 通讯中断；
8、 畸形波；
等等，所有的这些内容你都考虑到了吗？可能有一些异常你根本无法模拟，但是，你有没有想过这些异常？你有没有考虑在厂外（高校、研究院、权威机构等）模拟这些情况？你有没有尽可能地模拟实际情况来测试装置的稳定性？
组合条件测试
单项实验应该没有问题，但是，在多种情况同时发生时，装置会不会出现问题？这些条件该如何组合？该设置哪一些组合值？
极端条件测试
一个装置的运行也许没有问题，但是，多个装置同时运行呢？速度还是不是够快？在很多大量的运算的情况下，数据会不会丢失？功能是否依旧正常？系统是否依旧稳定？如何构成极端条件，来测试系统的性能？
系统稳定测试
装置长期运行，会不会依旧正常？如果构造一个环境，让系统能够长期的运行？稳定测试时的数据该如何记录？
作为一个开发人员，对开发出的装置和产品，必须提供一个完整的测试计划，这个计划也许是片面的，也许不太完善。但是，经过多次专家的论证和修改，它应该能测试装置的大部分情况。虽然它不能解决所有的问题，但是，经过多人完全的细致的测试后，至少，我们的系统将能在很大程度上保证它的稳定可靠。会使用现场的问题降到最少。
经常听到开发人员抱怨，调试人员没有对系统进行严格的测试。所以装置才会在现场出现问题；调试人员没有及时的汇报问题，所以才会出现很多功能的不完善。此类观点可以休也！
你是一个开发人员，你应该真正地了解现场要求，你应该在你的开发成果转为产品之前，花大量的时间呆在测试。如果你想通过调试人员的反馈来了解系统的问题，那你就错了。因为调试人员不会用很多的理论高度来分析他们所发现的问题，很多问题对他们来说也许不是问题，出现问题时，他们经常会问：是不是我做错了？所以，如果你希望完成一个真正的产品，你应该真正地测试你的系统，你应该多呆在现场，你应该做一个优秀的开发人才，而不是一个开发大老爷！