今天完成的事情：

因为重新去巩固黑盒测试，想到之前任务2里的几个测试方法 然后对之前任务里的东西重新做出改动修改

顺便发现自己用例的一些问题 重新理解等价类边界值场景这3个做了测试用例 重新学习了因果图和错误法

明天计划的事情：开始重新复习mysql增删改查 学些sql语句 重新复习压力测试工具 ，之后我想学习下python语言 然后边项目边学习自动化

遇到的问题：无
收获：

    错误推测方法

       基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

       另外，在项目测试过程中，针对非用例所发现的问题，如通过探索测试、随机测试等方法发现的或售后反馈的问题，如果具有普遍性，可以将其转化为用例，作为当前用例库的经验用例补充。

    因果图方法

       前面介绍的等价类划分法和边界值分析法都是着重考虑输入条件的罗列，并没有考虑到输入的各种组合，也没有考虑各个输入之间的相互制约关系。如果在测试时考虑全部输入条件的各种组合，可能组合数将是天文数字。因此必须考虑描述多种条件的组合的合理性，这就需要利用因果图。

       在软件工程中，有些程序的功能可以用判定表的形式来表示，并根据输入条件的组合情况规定相应的操作。判定表的每一列对应一条测试用例，以便保证测试程序在输入条件的某种组合下，操作是正确的。

       例如：彩信发送时，联系人&&附件&&文本相互制约能力，等价类划分法和边界值分析方法就变得不适用了。

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。白盒要考虑测试用例对程序内部的覆盖程度，最好的白盒测试是能覆盖到每一条路径，但是由于路径数目极大，要执行每一条路径是不可能。但我们能做到就是让覆盖率变高一点，下面要介绍的六种覆盖测试方法，看看他们的覆盖程度。

白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

jmeter的响应断言。

作用：一个HTTP请求发出去，怎么判断执行的任务是否成功呢？通过检查服务器响应数据，是否返回预期想要的数据，如果是，判断任务成功，反之任务失败。