第三章--测试用例与bug.ppt

第三章 测试用例与bug 测试用例的设计 设计测试用例----测试用例（test case）是按一定顺序执行的与测试目标相关的一系列测试。测试用例设计将产生许多测试所包括的执行动作、输入值、期望结果及其他任何运行测试的有关信息，如测试配置、周期、优先级等。 一个好的测试用例应该大致有4个特性： a，有效性：测试用例可以有效检测软件质量，能发现缺陷，或至少可能发现缺陷； b,可仿效：同一测试用例可以测试很多内容，因而减少测试用例的数量，但前提要简明易懂，尤其与开发人员能很好地通过测试用例沟通，我们曾经有一阶段因为测试用例的问题导致开发人员的抱怨，并展开过很强一阶段的培训强化； c，经济性：测试用例的执行、分析和调试是否经济，开发与测试都需要考虑一定的时间性和成本性； d．可维护性：每次软件修改后对测试用例的维护成本较低，即不修改或很容易的修改，方便以后的项目传承； 开发编写软件测试用例 开发编写软件测试用例主要包括准备测试脚本、测试输入、测试数据以及期望输出。 这部分的工作，主要是测试规程的正式编写，以及测试用例、测试脚本的编写。比如，测试数据的编写、应用协议的编写，各个接口的测试，功能的测试，函数的输入输出等，在测试规程编写时，同时也要考虑测试用例、测试代码的编写。 a，对于手动测试来讲，测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。 b，自动测试指测试者运行应用程序的同时，把他所有动作，包括键盘操作、鼠标点击等捕获下来，生成一个脚本文件，这个脚本可以被“回放”，也就是按照上一次的所有动作重复执行一遍，实现自动运行和测试。一些大数据量或重复机械的测试须借助自动测试工具来完成，并能测试效率。比如手机开关机或系统连续开启关闭10000次、连续长时间运行、多个任务一起运行等等。 对于自动测试，可能只需要启动测试工具，并告诉工具执行哪些测试用例，一般测试自动测试工具都要提前写好测试脚本，让其按照规定的动作执行，比如我们需要检测已创建或生成的文件的容量、文件数并按照一定的算法执行算出一个固定的值； 手工测试和自动测试是相互互补的 ，对一个成功的测试来说缺一不可。 C，编写设计执行测试用例的一些通用原则： A，Smart原则： specific：明确的 measurable：可衡量的（及时、效率、数量、品质、成本） Attainable：可达成的（虽具挑战，但必须是可达成的） Relevant：具有相关性 Time Band：有时间性 B，STAR/AR： Situation/Task：情况/任务 Action :行动，指出此人表现的细节 Result：结果，显示此人行动的结果或影响 Attention Action：建议行动，需要更谨密思考得行动 Enhanced Result：强化结果，更甚的结果或影响 测试用例结果的输出 将测试结果与期望输出进行比较 应该对每次测试的实际输出进行分析研究，判断软件功能是否正确。 该验证可以是非正式的测试者主观判断，也可以是将实际输出与期望输出进行严格准确的比较。 作为专业的测试人员，必须严格按照测试用例，对比输出的结果并记录追踪； 测试用例的内容 一般我们的测试用例包含很多方面与内容，比如：1，项目名称；2，模块；3，主题；4，创建日期；5，创建人、负责人；6，优先级；7，编号；8，测试动作和步骤；9，附件、脚本和log等；10，期望结果；11对应bug；12，上次测试的时间；13，测试的周期或轮数；14，测试结果、测试工具；15，测试的当前版本；16，结果描述；17，是否有必要设为稳定用例等等。Bug单和测试用例一样，要尽可能地把所表达的意思和问题陈述清楚，要简明扼要、主题和步骤鲜明。 如下是我以前带项目时所用的测试用例的模板： 需要补充解释以下几点： 1，项目的时间性不可能允许每一个测试循环把所有测试用例都执行一遍，尤其是回归测试或项目收尾时，需重点保证基本基本功能以及改动点相关的测试用例，所以勾选优先用例的一般都是此类用例，而其它很稳定的部分可以设为稳定用例，不用再花过多时间在其上； 2，许多测试工程师执行完一个测试用例后往往忘记或忽略附上自己的测试脚本、log和测试工具说明了，这一点很重要，因为开发人员和项目经理查询和分析问题、自己下次再次测试该用例时都需要检查问题的测试脚本以及相关问题log的； 3，主题和步骤一定要写清楚，这样别人尤其是开发人员才能清楚是怎么产生这个问题的； 4，因为测试用例多、项目组成员多、为了便于管控、记录和追踪、继承，须创建测试用例管理系统。 Bug的产生和提交 Bug的产生与提交 测试人员执行测试时，发现实际的结果与期望的结果不一样，就需及时提交相应的bug单，bug单填写除了填上问题点基本