|
测试是需要成本的也需要考虑当时当地的实际情况的这就是一方面我非常强调测试但也可能在特定的情况下完全没有传统意义的测试的原因 另一方面对测试的理解和实践是因人而异的（或者说存在某种进阶这种进阶由软件实践的经验和能力相对决定）根据进阶不同对其理解和实践就会不同 在这里包括单元测试究竟是不是设计以及在细致区分单元测试和测试用例都可以有不同的理解和实践这些理解和实践没有绝对的对与错而只是在粒度和看问题的角度上有所不同或者说软件实践经验的不同 但尽管存在不同的理解和实践我们却可以把分歧统一在一个前提下 那就是一切为了更好的软件实践 从这个基本点出发测试可以被看作传统意义的测试也可以看作是设计的一部分或者是辅助设计根据测试粒度的不同产生的其他的分歧也不再是问题甚至是更具挑战性的理解和实践测试可以看作测试传统意义的代码本身也可以看作测试（从这里也可以引申为设计和代码实践的随意性或者也可以说是一种非常自然的更高级的软件实践）在我的软件实践里我更喜欢这种实践模式当然这是有前提的他必须和具体软件项目人员时间和其他辅助资源相适应而不是一种必然选择显然在很多软件环境下我会采用适当保守的做法来保证我的队伍可以轻松而且可靠地完成工作这就是软件赋予我们的灵活性 实际上讲到这里怎么做可能是更好的实践已经有了答案尽管这个答案不是明确意义的对错或者第条第条的方式给出的我也试图谈论更多来更清晰这些回答当然这些具体看法根据个体实践经验不同会存在不同的理解这都是正常的 记住这里没有绝对性质的对错凡是能够更好的辅助完成软件实践就是成功的 我们时常提到测试驱动开发但实际上真正符合的不多通常所称的测试驱动开发只是有了单元测试而根本没有驱动的意味很多问题由此产生在很多时候我们谈论的差不多是两个不同的概念正常的情况下测试是可以作为主要设计手段的至少是极好的辅助设计手段根据粒度和规模的不同就体现为不同的具体实践包括传统意义的单元测试来测试单个的对象或者更大规模的对象群这都是正确的实践在这里也可能存在测试转化问题也就是开始作为设计的实践到后期的更趋向传统的测试这是更具体的实践 测试成本的要素包含很多方面是否写了测试代码只是其中一个重要部分是否采用JUint以及Mock对象更加不是对其评价的决定性因素对测试的更好评价应该是额外代码测试可重复性测试范围和边界值识别等综合构成（测试对设计的作用是更高级的判断） 对于涉及到数据库持久方面的测试涉及到UI（浏览器或者富客户端）交互的测试以及多对象多方法过程的测试（也可体现为UI交互这里是指独立性质的）等以及上面说到的一些问题（不再重复）是我们现实测试实践要面临的问题对这些问题的解决就会更多的涉及到项目具体情况的选择和具体项目和团队的情况来作最佳判断这就是成本的意义我在这里还想提醒在关注这些具体的项目因素的同时还要注意下面的问题 对象的所有者和使用者问题 不要单纯意义上理解测试有些测试可以采用单元测试之外的手段完成 项目在不同进展阶段测试的便捷性（也可体现为大分层概念） 测试是一个理解和实践都可能差异很大的软件实践它包含了具体的代码实践也是需要和项目管理和设计相适应的方法论当然也是体现实用哲学的软件思想 在方便的时候我很乐意详细阐述我在测试上的实践经验和教训（如讲座）也可以就我正在实践和思考的更具挑战性的思考和实践进行探讨 |
