测试06

30. 什么时候用到场景法

• 场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
• 使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
• 基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
• 场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。

**Note：**场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

31. 测试环境怎么搭建的？

关于软件测试的测试环境搭建，需要根据实际的需求来进行安装特定的软件，下面就简单介绍下java+tomcat+mysql安装方法。

1.java的安装

因为很多程序的代码都是通过java编程语言进行编写的，因此为了测试需要，我们需要安装支持java编程语言的安装包，即jdk。下载好指定的安装包后双击安装包，默认下一步即可。完成这些步骤后需要配置环境变量，右键点击我的电脑-属性-高级系统设置-环境变量-系统变量(s)-选中path-编辑 将安装好的java中的bin和jre的路径添加到环境变量中即可。在cmd中输入java -version和javac -version验证是否安装成功。

2.tomcat的安装

在java安装无误的情况下，下载好tomcat安装包，直接点击下一步即可。

3.mysql的安装

下载好安装包，将其解压到想要安装的盘符中；按照1中的方法，将mysql中bin的路径添加到环境变量中；打开cmd，切换到英文，输入mysqld -install(安装命令)；输入mysqld --initialize-insecure(初始化命令)；输入net start mysql(启动数据库命令)，如果能够顺利执行这些命令无报错，则数据库安装成功。倘若已经存在旧版本的mysql想将其卸载替换可依次执行net stop mysql和mysqld -remove，然后再进行mysql的安装。

32. 偶然性问题的处理

一、一定要提交!!

1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。

4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

二、程序不是测试人员写的，出问题也不是测试人员的原因。

至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

测试人员的任务只是尽力重现问题，而不是必须重现!!

三、下次再遇到的时候，拉他们来看就可以了。

因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )

四、你可以告诉程序员，测试过程是没有错误的。

测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

需要让程序员理解，测试人员是帮助他们的，不是害他们的。

客户那里发现问题比测试员发现问题结果要严重的多。

五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。

在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

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

实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。

至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现(仅仅出现一次)。

这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。

六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

其实只要自己尽到心就可以了，管别人怎么说呢。

七、我们使用的状态有：

程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。

测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。

按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。

呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：

关于“无法重现”我看是有这么个问题存在。

首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。

不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例(说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了)。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。

说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生;全选后点击“取消全选”按钮再办理业务不会发生;全选全消后，先点击人员再办理业务也不会发生。

其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。

呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。

最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.

测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议!!测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员做的多了，程序员不但不感激，可能反而会反感(好像程序员对测试人员有好印象的不多)。

再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现(但是我不可能遇到问题就拉程序员来看吧)，后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox(必填)再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现(不够成熟呀)，我就放弃了，也没有提交记录(为了避免麻烦)。

测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题?反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。

下面是其它一些人的观点：

doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试!!!我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。

liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG，是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!

ericzhangali(另一个空间)：首先一定要提交bug;其次不要企图RD一定去解这个bug;某些时候还得关闭这个bug。如果RD认为是测试错误，(不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，)那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。

darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。(编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试)

liyan_1014(雁子)：我觉得应该是这么处理：

1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚;这样对于再次重现也有一定的参考性。

2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。

3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。

33. 当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1.找到需求文档或者是原型图进行匹对
2.尝试多种测试环境和多种测试方式来确认是否为bug
3.整理bug的复现的步骤和出现的频率
4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug
5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug
6.测试人员需要将bug整理并写入测试总结中

34. 产品在上线后用户发现bug，这时测试人员应做哪些工作？

首先测试人员可以做的是重现这个问题并及时反馈给开发人员，找到解决方案进行修复。

如果问题只在线上才出现，测试环境重现不了，那么可能是版本或环境配置的问题；

如果问题不仅线上能重现，测试环境也存在，那么很有可能是测试人员在测试过程中未发现的Bug。

总之，项目组成员需要尽快修复Bug。

开发人员修复Bug之后，测试人员需要反思。

