【软件测试-5】& 进阶篇_软件测试 pc主流屏幕分辨率

本节学习：测试分类的划分

按开发阶段划分

测试金字塔理论

SDK，全称：SoftWare DeveLopment Kit，一般是指软件工程师特定的软件包建立的开发工具集合。

ROI：投入产出比

从测试金字塔可以得出以下结论：投入相同的人力和精力，从下往上，产出会越来越少

越往上层，它的产出越低；

越往上层，定位问题越困难；

越往上层，测试效率越低；

单元测试(Unit Testing)

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试

举例

手机功有很多，女孩子都喜欢用美颜功能，突然有一天美颜功能不可用了，怎么办？只针对这一功能的代码进行测试。
1

测试阶段：编码后或者编码前（TDD）(Test-Driven-Development)；

• 开发前：TDD(Test-Driven-Development)，也叫测试驱动开发，测试驱动开发就是测试人员先写测试脚本，一开始是没有代码的，这个脚本跑起来肯定会跑异常的，开发人员去分析这些异常，根据这些异常去慢慢的补充代码，直到测试脚本跑的时候没有任何问题，这就是测试驱动开发（先写测试脚本——根据报的异常开发人员去填代码——直到没有任何问题）
• 测试驱动开发对测试人员的要求很高，你不仅仅要把各方面的测试用例想明白，而且还要用代码的方式表示出来。

测试对象：最小模块（单元模块）；

测试人员：白盒测试工程师或开发工程师（白盒测试工程师主要是对代码进行测试，所以必须要懂代码）；

测试依据：代码和注释+详细设计文档；

测试方法：白盒测试（所有看代码的，与代码相关的测试都是白盒测试）；

测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试；

• 模块接口测试：用接口测试主要关注输入、输出，输入的话主要是看输入参数，输入参数的数量、类型、类型的排列顺序，输出的话主要是看否符合接口设计文档
• 局部数据结构测试：局部数据一般出现在方法里面，对于一个类而言，方法里面给他定义一个变量，就属于局部变量，如果在方法的外面，类的里面定义的变量就属于全局变量（针对这个类来说），在测试的时候，也要把在方法里面定义的这个局部变量在经过不同的逻辑（如，判断、循环）之后，值也相应地发生变化后，追踪测试这个值是否是正确的。
• 路径测试：如if else ,switch中的case1,case2…要保证每一个路径都能正确走过
• 错误处理测试：当碰到类似异常一样的东西，看是把它throw出去还是捕获异常（try…catch…finally）,如果throw出去的话，那这个错误就在上一层了，那就测试上一层该做什么样的处理，以什么样的方式展现给用户；如果用try…catch的话，在测试的时候要想办法让它发生异常，看它是不是真的能够捕获,捕获完了之后是不是真的会执行finally里面的东西。只写错误用例而不去测到底写的对不对，这是不行的。
• 边界测试：如，有一个for循环，for循环中的i从xx开始到xx结束，它的条件（小于等于或小于的数）就是它的边界，要测试这个for循环是否超过这个边界了；还有while,它里面也有循环条件，也涉及到了边界；还有do while等

我们发现，所有的测试内容只有看到代码之后才能去测，因为只有看到代码才会知道这个代码里面有啥，然后才会有针对性的去测，所以说，单元测试其实就是针对代码进行测试。

集成测试(Integration Testing)

集成：它是按照一定的策略（逻辑结构），组合单元模块形成一个功能模块

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

举例

手机拔打电话
通讯录可以添加、删除、更改手机号码
打电话，可以手动输入电话，也可以从电话本中查询需要打给哪个人的电话进行拔打，手动输入的电话可以正常拔打，
电话本查询出来的不能拔打出去？
1
2
3
4

测试阶段：一般单元测试之后进行；

测试对象：模块间的接口；

测试人员：白盒测试工程师或开发工程师；

测试依据：单元测试的模块（即详细设计文档）+概要设计文档；

