什么是可视编程？

　　在编程过程中，程序行为可视。程序行为就是什么输入、执行哪些代码、产生了什么输出？

　　可视编程由工具完成大部分工作，如生成桩、驱动、其他支持代码，人工只需要把功能细化、明确化并以用例形式记录下来；视需要测试，只有正在编写的代码逻辑复杂时才测试；程序行为可视，写几行代码就可以察看其行为，检验和调整编程思路，不必等到代码基本完成；不要求改变思维习惯。

　　可视编程步骤：1）编写函数声明；2）设定最简单的输入和预期输出，自动生成测试代码；3）根据设计功能，列出其他输入，设定相应的预期输出；4）编写几行代码；5）执行测试，察看程序行为；6）重复4、5，直到绿条出现，编码和单元测试同步完成。

　　白盒、黑盒，白盒覆盖的局限与应用？

　　白盒是指根据程序内部结构来设计用例，黑盒是指根据程序功能来设计用例。

　　白盒方法可以精确统计覆盖状况，从而衡量完整性，但白盒覆盖只能基于现有代码，不能发现代码缺失。

　　纯粹从白盒角度设计用例，叫做“跟着代码走”，即使完成了最高级别的覆盖率，测试员也可能还不了解代码应有的功能，更不用说检测功能是否正确，这种测试意义不大。

　　用例应首先从功能角度来设计，然后根据覆盖状况找出遗漏用例，新加的用例仍然要根据功能设定正确的预期输出。

　　自动用例的局限与应用？

　　自动生成用例是简单技术，但工具不可能自动了解代码功能，自动用例通常与功能无关，主要依赖自动用例是不现实的。

　　自动用例可用于边界测试，即为边界输入自动生成用例，捕捉边界输入产生的异常、崩溃、超时等极端错误，这类错误通常是程序员未考虑边界输入，也未编写防御代码造成的，属于代码缺失，白盒覆盖难于发现。

　　企业项目单元测试关键点：隔离

　　企业项目通常高耦合、可测性差。希望通过改进设计解决可测性问题是不现实的，程序是客观事物的反映，互相关联、互相纠缠不可避免。

　　将测试目标从原始项目中隔离出来，这是测试的前提。隔离的主要方式是打桩。打桩必然造成失真，因此应避免不必要打桩。

　　为减少工作量，应将个人的测试任务一次性隔离出来，任务以外的其他代码，关系紧密的应直接调用，关系松散的或未实现的自动打桩，库文件应直接调用。

　　企业项目单元测试关键点：用例

　　与测试独立小程序不同，企业项目的用例设计将面对一些难题：打桩造成的失真、脱离原系统后部分底层代码行为不可控、静态局部变量无法外部初始化、复杂的间接输入难于初始化、内部输出难于自动判断等，这些是工具必须解决的。工具还应提供足够的灵活性，在特殊情况下可以人工处理。

　　企业项目单元测试关键点：效率

　　效率决定实施能否成功。不要做平行、重复的事情，例如，没必要把黑盒方法和白盒方法分别做一遍、把动态方法和静态方法分别做一遍。

　　使用合适的工具是提升效率的前提。驱动、打桩、插装、底层模拟支持、统计覆盖率、协助找出遗漏用例等等工作，都是工具可以完成也是必须完成的。

　　工具的价值在于，解决人工难于解决的问题，提升效率，发挥人的智慧，而不是代替人的智慧。

　　边开发边测试，例如测试驱动开发和可视编程，都是大幅提升效率的开发模式，尤其是可视编程，可以在不增加开发时间的前提下同时完成编码和单元测试。

　　企业项目单元测试关键点：效果

　　与系统测试不同，针对具体单元，等价类是可穷举的，可以实现彻底测试，这也是需要单元测试的最主要原因，因此，应将彻底测试作为效果目标。

　　彻底测试并不是指测试所有代码，逻辑简单的代码是没必要测试的。彻底测试是指覆盖被测函数的所有输入等价类。

　　现实的思路是黑盒、白盒、自动相结合：1) 首先根据程序功能设计测试用例，可用分类集中法检验输入是否完整；2）根据白盒覆盖状况，为未覆盖的逻辑单位添加用例，实现高覆盖；3）执行自动生成的边界用例捕捉漏网之鱼。

　　原帖地址：http://bbs.51testing.com/thread-174302-1-6.html

版权声明：本文由会员测啊首发于51Testing软件测试论坛。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。