若是由于疏忽造成测试用例执行遗漏，测试人员需要在下次执行测试的过程中避免这样的情况。

若是由于用例评审的不严格、中途需求变更或者某些其他因素造成的测试用例覆盖不全，测试人员需要补全测试用例。

---

在测试过程中遇到未发现的Bug，测试人员不要自怨自艾，

也不要像没回事儿一样，需要正确对待“线上Bug”、汲取经验教训、不断提高测试能力。

测试人员需要不断学习，不断扩充，掌握测试工具、提升测试技能，从而设计出更全面的测试场景和测试用例。

35. 二八定理

80%的缺陷出现在20%的代码中，体现了软件缺陷群集现象

36. 如何跟踪缺陷

在执行用例的过程中发现了跟预期实际不符的情况，就提交缺陷,跟踪缺陷修改，跟踪缺陷流程主要有四个(一个正常的修改结束的流程，三个特殊处理流程)

1. 新建 – 开启 – 修改 – 关闭 提交缺陷后开发人员确认修改后回归通过；

2. 新建 – 拒绝 开发人员未确认缺陷拒绝修改，这个时候需要在确认需求理解正确(跟产品确认)和复现步骤(多次复现)的基础上, 跟开发人员沟通是否需要修改；

3. 新建 – 开启 – 修改 – 重开 修改后提交的版本回归不通过，这是需要重新打开缺陷,为了加快缺陷正确修改，可以跟开发人员沟通，协助开发人员定位缺陷；

4. 新建 – 开启 – 延期 部分开启的缺陷，由于无法复现, 难以修改，进度压力等原因,可能需要延期修改，这个时候，是否延期，是需要多方确认的(测试、产品、开发、领导)。

37. 缺陷的状态

1. New（新的）：bug提交到缺陷库中会自动的被设置成New状态

2. **Assigned（已指派）：**当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

3. Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”

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

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

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

7. Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”

8. **Reopen（再次打开）：**如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”

38. 缺陷的等级

bug缺陷等级一般划分为四个等级，致命、严重、一般、提示

​ 致命（一级bug） **通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。

​ **严重（二级bug） **通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

​ 一般（三级bug）** 通常表现为：界面、性能缺陷。

比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。

​ 提示（四级bug） 通常表现为：易用性及建议性问题

比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。

39. 缺陷单应该包含这些要素

缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件

40. 测试报告的主要内容

1. 概述：一般会在概述中添加项目背景、需求描述等信息。
2. 测试过程主要包含评审记录、测试范围、测试用例
3. 罗列出是否已按本次测试计划实现功能
4. 包括资源统计、执行情况、问题统计、问题列表、遗留问题
5. 主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。
6. 测试风险没有放在测试总结里，而是单独划分为一个模块，可见其重要性。

41. 如何定位bug：

1. 查看状态码

2. 查看服务器日志

3. 查看需求文档

4. F12（开发者工具）

5. 前台UI界面，我所提到的界面，包括界面的显示，兼容性，数据提交的判断以及页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位。

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

42. 开发没时间修复，如何推进bug的修复：

导致开发不修改bug的因素

​ 1、 开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

​ 2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

​ 3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

​ 4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

​ 开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题。解决方案

​ 1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点

​ a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性

​ b) 可以和开发人员列举一个之前的类似问题，为开发提供参考

​ c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

​ 2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改

​ 3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案

​ 4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题

43. 软件测试流程

在立项会中制定需求文档，由UI设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行修改，修改成功后关闭bug，进行回归测试，在上线前进行测试总结。

44. 项目介绍

45. 对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

圆珠笔

