测试发现bug 开发不认为是bug的时候你怎么办？
说法一：
1、首先明确开发说不是bug的理由。
2、如果是需求变更， 那就找产品经理确认是否是需求变更。
3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。
4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。
说法二：
1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
说法三：
首先，将问题提交到bug管理库里面进行备案。
然后，要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供bug是否确
认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是bug；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
测试分类：
单元测试：
单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。
单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。
单元测试代码里提供函数的使用示例，因为单元测试的具体表现形式就是对函数以各种不同输入参数组合进行调用。
集成测试：
集成测试的含义非常简单- 将单元测试模块逐个集成/组合，并将行为测试为组合单元。
该测试的主要功能或目标是测试单元/模块之间的接口。
我们通常在“单元测试”之后进行集成测试。一旦创建并测试了所有单个单元，我们就开始组合这些“单元测试”模块并开始进行集成测试。
该测试的主要功能或目标是测试单元/模块之间的接口。
首先单独测试各个模块。模块经过单元测试后，逐个集成，直到所有模块都集成在一起，检查组合行为，验证需求是否正确实现。
在这里我们应该理解，集成测试不会在周期结束时发生，而是与开发同时进行。因此，在大多数情况下，所有模块实际上都无法测试，这就是测试不存在的东西的挑战！
系统测试：
系统测试是将已经继承好的软件系统，作为计算机系统的一个元素，与计算机硬件、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。
系统测试的目标是：通过与系统的需求规格说明进行比较，检查软件是否存在与系统规格说明不符合或与之矛盾的地方，从而验证软件系统的功能和性能等满足规格说明所制定的要求。
验收测试：
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。验收测试一般由用户派出代表和开发方的测试小组一起进行测试验收，但也可能有用户单独验收，总之方式不限，最终的目的还是用户满意并接收。
静态测试：
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
动态测试：
动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式。
白盒测试：
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
黑盒测试：
黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
逻辑测试：
指某个操作需要多个步骤实现，应有清楚的提示，或者向导来帮助用户完成，某项功能，从不同的入口进入有不同的操作路径，但是逻辑上应该是一致，系统的各种状态要按照业务流程变化保持稳定。
界面测试：
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
易用性测试：
易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用。
安装测试：
Installing testing（安装测试），确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。通常情况测试伴随安装的整个过程。
兼容性测试：
软件兼容性测试是指检查软件之间能否正确地进行交互和共享信息。随着用户对来自各种类型软件之间共享数据能力和充分利用空间同时执行多个程序能力的要求，测试软件之间能否协作变得越来越重要。软件兼容性测试工作的目标是保证软件按照用户期望的方式进行交互。
一般性能测试：
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
稳定性测试：
对软件多次测试，长时间运行，是否正常运行 长时间对软件开启关闭软件和系统是否正常软件长时间执行某个业务后切换到别的不同的业务操作是否受影响，软件长时间开启但是不执行任何操作，然后检查能否正常执行业务操作，软件长时间对日常的用户数进行操作运行，观察系统内存占用率是否越来越大，可用内存是否减少，内存是否溢出，饱和运算内存是否占用过大、是否溢出。
负责测试：
负载测试（Load testing），不限制软件的运行资源，测试软件的数据吞吐量上限，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。
压力测试：
软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。
回归测试：
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
冒烟测试：
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
随机测试：
软件测试中除了根据测试用例和测试说明书进行测试外，还需要进行随机测试，主要是根据测试者的经验对软件进行功能和性能抽查。
软件缺陷：
即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。
进行软件缺陷分析后,软件缺陷的主要可以分为以下几种类型：
（1）设计不合理;
（2）功能、特性没有实现或部分实现;
（3）运行出错，包括运行中断、系统崩溃、界面混乱等;
（4）与需求不一致，在执行TestCase时则为实际结果和预期结果不一致;
（5）用户不能接受的其他问题，如存取时间过长、界面不美观;
（6）软件实现了需求未提到的功能。
软件故障：
计算bai机中的”软故障”是于“硬故障”相对的概念。硬du故障就是硬件设备在zhi运行出现的问题dao；软故障就是软件（像windows系统、应用软件等）出现问题，软故障就是软件或系统在操作运行时出现的问题。
1.软件不兼容：有些软件在运行时与其它软件发生冲突，相互不能兼容。如果这两个软件同时运行，可能会中止系统的运行，严重的将会使系统崩溃。比较典型的例子是系统中存在多个杀毒软件，如果同时运行很容易造成电脑死机。
2.非法操作：非法操作是由用户操作不当造成，如缺载软件时不使用缺载程序，而直接将程序所在的文件夹删除，这样不仅不能完全缺载该程序，反而会给系统留下大量的垃圾文件，成为系统故障隐患。
3.误操作：误操作是指用户在使用电脑时，无意中删除了系统文件或执行了格式化命令。这样会导致硬盘中重要的数据丢失，甚至不能启动电脑。
4.病毒的破坏：有的电脑病毒会感染硬盘中的文件，使某程序不能正常运行；有的病毒会破坏系统文件，造成系统不能正常启动；还有的病毒会破坏电脑的硬件，使用户蒙受更大的损失。
排除方法：
1.注意提示：软件发生故障时，系统一般都会给出错误提示，仔细阅读并根据提示来排除故障常常可以事半功倍。
2.重新安装应用程序：如果在使用应用程序时出错，可将这个程序完全缺载后重新安装，通常情况下，重新安装可解决很多程序出错引起的故障。同样，重新安装驱动程序也可修复电脑部件因驱动程序出错而发生的故障。
3.利用杀毒软件：一些版本低的程序存在漏洞（特别是操作系统），容易在运行时出错。因此，如果一个程序在运行中频繁出错，可通过升级该程序的版本来解决。
4.寻找丢失的文件：如果系统提示某个系统文件找不到了，可以从操作系统的安装光盘或使用正确的电脑中提取原始文件到相应的系统文件夹中。
程序测试包含哪些内容：
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人，以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误，并解决它
20 如果有必要，重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具。
软件测试的原则：
对计算机软件进行测试前，首先需遵循软件测试原则，即不完全原则的遵守。不完全原则即为若测试不完全、测试过程中涉及免疫性原则的部分较多，可对软件测试起到一定帮助。因软件测试因此类因素具有一定程度的免疫性，测试人员能够完成的测试内容与其免疫性成正比，若想使软件测试更为流畅、测试效果更为有效，首先需遵循此类原则，将此类原则贯穿整个开发流程，不断进行测试，而并非一次性全程测试。
线性模型：
线性模型是一类统计模型的总称，制作方法是用一定的流程将各个环节连接起来，包括线性回归模型、方差分析模型。
迭代增量的理解：
迭代增量模型是软bai件开发过程中、常用的开发模du型。其中的增量是指zhi是软件开发dao过程中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。比如，需要开发一个类似WORD的软件，应该首先开发出文件管理（保存、读取文件）、基本编辑功能、打印等，而其它不太常用的功能可以最后开发。
迭代是指增量开发过程中，各模块的开发是反复进行的，并不是完成了某个模块后就终止该模块的开发转而开发下一个模块，以上面的开发WORD为例，比如，现在已开发了文件管理模块，正在开发编辑模块，但后来发现，文件管理模块有某些功能还没有实现，可以在编辑模块的开发过程中同时继续开发文件管理模块，如此不断的反复，所以说这个过程是迭代的过程。经过这样的反复迭代后该软件的功能就会越来越完善，最终开发出优秀的产品。
软件生命周期：
一个软件产品或者系统要经历孕育、诞生、成熟、衰亡等阶段，一般称为软件生命周期。软件生命周期是软件的产生直到报废的生命周期。为了使规模扩大、结构复杂和管理复杂的软件开发变得容易管理和控制，把整个软件生命周期划分成若干个阶段，使每个阶段都有明确的任务，整理出软件生命周期模型。
瀑布模型：
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
螺旋模型：
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
V模型的缺陷及解决思路：
V模型仅仅把测试dao过程作为在du需求分析、系zhi统设计及编码之后的一个dao阶段，忽视了版测试对需求分析权,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。
W模型：
W模型增加了软件开发阶段中应同步进行的验证和确认活动
W模型由两个V字模型组成，分别代表测试与开发阶段，图中明确表示出了测试与开发的并行关系
W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
W模型优点：有利于尽早地全面的发现问题。
缺点：需求、设计、编码等活动被视为串行的；
测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
无法支持敏捷开发模式。
对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
敏捷开发与敏捷测试：
敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
软件质量模型：
软件质量模型主bai要是指遵循一定的国际或国内标du准，主要zhi需要考虑一下六方面内容：
1.功能性：能够满足明确和dao隐含要求的功能
2.可靠性：能够处理异常情况，在错误中很快恢复
3.易用性：易懂、易学、易用、漂亮好看
4.效率性：占用的资源，提供适当的性能。通常，效率就是我们常说的产品性能
5.维护性：是指产品可被修改的能力
6.可移植性：是指软件产品从一种环境迁移到另外一种环境的能力
保密安全性：
保密性(confidentiality)是指网络信息不被泄露给非授权的用户、实体或过程。即信息只为授权用户使用。保密性是在可靠性和可用性基础之上，保障网络信息安全的重要手段。
网络信息安全中保密性是指信息按给定要求不泄漏给非授权的个人、实体或过程，或提供其利用的特性，即杜绝有用信息泄漏给非授权个人或实体，强调有用信息只被授权对象使用的特征。
⑴用户验证：登录密码验证、IP地址访问限制等 sql注入
用户超时:登录超过30分钟，重新登录(安全设置，cookie过期时间30分钟)
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。
软件可靠性：
软件可靠性 (software reliability )是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件；规定的时间区间是指软件的实际运行时间区间；规定功能是指为提供给定的服务，软件产品所必须具备的功能。软件可靠性不但与软件存在的缺陷和（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量称软件可靠度。
软件可维护性：
定义：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
目的：通过必要的维护工作使得系统持久的满足用户的需要
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
3、软件维护的分类：
1）改正性维护；
2）适应性维护；
3）完善性维护；
4）预防性维护。
4、软件维护的特点：
1）改正性维护：
A、在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。
B、这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。
C、为了识别和纠正软件错误、改正软件 性能上的缺陷、排除实施中的误使用， 应当进行的诊断和改正错误的过程就 叫做改正性维护。
2）适应性维护：
在使用过程中，
外部环境（新的硬、软件配置）
数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。
为使软件适应这种变化，而去修改软 件的过程就叫做适应性维护
3）完善性维护：
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。
为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
这种情况下进行的维护活动叫做完善性维护。
4）预防性维护：
预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。
预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制 和测试。
软件可移植性：
软件相对于具体计算机的独立性，从狭义上讲，是指可移植软件应独立于计算机的硬件环境；从广义上讲，可移植软件还应独立于计算机的软件，即高级的标准化的软件，它的功能与机器系统结构无关，可跨越很多机器界限。从一种计算机向另一种计算机移植软件时，首先要考虑所移植的软件对宿主机硬件及操作系统的接口，然后设法用对目标机的接口代换之。因此，接口的改造容易与否，是衡量一个软件可移植性高低的主要标志之一。
可移植性是软件质量之一，良好的可移植性可以提高软件的生命周期。代码的可移植性主题是软件；可移植性是软件产品的一种能力属性，其行为表现为一种程度，而表现出来的程度与环境1密切相关。（注1：环境包括软件环境，硬件环境和系统的组织环境）。软件可移植性指与软件从某一环境转移到另一环境下的难易程度。为获得较高的可移植性，在设计过程中常采用通用的程序设计语言和运行支撑环境。尽量不用与系统的底层相关性强的语言。
软件测试和SQA的关系：
软件测试工具：
开源测试管理工具：Bugfree、Bugzilla、TestLink、mantis
开源功能自动化测试工具：Watir、Selenium、MaxQ、WebInject
开源性能自动化测试工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Application Load Simulator
[TestDirector]：企业级测试管理工具，也是业界第一个基于Web的测试管理系统。
[Quality Center]：基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。
[QuickTest Professional]：用于创建功能和回归测试。
[LoadRunner]：预测系统行为和性能的负载测试工具。
其他工具与自动化测试框架：Rational Functional Tester、Borland Silk系列工具、WinRunner、Robot等。
国内免费软件测试工具有：AutoRunner和TestCenter。
WinRunner：
通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。
企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。
如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。
现在还可以是软件公司功能检测人员的职位代称。
LoadRunner：
LoadRunner，是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
LoadRunner可适用于各种体系架构的自动负载测试，能预测系统行为并评估系统性能。
QTP：
HP QuickTest Professional 提供符合所有主要应用软件环境的功能测试和回归测试的自动化。采用关键字驱动的理念以简化测试用例的创建和维护。它让用户可以直接录制屏幕上的操作流程，自动生成功能测试或者回归测试用例。专业的测试者也可以通过提供的内置脚本和调试环境来取得对测试和对象属性的完全控制。
TestDirector：
TestDirector是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。
Selenium ：
Selenium [1] 是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。
Appium ：
Appium 是一个开源工具，用于自动化 iOS 手机、 Android 手机和 Windows 桌面平台上的原生、移动 Web 和混合应用。「原生应用」指那些用 iOS、 Android 或者 Windows SDKs 编写的应用。「移动 Web 应用」是用移动端浏览器访问的应用（ Appium 支持 iOS 上的 Safari 、Chrome 和 Android 上的内置浏览器）。「混合应用」带有一个「webview」的包装器——用来和 Web 内容交互的原生控件。类似于 Apache Cordova 或 Phonegap 项目，创建一个混合应用使得用 Web 技术开发然后打包进原生包装器创建一个混合应用变得容易了。
重要的是，Appium 是跨平台的：它允许你用同样的 API 对多平台（iOS、Android、Windows）写测试。做到在 iOS、Android 和 Windows 测试套件之间复用代码。
Jmeter：
Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。 它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
Apache jmeter 可以用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它可以用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
支付的测试用例：一、在支付金额上
1、金额的最小值 ：如0.01
2、无实际支付意义的金额：如0元订单
3、支付金额错误：格式错误 、数字错误（支付金额为负数）
3、超大金额 ：设置的最高金额上限。（如微信红包单个最大值为200等）
4、余额小于实际需要支付的金额
5、银行卡或其他设置当日消费金额或者是单笔消费金额超限
二、支付接口上
关于支付会设计到很多第三方接口的相关的事件。比如：支付宝 、微信、网银系统 、手机银行、POS机的终端服务 甚至是 扫码枪 等硬件设备也是有关系的。
三、支付的操作问题上
1、指纹支付
2、免密支付
3、账号+密码支付
4、动态获取支付验证码支付
5、银行卡号+密码绑定支付
6、信用卡可能会设计到支付码等
如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的。
四、产品的容错性上（异常处理）
1、如何处理退款
2、支付时出现断网
3、支付失败之后 如何补单和退单
4、支付金额不足的情况下 ，充值后 是否可以继续支付
5、持续点击 是否会出现多次扣款
6、如果发生多次扣款，如何退款到支付账号
五、产品后台处理上
成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
微信红包测试：
功能
1.在红包钱数，和红包个数的输入框中只能输入数字
2.红包里最多和最少可以输入的钱数 200 0.01
3.拼手气红包最多可以发多少个红包 100
3.1超过最大拼手气红包的个数是否有提醒
4.当红包钱数超过最大范围是不是有对应的提示
5.当发送的红包个数超过最大范围是不是有提示
6.当余额不足时，红包发送失败
7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，
7.1是否可以输入它们的混合搭配
8.输入红包钱数是不是只能输入数字
9.红包描述里许多能有多少个字符 10个
10.红包描述，金额，红包个数框里是否支持复制粘贴操作
12.红包描述里的表情可以删除
13.发送的红包别人是否可以领取
13.1发的红包自己可不可以领取 2人
14. 24小时内没有领取的红包是否可以退回到原来的账户
14.1 超过24小时没有领取的红包，是否还可以领取
15.用户是否可以多次抢一个红包
16.发红包的人是否还可以抢红包 多人
17.红包的金额里的小数位数是否有限制
18.可以按返回键，取消发红包
19. 断网时，无法抢红包
20.可不可以自己选择支付方式
21.余额不足时，会不会自动匹配支付方式
22.在发红包界面能否看到以前的收发红包的记录
23.红包记录里的信息与实际收发红包记录是否匹配
24.支付时可以密码支付也可以指纹支付
25.如果直接输入小数点，那么小数点之前应该有个0
26.支付成功后，退回聊天界面
27.发红包金额和收到的红包金额应该匹配
28.是否可以连续多次发红包
29.输入钱数为0，"塞钱进红包"置灰
性能
1.弱网时抢红包，发红包时间
2.不同网速时抢红包，发红包的时间
3.发红包和收红包成功后的跳转时间
4.收发红包的耗电量
5.退款到账的时间
兼容
1.苹果，安卓是否都可以发送红包
2.电脑端可以抢微信红包
界面
1.发红包界面没有错别字
2.抢完红包界面没有错别字
3.发红包和收红包界面排版合理，
4.发红包和收到红包界面颜色搭配合理
安全
1.对方微信号异地登录，是否会有提醒 2人
2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加
3.发送红包失败，余额和银行卡里的钱数不会少
4.红包发送成功，是否会收到微信支付的通知
易用性(有点重复)
1.红包描述，可以通过语音输入
2.可以指纹支付也可以密码支付
朋友圈点赞：
功能测试
1 是否可以点赞成功
2 点赞成功后是否可以去取消
3 没有网络情况下是否可以点赞
4 点赞成功后是否可以评论
5 是否按照点赞顺序，按时间进行排序
6 点赞一排可以显示多少人头像
7 是否有点赞人数限制
8 是否可以多次点赞
9 点赞完成后对手机是否有影响
10 点赞是手机是否有会出现故障
11 是否可以点赞刚删除的朋友圈
12 同一个朋友圈，是否能有多人观看及点赞
13 朋友圈是否有限制不可观看
14 朋友圈是否有设置三天后不可见
15 朋友圈是否对你开放
16 好友是否将你拉黑
17 是否可以点赞1天前朋友圈
18 是否可以点赞7天前朋友圈
19 是否可以点赞30天前朋友圈
20 是否可以点赞1年前朋友圈
21 是否可以点赞半年前朋友圈
22 是否可以点击自己发送的朋友圈
23 是否可以点击刚加好友的朋友圈
24 朋友点赞是否有提示本人收到朋友圈被朋友点赞信息
25 朋友评论是否有提示本人收到朋友圈被朋友评论信息
26 是否能接收朋友圈发的纯文字
27 是否能接收受朋友圈发的表情
28 是否能接受朋友圈发的图片
29 是否能接受朋友圈发的视频
30 是否能接收朋友圈发的音频
性能测试
1 点赞完成后下放点赞的头像显示速度
2 网速对点赞是否有影响
3 能否及时刷新点赞人数
4 能否及时刷新评论人数
5 网速对评论是否有影响
界面测试
1 界面与ui设计的效果图是否一致
2 图片位置显示是否正确
3 下拉朋友圈是否刷新
4 是否是中午简体
5 是否有错别字
易用性测试
1 操作是否简单
2 是否适合于不同年龄段人使用
兼容性测试
1 不同操作系统是否好用
2 不同微信版本
3 不同手机型号
安全测试
1 朋友圈内容涉嫌不良信息
2 看是否为好友，不是好友不可以进行看别朋友圈
3 微信必须要登录
弱网测试
1 2g网络点赞需要时间/是否可以点赞/是否可以评论
2 3g网络点赞需要多长时间/是否可以点赞/是否可以评论
3 4g网络点赞时间多长时间/是否可以点赞/是否可以评论
4 5g网络点赞时间多长时间/是否可以点赞/是否可以评论
5 公共网络点赞多长时间/是否可以点赞/是否可以评论
