测试人员担心的是: 逃逸缺陷, 自己那块没有测试点没有覆盖到, 我常常在思考这些问题:
怎么知道软件足够好?
如果软件并不是足够好, 怎样才能知道?
怎么知道已经完成了足够的测试?
测试人员的核心工作: 测试软件, 能在规定的时间内交付合格的产品.
所以就引申出两点影响我们的测试工作:
测试计划很重要计划部分我到后面的文章写一下.
还有一个是我们介入测试后具体该怎样测 (这个是我今天要解决的)
怎样测试这确是我很关注的一个问题:
首先我们思想中要有一个层级关系:
1. 首先用: http://www.cnblogs.com/insane-Mr-Li/p/9049510.html 思考问题的方式来搞清楚我们要测的是个什么东西, 我们想要对他做些什么, 从需求种筛选测试点.
2. 明白我们整个 web 测试点的框架: 功能测试, 性能测试, 可靠性测试, 负载测试, 易用性测试, 强度测试, 安全测试, 配置测试, 安装测试, 卸载测试, 文档测试, 故障恢复测试, 界面测试, 容量测试, 兼容性测试, 分布测试.
功能测试: 一般都是可以从需求上筛选一些的, 我们也可以看到真正做出来的东西再挑一些测试点再用 http://www.cnblogs.com/insane-Mr-Li/p/9049510.html 思考方法来考虑一遍, 筛选出一些通用测试点和这些功能的个性化测试点, 再进一步的用用例设计方法来筛选才是点, 然后再设计成用例.
例子: 上传下载
认识事物:
1. 是什么?: 根据需求明白这个东西是什么? 它主要想实现是什么?
测试点: 1. 上传附件
2. 整个上传文件的界面和操作风格是否与真个系统协调, 文字显示是否正确.
3. 页面按钮: 新增, 修改, 清除按钮是否生效,
2. 为什么?: 为什么上传附件, 上传的是什么东西? 可联系需求的前后关系是否合理.
测试点: 1. 设计是否有缺陷
2. 文件 (格式, 大小, 数量)
3. 怎么办?: 是怎样上传的?
测试点: 1. 上传分哪些步骤
4. 时间: 一般客户会在什么时间来操作系统? 操作的相应时间会是多少? 多长时间能测试完?
测试点: 1. 集中使用网速, 和并发问题
2. 操作的响应时间问题 (单个, 多个,)
5. 地点: 从哪里来? 现在在哪? 去往哪里?
测试点: 1. 从哪里跳转到这个上传页面
2. 上传和下载的位置是否合理
3. 上传之后应该上传的东去哪了, 上传的对不对
4. 上传文件的路径 (选择, 和手工输入, 文件名长度, 特殊字符等)
6. 人物: 谁在使用长传, 用什么方式上传?
测试点: 1. 这个软件使用者是: 老人, 小孩, 年轻人, 残疾人 (根据每种人的特点做相应个性化)
2. 是触屏手点的, 鼠标点击, 还是只要选中像回车键就可以等
7. 效果: 实际结果与预期结果
需要自己明白
8. 多少: 这个任务的量有多少, 我多久能测完 (属于测试计划中的)
我们还要搞明白这些问题:
1. 我们想要一个预期结果, 或者是客户所说的一个预期结果.
2. 我们现在有哪些?
3. 我们还要准备什么数据, 或者我们还能从别的地方准备的数据
测试点: 1. 前期准备的数据
2. 我现在有的数据
4. 上转到哪里?
再用用例设计方法;
上传附件
1. 有没有这个上传附件的地方
2. 按钮的大小, 美观, 易用性
上传的文件是什么?
等价类边界值: 有效的文件, 和无效的文件, 离点, 上点
1. 文件格式
2. 文件大小
3. 文件的数量 (单个上传, 批量上传)
(在这些有效等价类和无效等价类中, 对应的相应提示是否合理)
特殊域:
1. 只上传一个文件但是文件的大小以超过上限
2, 上传空文件
3, 不上传文件点上传
上传分哪些步骤:
流程分析: 上传界面我还需要做哪些步骤才能完成上传, 如果没有这些步骤会有那些结果
集中使用网速, 和并发问题
场景分析法: 1. 客户集中在什么时间使用, 可能这个时间段用户较多网络服务, 或软件运行有压力, 我们可以考虑租用高峰期期时间段服务器等措施解决.
2. 软件, 服务器, 网络, 等因素的并发问题
异常性测试:
1. 在上传是断网, 又忽然间连上, 上传还会不会继续
2. 中断了的话下次上传会不会有没有覆盖上一次已上传的部分.
3. 批量上传中有效数据中掺杂着一些无效数据会不会筛选出无效数据, 把有效数据进行上传.
4. 硬盘空间不足
未完待续....
来源: https://www.cnblogs.com/insane-Mr-Li/p/9076083.html