打开BOSS应用软件测试的死结[3] 软件测试
二、第二步：通过回归测试确保新业务上线
所谓“新上线业务功能导致原有正常业务功能出错”，实际上就是“回归测试”做得不够，或者说，回归测试就是为了预防这种问题的发生才被提出来。
1.要做好的具体工作
严格来说，软件开发/集成商正式发布的软件，在经过大量的测试后，会形成一个针对该软件的测试用例库，其中的测试用例覆盖了现有的全部软件功能。而当增加一个新业务功能，针对该新业务功能本身，固然要做测试，但为了验证该新业务功能的代码或配置信息是否对原有功能产生消极影响，还必须经过完整的回归测试。从实际操作的角度来看，开发/集成商和运营商需要这些具体工作。
1)开发/集成商建立完整的测试用例库，并执行自动化的回归测试。为了确保新业务上线，能对原有功能执行严格的回归测试，必须能将回归测试自动化，并且这种自动化是依赖于原有功能的完整测试用例库的基础之上。没有完整、涵盖原有软件所有功能的测试用例库，就不可能知道要执行哪些回归测试;没有对回归测试自动化，不可能手工执行工作量如此巨大的回归测试，也就不可能真正做到“严格”。
2)营商搭建完整的回归测试环境，并执行必要的回归确认测试。一般来说，运营商在新业务功能上线前，均会对新业务功能本身进行确认测试。但即使在开发/集成商做过严格的功能回归测试后，运营商仍然还需要对其进行必要的回归确认测试，尤其是针对相关联的业务功能来说更加如此。实际上，回归确认测试工作量往往数倍于新功能本身的确认测试，所以这部分工作不能忽视。
2.工作落实建议
第一个工作实际上是以第一步“加强上线前开发/集成商的软件测试”的所有工作内容为基础。没有完整而务实的测试工作流程，就不可能有完整的测试用例库;没有自动化回归测试工具，就无法录制这些测试用例的自动化回归测试脚本(开发/集成商自行编码实现自动回归测试，工作量一样很大，不现实)，也就不可能进行严格的回归测试(对于BOSS这样的大型应用软件，回归测试是不可能通过手工测试能够做好的)。做不到第一步中的五点工作内容，“执行严格的回归测试”将会成为一句空谈。
第二个工作，一方面需要运营商提供设备、开发/集成商负责搭建并维护一套完整的测试环境。另一方面，作为客户，运营商在安排新业务功能的确认测试工作量和工作时间时，要充分考虑到回归确认测试。如果不承认这个必要的工作，往往不可避免会出现“新上线业务功能导致原有正常业务功能出错”这样的问题。
三、第三步：通过性能测试保证系统支撑能力
1.要做好的具体工作
之所以出现系统性能越来越差，越来越慢，直至某天系统开始宕机这样的现象，完全是因为随着系统新业务功能的不断开通，以及系统支撑用户量、数据量的增长，没有量化地把握系统支撑能力变化趋势，从而无法掌控系统支撑能力的发展所致。为此，需要做好以下这些工作。
1)对新上线业务功能执行量化的性能测试和分析。由于缺乏新上线业务功能对生产系统产生多大影响的量化性能测试和分析结果，所以无法把握新功能所消耗部分的系统资源所代表的设备成本。而通过对所有新上线业务功能的量化性能测试和分析，就可以做到心中有数，准确地掌控系统荷载情况的变化趋势，从而及早地预测出系统支撑能力的“临界点”。
2)及时对新业务发展或系统支撑能力做出调整。仅仅有了上述的工作基础，仍然不能彻底解决问题，还需要将这些量化的数据作为决策的依据，是在系统支撑能力限制下有选择的调整新业务的实现方式，还是及时、有计划地扩充系统支撑能力，都是必须要执行的工作内容。
2.工作落实建议
对于第一项工作，在运营商提供完整测试环境和工具软件的前提下，开发/集成商应当在运营商的明确要求下，认真落实执行这个工作要求，并定期向运营商提交量化的测试分析数据，以及针对业务实现方式或系统扩容的实际可行的调整建议。
在开发/集成商做好第一个工作内容的基础上，运营商要做到的，就是及时关注这些测试分析数据和调整建议，并有计划地安排和落实执行。只有这样通过双方的共同努力，才能确保应用系统的真正稳定可靠运行。
总结
总的来说，切实做好第一步工作，或者说解决好第一个问题，才是打开BOSS应用软件测试死结的关键所在。没有了第一步的落实执行，后两步的工作缺乏基础，就显得空洞而不务实。而做好第一步的工作，关键是开发/集成商和运营商双方面的努力：一方面开发/集成商要在管理上建立完整而实用的测试流程并确保执行，和培养合格的测试队伍;另一方面运营商要在系统建设之初就充分考虑测试环境方案，以及要求开发/集成商引入并使用好相应的自动回归和性能测试工具。
文章来源于领测软件测试网 https://www.ltesting.net/
