目录
首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。
而软件测试,自然是为了发现软件(产品)的缺陷而运行软件(产品)
比较标准的软件测试的定义是:在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
IEEE 标准的定义:使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验;它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
首先先来看软件的生命周期
然后根据软件的生命周期可以对比下图的软件测试生命周期
首先我们站在开发人员的角度看看测试人员描述bug不准确会带来什么问题？
1.描述bug不清晰，就一句话，没有具体的操作步骤。
比如：拨打电话出现死机。（就简单的一句话，就啥都没了，拨打什么号码–没写，在什么情况下拨打电话–没写）
2.提交的bug看不懂啥意思，不知所云。
这种bug只有测试工程师自己能看懂，别人根本看不懂，他却以为别人能懂。
3.没有写出现的概率。
偶发的bug没有log和其他更多信息，有的bug概率很小，小到不影响用户使用，如果不写清楚，开发人员将浪费大量时间去定位问题。
4.bug发生的前提条件都不写。
比如：bug描述是充电图标显示重叠。但是没有写什么条件下出现，开机状态？还是关机状态？开发工程师懵逼，还要自己去一个个去试，浪费开发人员的时间，描述不详细但是测试工程师还觉得自己没毛病，一切挺好。
5.bug等级乱定位
比如一个很小的甚至是建议性的问题，把bug等级提到最高。软件开发一看，全是致命性1级bug，仔细一看很多小问题也被提为1级bug，此时开发人员的心情肯定的奔溃的。
6.测试工程师描述bug，却不写预期结果。
开发都不知道要修改成什么样，一脸懵逼。结果开发理解错了，修改的结果不是预期的结果，这就浪费开发的时间了，你想想此刻开发人员的心情是怎样的？
7.出现问题的软件版本没写清楚，开发人员不知道是在哪个软件版本出现的。
所以正确的bug描述才是开发人员和测试人员好的沟通方式
1.bug标题要简洁明了，不要啰嗦一堆。
2.要写出现问题的前提条件。
什么情况才会出现,必须要写清楚。
3.操作步骤要分步骤一步步写清楚，不要怕麻烦。比如步骤1，步骤2，步骤3。
4.要写实际结果和预期结果，让开发清楚要修改bug到达的预期效果。
5.要写出现的概率，比如操作10次出现1次。
6.提供必要的截图和log，甚至复杂的操作步骤要提供视频。
7.bug等级要分类好，致命性bug、严重bug、一般性bug、建设性意见，必须严格按照标准划分。
8.出现bug的软件版本号，要写清楚。
例如：
Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等
Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等
Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等
Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等
发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG
1、选择测试方法：选择最合适当前项目的测试方法（比如项目紧急的时候？项目频繁发版）（例如：重复测试的工作可以采用自动化测试）
2、角色和职责：需要在测试策略里面明确定义各个角色，以及该角色的职责。比如项目经理、测试组长、测试工程师。
3、环境需求：这一点非常重要，它将描述测试时需要的系统环境（软件，服务器Linux，windows，数据库MySQL），包括软硬件以及网络环境等等。在澄清环境需求的时候，测试组织可以识别出资源方面的风险。
4、风险分析：影响测试过程的风险都应该尽早被识别出来，而且必须有相应的解决办法以便消除或减轻这些风险。（例如：人员休假、软件是否完成）
5、测试进度评估：测试进度将会评估完成测试所需要的时间。在设定进度的时候，首先需要明测试范围（比如说这次增加一个D模块，部分功能会影响原来已经上线的B模块的功能）然后根据测试资源的多少来指定能被各方面认可的测试进度计划。
6、回归测试（Regression Testing）策略：回归测试用来保证之前fix bug的代码不会影响软件的其他部分，这样需要我们选择已经执行过的测试用例重新运行。测试人员需要找到一个方法来确定哪些测试用例应该在回归测试中运行，用例不能太多，因为资源有限，用例也不能太少，否则会达不到必须的测试强度。
7、优先级：测试范围内的东西不会都是一样重要的，加上测试资源各种有限，所以为测试的模块排定优先级是十分的必要。
优点：
强调需求，设计的作用，前一阶段完成后只需关注后续阶段；
为项目提供按阶段划分的检查点，里程碑清晰
缺点：
线性研发过程难以适应需求的频繁变化
项目周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险
强制的里程碑，对于开发过程中出现的变化，适应能力较差，
文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。
优点：
在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。
缺点：
但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。
优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。
局限性：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。
敏捷模型是在互联网的快节奏下应运而生的，也是当前最为主流的开发测试模型。
举一个例子：
以抖音为例，在需求分析阶段，先收集用户的需求：市场上目前缺少短视频的APP，同时，有了今日头条的成功，能不能沿用它的设计思路，将展现形式由文字转变为短视频，通过标签推荐的算法，向用户推送他可能感兴趣的短视频呢？
基于这样的需求，形成需求文档，接下来，产品经理拉着团队里开发、测试、设计一起做需求评审。
除了开发根据需求文档做开发计划之外，与此同时，测试人员由于更早的介入到软件项目当中，也可以根据需求文档开始编写测试计划了。
形成测试计划之后，开始着手测试用例的设计与开发。
跟传统的瀑布模型、V模型不同，等到开发人员提测的时候，测试用例已经设计开发完成，可以直接开展测试工作。
执行测试的过程中，发现了 bug 立即反馈给开发团队进行修复，修复后进行回归测试，直到全部测试用例通过，由产品经理来验收。
以上就是关于敏捷模型的介绍
左边描述的是针对单独的程序片段相互分离的编码和测试，此后进行频繁的交接，再通过集成，最终合成可执行的程序，对这些程序进行测试，这些程序还是需要冀衡测试，已经通过的程序可以进行封板提交给用户，也可以作为更大集成的一部分，X模型还定位了探索式测试，探索式测试是不进行事先计划的特殊类型的测试，能够帮助测试人员在测试计划之外发现更多的错误。
519
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
