理论知识---2

26.写好测试用例的关键 /写好用例要关注的维度
1.测试用例设计方法

等价类划分法；边界值分析法；因果图；决策表；正交试验；场景法；状态迁移；错误推测法

2.测试用例的组成元素
用例编号；用例标题；功能模块名称；前置条件；输入数据；操作步骤；预期结果；优先级；执行结果；编写人；执行人

3.用例标题
字数不能太多
概括性-看到标题就能清楚这条用例测试点是什么
不能歧义性
-------------------------分割线----------------------------
27.测试用例的状态
排队（In Queue）：
测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。

进行中（IP）：
该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）

阻塞（Block）：
一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。

跳过（Skip）：
你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。

通过（Pass）：
测试运行结束，测试人得到了预料中的测试结果状态和测试行为。

失败（Fail）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。

警告（Warn）：
在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。

关闭（Close）：
一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。
-------------------------分割线----------------------------
28.常见的测试用例设计方法
1.等价类划分法：
定义等价类划分法，界面只要输入的地方就可以使用等价类划分法，从无穷多的数据中选择少量具有代表性的数据进程测试
2.边界值：
边界值常常和等价类划分法 一起使用 形成一套更为完善的测试方法

3.因果图及判定表法：
在一个界面中有多个控件，如果控件之间有组合关系或者限制关系，不同的控件组合会产生不同的输入结果，为了弄清楚不同的输入结果会产生不同的输出结果，可以使用因果图判定表法

4.正交表：
在一个界面中有多个控件，每个控件有多个值，测试时候考虑不同的控件取多个组合，但组合数量巨大（大于20使用正交表，小于20使用因果图及判定表法），没有必须进行全部测试，从所有的组合中挑选最优的，最少的组合进行测试

5.测试大纲法：
程序包含多个窗口，每个窗口中有多个功能，这些功能之间又有一定的联系。为了梳理清楚窗口之间以及窗口不同功能之间的联系 使用测试大纲法

6.场景法
大多数的业务比较复杂的软件系统都适合使用场景法，是一种基于软件业务的测试方法，把自己当成最终用户，尽可能的模拟用户在使用此软件的操作

7.错误推断法：
基于经验和直接推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法

8.随机测试
随意测试，不考虑任何用例和需求，完全站在一个用户的角度对产品进行使用适用场景
-------------------------分割线----------------------------
29.判定表用在哪些时候/哪些功能
又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
　　例如，某公司对客户分类标准如下：
　　顾客每次订货额在1000元以上（含1000元），信誉好的，订单设“优先”标志；
　　信誉不好，但是老客户的，订单设“优先”标志；
　　信誉不好，但是新客户的，订单设“正常”标志；
　　每次订货额在 1000元以下，订单设“正常”标志。

此表分两大行，两大列，分别用不同的颜色区别。
　　浅蓝：列出所有条件（或称为输入）
　　浅灰：列出所有结果（或称为输出，行动或决策）
　　浅黄：穷举所有条件的组合
　　浅绿：根据每一列的条件，判断出结果
　　因为穷举了所有条件，所以可以说这个判断是100%正确的。下一步是对这个表进行合并优化。
　　 例如，从编号为1，2的列可以看出，顾客订单>=1000,信誉好，不管是新顾客还是老顾客，都设为优先，于是上面的表合并整理后

这样，我们就可以得到更清晰的逻辑判断，也可以更好的协助我们编写测试用例。而决策表，对于开发人员来说一样有用

-------------------------分割线----------------------------
30.什么时候用到场景法
大多数的业务比较复杂的软件系统都适合使用场景法，是一种基于软件业务的测试方法，把自己当成最终用户，尽可能的模拟用户在使用此软件的操作
-------------------------分割线----------------------------
31.测试环境怎么搭建的？
即软件、硬件和网络三种环境的合集，也就是说：测试环境=软件+硬件+网络

　　硬件：包括PC机、笔记本、服务器、各种终端等。例如要测试photoshop软件，是要在PC机上测，还是笔记本上测?是在cpu为酷睿的计算机上测，还是要在炫龙的cpu上测?不同的硬件环境photoshop的处理速度是不一样的。

　　软件：这里主要指的是软件运行的操作系统。例如测试photoshop，是指windows xp下测试还是在vista下测试?可能会有兼容性问题。软件环境还包括与其他各类软件共存同一系统时的兼容性问题。

　　网络：主要针对的是C/S结构和B/S结构的软件。
　1、真实：尽量模拟用户的真实使用环境。这里需要提一点，关于项目软件与产品软件需要不同看待。项目软件由于只针对某一群体的用户，所以测试的环境比较单一。但产品软件针对的是广大群众，所以测试环境比较复杂，要多方面考虑。

