怎么测试自己编的程序

不同的程序不同的测试工具

程序大都开发完成后 生成编译一般都提示第几行编写的程序错误。解决后再看做出来的效果。如果有bug问题，在进行源代码的修改，反复进行直到满意为止。当然还有其他环境下提供的测试及自己累积的经验进行测试。

黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否

都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的

情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序

是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”

法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输

入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测

试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是

否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按

预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证

。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在

使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的

独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序

违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错

。第三，穷举路径测试可能发现不了一些与数据相关的错误。

还有一个灰盒测试

灰盒测试

灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内

部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运

行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来 ***

作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试盒黑盒测试的要素.它

考虑了用户端、特定的系统知识和 *** 作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测

试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试

以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序 *** 作

等通常在测试人员视野之外的信息设计测试。

有些软件的功能非常简单，比如简单的数学运算，或者统计用户输入字符的数量；有些软件的功能非常复杂，比如 *** 作系统，或者汽车的自动驾驶算法等等。

对于复杂的软件，因为它们极高的复杂度，我们很容易理解它们为什么很难“完美”，所以，强如微软，也会发生比尔·盖茨演示Windows 98时蓝屏的尴尬；强如特斯拉，也会发生自动驾驶状态的汽车径直撞向大货车的悲剧。

那么，对于特别简单的软件，我们是不是可以进行"彻底"的测试，保证它们是完美的呢？

这是不可能的！即使拥有无限的预算，我们也无法做到这一点。

如果把问题简化，限定用户最多只能输入10个字符，超过10个字符的情况就告知用户无法处理，这种情况下，我们能否进行"彻底"的测试？

这也是不可能的！

在用户输入超过10个字符的情况下，程序真的会告知用户无法处理吗？为了确认这一点，我们需要把所有超过10个字符的输入都覆盖到，确保程序会告知无法处理，而不是意外地返回一个错误的统计值。大于10的自然数仍然是无穷多的，我们还是无法把所有的情况都覆盖到。

如果我们把问题再度简化，只测试字符数量在10以内的"有效"输入呢？

世界上有许许多多的语言和文字，unicode编码可以涵盖世界上所有语言的字符，它包含的字符的数量级大概是一百万。粗略地估算下来，用户输入字符数量为1的情况，我们有100万个测试要验证；用户输入字符数量为10的情况，我们有100万的10次方个测试要验证,只要有一个测试没有被覆盖到，我们就不能打包票说在那种情况下程序可以正常工作，也就不敢打包票说程序是没有bug的。

就像发财“捷径”买彩票一样，每一组号码要买都是要钱的，买下的号码很可能都打了水票，但是你总觉得你没买的号码里可能有”惊喜”。

在现实世界中，绝大部分的软件程序比这个字符统计的程序要复杂得多，它们一定或多或少有bug没有被发现，或者有bug被发现了却没有被修复，它们肯定称不上完美，却仍然达到了较高的软件质量，这当然不是因为它们把测试做得非常彻底，而是因为放弃追求不切实际的"完美"，在预算范围内采用了合适的测试策略，得到较高的投资回报率。

其中的一个策略，是关注核心功能。

我们在买新车的时候，会对车进行非常细心的检查，刹车灯不亮，雨刮器有异响，或者轮毂有轻微刮擦，都可能导致我们拒绝收车。

在买二手车的时候，情况就不一样了，因为我们会有充足的心理准备来接受不完美。面对一辆标价5万的二手轿车，我们在验车的时候一定会重点验证发动机、变速箱、车架、转向机；至于空调是不是能制冷，我们可能会关注，但是不会过多影响我们的决定；至于车门上的车漆是否有色差，我们根本就不会花时间去看！

其实，我们还是挑剔的，只是，因为预算有限，我们深知无法买到完美的车，所以我们会做妥协。软件测试的思路也是这样的。我们无法保证软件产品的"完美"，在预算和资源有限的情况下，我们需要专注于软件的核心功能，尽量保证核心功能得到良好的测试。

以字符统计的程序为例，如果它的主要用户是中国用户，我们可以重点测试中文和英文字符，而不需要花精力去测试程序对于亚美尼亚语字符的表现，在非核心功能的测试成本比较高的情况下更应该如此，否则，我们花费了宝贵的人力和时间，只是收获了用户可能并不太在乎的完美度，就像是架起高射炮只是为了打蚊子，成本很高，收益很小，不值得。

合理的软件测试思路是把钱花在刀刃上，重点关注核心功能的测试，预算有限时应该如此，预算充足时同样应该如此。

---