目录
6.软件测试分为静态测试（文档测试），动态测试（黑盒、白盒、灰盒）
1.什么是软件测试？测试的目的是什么?
是使用人工或自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
测试的目的是找出软件产品中的缺陷，站在用户的角度考虑软件的质量，保证软件的质量，使软件尽可能的符合用户的要求。
2.测试分为哪几个阶段?
一般来说分为5个阶段：单元测试、集成测试、确认测试、系统测试、验收测试。
①单元测试：是对软件中的基本组成单元进行测试，如一个模块、一个过程等等，它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件最基本组成单元的正确性。
②集成测试：在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。其主要目的是检验软件各单位之间的接口是否正确。实践表明，一些模块虽然可以单独工作，但并不能保证连接起来也能正常工作。测试重点是模块间的衔接以及参数的传递等。
③确认测试：确认测试的目标是验证软件的功能和性能以及其他特性是否与用户的要求一致。确认测试一般包括有效性测试和软件配置复查。一般由第三方测试机构进行。
④系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确。重点：整个系统的运行以及与其他软件的兼容性。
⑤验收测试：旨在向软件的购买者展示该软件满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
⑥回归测试：是在软件的维护阶段，对软件进行修改之后进行的测试，其目的是检验对软件的修改是否正确。
3.软件测试的流程是什么?
需求分析：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。
测试计划：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。
测试设计：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。
测试实施：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束。
测试评估：根据测试的结果，出具测试评估报告。
4.软件质量保证与测试
是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。
5.怎样写测试计划和测试用例
简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。
6.软件测试分为静态测试（文档测试），动态测试（黑盒、白盒、灰盒）
静态测试：是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
黑盒测试：已知产品的功能设计规格，完全不考虑产品的内部细节，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。
灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
7. 测试用例
指在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和与其结果。测试用例=输入+输出+测试环境。测试用例有两个模板，word和excel，前者适合性能测试，后者适合功能测试。
8. 软件测试的V模型
9. 白盒测试的覆盖
①语句覆盖：可执行语句至少被执行一次；
②判断覆盖：每个判断的取真分支和取假分支至少经历一次；
③条件覆盖：每个条件的取值至少满足一次；
④判断条件覆盖：判断和条件都满足；
⑤条件组合覆盖：每个条件的所有可能都至少出现一次，并且判定结果至少出现一次；
他与条件覆盖的区别：他不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次；
⑥路径测试：执行所有可能的执行路径；
⑦基本路径测试： 路径测试执行了每个路径，每个判定的结果肯定经历过一次
10.如何测试一部电梯
①功能测试,最基本的上下功能,开关功能,还有里面的各个按键。
②性能测试(很多人忽略的),比如电梯的调度算法,用户的等待时间,平均等待时间,上下的速度,耗电量等等。
③压力测试,比如承重量(你实际承受力是20人,那么当进入19个人的时候就应该报警,或者是实际上用户有可能一股脑的全部冲进电梯,所以在静止的时候电梯需要考虑到这种情况),突然断电,门打不开等等。
④可用性测试,按钮是否方便,按键的感觉是否好,视觉效果,现在很多人诟病的事情是,开和关两个按钮的图示很不友好,在紧急的时候很容易搞错。
⑤兼容性测试,比如每个国家的电压不一样,是否考虑到这个情况。
⑥本地化/国际化测试,曾经看到一部电梯的使用手册翻译成英文,翻译得很差。
⑦可维护性测试,电梯如果坏了怎么去维修。
11.注册/登录功能测试用例设计
登录：
页面测试：布局是否合理，输入框和按钮是否对齐，界面风格是否统一，有无错别字。
功能性测试：①用户名和密码都为空，验证是否登录失败，且提示信息正确。
②用户名或密码为空，验证是否登录失败，且提示信息正确。
③输入未注册的用户名和密码，验证是否登录成功，且提示信息正确。
④输入已注册的用户名和正确的密码，验证是否登录成功。
⑤输入已注册的用户名和错误的密码，验证是否登录失败。
⑥验证用户名和密码是否大小写敏感。
⑦页面上的密码是否加密显示，或者是否有明暗码切换按钮。
⑧刷新页面是否会清空用户名和密码框。
⑨用户名和密码是否支持中文和特殊字符。
⑩快捷键Tab和Enter等是否能正常使用。
兼容性测试：①不同浏览器下，验证登录页面的显示和功能的正确性。
②相同浏览器的不同版本下，验证登录页面的显示和功能的正确性。
③不同移动设备终端的不同浏览器下，验证登录页面的显示和功能的正确性。
④不同分辨率界面下，验证登录页面的显示和功能的正确性。
安全性测试：①用户密码后台存储是否加密。
②用户密码在网络传输过程中是否加密。
③不登录的情况下，在浏览器中直接输入登录后的URL地址,验证是否会重新定向到用户登录界面。
④密码输入框是否支持复制粘贴。
⑤密码输入框内输入的密码是否能在页面源码模式下被查看。
⑥用户名和密码框使用SQL注入方法输入，验证系统的返回界面。
⑦连续多次登录失败后，系统是否会阻止后续的尝试以应对暴力破解。
⑧验证同一用户是否能在同一终端的多种浏览器上同时登录。
⑨验证同一用户是否能在多台终端的浏览器上同时登录，验证登录是否有互斥性。
⑩截取到的token等信息，是否可以在其他终端上直接使用 。
性能压力测试：①单用户登录的响应时间。
②高并发情况下用户登录的响应时间。
③多个请求同时提交时系统是否崩溃。
12. Jmeter使用
线程组参数：
线程数：就是模仿并发用户的数量，
Ramp-up: 运行全部线程的总时间，单位是秒。
循环次数：就是每个线程要循环多少次。
HTTP请求参数：
协议：https或者http，根据我们接口的实际对应协议来写即可。
方法：我们的接口用的是POST方法，所以将方法设置为POST。（POST方法的参数要写在BodyData请求体中，用json格式传入）
路径：即接口对应的url信息。
Content encoding：编码格式，通常为utf-8。
不存在跳页等操作，所以重定向无需额外设置。
用表格查看结果
13.冒烟测试
在一般的项目里，我们往往需要进行多个版本的测试工作，但是在我们按照计划执行正式的系统集成测试前，我们需要作一些中间测试版，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。
如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
这样的测试就叫做冒烟测试，它是一种自由测试。
冒烟测试的名称可以理解未该种测试耗时短，仅用一袋烟功夫足够了。它的作用就是保证系统的主流程和新模块的基本功能能用，保证希望集成测试能正常开展，优点是节省测试时间，防止build 失败。缺点是覆盖率还是比较低。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
流程：
第一步：确定冒烟测试用例
测试经理会和项目经理等相关人员从测试用例库中选定重要的测试用例，标记为冒烟测试用例。
第二步：执行冒烟测试
关于执行冒烟测试的人选，通常我们会让测试人员进行。具体流程如下：
由此可以看到冒烟测试失败的话，会导致测试进度延期，成本和进度风险很大，因此冒烟测试失败是一个很大的项目失误，所以一般的，在发布前，开发人员会内部执行一次冒烟测试，来保证提交的版本的质量。
14.测试方法
15.测试团队的工作
16.Bug管理工具
JIRA：集项目计划、任务分配、需求管理、缺陷跟踪于一体的软件。
QC（Quality Center）：惠普公司的企业级基于WEB测试管理工具。需要安装配置IIS和数据库，系统资源消耗比较大；功能很强大，结合有BUG管理，需求管理及用例管理等功能。
Bugzilla：是由Mozilla公司提供的基于Web方式，免费的开源的一款功能强大的Bug管理系统。
BugFree：基于WEB的，配置安装简单，只需到网上获取安装包，再配下PHP通用的环境即可。
EasyBug：基于WEB的在线的，不用配置；界面很漂亮，操作容易上手。
Mantis：一款基于Web的Php+Mysql的开源BUG管理系统，一款简单实用的系统，也有截图功能，不过是以附件的形式存在，报表功能比较强大，需要配置才可用。
17.自动化测试
（1）单元测试自动化：调用被测试类或方法，根据类或方法的参数，传入相应的数据，得到一个返回结果，断言是否与预期结果相等，相等通过，否则失败。单元测试关注的是代码的实现与逻辑。
（2）接口自动化测试：根据接口文档，到底传入的时get或post请求呢？调用被测试的接口，构造相应的数据（id=1，name=yht），得到返回值，是200就成功，并返回查询结果，不管输入的参数是怎样的，都将得到一个结果，最终断言返回的结果是否等于预期结果，等于则通过，否则失败。接口测试关注的是数据，只要数据没问题，基本就成功，剩下的就是如何把数据展示到页面了。
（3）web测试自动化：这测试更贴近用户行为，模拟用户点击了某个按钮，像文本框输入的什么。比如一个登陆操作，用户登陆了之后可以看到登陆成功，但web自动化并不知道点击登陆是否生效，所以需要找到证据，比如：登陆成功后会显示“欢迎xxx”之类的。这就是登陆成功的最有力证据，所以，当web自动化登陆成功后，就去获取这个数据断言，相等则通过，否则失败。所以web测试。自动化关注的是用户的操作行为，页面上的按钮和输入框是否可用。
1879
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