测试方法：黑盒测试与白盒测试相结合（即灰盒测试）；

测试内容：模块（接口）之间数据的传输测试、模块和模块之间的功能冲突测试、模块组装功能的正确性的测试、全局数据结构的测试、单模块缺陷对系统的影响（单个功能模块的缺陷对整体的影响的测试）

系统测试(System Testing)

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

举例：

新买手机都会有一个合格标签，在出厂前手机厂会所某型号的手机上的所有功能全部测试一遍。包括手机硬件本身，手机上自带的APP。
1

测试阶段：集成测试通过之后

测试对象：整个系统（软、硬件）

测试人员：黑盒测试工程师（即功能测试工程师）

测试依据：需求规格说明文档

测试方法：黑盒测试方法

测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

回归测试(Regression Testing)

在什么时候进行回归测试呢？

在系统引入新的代码的时候会进行回归测试；如：增加新功能、修改过BUG之后

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

举例

接着上边的美颜功能不可用的例子，拿去维修点进行了维修，拿到手机后第一件事情是先看美颜功能修好了没有，第二事情就是看看手机的其它常用功能是否正常
1

回归测试的策略如何去做？

回归测试的策略很重要

第一：我们要学会评估回归测试的范围，这要求一个人的技术，经验，能力要好；

第二：自动化测试；

• 评估回归测试的范围：也就是在增加了一些新的代码之后，这个代码的影响范围自己要做一个评估，评估这个代码可能会影响到哪一些功能，然后只对它可能影响到的一些功能做一个回归测试，而不是一股脑的把所有功能都重新做一个测试。这样就会把回归测试的范围缩小了 ，但是这种方式可能也不是很保险，可是所有都测的话又很麻烦，因此，我们可以使用自动化测试进行测试。
• 自动化测试：每次有一些新的功能在项目初期开始迭代的时候，如果人力、技术允许的话就可以对每一个主要的核心功能都给它写一个自动化脚本进行测试，自动化脚本写好之后再次增加新的功能的时候，只需要在写好的脚本上添加新功能的测试脚本就可以了，也就是每一次做功能的迭代的时候把这个自动化脚本也迭代一下，迭代完之后每次做回归测试的时候把这个自动化脚本跑一遍就行了，如果有问题的话脚本也可以帮助我们纠错。并且，自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

总结：回归测试在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

冒烟测试（smoke testing）

冒烟测试：就是对系统的主要功能和核心的流程进行测试。

为什么只对主要功能和核心流程进行测试呢？

因为它是评判系统是否进入正式的测试环节的依据，即准入原则。

举例

新买手机回来，第一件事情是把常用功能试一遍，第二件事情把所有的功能试一遍。
1

• 冒烟测试，这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。也可以理解为该种测试耗时短，仅用一袋烟功夫足够了。
• 冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
• 冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时，测试人员会先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。
• 针对冒烟测试也还有一个专门的测试用例——提测用例（系统提交测试的用例）：判断系统是否能正式地提交给测试人员的用例
  • 提测用例很少，它主要针对本次迭代的主要功能和系统的核心流程进行测试用例的设计。
  • 它一般需要我们单独去写，不会把它放在真实的系统测试里面。

验收测试(Acceptance Testing)

验收测试就是：客户（甲方）按照用户的需求对系统进行测试。

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买者展示该软件系统满足原始需求。

举例

买到新手机，一般会有7天包退，一个月包换，我们会尽量在7天内把手机的所有功能都试一遍。
1

测试阶段：系统测试通过之后

测试对象：整个系统（包括软硬件）。

测试人员：主要是最终用户或者需求方。

测试依据：用户需求、验收标准

测试方法：黑盒测试

测试内容：同系统测试一致，除此之外，还有文档测试（软件设计文档、功能设计文档、用户使用手册、详细功能使用文档等）

按测试实施组织划分

α测试(Alpha Testing)

α测试：就是让用户到开发环境下进行测试

