第五部分：使用测试文档
2016-12-14 11:46:09 0 举报AI智能生成
使用测试文档
作者其他创作
大纲/内容
计划测试工作<br>
测试计划的目的<br>
软件测试计划-软件测试员与开发小组交流意图的主要方式<br>
测试计划过程的最终目的-交流测试小组的意图、期望、以及对将要执行的测试任务的理解<br>
测试计划主题<br>
高级期望
测试计划过程和软件测试计划的目的是什么<br>
测试的是什么产品<br>
产品的质量和可靠性目标是什么<br>
人、地点和事<br>
定义
构造-程序员放在一起需要测试的代码和内容的搜集<br>
测试发布文档-程序员发布的文档<br>
Alpha版-演示目的的早期构造<br>
Beta版-向潜在客户广泛发布的正式构造<br>
说明书完成-说明书预计完成且不再更改的日程安排<br>
特性完成-程序员不再向代码增加新特性，并集中修复缺陷的日期安排<br>
软件缺陷会议<br>
团队之间的责任<br>
那些需要测试、那些不需要测试<br>
测试的阶段<br>
测试的策略<br>
资源需求<br>
人员
设备
办公室和实验室空间<br>
软件
外包测试公司<br>
其他设备
测试员的任务分配<br>
测试进度
测试案例
软件缺陷报告
度量和统计
在项目期间每天发现的软件缺陷总数量<br>
仍然需要修复的软件缺陷清单<br>
根据严重程度对当前软件缺陷评级<br>
每个测试员找出的软件缺陷总数<br>
从每个特性或区域发现的软件缺陷总数<br>
风险和问题
编写和跟踪测试<br>
测试用例计划的目标<br>
有条不紊地仔细计划测试用例重要性<br>
组织
重复性
跟踪
测试（或者不测试）证实<br>
测试用例计划综述<br>
测试设计<br>
测试设计说明的目的-组织和描述针对具体特性需要进行的测试<br>
测试设计说明内容<br>
标识符-用于引用和标记测试设计说明的唯一标识符<br>
要测试的特性-测试设计说明所包含的软件特性描述<br>
方法-描述测试软件特性的通用方法<br>
测试用例确认-对用于检查特性的具体测试用例的高级描述和引用<br>
通过/失败规则-描述测试特性的通过和失败由什么构成<br>
测试用例
测试用例细节基本上应清楚解释要向软件发送什么值或者条件<br>
测试程序
测试程序说明为明确指出为实现相关测试设计而操作软件系统和试验具体测试用例的全部步骤<br>
测试用例组织和跟踪<br>
组织
计划执行哪些测试用例<br>
计划执行多少个测试用例？执行需要多少时间<br>
能否挑出测试集测试某些特性或软件部分<br>
在执行测试用例时，能否记录哪一个通过，哪一个失败<br>
在失败的测试用例时，哪些在最近的一次执行时也失败了<br>
最近一次执行测试用例是通过的百分比是多少<br>
管理和跟踪<br>
书面文档
电子表格<br>
自定义数据库
报告发现的问题<br>
设法修复软件缺陷<br>
不修复缺陷的原因<br>
没有足够时间<br>
不算真正的软件缺陷<br>
修复的风险太大<br>
不值得修复<br>
无效的软件缺陷修复报告<br>
报告软件缺陷的基本原则<br>
尽快报告软件缺陷<br>
有效描述软件缺陷<br>
在报告软件缺陷是不要做评级<br>
对软件缺陷报告跟踪到底<br>
分离和再现软件缺陷<br>
不要想当然地接受任何假设<br>
查找时间依赖和竞争条件的问题<br>
边界条件软件缺陷、内存泄漏和数据溢出等白盒问题<br>
状态缺陷仅在特定状态中显露出来<br>
考虑资源依赖性和内存、网络、硬件共享的相互作用<br>
不忽视硬件<br>
对软件缺陷分类<br>
严重性
系统崩溃、数据丢失、数据毁坏。安全性被破坏<br>
数据性错误、结果错误、功能遗漏<br>
小问题、拼写错误、UI布局、罕见故障<br>
建议
优先级
立即修复，阻止了进一步测试，立竿见影<br>
在产品发布之前必须修复<br>
如果时间允许应该修复<br>
可能会修复，但是即使有产品也能分布<br>
软件缺陷的生命周期<br>
打开-软件缺陷首先被软件测试员发现，被记录报告并指定给程序员修复<br>
程序员修复了代码，报告又指定回到测试员手中<br>
测试员执行验证测试，确认软件缺陷确实得以修复<br>
软件缺陷跟踪系统<br>
标准：测试事件报告<br>
手工软件缺陷报告和跟踪<br>
自动化软件缺陷报告和跟踪<br>
成效评价
0 条评论
下一页