1. 能否正常书写
2. 写出来的字遇水是否会消失
3. 是否有笔油泄露
4. 笔帽是否能正常按下弹起来
5. 一支笔可以用多少时间、写出的字是否褪色
6. 笔的长短粗细是否顺手
7. 一根笔芯用尽是否方便更换
8. 外形是否美观
9. 笔油是否含有有害物质
10. 笔尖是否容易伤到人
11. 笔油或者墨水保质期多长 过期是否产生有害物质
12. 在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何
13. 长时间按住弹簧，松开后看弹簧是否可以恢复
14. 笔芯弹出弹回的快慢。
15. 连续按，看弹簧能经受多少次伸缩。
16. 如果以极快的速度按压弹簧，该笔是否会崩溃？
17. 有些圆珠笔，不关掉，或者不盖盖子很容易干燥，时间久后是否可以正常使用
18. 掉在地上是否会坏掉
19. 被踩了后是否容易坏，承受最大压力
20. 笔芯的颜色
21. 是不是可擦掉的笔
22. 图案是否会掉色
23. 笔墨的气味
24. 墨水多久能干
25. 笔杆折断，材质是不是容易刮伤手
26. 误食笔墨是否引起中毒
27. 流畅度
28. 在木板或墙壁上书写，在其他物体上书写
29. 这个笔芯的笔尖/笔壳摔坏了，我换其他的笔芯的尖能不能继续用
30. 高温和低温环境下对笔芯出墨和笔壳的影响

三角形测试用例设计

（参考）

https://blog.csdn.net/junjunba2689/article/details/82587612

https://www.cnblogs.com/jpr-ok/p/6374742.html

1、构成三角形的条件：任意两边之和大于第三边；

2、构成等腰三角形的条件：任意两边相等；

3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

4、构成等边三角形的条件：三条边都相等。

一、等价类划分：三角形三条边A、B、C的数据类型不同

我们再分析一下三角形的等价类：

​ 有效等价类：

​ 输入3个正整数或正小数：

​ 1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B

​ 2、两数之和不大于第三数

​ 3、两数相等，如A=B或B=C或C=A

​ 4、三数相等，如A=B=C

​ 5、三数不相等，如A！=B，B！=C，C！=A

​ 无效等价类：

​ 1、空

​ 2、负整数

​ 3、非数字

​ 4、少于三个数

​ 等价类表：

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VrI2AoI6-1609163124810)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1609157470669.png)]

测试用例

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mbBNcWyo-1609163124813)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1609157510149.png)]

46. 在项目中发现哪些经典bug？什么原因导致的？

注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的

接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据

47. 一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

1. 影响用户体验
2. 如果不修改，在上线时可能会引起其他bug发生
3. 如果在版本迭代在修改，时间久了对bug的认知就没有现在清楚了
4. 拖得越久越难修复
5. 不符合需求产品需求

• 1
• 2
• 3
• 4
• 5

48. 在需求文档不太详细的情况下，如何开展测试？

软件生命周期中，需求是整个周期的源头。良好的开端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企业中，并没有对需求引起足够的重视。原因并不是PM们不知道需求的重要性，而是商业竞争中不得不裁剪某些看似不能获得很大利益的步骤。

什么是需求？很多PM和开发人员都未必真正考虑过这个问题。IEEE对需求有以下两种定义的方式。

1. 解决用户问题或达到用户目标需要具备的条件或能力

2. 遵守合同、协议、规范或其他要求

然后用规范的文档描述出来，就成了我们熟悉的SRS。

我们常说的需求，其实并不是我们认为的SRS。SRS应该叫做需求规格说明书。那需求是什么呢？与需求规格有什么区别？

需求：对要实现的功能的粗略描

需求规格：对需求的精确定义

我们知道，在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符。性能方面，时间和容量规定等。当然还包含其他非功能，性能方面的定义。

除了以上所说的需求，对于测试人员，还必须有测试需求。这个环节，很少有企业会重视。测试需求分为2方面：

需要测试哪些方面

软件是否可测，需要增加哪些开发需求

其中第一条，很多企业都列到了测试计划中，这也可以，没有规定一定要放到哪个文档里。但是对于第二条，可以说几乎没有多少企业去做。

接下来，在没有明确需求，需求规格，测试需求的情况下，我们怎么去做测试呢？现在很多企业，其实就是在这种情况下做项目的。

