性能测试：如何评价系统的极限性能？
答：并发度，相应时间，单位时间吞吐量，系统稳定性，多场景。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行，通过负载测试，确定各种负载系统下的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统提供的最大服务器级别的测试。
软件测试中，集成测试的步骤是什么？
1.采用何种系统组装方法来进行组装测试。
2.组装测试过程中连接各个模块的顺序；
3.模块代码编制和测试进度是否与组装顺序有关；
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.导致模块测试完成延后 |
| 自底向上 |
|
| 优点 |
缺点 |
|
|