性能测试:如何评价系统的极限性能?算法
答:并发度,相应时间,单位时间吞吐量,系统稳定性,多场景。编程
性能测试是经过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,二者能够结合进行,经过负载测试,肯定各类负载系统下的性能,目标是测试当负载逐渐增长时,系统各项性能指标的变化状况。压力测试是经过肯定一个系统的瓶颈或者不能接受的性能点,来得到系统提供的最大服务器级别的测试。设计模式
软件测试中,集成测试的步骤是什么?服务器
1.采用何种系统组装方法来进行组装测试。并发
2.组装测试过程当中链接各个模块的顺序;框架
3.模块代码编制和测试进度是否与组装顺序有关;ide
4.测试过程当中是否须要专门的硬件设备;工具
5.集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。性能
(自顶向下和自底向上的集成测试方法)
单元测试
模块测试(单元测试)
模块测试是针对程序中单个子程序,子程序或者过程进行测试的过程,也就是说,一开始并非对整个程序进行测试。1.将注意力集中在程序的较小单元上,所以它是一种管理组合测试元素的手段。
2.模块测试减轻了调试(准肯定位并纠正某个已有错误的过程)的难度,这是由于一个某个错误被发现出来,就知道具体在哪一个模块中。
3.模块测试为咱们提供同时测试多个模块的可能,将并行工程引入软件测试。
模块测试的目的:将模块的功能与定义模块的功能规格说明或接口说明进行比较。
测试目标:不是为了说明模块符合其规格说明,而是为了揭出模块与规格说明存在矛盾。
测试用例的设计
模块测试测试用例设计以下:使用一种或多种白盒测试用例方法分析模块的逻辑结构,而后使用黑盒测试方法对照模块规格说明以补充测试用例。
模块测试过程当中,咱们有两点要考虑:1.如何设计一个有效的测试用例集。2.将模块组装成工做程序的方式
非增量测试:软件测试独立地测试每一个模块,而后将这些模块组装成完整的程序。
增量测试:将下一步要测试的模块组装到测试完成的模块集合集合中。
测试单独的一个模块须要一个特殊的驱动模块和一个或多个桩模块。
另外一种选择是增量测试,不一样于独立地测试每一个模块,增量测试首先将下一个要测试的模块组装到前面已经测试过的模块中去。
驱动模块:是人们编写的一个小模块,模拟被测模块的上一级模块,用来将测试用例驱动或传输到被测模块中(也能够数测试工具代替)。驱动模块还必须向测试人员展现被测模块的结果。
桩模块:是指被测模块所调用的模块,主模块是“驱动模块”,被测模块编制一些模拟下级模块功能的“替身”模块,代替被测模块接口,接受或传递被测模块的数据。
结论
1.非增量测试所须要的工做量要多一些。自底向上的增量测试须要驱动模块,但不须要桩模块。自顶向下须要桩模块,但不须要驱动模块。增量测试所需的工做量要少一些,由于使用过了前面测试过的模块来取代非增量中所须要的驱动模块或桩模块。
2.若是使用了增量测试,能够较早地发现模块中与不匹配接口,不正确假设相关的编程错误。这是因为尽早地对模块组合进行了集成测试,若是是非增量测试,只有到了测试过程的左后阶段,模块之间才能够“互相看到”。
3.使用了增量测试,理由如2所述,若是使用了非增量测试,直到程序组装后,这些错误才浮现出来,到了这个时候,就难以定位错误,由于他可存在程序的任何位置,很难定位。相反,若是是增量测试,这种错误就很容易发现,由于这个错误可能与最近添加的模块有关。
4.增量测试会将测试进行的更完全,换言之,增量测试用先前测试过的模块,取代了非增量测试中使用桩模块或驱动模块,所以,到最后一个模块测试完成时,实际模块受到了更多的校验。
5.非增量测试所占用的机器时间显然少一些,由于一个被测模块可能有多个子模块,而一个子模块可能只有一个驱动模块,因此完成一次增量测试所须要的机器指令,显然多余采用非增量测试方法所须要的指令。
6.模块开始时,若是采用非增量测试,就会有更多的机会进行并行操做。
自顶向下测试和自底向上测试
注:“自顶向下测试”,“自顶向下开发”和“自顶向下设计”经常使用做近义词,“自顶向下测试”和“自顶向下开发”确实是同义词,但“自顶向下设计”则是独立的概念,在自顶向下设计模式下的程序既可以使用自顶向下的方式也可使用自底向上的增量测试。
注:自底向上的测试常被错误地当作非增量测试,缘由在于自底向上的测试的开展方式与非增量测试是相同的(即对底层或终端的模块进行测试),可是自底向上是一种增量测试。
最后:两种方法都是增量测试。
自顶向下测试
自顶向下测试从程序的顶部或初始模块开始,测试开始以后,选取哪个后续模块进行测试没有惟一正确的方法。
1.惟一原则是:要成为合乎条件的下一个模块,至少是一个该模块的从属模块事先通过了测试。
2.若是桩模块只是返回了控制,或显示出一条信息确却没有返回一个有意义的结果,主模块就会发生失效。这并非主模块存在错误而是由于桩模块未能模拟出相应的模块。此外,桩模块仅仅返回一个“已经连通”的结论是不够的。
3.另外一个须要考虑的是采起什么样的形式将测试用例提交给程序?(由于顶部模块既不传入参数,也不执行输入、输出操做)
解决方法:
1)编写桩模块的多个版本,每一个版本将不一样的有效测试数据返回给主模块。
2)将测试数据放在外部文件中,由桩模块读取并返回给主模块。
测试完顶部模块以后,接下来可能的测试序列有不少。总的来讲,不存在最佳模块序列,但有两项参考指南
1.若是存在程序的关键部分,那么在设计模块序列中应当把这些关键的模块今早地添加进去。所谓“关键模块”,多是复杂的模块,某个采用新算法的模块,或不被怀疑容易发生错误的模块。
2.在设计模式中应该把I/O模块尽量早地添加进来。
自底向上测试
大多数状况下,自底向上测试与自顶向下测试是对立的,一方的优势是另外一方的缺点。一方的缺点又是另外一方的优势。自底向上的策略开始于程序的终端模块,测试完这些模块以后,没有最佳的方法挑选下一个测试的模块。惟一的原则是:要成为合乎条件的下一个模块。有别于使用桩模块,因为驱动模块能够交迭地调用被测模块,所以不须要驱动模块提供多个版本,大多数状况下,开发驱动模块要比开发桩模块容易些。
自底向上的不足之处是:它没有早起程序框架的概念,事实上,直到最后一个模块被添加进来,才造成可工做的程序,它就是完整的程序。尽管I/O程序能够在整个程序集成测试以前进行测试。
自顶向下没有没法创建全部测试环境问题,若是驱动模块看作一个探测指针的话,那么将它直接放入被测模块,不会受到中间模块的影响,检查自顶向下相关问题的其余问题,不会作出设计和测试重叠的不明智的决定。由于自底向上的测试直到程序设计完成后才开始,没有测试完一个模块以前就开始另外一个问题也不会存在,这是由于自底向上的测试不在有如何将数据绑定到桩模块中去的烦恼。
自顶向下的测试 |
|
优势 |
缺点 |
|
2.桩模块比最初表现的更复杂 3.在引入I/O以前,向桩模块引入测试用例比较困难 4建立测试用例的环境困难 5.观察测试用例输出困难 6误解设计和测试能够交迭进行 7.致使模块测试完成延后 |
自底向上 |
|
优势 |
缺点 |
|
|