当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能，背景，架构。于是，马上就会想得到需求文档。但结果往往是失望的，根本没有文档，或者文档根本不具备参考价值。此时不必太失望，因为这种情况实在是太常见啦。这时，请试着从以下几个步骤着手。

查阅文档：文档是最具权威的，也是记忆最长久的。有时，我们的项目可能是在原有产品的基础上，进行版本升级。这时，先去找找，有没有原有版本留下的需求，或者是用户手册等文档。从这些文档中，了解项目的背景，系统的基本功能。这对了解新项目是有很大好处的。并且，在产品升级的项目中，验证老版本的功能在新版本中是否正常，也是一个必要的工作。可以先参考老版本的相关文档，设计新版本中的用例。

也有时，我们的项目是一个行业项目，比如金融项目。我们可以参

考一些行业知识的书籍，文档。这对理解系统也有很大的好处。

实在没有文档，那只好暂时跳过这一步骤了。

在进入下一步骤之前，你可能得到了一些相关文档，也可能什么也没得到。无论如何，你可能对系统已经有了一些了解。这时，请记录下来，写成文档。无论是对自己，还是对别人，在以后都可能极有参考价值。试想一下，如果前人已经给你留下了这些文档，你是否可以轻松很多？还要注意及时更新你的文档。因为你对系统的理解，随时都在变化着，一定要保证你的文档和当前你对系统的理解是一致的。

试着使用系统，根据经验和常识猜测：既然没有需求，那可以推测，该项目的管理一定是很糟糕的，对测试也不会投入很大的成本。因此，测试人员一般都是在编码完成后才进入项目。这时，应该已经可以看到成型的系统了。在没有需求的情况下，试着先“玩”一下系统吧。在这过程中，你应该对系统有可更深入的认识，在上一阶段中，你可能留下很多疑惑或是猜测，这时应该能排除一部分了。

使用系统的同时，你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识，比如什么是持仓，什么是平仓。那么你如何能真正理解这个系统呢？当你有了业务知识以后，你会进行更深入的思考，来全面测试系统。

你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选，不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。

最后加上你的主观判断，你对系统的整体感觉怎么样？是否越用越厌烦，为什么厌烦。系统的反应速度是否可以容忍，细节处理是否圆滑，等等。

在你认识系统的时候，可以使用一些方法，来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时，你也留下宝贵的文档。当然，这个步骤中，你也要随时注意保留和更新文档，以备后用。

沟通：需求规格不一定非要以文档的形式表现出来。软件既然能做出来，那肯定是有需求的。而最清除需求的，一定是软件的直接制造者，开发人员。开发人员自己知道需求，但一般不会主动和测试人员沟通。因此，测试一定要主动和开发人员沟通。可以安排会议，让开发人员给测试人员介绍系统，并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候，一定会有更多不明确的地方。这时就需要利用自己的行业知识，计算机知识等，猜测一

部分。不需要每个细节都去询问开发人员。因为开发人员也有自己的工作，他们不希望花太多时间来给你解释。

有些项目中，客户会直接参与到项目组来。这时，测试人员在权限允许的情况下，可以和客户进行沟通。客户那得来的需求，是最原始的需求。但是，客户未必有良好的表达能力来描述希望的功能，也未必有计算机知识，因此不能描述出一些隐式的需求。在被允许的情况下，测试人员可以和客户进行交流，不仅可以帮助客户正确描述出真实需求，测试人员也能详细了解需求。但是项目是要考虑成本的，客户的期望是无限制的。在客户提出需求以后，测试人员要先和PM或其他相关负责人协商后，才能将与客户交流得来的需求，作为测试的依据。同事，第一时间告知相关开发人员最新的信息，也记录成文档。这时，你就将非文档形式的需求，转换为文档形式了。至于文档的格式，不一定要按照标准SRS的格式。因为它本身就不是个规范的SRS。以任何容易理解的方式，组织你的文档。

有时候，会根本找不到可以沟通的人。不要奇怪，确实就是有这种时候。比如：

1. 测试一个开源软件

