测试

测试的基本流程

单元测试、集成测试、系统测试、验收测试、回归测试

参考回答：
1、单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。
2、集成测试：通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。

自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。

3、系统测试：是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

4、回归测试：回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

5、验收测试：验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。

Beta测试：由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件。

单元测试、集成测试、系统测试、验收测试、回归测试这几步中最重要的是哪一步

参考回答：
这些测试步骤分别在软件开发的不同阶段对软件进行测试，我认为对软件完整功能进行测试的系统测试很重要，因为此时单元测试和集成测试已完成，能够对软件所有功能进行功能测试，能够覆盖系统所有联合的部件，是针对整个产品系统进行的测试，能够验证系统是否满足了需求规格的定义，因此我认为系统测试很重要。

集成测试和系统测试的区别，以及它们的应用场景主要是什么？

参考回答：
区别：
1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。

2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。

3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。

应用场景：

集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。

系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。

黑盒测试：

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。

白盒测试：

白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

测试项目具体工作

搭建测试环境
撰写测试用例
执行测试用例
写测试计划，测试报告
测试，并提交BUG表单
跟踪bug修改情况
执行自动化测试，编写脚本，执行，分析，报告
进行性能测试，压力测试等其他测试，执行，分析，调优，报告

bug的周期，以及描述一下不同类别的bug

参考回答：
1、New:（新的）
当某个“bug”被第一次发现的时候，测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

2、Assigned（已指派的）

当一个bug被指认为New之后，将其反馈给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

3、Open（打开的）

一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

4、Fixed（已修复的）

当开发人员进行处理（并认为已经解决）之后，他就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

5、Pending Reset（待在测试的）

当bug被返还到测试组后，我们将bug的状态设置为Pending Reset”

6、Reset(再测试)

测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

7、Closed（已关闭的）

如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”

8、Reopen（再次打开的）

如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

9、Pending Reject（拒绝中）

如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

10、Rejected(被拒绝的)

测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

11、Postponed（延期）

有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“

不同类别的bug：

Bug类型、代码错误、界面优化、设计缺陷、配置相关、 安装部署、 安全相关、 性能问题、标准规范
、测试脚本、 其他

如何写测试用例

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰

测试人员能达到的层次

大概有这么几个级别：　
　1、开一个bug；　　
　2、查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；　
　3、对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；　　
　4、尝试通过研究代码确认问题所在；　　
　5、尝试给出一个fix；　　
　6、对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；　　
　7、能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。

作者：乐搏学院
链接：https://www.zhihu.com/question/20269633/answer/1605309010
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

测试常见方法

等价类划分法、边界值分析法、因果图-判定表法、正交分析法、状态迁移法、业务分析法；而白盒测试中常用的测试用例设计方法还有：条件覆盖、语句覆盖和分支覆盖等方法。

等价类划分法

等价类就是某个输入域的子集。

等价类划分法是把所有可能的输入数据集合划分成若干个子集，每个子集内的元素对于揭露程序中的错误都是等效的，在每个等价类中取一两个数据作为测试的输入数据即可，这样就可以用少量代表性的测试数据取得较好的测试效果。

等价类又划分为“有效等价类”和“无效等价类”。

有效等价类，就是符合需求规格说明书要求的合理、有意义的输入数据集合。利用有效等价类可检验程序是否完整实现了需求所规定的功能以及功能的实现是否正确符合预期。（简言之，有效等价类校验功能是否做完了且做得是否正确。）

无效等价类是指那些不合理的、无意义的输入数据所构成的集合。这类测试数据可反向验证功能的正确性和程序的容错处理。

（2）设计用例步骤

第一步、依据需求规格说明书，确定输入数据的范围。

第二步、将输入数据的范围划分成若干个互无交集的有效等价类。接着确定无效等价类包含的输入数据。

第三步、分别从每个等价类中提取一两个有代表性的数据作为测试数据。一般的，每提取出一个数据就可设计一条测试用例，或根据实际业务需求用最少数量的用例覆盖最多的测试场景。

等价类划分经验

1.有效等价类一般可以直接在需求中找到

2.无效等价类a为空；b重复;c数据有范围要求-超出范围的;d有字符个数要求;f填写项的格式，样式（要求整数，小数，字符）

