首页>>技术前沿>>网站/软件行业动态
如果不从一个系统的角度来思考软件质量，就无法真正构建出健壮的、让业务和团队都有信心的软件系统。质量从来都不只是QA的职责，而是整个团队的职责。关于软件质量，一个根深蒂固的误解是:缺陷在开发过程中被引入，然后在测试阶段被发现，最后在QA和开发的来回撕扯中被解决（或者数量被大规模降低），最后在生产环境中，就只会有很少的，优先级很低的缺陷。然而事实上，很多需求从开始就没有被仔细分析，业务价值不很确定，验收条件模糊，流入开发后又会引入一些代码级别的错误，以及业务规则上的缺陷，测试阶段会漏掉一些功能点，上线之后更是问题百出（网络故障、缓存失效、黑客攻击、操作系统补丁、甚至内存溢出、log文件将磁盘写满等等）。
一.新功能推迟/重复测试
按照用户故事的开发流程，开发人员完成功能后，多方角色会首先在开发人员的机器上进行用户故事的快速验收以及探索性测试，然后开发人员会提交代码，由QA拿到包之后部署到测试环境进行测试。但有的时候QA在开发机器上快速验收之后，开发人员又进行重构，曾经经历过“故事验收的时候功能都是正常的，拿到包部署之后好多功能不工作了”的事情，跟开发人员确认，又是重构导致的。有时候开发人员会在用户故事验收之后告知QA还会继续重构，QA可以等到重构完成后再拿新的版本做测试，这样就会导致用户故事的测试时间推迟。或者开发人员会先重构再做验收，而这样又会导致QA在开发机器上进行重复的验收测试。
二.无计划不可见
开发人员的重构时机对我们来说是无规律的。有的时候一边开发用户故事一边重构，有的时候会在故事完成后、QA在开发机器上验证结束后才做重构，有的是代码评审后大家指出问题后做重构，有的甚至得等到项目组来了有经验的开发人员才开始重构。对QA来说，重构的时机是无计划的。
另外重构也是不可见的。我们总谈可视化，日常的开发工作由用户故事和缺陷来可视化，而重构经常是幕后进行的，不被跟踪、不被记录、不可见，有经验的开发人员会在进行“大”的重构之前口头告知团队，如果没有告知，就在不知不觉中发生了，只有功能被破坏了才能意识到
三.瀑布模式中的QA
在这样的环境中，QA们能做的事情非常有限。在需求开始时他们会参加需求澄清的会议，制定一些测试计划，然后进行测试用例的设计。有的企业会用诸如Excel之类的工具来记录这些用例。这些在Excel里的，“死”的用例作用非常有限。而最大的问题在于：它们无法自动化执行。另外，在实际软件开发中，需求总是会经常发生变化，需求的优先级也会有调整，然后这些记录在Excel中的“死”的用例会很快过期，变得无人问津。
除此之外，QA中的有些成员会使用工具来录制一些UI测试的场景，然后在每个新版本出来之后进行回放。然而，当UI发生一点变化之后，这些自动化的用例就会失效：比如HTML片段中元素位置的调整，JavaScript的异步调用超时等等。
显然，这种单纯以黑盒形式来检查功能点的测试方式是不工作的，要真正有效的提升软件质量，仅仅通过事后检查远远不够，软件的质量也应该内建于软件之中。QA的工作也应该是一个贯穿软命周期的活动，从商业想法到真实上线，这其中的所有环节都应该有QA的参与。
总结
以上列出了QA不喜欢重构的三个理由，归根结底其实都是重构不当导致的。代码重构（Code refactoring）指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。而不当的重构往往只关注了前半部分却忽略了对输出结果的影响。
个人认为，如果能够注意以下几个方面，也许可以很大程度减少QA对重构的顾虑：
1. 充足的自动化测试是保障输出结果的一个有效途径。不管对于历史代码还是新代码，进行重构的前提应该是确保这部分功能已经被足够的自动化测试覆盖，有的开发人员认为这是一个不可行的
建议，因为“充足”对于每个人每个角色的标准可能是不一样的，QA也许永远都不会觉得测试足够，但是其实可以借助测试覆盖率等度量工具，甚至直接针对功能特性由QA来定义需要哪些自动化测试，在补齐这些自动化测试的基础上再做重构。
2. 对于新功能的重构，应该融入到正常开发过程中，在故事验收之前已经完成相应的重构，因为自动化测试不是万能的，也不可能达到100%的覆盖率，所以还是需要QA验证的。这么做就意味着
客户要为我们的重构买单，所以作为软件领域专家的我们，如何让业务领域专家的客户理解重构的价值，这就变的至关重要了。小步前进，尽量避免或者减少大的重构，这样可以减少突然增多的回归测
试工作量，也会减少功能被破坏的风险。如果发生了大的重构，反思一下是哪里出了问题？是我们积攒了太多的技术债？还是业务领域模型发生了大的改变？然后采取措施避免类似的事情再度发生。
对于一些核心功能或者组件，进行重构之前尽早告知团队QA，如果能够给QA讲解一下重构的目的以及本次重构可能会影响到的业务区域会对QA有很大的帮助。这样做一方面可以让QA把重心放在最容易受到影响的功能上加强回归测试，另一方面也能帮助QA更合理地安排测试计划。
版权声明:
1、陕西弈聪网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，百度关键词优化，西安软件开发等技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。
2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。
企业动态