　　2、干净：测试环境中尽量不要安装与被测软件无关的软件。笔者就遇到这种事情，两台机器，针对一个功能，一台测试OK，另一台测试NG，最后根据调查发现，测试OK的机器上安装了客户根本不会安装的VC++开发环境，测试NG的机器正因为没有安装VC，所以测试出了这个bug：软件中缺少必要的动态链接库支持。但这个干净也不是必须的，有时还要刻意去测试某个软件去其他软件并存时的兼容性问题。

　　3、无毒，这个应该不必多说了，测试工作应该确保在无毒的环境中进行。

　　4、独立：测试环境与开发环境相互独立。就是说开发环境和测试环境最好分开，即测试人员和开发人员分别用不同的服务器(数据库、后台服务器等)，避免造成相互干扰。
-------------------------分割线----------------------------
32.偶然性问题的处理
一、一定要提交！！
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。

二、尽量重现bug
对于整个项目或者产品而言，如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，如果不能及时、准确的定位和解决，最终发布出来的软件到达用户手中后，一旦出现势必会影响软件在用户心中的形象，严重的会“迫使”用户选择竞争对手的产品，这些显然都是公司所不愿看到的。而对于测试人员而言，出现了这些不可复现的Bug，实际上是一次很好的锻炼和提高机会，如果只是提交缺陷报告将这个大皮球踢给开发人员，不仅丧失了一次提高测试水平的机会，还有可能破坏和开发人员之间的关系。
要想复现不可复现的Bug，需要先提到一个概念就是ET（Exploring Test），也就是探索式测试，这种测试方法是由James Bach首先提出来的，在所掌握的被测对象的信息不是很充分的情况下，这是一种很有效的测试方法.当出现不可复现的Bug时，大家可以从以下五个方面来进行考虑：
1、被测对象的版本信息
我测试的到底是哪个版本，这主要是有两个作用：一是确认我测试的是正式的软件版本，如果不是就先记录下该问题，然后选择正式的版本进行测试（开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug）；二是可以和其它版本进行对比，如果其它的版本没有类似的问题，就可以去对比这两个版本之间的区别。
2、环境
这里的环境是指出现不可复现的Bug时所对应的测试环境等，比如测试所用的计算机，如果出现不可复现的Bug，那我换一台机器是不是还会出现类似的问题，也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
3、模式
这里的模式是指我对这个Bug如何出现的一个理解，先给这个Bug设定一个模式，比如是不是[数据库](javascript:😉通信中断，然后再进行测试，收集更多的信息去修改和完善这个模式，这样不断进行，最终直到Bug能完全复现为止，这个时候只要使用这个模式就可以复现出Bug了。
4、人
这里提到的人有两个含义：一是测试是由人来进行的，人的操作、人的思维方式会有不同，通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹；二是想复现不可复现的Bug，往往需要多个人之间的相互协作，比如测试人员、开发人员等，通过大家的沟通和协作就能更容易去复现了。
5、测试工具
通过一些debug工具或者log工具等搜集内存等信息，根据这些信息来进行分析，找出不同信息之间的共同点，比如某一块内存始终都会被改写等，通过这种方式来去复现Bug。
上面的五个方面都是和ET的思想紧密相关的，通过不断的测试和不断的信息收集和分析，逐步的把模糊的、不确定的测试变成清晰的、确定的测试，这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。

三、实在没办法重现

问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现

-------------------------分割线----------------------------
33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
1.找到需求文档或者事原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为Bug
3.整理Bug的复现的步骤和出现的频率
4.开发坚称不认为是Bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理，测试，测试经理和项目经理进行确认并确认会来判定是否为bug
6.测试人员需要将Bug整理并写入测试总结中
-------------------------分割线----------------------------
34.产品在上线后用户发现bug，这时测试人员应做哪些工作？
首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。
当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。

解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。

最最重要的：补测试用例！
-------------------------分割线----------------------------
35.二八定理
二八定律又名80/20定律、帕累托法则（Pareto‘s principle）也叫巴莱特定律、朱伦法则（Juran's Principle）、关键少数法则（Vital Few Rule）、不重要多数法则（Trivial Many Rule）、最省力的法则、不平衡原则等，被广泛应用于社会学及企业管理学等。
二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。他认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，因此又称二八定律。
-------------------------分割线----------------------------
36.如何跟踪缺陷
1.为什么要提缺陷跟踪

缺陷，也称为变更请求，是来自于测试工程师，开发工程是，客户等的反馈。本文中将统称为变更请求。建立缺陷跟踪，就是要把这些反馈系统的管理起来；缺陷跟踪系统通过为变更请求标注优先级，保证了严重的变更请求得到优先解决；缺陷跟踪系统还为每个变更请求设定状态，方便管理者统计和更新。缺陷跟踪系统还可以把不同来源的相似问题作一个归一，避免重复解决问题。

2.如何实现一个缺陷跟踪系统

首先，圈定该系统的应用范围，是单一的项目，是一个部门，还是多个组。 其次，商定跟踪模型，这是核心所在。这一步需要和项目成员一起讨论确定一个大家都接受的模型，包括设计变更的生命周期等一系列定义。接下来要设定一些角色，比如提出者，管理者，质量保证工程师或测试人员等。然后需要制定一个执行计划；再下来部署该缺陷跟踪系统，一个原则是尽量少的对系统进行修正；最后确保该系统正常运转，达到最初的目标。
3.自定义缺陷跟踪系统

定制可以分作两类：大动作的变动，比如增加变更的类型或者变更活动的新规则。这类定制只有管理员有权限来操作。另外一种是小动作的变动，比如表单格式，用户界面的定制，这类定制一般用户就可以完成
-------------------------分割线----------------------------
37.缺陷的状态
New（新的）：bug提交到缺陷库中会自动的被设置成New状态
Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”
Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”
Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”
Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”
Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”
-------------------------分割线----------------------------
38.缺陷的等级
1）致命错误：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。

2）严重错误：系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，以及功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启，自动退出，关联程序间调用冲突，安全问题、稳定性等。

3）一般错误：功能没有完全实现但不影响使用，功能菜单存在缺陷但不影响系统稳定性。

4）建议问题：界面，性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等。

-------------------------分割线----------------------------
39.缺陷单应该包含这些要素
缺陷标题； 缺陷描述； 缺陷影响； 环境配置 ； 期望结果和实际结果； 优先级和严重程度 ； 变通方案； 根原因分析； 附件；
-------------------------分割线----------------------------
40.测试报告的主要内容
测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）
BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等

-------------------------分割线----------------------------
41.如何定位bug
1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题

　　2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常

　　3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等

　　4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug

　　5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）

　　6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）

　　7、确认bug后，提单给开发进行bug跟踪。

　　　 问题单上要描述清楚以下信息：

　　　 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等

　　8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）
-------------------------分割线----------------------------
42.开发没时间修复，如何推进bug的修复：
和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。
-------------------------分割线----------------------------
43.软件测试流程
我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。
-------------------------分割线----------------------------
44.项目介绍
参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程
-------------------------分割线----------------------------
45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计
-------------------------分割线----------------------------
46.在项目中发现哪些经典bug？什么原因导致的？
注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的
接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到
数据用fiddler可以抓包拦截篡改数据
弱网环境下订单可以重复提交
验证码可以重复使用
跑性能测试的时候，当前账号下的订单跑到别的账户上去了每次重新登陆都提示重设支付密码，而且设置的密码不能和上次相同
在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加
第一次提现申请未审核，再继续第二次提现申请无法成功
前台发布出租房源，后台通过审核并且成功加入出租列表，前台搜索失败
-------------------------分割线----------------------------
47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
-------------------------分割线----------------------------
48.在需求文档不太详细的情况下，如何开展测试？
1.首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来
2.提取测试点，然后叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，然后再编写测试用例，再评审，评审通过后，再进行后续的测试
-------------------------分割线----------------------------
49.如何尽快找到软件中的bug?
1.尽快熟悉公司的产品业务，只有熟悉了产品的业务流程，你才能迅速找出软件中存在的一些重要的缺陷。
2.把自己当成用户，把自己当成是用户去使用该系统
3.善于怀疑，不要过于相信开发人员的能力
-------------------------分割线----------------------------
50.什么是bug？
1.软件未实现需求和规格要求的功能
2.软件未实现需求和规格未明确提及但应该实现的内容
3.软件难以理解，，不易使用，运行缓慢，或者最终用户(估计会)认为不好
4.测试用例执行中发现的与预期结果不符的现象
-------------------------分割线----------------------------
51.ATM机吞卡的吞卡现象是不是BUG?
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
-------------------------分割线----------------------------
52.如何减少非问题单的提交？
熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
跟产品确认该问题是否属于非问题单。
-------------------------分割线----------------------------
53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。
-------------------------分割线----------------------------
54.你们发现bug会怎么处理。
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。