边界值分析法

（1）简介

边界值分析是通过选取指定数据域的“上点”“内点”“离点”来测试输入或输出的边界。

上点：就是边界上的点，无论域是开区间还是闭区间。若是开区间，上点在域外；若是闭区间，上点就在域内。

离点：是指离“上点”最近得点，这里跟待测数据域是闭区间还是开区间有关系。如果是开区间，那么离点就在域内；如果是闭区间，那么离点就在域外。

内点：域内的任意点都是内点。

（2）设计用例步骤

第一步、确定测试域。

第二步、选取“上点”“内点”“离点”。

第三步、每个“上点”和“离点”就是一条用例，“内点”可选取代表性的中点创建一条用例。

用例的优化

1.对于不同控件的有效等价类及有效边界值尽可能的在一条测试用例中测试。

2.在一条用例中，先一次只测试一个控件的无效等价类，无效等价类在开始的时候不能组合，避免屏蔽现象的发生。最后在适当考虑无效等价类的组合。——验证软件处理极端数据的能力

等价类划分经验

1.有效等价类一般可以直接在需求中找到

2.无效等价类a为空；b重复;c数据有范围要求-超出范围的;d有字符个数要求;f填写项的格式，样式（要求整数，小数，字符）

因果图判定表

应用场景：界面有多个控件，控件之间有不同的组合，得到不同的结果。如按钮，复选框，单选框。一般一个控件的的可选项不超过3个。组合最终用例不超过20条比较好。

步骤：找出输入项，找出输出项，找出输入项的关系，找出输出项的关系，找到输入与输出的关系，画因果图，得判定表

正交表

应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

判定表，因果图也是考虑控件组合，但是组合数量较少（一般不会超过20中）Ln(mk)

n是表的行数，也就是需要测试组合的次数

k是表的列数，表示控件的个数（因数个数）

m是每个控件的取值个数（因数水平）

步骤：列出所有输入及取值，选取合适的正交表，编写组合测试用例。

正交表的局限性：现有的正交表的个数有限，要求每个控件的取值个数相等，在实践中很难遇到。

正交表选择数据的思想:公平，均匀

a.每个控件都要参与组合，每个控件的取值与参与组合的次数尽量相等。

b.从所有的组合数据中，均匀，零星的挑选作为用例的组合数据。

场景法

应用场景：

a.界面特点：没有太多填写项，主要通过鼠标的点击，双击，拖拽等完成操作

b.把自己当做最终的用户，在使用该软件的时候可能会遇到哪些场景，目的是测试软件的主要业务流程，主要功能的正确性和主要错误处理能力。

核心概念

a.基本流（正确流）模拟用户正确的操作流程—验证软件的业务流程和主要功能

b.备选流（错误流）模拟用户错误的操作流程—验证软件的异常处理能力

总结：场景法是基于等价类划分的一种测试方法（技术），场景法的应用时基于对软件业务的深入理解。

测试大纲法

大纲着眼于需求，为了列出各种测试条件，将需求转化为大纲；在根和每个叶点之间存在唯一路径，每条路径定义了一个特定的输入条件集合，用于定义测试用例。

涉及到多个窗口，每个窗口包含多个动作，找到每个窗口的动作之间的联系。

https://blog.csdn.net/julielele/article/details/77753834

怎么看待测试，知道哪些测试的类型，有用过哪些测试方法？

参考回答：
测试是软件开发中不可或缺的一环，测试通过经济，高效的方法，捕捉软件中的错误，从而达到保重软件内在质量的目的。
测试分为功能测试和非功能测试，非功能测试又可以分为性能测试、压力测试、容量测试、健壮性测试、安全性测试、可靠性测试、恢复性测试、备份测试、协议测试、兼容性测试、可用性测试、配置测试、GUI测试。

测试方法用过等价划分法、边值分析法、错误推测法、因果图法。

α测试和β测试，以及什么时候用到他们

α测试：在受控的环境中进行，由用户在开发者的场所进行，并且在开发者对用户的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题
β测试：在开发者不能控制的环境中的真实应用，由软件的最终用户们在一个或多个客户场所下进行，由用户记录在测试中遇到的一系列问题，并定期报给开发者。

