认识达内从这里开始

系统测试是软件测试程序员在测试软件的时候会经常用到的一个测试方法，而本文我们就通过案例分析来简单了解一下，系统测试实践包含哪些策略。

1.系统测试的对象和测试目标

我们可能会有这样的疑问：在集成测试结束的时候，这个心形图案就已经完成了，并且我们也进行了测试，为什么还要再进行系统测试呢?或者说这个问题从测试的角度来看，就是已经在集成测试中执行了的测试用例，在系统测试中还需要再执行一遍吗?集成测试和系统测试的差异主要在哪里?

做集成测试的时候：

目光是紧盯着新开发的功能的。而且随着功能的不断集成，系统的复杂性开始急剧膨胀，我们很难(或者说没有足够的测试时间，或是说系统还不够稳定)来把和功能相关的所有组合都验证完。

更重要的是，集成测试主要还是针对功能的集成，在集成测试中我们无法(或者说没有足够的测试时间，或是说系统还不够稳定)对被测对象的其他非功能方面的质量来进行测试验证。、

在系统测试中需要测试的主要内容包括：

从系统角度来验证测试功能的正确性。

从系统角度来验证各种非功能的质量的正确性。

2.入口准则——何时可以开展系统测试

系统测试的入口准则，就是集成测试的出口准则，再加上一条：测试团队已经做好了测试准备，包括测试用例、测试资源和测试环境都已到位。

3.测试用例选择

现在我们来回答本节开头提的问题：我们在集成测试中执行了的测试用例，在系统测试中还需要再执行一遍吗?

答案是，系统测试和集成测试的测试用例肯定会有相同的部分，但并不是简单地重复一遍，而是存在一定的选择策略。

针对“系统角度的功能测试”：可以选择level1和部分level2的测试用例。

针对“非功能的质量的正确性”：可以选择level3的测试用例和level4的测试用例。

4.测试执行顺序

我们在集成测试中并没有讨论测试执行顺序，是因为集成测试的测试对象很单一，就是“功能”。虽然后面我们提到在集成测试的后期，可以考虑增加一些“非功能方面”的测试，但是总的来说这并不会给测试带来先执行什么再执行什么的困扰。

软件测试架构师在考虑测试执行顺序的时候，可以基于如下几点：

有些测试方法本来就需要满足一些条件才能进行。例如，满规格测试需要在基本功能正常的情况下才能进行，否则将很难区分问题到底是出在规格上，还是功能上。这就需要我们按照测试方法本身的条件来安排测试执行顺序。例如，先进行稳定测试，再进行压力测试，然后进行恢复测试。

如果有两种测试方法，都能对测试对象进行测试，先进行复杂的，再进行简单的。或者说，尽量先执行复杂的、难的测试用例，再进行简单的测试用例。这样考虑的原因是，希望缺陷能够尽量在测试的前期发现，另外先执行难的测试用例也能保证这些测试用例有充足的测试时间。

可以考虑组合多种测试方法，或者说让测试者想办法把一些测试用例放在一起执行。例如，可以将功能测试的测试用例和满规格的测试用例放在一起进行，在满规格的情况下测试功能。这种测试执行顺序特别适合系统测试中需要重复执行、集成测试中已经执行过的那些测试用例，往往可以发现很多新的问题。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。