优点：用户在测试过程中发现的问题可以及时的反馈给开发人员，及时的得到解决

缺点：用户在开发环境下进行测试时，容易受开发人员和测试人员的影响

β测试(Beta Testing)

β测试：就是实际用户（实际在使用软件的用户）在真实的环境下进行测试，测试的环境、地域不受限制

优点：用户测试的结果更接近用户实际使用的情况的反馈

β测试是在α测试之后

β测试和α测试的对比

• 地域不一样：α测试是在开发环境下，β测试是在用户实际使用环境下
• 时间的集中程度不一样：α测试的测试时间相对比较集中，β测试的测试时间相对比较分散
• β测试是在α测试很长一段时间之后才进行的。

第三方测试

第三方测试：既不是用户测试也不是由专门的测试人员去测试，而是由软件的第三方测评机构进行测试。

为什么会有第三方测试？

因为，如果让用户测试的话，用户会站在自己的角度进行测试，让测试人员测试的话，测试人员也会站在自己的角度，凭借自己的经验进行测试，但是有些软件是有一些标准存在的，不能再从自己的角度进行测试了，而第三方测试就比较客观，它会按照这些标准进行测试，因此，就有了第三方测试。

按是否运行划分

静态测试(Static testing)

静态测试就是不运行代码来测试。

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下

• 检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。
• 静态质量：度量所依据的标准是ISO9126。在该标准中，软件的质量用以下几个方面来衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Effiffifficiency)、可维护性
  （Maintainability）、可移植性(Portability)。
• 下图是最新的ISO25010静态质量标准
  

注：代码静态分析和文档测试都属于静态测试

动态测试(Dynamic testing)

动态测试就是写测试用例，运行程序，对系统进行测试，查看分析系统的输出是否符合预期。
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。

注：大多数软件测试工作都属于动态测试。

按是否手工划分

手工测试(Manual testing)

手工测试就是： 设计测试用例，运行程序，一步一步手动执行测试用例，对系统进行测试，这是最传统的测试方法，也是用的最多的一种测试方法，但是它是有一定的缺陷的，如果数量太大，就会容易出错，因为人总有疲惫和走神的时候，再者就是效率十分低。

当然，它也是有自己的优点的，测试时比较灵活，可以根据不同的实际情况进行对测试用例的修改和完善，自动化测试是永远都无法代替手工测试的。

手工测试就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。

总结优缺点：

优点：自动化无法替代探索性测试、发散思维结 果的测试。

缺点：执行效率慢，量大易错。

自动化测试(Automation Testing)

自动化测试就是把手工测试的测试用例转换成自动化脚本，让机器（电脑）去执行脚本；给定预先设计好的条件和结果的预判去执行；

自动化测试从底层来说有：接口自动化、性能自动化、web自动化、app自动化。不同的自动化用的框架和接口也不一样。

• 接口自动化可以用：dijago、RobertFrameWork框架；
• 自动化：使用unittest框架和selenium工具；
• app自动化：appium,阿里巴巴有一个开源的Macaca,它里面的很多组件、原件和appium差不多一样
• 自动化测试需要掌握Java或python语言中的至少一门。

自动化的意义（价值）：解放双手，提高测试效率，节省大量的人力和时间资源。

如何判断一个自动化脚本是否有价值呢？

就是看自动化脚本的使用频率高不高，使用频率越高越有价值。

什么样的项目可以使用自动化？

（1）项目周期长，需要不停地迭代；

（2）适用于需求比较稳定的项目；

如何去做自动化？

• 自动化实施步骤：

1.完成功能测试，版本基本稳定

2.根据项目特性，选择适合项目的自动化工具，并搭建环境

3.提取手工测试的测试用例转化为自动化测试的用例

4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期

5.生成自动测试报告

6.持续改进，脚本优化。

按照是否查看代码来划分（非常重要！！）

看代码的是白盒测试，不看代码的是黑盒测试，不管黑盒、白盒，抓住bug就是好盒。

