品质伙伴给大家说说单元测试的事。
　　基于亲身实践、跟踪观察周边的IT团队以及与同行交流分享，品质伙伴发现IT人在软件开发过程中的一系列选择对软件单元测试的成效具有重要的影响。初步梳理，至少涉及下列几个方面：
　　· 设定测试目标
　　· 选择测试策略
　　· 圈定被测单元
　　· 划分参与者职责
　　· 分割被测应用
　　· 选择测试技术
　　· 选择测试框架
　　· 配置基础测试环境
　　· 呈报测试结果
　　· 强化个体测试能力
　　· 打造团队测试能力
　　先来看看“设定测试目标”对测试成效的影响。
　　品质伙伴观察到，IT人通常在几类场景下选择、审视和修订单元测试的目标。包括（a）制定研发流程/计划时；(b)处理用户体验投诉/质量事故；(c)应对市场推广/销售竞争受挫。场景（a）下IT人有可能全面均衡地考虑功测试效果和资源效率，追求尽可能高的资源效率，场景（b）和场景（c）下IT人可能迫于压力，希望更快、更大的成效，较少顾及资源效率。
　　有机会参与“设定测试目标”活动的IT组织成员包括单元测试的倡议者、附和者。他们可能做出的选择包括：
　　在时间、资金、知识技能约束较宽松时，将目标延展到全面系统改进质量、即测试目标可能被设定为“改进开发管理、执行流程，降低质量风险”。毕竟做大做强是一种组织习惯行为；
　　当参与本项活动的成员以QA为主体时，可能将目标重点聚焦在强化质量保证体系、目标被设定成“改善质量保证流程，降低质量风险”。这些内容也是成员们有能力把握的领域；
　　品质伙伴以为，目标设定的结论应当覆盖下列三个方面。
　　改善既有质量环节--改善编码规则、单元测试、集成测试，提高早期缺陷发现率，降低缺陷遗漏；
　　规范测试过程活动--测试需求，测试设计、测试执行、缺陷跟踪；
　　推广使用测试设施--引入高效测试技术和框架，强化不同环节衔接、提高测试效率；
　　实践中不少IT人都选择了这条道路。
　　品质伙伴观察到，不当的测试目标选择，使得部分IT人的工作陷入困境。即测试目标高于具体产品的品质要求或者IT组织的技术积累时，长期目标和短期效果可能无法兼顾。目标设定后，执行阶段需要进一步细化成一组方法、流程、步骤、规范。当细化后的的要素与和IT组织的既有实践、经验、基础设施重合越高，执行的效果越好。否则可能需要较长时间地推行上述细化要素，才能体现出提升缺陷发现率，降低缺陷遗漏的效果。经验表明，如果以追求立杆见影效果为目标，针对性的增加测试用例、高效执行并检验结果往往效果更佳；
　　如果设定的测试的目标低于产品的品质要求，执行过程可能比较顺利。随着开发周期的不断演进，后端环节会发现的超出预想的品质问题。严重时造成产品丧失竞争力；
　　有些时候，IT人制定测试目标时缺少准确质量风险识别，措施针对性不强，再基于目标细化出一组方法、流程、步骤、规范以及相应的考核指标，表面上工作细致扎实，效果却值得商榷。经验表明应用软件的不同部分的质量属性存在差异，测试努力应当有重点地覆盖高风险部分。通过测试努力大限度的降低产品的质量风险。
　　接下来一起审视“选择测试策略”对测试成效的影响：
　　任何软件开发项目都受到时间、质量、资源投入的限制。IT人需要在给定的时间、资源投入前提下向客户交付质量认可的产品。单元测试的倡议者、附和者必须确定单元测试资源的投放侧重点--即选择具体的测试策略。
　　对于单元测试，IT人可能选择如下的测试重点(资源和精力着力点)：
　　· 通过改善代码规范性，消除代码实现时不良编码习惯产生的隐患；
　　· 通过验证设计和实现的一致性消除代码实现时与设计的不一致；
　　· 通过改善和确认功能完整性，消除代码实现与功能规格的不一致；
　　· 通过提升和验证接口相容性，消除代码实现与接口约定的不一致；
　　· 通过重复验证，规避免改动的副作用，消除代码修改后与预期的不一致；
　　· 品质伙伴观察到，“测试策略”选择不当可能引发的风险有测试活动无法与其他质量保证尝试有效配合、正向影响；
　　· 缺少与所选策略有机配合、成熟/高效的识别、监测、跟踪手段；
　　· 缺少与所选策略有机配合、成熟/高效的执行控制、结果生成、报告手段；
　　测试活动在规划阶段看起来非常清晰，执行时遇到一大堆困难。大量的重复、耗时、高强度的工作需要大量的人力投入。
　　再来一起审视“圈定被测单元”对测试成效的影响：
　　品质伙伴观察到，所谓单元，业界有不同的认定。IT人需要结合自身的开发活动，确定具体的内涵。可能的选择包括：
　　开发团队如期望通过单元测试活动重点验证代码逻辑是否符合预期，则可能把单元定义为源代码片段；
　　期望通过单元测试活动，验证采用结构化方式开发的程序代码及行为，开发团队可能把单元定义为函数；
　　如期望通过单元测试活动，验证采用面向对象方式开发的程序代码及行为，团队可能把单元定义为类及属性；
　　当期望通过单元测试活动，验证采用既有程序代码文件时，团队可能把单元定义源代码文件(耦合功能)；
　　如果期望通过单元测试活动，验证程序模块正确性，则团队可能把单元定义程序模块/构件；
　　品质伙伴注意到，单元定义选择不当可能诱发一些列风险。包括：
　　单元测试实施过程中，缺少成熟/高效的识别、用例创建辅助、监测、跟踪手段；
　　单元测试实施过程中，缺少成熟/高效的测试执行控制、结果汇总、报告创建/分发手段；
　　因此选择源代码逻辑片段、源代码文件、程序模块/构件为测试对象时需要仔细评估。