（1）验证功能的（目标是把所有问题都找到）；
（2）执行所有的用例（每个模块都覆盖到）；
（3）随意测试/重要模块（发现可能被忽略的问题）；
5.用例的维护（维护阶段：评审阶段、执行阶段、结束之后）：
（1）与当前产品不一致；
（2）发现覆盖不全面的；
（3）用例多余；
（4）需求要求指标调整；
（5）用例描述不清的；
（6）部署后发现的缺陷；
6.用例怎么写比较好：
（1）整体用例逻辑清晰；
（2）执行环境，模块，步骤，结果（页面展现/数据库）；
7.用例怎么写，写在哪？
（1）根据需求文档写测试点，再转化成用例，测试点一般可以用xmind梳理；
（2）根据公司要求，写在禅道或者excel，或者是其他地方；
（三）执行测试，记录原始数据，对缺陷进行管理（缺陷报告记录bug，通知开发组）
1.软件测试的执行：
（1）执行测试用例；
（2）记录原始测试数据；
（3）记录缺陷；
（4）对所发现的缺陷进行跟踪、管理和监控；
2.可能遇到的问题（解决办法）：
（1）提交缺陷不能被重现；（清晰的描述，必要的前提条件，100%重现的步骤，输入的数据，缺陷的版本号，测试的平台，截图，日志；）
（2）对缺陷的理解不一致；（检查测试环境；）
（3）环境引起的缺陷是否算bug；（多次重现缺陷，确保正确性；）
（4）开发认为是重复的缺陷；（实际结果=预期结果，没有引起其他缺陷；）
3.什么是bug？基本概念：所谓bug，在程序中是指软件运行中因为程序本身有的错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。
4.什么是软件缺陷：
（1）要求的功能未实现；
（2）画蛇添足；
（3）出现指明不应该出现的错误（软件应该有一定的异常处理能力--当用户输入错误的数据时，程序应该给出恰当的处理）；
（4）需求虽未明确提及，但应该实现的功能（需求也是人写的，可能写的不全面）；
（5）软件难以理解、不易使用、运行缓慢，站在用户角度，所有不好的地方；
5.缺陷报告的组成
（1）缺陷编号(Defect ID)：表明提交bug的顺序、在实际项目中，整个项目统一编号，一般是由缺陷管理系统自动生成；
（2）缺陷标题(summary)：简明扼要的描述一下该bug；标题：简洁、具体；
（3）缺陷的发现者(Detected By)：一般就是自己；
（4）发现缺陷的日期(Detected on date)：一般是当天；
（5）缺陷所属的模块(subject)：在测试程序的哪个功能模块时发现的bug、开发经理据此-分配bug给开发人员；
（6）发现缺陷版本(Detected in release)：在测试程序的哪个版本时发现的bug；
（7）指派给谁处理(Assigned to)：测试人员指派给开发经理、开发经理根据bug所在的模块-指派给具体的开发人员；
（8）缺陷的状态(status)：表明bug此时所处的状况或被处理情况；
A.测试人员发现bug，提交缺陷报告给开发经理，把缺陷的状态置为：new（新提交）;
B.开发经理验证提交的bug，如果是bug，把缺陷的状态改为：open（打开的bug，开发组承认的bug），并指派给相应的开发人员修改；如果不是bug，把缺陷的状态改为：rejected（拒绝）;
C.开发人员看到指派给自己bug，进行缺陷修复，改完后，把缺陷的状态改为：fixed（修改完的bug、待返测的bug）;
D.测试人员对修复的bug进行返测，如果返测成功，把缺陷的状态改为：closed（关闭、返测成功的bug、归档）；如果返测失败，把缺陷的状态改为：reopen（重新打开的bug、返测失败的bug）;
--------------------------------------
以上过程一般称为“缺陷（报告）的处理流程”，或者“缺陷的跟踪过程”，或者“缺陷的生命周期”：New->Open->Fixed->Closed。
（9）缺陷的严重程度(severity)：表明bug有多糟糕或者对软件的影响有多大；
Urgent：造成死机、崩溃等重大bug；
VeryHigh：非常严重的bug；
High：严重的bug；
Medium：中等程度的bug；
Low：小的bug；
--------------------------------------
严重级别：
Block——崩溃的、致命的；
Critical——主干功能出错；
Major——次要的功能出错，或次要的分支出错；
Normal——非重要分支出错；
Minor——样式，细节问题；
--------------------------------------
说明：每个级别代表的含义在不同公司可能不同，一般会在专门文档中或测试计划中定义出详细的准则。
案例：Bug Level（级别） Definition（定义）；
性能：Performance；
功能：Function；
（10）缺陷的优先级（priority）：测试人员希望程序员在什么时间内或程序的哪个版本修改该bug；
Urgent：立即修改，否则会影响开发或测试进度；
VeryHigh：本版本修改；
High：下版本修改；
Medium：发布之前修改；
Low：在发布中允许存在的bug；
--------------------------------------
说明：每个级别代表的具体含义在不同公司会略有不同。
A.严重程度：一般严重程度越高，优先级越高；
B.影响范围：一般影响范围越广，优先级越高；
C.开发组当前任务：任务越轻，优先级越高；
D.解决bug的成本：成本越低，优先级越高；
（11）缺陷描述（description）：把发现bug的步骤、过程、使用的数据等记录下来，使程序员可以通过描述再现该bug；描述：详细的重现步骤、提供平台信息、截图；
--------------------------------------------
说明：
a、严重程度和优先级不是严格正比关系；
b、严重程度确定好后一般不修改了，优先级在实际工作中经常需要调整（一般是往后推延）；
c、在产品发布之前，不是所有的bug都会被修复；
d、对于不修复的bug，需要进行缺陷讨论，确定修改它的成本和风险以及该bug给用户的影响（造成的经济损失或导致法律诉讼）；
5.缺陷报告的用途
（1）记录bug；
（2）对bug进行分类（发现者、日期、模块、版本、严重程度、优先级、状态）；
（3）跟踪bug（new->closed）；
（4）对bug进行统计分析总结；
6.如何识别软件缺陷
（1）参考测试用例的预期结果——实际结果和预期结果不一致，就是bug；
（2）参考需求文档——与需求不符的就是bug；
（3）通过与开发、需求、用户沟通进行确定；
（4）参考缺陷的5点定义：
A.要求的功能未实现；
B.画蛇添足；
C.出现指明不应该出现的错误（软件应该有一定的异常处理能力——当用户输入错误的数据时，程序应该给出恰当的处理）；
D.需求虽未明确提及，但应该实现的功能（需求也是人写的，可能写的不全面）；
E.软件难以理解、不易使用、运行缓慢，站在用户角度，所有不好的地方 ；
说明：不可重现的bug又称为随机缺陷，也要提交，但是要说明它不可重现；
7.引起软件缺陷的原因
（1）所有的人都会犯错误，因此由人设计的代码、系统和文档中很可能会引入缺陷。当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效。虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。
（2）产生缺陷的原因是多种多样的：人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。
（3）失效也可能是由于环境条件引起的：放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。
（4）线上bug分析 ：非常慎重的对待线上Bug，项目组一起制定改进措施，杜绝再犯。
8.bug怎么写，写在哪？
（1）根据公司要求，写在禅道或者excel，或者是其他地方；