黑盒测试(Black-box Testing)

黑盒测试就是测试的时候只关心输入和输出，不去看功能的内部逻辑和代码的具体实现。

黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。

注：系统测试就是黑盒测试。

白盒测试(White-box Testing)

白盒测试就是对程序的内部逻辑，结构，功能进行的测试。

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果。

• 白盒测试的方法：语句覆盖法（即代码中的每一个语句都要执行到）、逻辑覆盖法（基于代码里面的具体实现）、循环覆盖法（如for循环、while循环、do…while循环中的每一个语句都要执行到）
• 逻辑覆盖法：有路径覆盖、判定覆盖、判定组合覆盖、条件覆盖

注：接口测试/单元测试就是白盒测试的一种 。

灰盒测试(Gray-Box Testing)

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的逻辑结构。

按测试地域划分

国际化测试

• 软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。
• 软件国际化：就是开发了一款软件的时候运用了一种工程技术，可以使得软件使用不同国家的语言和当地的风俗习惯而不用修改软件的源码。

如何进行软件国际化测试？

本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试 的一些要点。

1、本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否整齐、不走样。

2、是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。

3、在不同的屏幕分辨率下界面是否正常显示。

4、是否存在不同的字体大小，字体设置是否恰当。

5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。

6、排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。

7、在不同的国家采用不同的度量单位，软件是否能自适应和转换。

8、软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上，如（美国芯片）。

9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。

10、联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误。

软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测 试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。

本地化测试

之前我们所讲的全是本地化测试。

【备注】：软件国际化测试和本地化测试是融为一体的，它们是相互依存的，实现国际化其实就是为了本地化，进行本地化测试也是为了让软件能够国际化。

按测试对象划分（非常重要！！）

业务测试

界面测试

• 界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
• 一般大厂都有自己的规范可以作为测试参考。中小公司这部分测试一般都没有，除非明确的错误，否则容易和开发人员引起争议。

界面测试都包含哪些方面呢？

文字测试：字体大小、字体类型、字体粗细、斜体、字体颜色、是否加下划线、是否是链接等；

图片测试:大小、颜色、清晰度、排版、是否重叠等‘

控件测试：按钮、文本框、滚动条、下拉框、勾选框等

有效控件和无效控件：置灰（无效控件）、高亮（有效控件）；

备注（提示说明）：语言是否清晰，表达是否清楚；

整体布局排版；

一些常见的界面错误

界面测试常见的错误：不合适的快捷键，文字丢失（没有正常展示），没有对齐，截断，重叠展示，重复的快捷键等。

响应式测试

什么是响应式？

响应式测试就是系统的页面可以随着屏幕的分辨率不同而自适应。

如何进行响应式测试？

响应式测试需要注意的地方;
(1) 页面上的文字随着屏幕分辨率变化的时候不会出现重叠、遮挡、消失；

（2）页面上的图片随着屏幕分辨率变化的时候不会出现模糊、重叠、遮挡、消失；

（3）页面的功能随着屏幕分辨率变化的时候没有消失；

（4）页面的功能随着屏幕分辨率变化的时候可以正常使用；

（5）要严格遵循UI设计图；

（6）页面在不同的屏幕分辨率进行衔接，衔接是否丝滑，不出现断层；

容错性测试

当系统因为外部环境的影响，或者用户的误操作，导致系统内部发生错误，但是系统可以自我处理，使系统正常稳定运行。

数据级别的容错性：日期、货币、时间；

验证级别的容错性：查询信息的前后空格（如从百度中查询一个词条的信息，在搜索框中词条前后输入空格，也能查到相关内容）,这里使用的是trim()；验证码输入错误；同一个系统前后信息的容错处理；密码和确认密码；

环境容错处理：当系统运行的时候出现断电、断网、服务器故障的时候可以随时切换用电器、网络，备用服务器，并让用户无感知。