测试的相关流程是什么？

需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试

敏捷测试

敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，这些实践具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。和传统测试的区分，可以概括如下：

1）传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。

2）传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。

3）传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。

4）传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。

5）传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。

6）传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。

7）传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

探索式测试

主要侧重于分析潜在风险
虽然不用事先创建测试用例，但是测试人员通过发散性的思维去思考每个模块、每一步甚至每个按
钮可能会出现的缺陷问题，可以让测试人员的时间和精力更多地集中在创造性地思维上，发现更多
隐藏的缺陷。

探索式测试准备工作：
1、测试之前一定会有一个全局的方针战略，即整体的测试计划，它可以避免走错大方向、该测的部
分没有覆盖到或者投入了大量时间到计划之外的部分。
2、测试一旦开始，没有固定的思路，测试人员不受任何先入为主的条条框框约束，根据测试途中获
取的信息，指导各自走不同的路径，最终目的就是发现潜藏的缺陷。

总结：
探索式测试试图把制定计划，进行测试，重新制定计划等多个过程有机地结合起来，每次只前进一
小步，但这每一步都是由软件过去和当前的运行状况，软件在测试时表现出来的各种行为和软件运
行时留下的种种蛛丝马迹来即时确定的。有效地利用探索式测试技术可以帮助我们发布一个高质量
的软件产品。

请问测试开发需要哪些知识？需要具备什么能力？

参考回答：
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；
考编程语言基础，如C/C++、java、python等；
自动化测试工具，如Selenium、Appium、Robotium等；
计算机基础知识，如数据库、Linux、计算机网络等；
测试框架，如JUnit等。
需要具备的能力：
业务分析能力，分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；
缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；
团队协作能力，合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担；
专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；
逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；
问题解决能力，技术上的问题、工作中的问题、沟通问题；
沟通表达能力，和技术人员、产品人员、上下级的沟通；
宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向

测试开发短语

SRS：需求分析文档；
HLD：概要设计文档；
LLD：详细设计文档；
BD:基本设计;
DD:详细设计;
FD:结构设计;

单元测试 参照 详细设计说明说（LLD）
集成测试 参照 概要设计说明书（HLD）
系统测试 参照 需求规格说明说（SRS）

需求规格说明书 ：是为使用用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。
概要设计 ：就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。
详细设计：就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。

测试题目https://www.nowcoder.com/ta/review-test?query=&asc=true&order=&tagQuery=&page=1

怎么去评测bug？

Bug的priority（）和severity（）是两个重要属性，通常人员在提交bug的时候，只定义severity，而将priority交给leader定义，通常bug管理中，severity分为四个等级blocker、critical、major、minor/trivial，而priority分为五个等级immediate、urgent、high、normal、low。
Severity：
1、blocker：即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误， 如服务器500错误。
2、critical：即映像系统功能或操作，主要功能存在严重缺陷，但不会映像到系统稳定性。常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
3、major：即界面、性能缺陷、兼容性，常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。
4、minor/trivial：即易用性及建议性问题。
Priority
1、immediate：即马上解决，
2、urgent：急需解决
3、high：高度重视，有时间要马上解决
4、low：在系统发布前解决，或确认可以不用解决。

软件质量的六个特征

参考回答：
按照软件质量国家标准GB-T8566–2001G，软件质量可以用下列特征来评价：
a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。

b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。

c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。

d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。

e.可维护特征：与进行指定的修改所需的努力有关的一组属性。

f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。

软件缺陷包括五种：

1、软件没有实现产品规格说明所要求的功能模块； —A
2、软件中出现了产品规格说明指明不应该出现的错误； ----B
3、软件实现了产品规格说明没有提到的功能模块； -----C
4、软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；
5、软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。

可以作为软件测试对象的是：需求规格说明书、软件设计规格说明、源程序

关于自动化测试描述正确的是：
引入自动化测试可以降低测试成本
软件产品测试适合自动化测试
D自动化测试脚本同样需要进行验收和确认

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
B、实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
1)需求变动不频繁
2)项目周期足够长
3)自动化测试脚本可重复使用
D、自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。

性能测试类型
基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考
负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 。
压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。
稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题
性能测试基本概念
1.响应时间
2.吞吐量
3.并发数
4.资源利用率

