什么是软件缺陷（bug）
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其应有功能的缺陷。一般定义缺陷有以下5条原则：
- 软件未实现产品说明书要求的功能。
- 软件出现产品说明书指明不应该出现的错误。
- 软件实现了产品说明书未说明的功能。
- 软件未实现产品说明书虽未明确提及但应该实现的目标。
- 软件难以理解，不易使用，运行速度慢，或者软件测试员认为最终用户会认为不好。
提交缺陷（bug）的要求:
Bug描述的基本要求是分类准确、叙述简洁、步骤清楚、实际结果描述准确、复杂问题有据可查（截图或其他形式的附件）。基本要求如下：
问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其他信息
- 单一：尽量一个bug只针对一个软件缺陷
- 简洁：每个步骤尽量简单明了
- 再现：问题必须能在自己机器上重现方可上报（个别严重问题重现不了也可上报，但必须标明）
- 复杂的问题：应附截图补充说明或直接通知指定的修改人，截图文件格式建议用JPG或GIF
- 报告中不允许使用抽象的词语：如“有错误”、“有时候”之类的不确定语句
一个BUG的生命周期
通过一个比较完整的bug的处理流程图，更深刻的理解bug的状态以一个bug的生命周期。
详细介绍：
提交（打开）缺陷
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。
如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。
有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。
也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
最后，“状态”和“指派人”的对应关系如果更加细化，对项目而言是有益的： ``` 已关闭--->指派给修复这个bug的开发工程师。
无需解决，不是bug--->指派给提交这个bug的测试人员。
无需解决，迭代待解决--->指派给项目的产品经理。 ```
软件生命周期的主要阶段
软件生命周期(SDLC)的六个阶段
1、问题的定义及规划
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。”唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4、程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。黑盒测试
什么是黑盒测试
黑盒测试又称功能测试或者数据驱动测试，是针对软件的功能需求/实现来进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构
黑盒测试部分用例设计方法
等价类划分
解析：
1）输入条件中规定了输入数据的取值范围，可分为一个有效等价类和另两个无效等价类
2）输入条件中规定了输入数据的个数，可分为一个有效等价类和两个无效等价类
3）若规定了输入数据必须遵循的原则，则可分为一个有效等价类和若干个无效等价类
4）若输入条件中规定了输入数据的一组取值，且软件对不同的输入值对应有不同的处理，则每个允许值构成一个有效的等价类，其他值构成一个无效的等价类
5）若规定输入为整数，则正整数、负整数。零构成有效三个等价类，小数构成无效的等价类
边界值分析
意义：测试输入数据规则的边界是否有问题
较常用
1)若输入条件规定了取值范围，则选择恰好落在边界上和处在边界内、边界外的测试值
2）若规定了输入数据的个数，则选择最小个数，比最小个数多1、少1，比最大个数多1少1等几种测试情况作为测试时输入数据的个数
3）若输入数据为有序集合，则选择有序集合中的第一个、最后一个以及越界输入作为测试用例
因果图
1）分析软件规格说明书描述中，那些是原因（输入条件和输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标志符
2）分析软件规格说明书描述中的语义，找出原因与结果之间、原因与原因之间的对应关系，根据这些关系，画出因果图
3）由于语法与环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现，在因果图上用一些记号表明约束或者限制条件
4）把因果图转换成判定表
5)把判定表的每一列作为依据拿出来设计测试用例
错误推测
根据经验和直接来推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法
猜测哪有错，程序中有可能出现错误的地方，基于代码评审来看
根据经验推测可能出现的错误
1）程序中所有可能出现的错误
2）容易发生错误的特殊情况
3）以前产品测试中曾经发现的错误
常用功能测试方法（浏览一下即可）
常用的功能测试方法
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1、页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3、检查按钮的功能是否正确：如update， cancel， delete， SAve等功能是否正确。
4、字符串长度检查： 输入超出需求所说明的字符串长度的内容， 看系统是否检查字符串长度，会不会出错。
5、字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。
6、标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。
7、中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错。
8、检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出。，带出信息和添加的是否一致
9、信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。
10、检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理。
11、检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。
12、检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。
13、重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14、检查多次使用back键的情况： 在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。
15、search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
16、输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
17、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19、快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20、回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。
手工测试和自动化测试的优缺点
手工测试和自动测试
a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现
b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试
手工完成测试的全部过程无法保证测试的科学性与严密性:
修改的缺陷越多，回归测试越困难
没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率
反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一
测试花费的时间越长，测试的严格性也就越低
自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析
软件测试不可能完全自动化
不能完成所有手工测试任务
无创造性且灵活性差，不能改进测试的有效性
过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时
测试脚本的维护高
来源：oschina
链接：https://my.oschina.net/u/4346073/blog/3673045