你的位置:首页 > ASP.net教程

[ASP.net教程]影响单元测试成效的重要决定(中)


继续单元测试的话题---影响单元测试成效的重要决定。欢迎对号入座。

闲话少说,接着分析“划分参与者职责”如何影响单元测试。

软件工程实践中,开发团队里的多名程序员相互合作、完成软件设计和代码的实现,IT人必须将单元测试的任务分配给具体的承接人。

品质伙伴注意到,IT业界流传的一些观点会困扰单元测试任务的分配。如“编码人员不宜测试自己的代码”就是其中之一。品质伙伴的以为这是片面的看法,这种源自个体学习和演练的假设,对于基于多人合作、规格说明的软件开发在多数场景下不成立。单元测试实践中基于编码规则、设计规格所进行的检查、验证活动不仅可以由专职测试人员承担,由编码人员承担的效果更好;在XP模式开发实践中,代码的设计意图只有设计编码者清楚,因此单元测试由编码人员亲自承担更合理。

IT人分配单元测试可能的选择包括:

由源代码实现者承担单元测试,优势是可以方便验证实现和设计意图是否一致,不足之处是编码人员容易忽略缺陷(尤其是引起用户体降低的缺陷)、不利于发现自身代码的规范性、不良编码习惯等问题;

结对代码实现者互相承担对方代码单元测试,品质伙伴以为这是最理想的任务划分方式,可以兼顾验证实现和意图、和代码规范性;优势是方便确认代码逻辑和设计意图一致性、同时便于发现代码的的规范性、不良编码习惯问题,不足之处是编码人员容易忽略缺陷(尤其是引起用户体降低的缺陷);

独立测试者承担代码单元测试是一种受限的选择,这种方式对验证实现和规格说明是否一致效率高;有利于确认代码逻辑和设计规格是否一致,也方便发现代码的规范性、习惯性问题;不足之处是当设计规格不完整时,测试验证的效率不高。

测试任务承担着选择不当会引发一系列风险,包括:

可能误导对单元测试的认知,如果将单元测试任务全部分配给专职测试人员,会让部分开发人员以为单元测试是他人的职责、模糊质量主体的职责;

另外独立测试者的测试效率受限于设计规格质量,而实际项目中很多开发团队缺少有效的记录、更新和交流测试规格的手段,独立测试团队的单元测试成效不理想;

作为建构系统的设计和实现人员,在心理上排斥缺陷、趋向自我肯定,容易降低用户的体验标准,接受代码的非预期表现,遗漏代码缺陷;

 

继续分析“分割被测应用”如何影响单元测试

在IT业界的,许多开发项目非常关注进度。初期代码大多没有经过单元测试,直到开发过程因为质量问题而返工,致使质量和进度风险加大时才安排单元测试。为避免更多的质量和进度风险,必须对遗留代码进行单元测试。单元测试倡议者、附和着、管理者、实施者需要对规模较大的代码集进行拆分,以适配选择单元测试的可用资源、技术和设施。可能选择包括:

以单个代源码源文件为单独测试任务:这种任务划分方式重点关注逐个验证文件内包含的代码单元;有利于集中精力查找和排除小范围代码的缺陷、而且可以统一制定测试配置,由多人共享,适合短期采用;

以紧密耦合源码源文件为单独测试任务;这种任务划分方式重点致力于验证跨文件、紧密耦合的代码单元;测试工程和配置可由多人共享,适合个人、小组、测试时间合理时采用;

以被测应用所有源码文件为单一测试任务;这种任务划分方式适宜于于验证应用整体逻辑依赖;对于集中测试、回归测试,代码修改后回归测试以及无依赖分离、运行平台资源富裕的场景,这种方式有较高效率;

选择不当引发的风险

可能耗费大量时间、人力调试环境。尤其当应用采用单一测试任务时,代码之间依赖性强,耦合紧密。测试代码段的输入、输出设定难度加大,缺陷分析定位效率下降;

 

接着分析“选择测试技术”对单元测试的影响

IT业界存在多种不同特点单元测试的技术和方法,如静态代码分析、动态性能分析、功能验证等,具体测试技术对不同应用类型、编程语言和实现技术呈现的效率也不同。IT人需要确定与应用架构/逻辑、企业发展战略匹配的测试技术,具体的参与者就是单元测试的倡议者、附和着、管理者。

可能选择

若单元测试重点是验证代码是否遵循规范,则可以选择静态源代码分析方法,而且可以基于可复用的检查规则、引入工具执行快速分析;测试过程无需运行构造、运行被测代码;如果选择缺省检查规则集,还可以节省人力、时间投入。不利因素是静态分析如需要特殊规则定制,必须由掌握专门规则定制技能的人员承担,如果必须依赖特殊规则进行静态分析,定制决策需要谨慎把握;

作为增强测试效果的手法,品质伙伴建议IT人选择应用执行时跟踪分析技术,优势是可以复用规则,无需单独进行用例设计;不同于静态分析,这种方式需要构造和执行应用,如果必须依赖特殊规则进行运行时分析,规则的定制需要谨慎把握;

品质伙伴以为,完善的单元测试必须包含受控状态下代码的动态执行和预期结果对照分析,这种方式是业务逻辑验证的有效方式,包括执行灵活设计的针对性用例,还可以兼顾功能和性能测试;

测试技术选择不当引发一些列风险,包括

耗费大量时间、人力学习,低水平重复,成效差--缺陷暴露率低;

测试资产积累和测试技术缺少重用价值;

 

接着分析“选择测试框架”对单元测试的影响。

测试框架指各种降低手工测试操作强度、改善测试效率的应用程序、共享库以及辅助设施,可以包括用例生成、记录、构造及执行控制、过程跟踪、执行结果汇总等功能单元。测试活动具有操作频繁重复、派生数据量大、结果呈现方式多变等特点,如果采用手工方式实施测试,则需要投入大量的人力和时间,对于成规模的代码,无疑意味着相当大的投入。

IT人需要跟据应用特点选择支撑已有测试技术的测试框架。具体的选择人就是单元测试的倡议者、附和着、管理者;

可能选择包括

开发团队或个人若注重测试过程的技术创新、团队技能增强等,可以不用第三方框架。这种方式的优势是能够灵活、无冗余地落实测试,瞄准应对特定应用的测试要求,不足之处是大量基础测试功能必须独立实现,需要更多的时间、人力投入;如果特定应用特性需要发生变化,必须同时更新大量测试资产;

如果开发团队希望兼顾创新和测试效率,注重分享成熟经验,可能引入开源框架;这就需要开发人员学习、熟练使用框架API;不足之处是大多数开源框架下的测试用例开发类似于编码,工作效率不高;

如开发团队注重开发效率、希望发挥开发人员业务知识优势,可以选择商业测试框架;优势是易用性较高,可以根据需求定制静态检查规则;缺点是需要较高初期投资;

测试框架如果选择不当可能引发一些列风险

产品质量缺陷是否及时发现、风险能否降低、市场机会得以把握;

开发人员的测试知识和能力是否明显提升,竞争力增强;

资本投入是否收到预期回报。