界面容错处理：进行一些危险或者用户禁用操作的时候，有没有给用户提示或者把这些功能屏蔽，比如：（1）注册的时候账户和密码的位数限制，当用户输入最大位数的时候就禁止输入了。（2）用户只能输入一些规定好的固定选项的时候，以下拉框的形式展示；（2）在一些复杂容易出错的操作，会给用户提示。

灾难恢复性测试：人为地让系统发生一些故障，让系统出现断网断电，系统崩溃的极端情况，检测系统是否可以自我恢复数据，以及恢复这些数据的正确性和耗时。

文档测试

文档测试就是在软件开发过程当中产生的文档进行测试，它可能有软件设计文档，软件流程图文档，功能分析设计文档，用户使用手册等。

文档测试关注点：

• 文档测试主要测试文档和软件系统的一致性（即测试文档中写的功能，软件系统中也要都有。）
• 文档的专业术语要得当，
• 文档的正确性；
• 文档的完整性（文档内容要完整）；
• 文档的易用性（容易阅读和理解）；

兼容性测试

兼容性主要是指软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。

大家经常上网，同一网站在不同的浏览器上表现不一样，有遇到过吗？IE-工具-兼容视图设置
1

WEB系统的兼容性（WEB的兼容性测试）

• 平台测试
  • Windows系统:Windows10、Windows7
  • Mac:IOS的不同版本
• 浏览器测试
  • 浏览器：Firefox、Chrome、edge、Opera、Safafi、360、IE、QQ浏览器

看浏览器是在哪一个平台上
这些浏览器需要分别安装在WIndows10上、Windows7上、Mac 的IOS的不同版本上安装，安装好之后，分别去测系统上不同的浏览器的效果是什么样的；

对当下市场上每一个的浏览器的主流版本也要进行测试

最常见的就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面的显示不同。常见的IE8的兼容性。

为什么要测试这么多的浏览器？

原因：不同的浏览器内核不一样，对同一个页面的解析不一样。

举例：同一个网页在不同浏览器下打开后的解析情况

从图片中可以看出在IE浏览器中打开，解析不完整；

在火狐和谷歌浏览器中虽然打开了也成功解析了，但仍有一些解析不一样的地方（蓝框中框住的）。

APP的兼容测试

• APP分不同的版本，一个是IOS,一个是Android，IOS APP和Android
  APP它用的是两个不同的开发包，它是由两种不同语言开发的，是两个不同的东西，不能说同一个APP的安装包既能安装在IOS上，也能安装在Android上，一定要区分清楚。
• IOS系统:iPhone6S、iPhone12、iPhone13…不同的苹果机型有不同的版本，我们要在不同版本上进行IOS系统的主流版本的测试；
• Android系统:
  华为、小米、vivo、OPPO、魅族…不同的品牌有不同的机型，我们要在每一个机型上进行Android系统的主流版本的测试；

兼容性测试的策略可以采用自动化测试。

如：Android系统，不同的品牌有不同的机型，不同的机型也有不同的版本，人工测试耗时耗力，如果要提高效率就需要采用自动化测试

如何采用自动化测试进行测试呢？

先把脚本写好，写好之后就可以把不同品牌的不同机型及不同机型的不同版本给它放到一个配置文件里面，然后每次运行脚本的时候，如果换不同的手机的话，就只需要在这个配置文件里面将手机的各种配置给它读取一下就好了。脚本里面的测试内容不用变，每次只需要根据测试不同的机型或版本换相应的配置就好了。

• 软件本身能否向前或者向后兼容（如对某一个软件做迭代，此次迭代的功能不能影响历史功能也不能影响后续再开发功能时的进一步扩展）
• 测试软件能否与其它相关的软件兼容（如：淘宝和支付宝之间的兼容（关联），在淘宝上买的东西也可以在支付宝中查看物流或查看钱花去哪了，买了什么东西等）
• 数据兼容性测试（如某一个APP上买的东西花费的钱数在支付宝上也会有相同的数据显示）

