测试准入准出标准：
1、开发编码结束，并在开发环境已完成单元测试
2、需求规定的功能已实现，若没有完全实现，需提供测试范围
3、已完成集成测试，基本流程可以走通，界面功能已实现，代码评审并符合软件编码规范。
4、开发提交代码，提交并通知测试测试
5、兼容性测试要求明确
6、安全测试和性能测试范围和要求
测试暂停、停止
1、冒烟测试发现重大bug，或者bug过多，流程卡壳等，可暂停测试返回开发
2、被测项目暂停 测试暂停
3、优先级更高的任务 暂停测试
发现缺陷
1、用户体验差
2、界面明显错误信息
3、功能不完备没有按需求说明写代码，导致功能确实
4、功能不完善、流程不正常、异常情况处理
5、逻辑不正确，与需求说明书、测试用例不符
6、交互性不好，与其他模块集成出现问题
7、性能不好，压力承载差
缺陷报告
前提：上报的缺陷一定要是可以重现的缺陷。
偶发性问题可以先写在报告里，视优先级，后续跟踪处理。
缺陷报告不仅给开发看，还有质管人员、市场部产品等需求方。
缺陷报告包含信息
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
- 软件开发人员希望获得缺陷的本质特征和复现步骤。
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
缺陷报告的写作准则（5C）
- Correct（准确）：每个组成部分的描述准确，不会引起误解。
- Clear（清晰）：每个组成部分的描述清晰，易于理解。
- Concise（简洁）：只包含不可少信息即可。
- Complete：包含复现bug的完整步骤和其他本质信息。
- Consistent（一致）：按照一致的格式书写全部缺陷报告。
缺陷报告的组织架构
1、缺陷标题
2、缺陷基本信息
3、软件和硬件环境
4、软件版本
5、缺陷类型
6、缺陷严重程度
7、缺陷的处理优先级
8、复现缺陷的操作步骤
9、缺陷的实际结果描述
10、期望的正确结果描述
11、注释文字和截取的缺陷图象
- 提供测试的预备步骤和信息
- 简单一步步引导复现缺陷
- 每个步骤尽量只记录一个操作
- 每个步骤前使用数字对步骤编号
- 使用短语和短句，避免复杂描述
- 复现操作步骤要完整准确简短
- 没有缺漏任何操作步骤
- 每个步骤都是准确的
- 没有多余步骤
- 常见步骤合并为较少步骤
缺陷报告原则
- 组织Structure 最好做详尽的记录
- 重现Reproduce 必须检查问题是否可以重现，如果不可重现仍然要记录。（原则：编写缺陷报告之前反复尝试3次）
- 隔离Isolate 写之前隔离错误，改变变量，看看是否由于
- 对比Compare 如果以前验证过现在出错的测试用例，那么就该检查以前的测试结果，同样条件下以前的测试是否通过，如果通过，那么这就是个回归bug。
- 总结Summarize 第一行写总结，清楚看到这次功能需要修改哪些地方
- 精简
- 消除歧义
- 中立 保持公正的原则
- 检查 给一个或多个同行检查
缺陷跟踪（BUG管理）
JIRA、BUGZILLA、QC、禅道
项目模式基本流程
1、产品经理创建产品
2、产品经理创建需求
3、项目经理创建项目
4、项目经理确定项目要做的需求
5、项目经理分解任务，指派别人
6、测试人员测试，提交bug
易用性测试
指用户在使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户目的。
易用性测试包括对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。
包含以下方面：
1、易理解 2、易学习性 3、易操作性 4、吸引性 5、依从性
兼容性测试
浏览器测试：
浏览器兼容 操作系统兼容
浏览器内核：IE\Chrome\FireFox\其他
国产浏览器基本都是chrome内核改了改，选一个有代表性的浏览器测试即可。
工具：Letester （越来越少）
www.browsershots.org 越来越多 通过在线截图的方式展现页面的兼容性（限制在于只可以通过输入网址查看，未上线的项目无法查看）
SuperPreview 微软 （尚未完善）
APP测试：
人工测试、第三方测试工具