测试人员担心的是：逃逸缺陷，自己那块没有测试点没有覆盖到，我常常在思考这些问题：
怎么知道软件足够好?
如果软件并不是足够好，怎样才能知道?
怎么知道已经完成了足够的测试?
测试人员的核心工作：测试软件，能在规定的时间内交付合格的产品。
所以就引申出两点影响我们的测试工作：
测试计划很重要计划部分我到后面的文章写一下。
还有一个是我们介入测试后具体该怎样测（这个是我今天要解决的）
怎样测试这确是我很关注的一个问题：
首先我们思想中要有一个层级关系：
1.思考问题的方式来搞清楚我们要测的是个什么东西，我们想要对他做些什么，从需求种筛选测试点。
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.硬盘空间不足 文章源自玩技e族-https://www.playezu.com/194571.html