可维护性

什么是性能问题？ 如果你的系统对于一个用户访问还很慢，那就是性能问题；
什么是扩展性问题？ 如果你的系统对一个用户来说是快的，但是在用户不断增长的高访问量下就慢了。
可伸缩性(可扩展性)是一种对软件系统计算处理能力的设计指标，高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够保证旺盛的生命力，通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。

1、概念上：
QA：Quality Assurance （质量保证）
QC：Quality Control （质量控制）
QM：Quality Manage （质量管理）

2、定义上：
QA：为达到质量要求所采取的作业技术和活动
QC：为了提供足够的信任表明实体能满足质量要求，而实施的根据需要进行证实的全部有计划、有系统的活动
QM：确定质量方针、目标和职责，并在通过诸如：质量策划、质量控制．质量保证和质量改进，使其实施的全部管理职能的所有活动

3、职责上：
QA：最重要的职责在于系统层面的完善，侧重于问题的防范及对已发生问题的根源的探究及其对策的实施，从而降低不良的产生
QC：最重要的职责在于对制成品的监控
QM：最重要的职责在于从组织层面上保障质量工作环境

4、技能要求上：
QA：具备必要资质的QA是组织中的高级人才，需要全面掌握组织的过程定义，熟悉所参与项目所用的工程技术
QC：既包括软件测试设计员等高级人才，也包括一般的测试员等中、初级人才
QM：不仅要具备QA、QC的技能，还需具备专业管理才能

编写测试计划的目的是：
使测试工作顺利进行
使项目参与人员沟通更舒畅
使测试工作更加系统化

GUI：
界面整体风格合理，美观。 图标风格统一，title大小适中。 背景图片清晰，图层透明度适中
功能：

1.title：Trip.com
2.Hotels，Flights，Trains，Cars四个icon和name，点击跳转对应页面
3.Things To Do 模块展示卡片和title，Show All点击展开，卡片点击跳转正确
4.底部Home Deals My trip Accout四个模块，点击切换正常
5.登陆和非登陆状态首页展示需求
6.【邮件】图标有消息时会有提示，点击打开消息列表
7.滑动屏幕页面滚动流畅，下拉页面刷新
8.切换语言，首页支持多语言（about us 中有说明）
9.不同国家默认首页有本地化特性（根据about us可以推断的隐性需求）
性能：
首次进入首页-页面加载时间 其他页面返回首页时-页面加载时间 弱网络情况下-首页加载时间 低配置手机上，首页页面加载时间
兼容性：
手机类型兼容性：Android iOS 手机操作系统版本兼容性 手机生产方兼容性 屏幕尺寸兼容性，有无刘海兼容性 APP自身版本的兼容性
安全性：
首页中个人敏感信息不显示 网络传输过程中个人信息需要加密，验签。

请问测试开发需要哪些知识？需要具备什么能力？

参考回答：
需要的知识：
软件测试基础理论知识，如黑盒测试、白盒测试等；

考编程语言基础，如C/C++、java、python等；

自动化测试工具，如Selenium、Appium、Robotium等；

计算机基础知识，如数据库、Linux、计算机网络等；

测试框架，如JUnit等。

需要具备的能力：

业务分析能力，分析整体业务流程、分析被测业务数据、分析被测系统架构、分析被测业务模块、分析测试所需资源、分析测试完成目标；

缺陷洞察能力，一般缺陷的发现能力、隐性问题的发现能力、发现连带问题的能力、发现问题隐患的能力、尽早发现问题的能力、发现问题根源的能力；

团队协作能力，合理进行人员分工、协助组员解决问题、配合完成测试任务、配合开发重现缺陷、督促项目整体进度、出现问题勇于承担；

专业技术能力，掌握测试基础知识、掌握计算机知识、熟练运用测试工具；

逻辑思考能力，判断逻辑的正确性、对可行性逻辑分析、站在客观角度思考；

问题解决能力，技术上的问题、工作中的问题、沟通问题；

沟通表达能力，和技术人员、产品人员、上下级的沟通；

宏观把控能力，有效控制测试时间、有效控制测试成本、有效制定测试计划、有效进行风险评估、有效控制测试方向。