Bra*_*rad 3 language-agnostic testing unit-testing
我多年来一直在编写软件,但从未掌握过测试的艺术.我的典型测试包括在我的机器上进行彻底的运行,然后通过VMware在各种操作系统中进行测试.主要是一种蛮力的游戏 - 直到它打破或不打算的方法.在可能的情况下,我在实际的硬件上工作,但这并不总是实用的.
我的问题是双重的:
感谢您的时间和意见.
将您的软件划分为组件(可以是从单个函数到整个程序的任何组件),并彻底对这些组件进行单元测试,尤其是与应用程序其他部分可以看到的API和行为相关.(不要忘记检查故障模式,但要注意过于谨慎地与故障的确切性质绑定;它通常足以测试是否存在正确的异常类而不是确切的消息.)确保那些测试通过; 你正在根据组件应该做什么的规范来磨练它们.(自动化测试运行在这里有所帮助,CI系统也是如此.)这很重要,因为......
测试组成应用程序的组件的组成是否有效(这是集成测试).理想情况下,你只会在这一点上找到事物规格中的错误(哈!),无论你在哪里通过单元测试确定组件是错误的,都会告诉你存在错误.尽管被告知这些事情仍然无法协同工作,但您可能在上一步的规范中遇到了错误,因此您通常会通过向单元测试添加更多详细信息并修复组件直到它们工作来解决这些问题.
请注意,为了实现良好的集成,您需要保持这个阶段,以便集成本身足够简单,以至于它在"明显没有错误"类程序而不是更大的"No Obvious Bugs"类中.像Spring或脚本语言这样的集成框架在这里可以提供很多帮助(尽管使用后者,你必须防止在狡猾的情况下创建组件;如果你创建了一个组件,那么就承认它并确保它有一个正确的使用合同和单元测试确保它符合合同).
在可以的地方,您可以通过将其他人组合在一起来制作组件; 这些更高级别的组件需要进行单元测试,如上面步骤1所述.这可能听起来像额外的工作 - 它可能是 - 但它确实具有意味着您可以对程序的较大部分使用自动化测试的优点.(唉,使用自动化测试工具进行所有集成测试更加困难;这样的事情往往更好地进行单元测试,你可以模拟出所有不相关的部分.)但这并不能帮助你避免......
这是测试整个应用程序以查看它是否实际执行所需操作的位置.这可能是自动化的,但通常不是.这是您引入用户以让他们看到事物是否符合预期的级别,尽管您可能希望先使用内部测试人员.这一切有多容易取决于应用程序的性质.
还要注意,用户界面倾向于在这一步骤中花费更多的时间而不是其他界面,正是因为制作好的用户界面很难不可能在算法中确定(毕竟它与人类心理学有很大关系).
最后一点:我在这里写的内容听起来像测试是一个费力的过程,在项目结束时需要很长时间.不是!您通常可以在其他部分之前完成部分应用程序,对这些部分进行集成(使用其他位的模拟)并测试该子应用程序的实际可接受程度.当然,这样做时要注意阻止用户相信一切都已完成; 一种方法是弹出对话框并说出"魔术在这里发生"之类的事情.愚蠢但有效.:-)