功能测试总结
一、软件测试
定义：软件测试是为了发现问题而执行的过程
目的：占在用户角度，分析问题
二、公司测试的流程：
参与需求评审（评审过程中，会和产品人员说出自己的对需求的想法以及意见），深入需求，分析需求
编写测试计划---评审测试计划（有些公司无需评审）
根据需求文档编写测试用例
评审测试用例
开发提测项目：（冒烟测试：成功则继续，不成功则跟开发人员沟通修改bug，并且把堵塞的bug提到管理系统中，发给对应项目人）
冒烟测试通过后，执行第一轮需求测试用例
提交bug跟踪bug，并进行回归测试
第二轮：重新把所负责的模块继续跟踪bug，并进行回归测试
第三轮：兼容性测试（重新跟踪bug，并进行回归测试）
第四轮：系统测试
最后验收测试（把最终产品交给产品人员进行验收测试，同时测试内部人员也进行验收）
发邮件告知该项目所有负责人，说明：该项目已达上线标准
把项目提测到预线上环境，在预线上环境进行一轮系统测试，完成后，通知相关人员 并说明：已达到上线标准
项目经理统筹会议，负责该项目的开发，测试，产品人员叫到一起参加会议，遇到风险，则沟通如何避免风险
安排时间上线
测试人员在此进行验收，相关人员同时进行验收后，交给产品人员验收完后，项目上线
编写测试报告总结
三、编写测试计划：
编写内容包含：
软件计划的目录
文档说明（变更说明，是几个版本，审批人，编写人）
编写目的
测试策略
测试范围·
测试阶段的里程碑
风险
测试人员
测试类型
四、编写测试计划的目的：
提前规划好测试流程，让测试思路更清晰
编写测试计划提前评估项目风险，制定计划避免风险早做准备
划分好模块化里程碑，规划好模块测试时间，要按时完成项目！
五、编写测试用例：
测试用例定义： 对一项特定软件产品进行描述，指定输入，预期结果和一组测试想执行条件的文档！
测试用例目的：
防止测试不全面，是测试人员的重要依据
与产品、开发需求统一
再次与产品人员确认预期结果
六、按阶段执行测试流程
单元测试：把整个项目分为最小粒度的测试，称为单元测试也叫模块测试！
模块分为：驱动模块和桩模块，桩模块调用驱动模块！
集成测试：把多个模块组合在一起，进行测试
集成测试遵循的原则：
所有公共接口都应该被测
关键模块必须进行充分测试
集成测试应按到一定层级来进行
集成测试的策略应该综合考虑质量，成本和进度之间关系
集成测试应尽早开始，以总体设计为基础
在模块和接口的划分上，应测试人员和开发人员多沟通
当接口在此修改后，应在此进行测试
测试执行结构应如实记录
系统测试：该项目全部完成，对项目整体进行测试e
验收测试：把测试人员测试完的项目交于需求方，需求方进行验收
七、按是否查看代码划分流程：
黑盒，白盒，灰盒
黑盒： 不查看代码，执行项目需求的功能测试
白盒：对程序代码进行走查测试
灰盒：进行一部分走查测试，同时执行全部功能测试
八、按是否运行程序划分：
静态测试：指不运行被测试的软件，只是静态的检查程序代码，界面和文档中存在的错误
动态测试：指实际运行被测试的软件，输入相对应的测试数据，检查实际结果与预期结果是否一致
九、其他测试
回归测试，冒烟测试，随机测试
回归测试：跟踪bug，bug定位解决后，验证bug是否解决，称为回归测试！
冒烟测试：用一根烟的功夫查看影响下一步的功能点！
随机测试：随机数据是随机产生的！测试人员想测那就测那
十、需求分析
需求来源：
来自用户的需求
来自产品人员对产品的长期规划
来自公司内部的需求
产品偶尔的抽风奇想
需求文档：产品人员所规划好的文档
需求原型：用线条，图形描绘出的产品框架，也称线框图
测试人员分析需求点：
测试人员带着问题去分析需求
分析需求时要明确测试人员测试范围
测试人员要明确需求中所要的最终预期结果
测试人员需要找出产品需求文档中遗漏的点
测试人员分析需求时一定要考虑数据来源是什么？数据如何调取
需求文档的重要性：
是产品，开发，测试人员开发测试用例的重要依据
软件测试需求是开发测试用例的依据
有助于保证产品的质量与进度
测试需求是衡量测试覆盖率的重要指标
测试需求的特征：
完整性：每一项需求都必须将所要实现的功能描述的清楚，是设计人员实现功能所需的信息
正确性：每一项需求都必须准确的陈述其要开发的功能
可行性：每一项需求都必须在已知的环境或系统实现的
必要性：每项需求都是编写文档的根源，每项需求都需求回溯到具体用户
无歧义性：对所有的需求，读者只能有一个明确统一的解释（语言，图，表）
可验证性：检查每一项需求是否可以通过测试用例或其他验证方法。
测试人员什么时候介入项目：
产品需求开始外部第一次评审就需要介入
如何提高需求能力：
熟悉业务，了解系统
用客观角度站在客户方思考
多思考，不要被思维束缚
十一、功能测试的方法/功能测试用例的方法
方法： 等价类划分法，边界值法，因果图方法，判定表方法，场景法，错误推断法
等价类划分法：有效等价类/无效等价类
有效等价类：输入有意义的数据构成的集合，查看是否满足规格内的功能和性能
无效等价类：正好相反，输入无效的数据
边界值法：需求文档中规定参数的临界点
原则：
1、如果输入条件规定了值的范围，取刚好达到这个范围的边界值，以及刚刚超出的那个值作为测试输入数据
2、如果输入条件规定了值的个数，则用最大个数，最小个数，比最大个数多一个，比最小个数小一个的数做为测试数据
3、如果程序的规格说明给出的输入域或输出域是有序集合（如：有序表，顺序文件），选择第一个元素和最后一个元素作为测试用例
4、如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。
5、分析规格说明，找出其他可能的边界条件
因果图法：分析软件需求规格说明描述那些是原因，那些是结果！
判定表方法：判定表示分析和表达多逻辑条件下执行不同操作的情况的一种方法！
场景法：现在的测试都是用事件触发来控制流程的，事件触发情景变为了场景，而同一事件不同的触发顺序和处理结果形成了事件流 主要用于：业务逻辑复杂的一些功能、性能测试！
错误推断法：根据软件测试人员工作经验来判断一些错误问题！
集成测试应当按一定的层次进行