易用性测试

易用性测试也称用户体验性测试（UE）。

手机拔打电话功能不放在首页，放在一个目录下边，点击三四次才可以找到拔打电话功能，这个功能好用吗？
1

易用性（Useability）是交互的适应性、功能性和有效性的集中体现。易用性属于人体工程学的范畴，人体工程学（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科。

易用性测试要注意的东西：

符合标准规范、直观性、灵活性、舒适性、实用性等。

安装测试

测试程序的安装、卸载

典型的是app的安装、卸载

app的安装方式的测试有哪些？

• 应用商店、安装包、命令行（测试环境下）、压缩包解压，第三方应用安装（如电脑管家，手机助手等），要对这些安装方式都要测试一下；

app的卸载方式的测试有哪些？

• 应用商店卸载、桌面卸载、第三方应用的卸载、命令行卸载（测试环境下）；

app安装、卸载需要测试的情况有哪些？

• 测试在断电、断网情况下的安装和卸载；
• 安装过程中空间不足怎么办？
• 安装过程中如果暂停，继续安装是否会成功安装
• 安装过程中手机突然关机，手机重新开机后是否还可以正常安装和卸载；
• 卸载的过程中是否可以清除产生的所有相关数据等等；

安全测试

• 安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，需要熟悉各种网络协议TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等。
• 从软件来说，熟悉各种攻击手段，例如SQL注入、XSS注入、上传下载（对于付费，保密的文件进行测试，防止会被半路截取信息；在上传的时候，防止上传有病毒的文件；上传过大的文件或下载过大的文件）。防爬虫测试、黑客、病毒等。

作为web入门测试，可以IBM的appscan。

性能测试

性能测试就是检查系统是否满足需求规格说明书中规定的性能。

为甚麽要进行性能测试？

（1）希望用户能够有很好的体验，系统能够快速的响应用户的需求；

（2）系统能够处理预期的用户负载；

（3）系统能够处理预期的事务数量；

（4）系统在满足以上指标的情况下，可以稳定的运行，用户也要有良好的体验；

性能测试的通用测试：

响应时间（最需要考虑的）：响应时间是有一个3/5/10原则

TPS：(Transaction Per Second)每秒处理的事务数量（越多越好）;

吞吐量：系统在单位时间内处理的信息量；

点击率：每秒向服务器发送的HTTP请求的个数；

系统在运行时占用的资源的情况：CPU、内存、磁盘、网络带宽、耗电量（占用系统资源越少性能越好）

通常表现在以下几个方面：

对资源利用（如内存、处理机周期等）进行的精确度量

对执行间隔

日志事件（如中断，报错）

辅助存储区（例如缓冲区、工作区的大小等）

处理精度等进行的监测

内存泄漏测试

内存泄漏测试就是在分配内存的时候，没有及时释放内存或者无法释放，导致系统运行占用的内存越来越多，系统运行越来越慢，甚至崩溃。

电脑打开的东西太多，机器反应慢甚至死机，重启之后就好了，过会同样的问题出现了。
1

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH、Delphi等。从用户使用的角度来看，内存泄露本身不会造成什么危害，一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累积的，只要执行的次数足够多，最终会耗尽所有可用内存，使软件的执行越来越慢，最后停止响应。可以 把这种软件的问题比喻成软件的“慢性病”。

造成内存泄露的原因有很多，最常见的有以下几种。

• 分配完内存之后忘了回收。
• 程序写法有问题，造成没办法回收。
• 某些API函数的使用不正确，造成内存泄露。
• 没有及时释放。

内存泄漏的检测方法：

• 1、对于不同的程序可以使用不同的方法来进行内存泄露的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof. AQTime、Purify、BundsChecker等。 有些开发工具本身就带有内存问题检查机制．要确保程序员在编写程序和编译程序的时候打开这些功能。
• 2、通过代码扫描分析工具来检查
• 3、静态测试