2. 接到一个测试外包，但又没有得到相关文档，为了追求利益，还是接下了

3. 软件项目组的部分人员已经联系不上等等

这时候，一方面需要PM协调获取相关资料，联络相关人员。另一方面，测试人员也可组织头脑风暴，利用集体的智慧，共同探讨和猜测软件中的各个环节。也可以安排Bug Bash，让尽可能多的人员参与随机测试。一定会有人提出具有创造性的意见的。

在进行以上步骤的时候，利用良好的工具，能让你事半功倍。我经常在使用的一个工具，就是Mindjet MindManager。这是一个很好的，帮助扩展思维的工具。它以分支的形式，来表现你的思维层次。你可以先列出个最基本的系统整体结构，然后逐步细化，增加分支。不要急于一次就将真个系统分析透彻，这是不可能的。你在进行以上步骤的时候，随时会细化这个结构。当项目结束后，看看这个结构图，简直可以当作SRS来参考。

49. 如何尽快找到软件中的bug?

1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

2、把自己当成是用户，把自己当成用户去使用该软件，比如在试用软件的过程中，思考用户是这样操作的么

3、善于怀疑 ，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生；别人认为是对的，我却认为是错的。假如一个水平很高的程序员编写的程序，不要有“他写的这个程序应该没有问题吧”这种想法，这样很容以遗漏软件中的Bug。

4、不用让程序开发员“用户不会这样操作”的观点说服自己，遇到这样的情况，你要坚持自己的正确的观点，把这种现象作为一个Bug。

5、在测试的过程中要跟踪一条数据的完整流程，比如“点击商品—收藏商品—加入购物车—订单结算—付款—消费二维码—消费—二维码失效”，如果在测试软件过程中业务流程逻辑都走不通的话，还么这个软件测试与不测试就没有什么区别的。

**6、在测试的过程中要跟踪一条数据的完整程，**要注意的事项 ，程序员提交新的版本后，作为测试人员应该立即与程序员沟通这个修改的功能，并了解这个新修改的功能影响那些功能。而被影响的功能，是在回归测试中优先重点测试的地方，而且也是最容易产生Bug的地方。

7、软件的边界值 ，众所周知软件最容易在边界值上出现问题，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空的情况；

8、非法容错性，比如在需要输入数字的地方输入字母，在需要输入字母的地方输入数字，在需要用户输入的文本框中拷贝字数很多的整编文章到这里测试看看软件是如何做处理的；

9、学习他人经验：三人行必有我师焉，人外有人，天外有天。

50. 什么是bug？

• 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

• 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

• 和预期不一致的软件行为。

  一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。

  和测试员预期不一致的软件行为。
  和程序员预期不一致的软件行为。
  和文档预期不一致的软件行为。
  和管理者预期不一致的软件行为。
  和客户预期不一致的软件行为。

51. ATM机吞卡的吞卡现象是不是BUG?

1.由于保护机制，你一次取钱数额有限，需要多次操作的时候每次现出卡你会觉得麻烦无比。

2.吞卡当然是为了安全，这没有什么争论吧。

3.至今从没见过吞了的卡还能吐出来的，根据后边ATM机的构造，也不可能再退出来，是直接掉在一个小盒子里的。

4.不可能你随时去取吞卡别人就给你取，首先ATM必须双人操作才能进，第二营业厅也必须双人在场，不能一人在营业厅，所以一般都是加钞的时候顺便取出来。

5.现在在任何地方应该都不会有不核实情况直接给人吞卡的，外行卡除外，外行卡被吞，本行毫无办法核实任何信息，只能让你出示身份证信息并登记，确保是被你这个人取走的。

52. 如何减少非问题单的提交？

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

53. 有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

同类型软件在你的操作系统硬件环境上运行，如果一慢一块，则是软件问题

同一软件在别人的操作系统上，如果运行速度加快，则是你的操作系统或硬件的问题

54. 你们发现bug会怎么处理。

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

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

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

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

• 1

2）漏测：

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

 解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。
 b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

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

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

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