[你问我来答第20期]：如何编写好的测试用例？(已结束)

p516336030

回复 39# wuqinqing

楠族开心果

新人做开始都是做黑盒测试的吧，那做多久合适呢；然后还是要转向白盒和性能对吧？

请问对新人来说，需要 ...
qiuwei1211 发表于 2012-3-5 13:44

新人做开始都是做黑盒测试的吧，那做多久合适呢；然后还是要转向白盒和性能对吧？
请问对新人来说，需要尽快掌握的内容是什么？
谢谢

黑盒测试能做多久，我之前解答了。这个技术含量也是有些的。转与不转白盒和性能这个得看你公司和你自己的需要。

需要掌握的技能，对不同起点的人应该有不同的要求。对于无基础的新手来说，我认为应该从以下几个方面进行掌握。

1）兴趣是最好的老师

    对于软件测试工作，通常是比较枯燥的，如果没有兴趣很难做到持久。
首先需要了解，你是否愿意做软件测试，愿意做白盒测试还是功能的黑盒测试，不要盲目的参与到工作中，否则对于用人单位，对于个人的成长都是浪费。

2)测试人员要学会思考
     测试是个技术工作，需要学会主动思考。如果你遇到一个好的测试主管（组长），他会主动的解决你的测试实际技术难点，这是你的幸运。但是测试问题错综复杂，测试主管工作很忙，他没有时间解决你遇到的任何技术问题，需要你自己分析问题的性质，尝试各种解决方法，搜索网络上的文章，最好如果仍然解决不了才向主管求助。
     我们反对遇到问题表现得很茫然失措，不要问一些很“弱智”的问题，否则主管认为你解决问题的能力不做，学习能力欠缺，这样对于今后的发展不利。
     测试人员如何思考？根据问题的现象思考。问题是属于测试专业知识不足引起的，还是测试用例等测试文档模糊、错误引起的，是个别现象还是测试项目的其他内容都存在的普遍现象。测试要从模拟用户使用的角度展看，因此要用最终用的角度，分析问题的严重程度。
     在询问最终的解决方法前，确保你根据自己的经验尝试了各种解决方法，并且尽量把你发现的问题和猜测，告诉测试主管，证明你已经主动思考了，但是没有找到好的解决方法，或者不能确定是否方法可行。

3）选择适合的测试学习材料
     软件测试的技术博大精深，对于初学者该从何入手呢？可以从以下几个方面学习：
第一是公司提供的培训材料。测试新员工到公司后一般都要经过短暂的培训，这是学习的最好的第一手材料。针对性特别强，都是公司今后用到的测试知识的总结，针对性和实用性都很强。如果有不懂得问题，可以随时提出来，因为你是测试新人，不懂要问，任何人都不会对你的能力表示怀疑。
     第二是借助测试项目的测试文档学习，包括测试计划、测试用例，测试缺陷数据库，可以先看看以前发现了哪些bug，这些bug是怎么发现的，有什么规律和特征，学习别人怎么写测试缺陷报告。
     第三是阅读测试书籍和测试网站和论坛。这些内容很多，建议利用工作之后的时间，根据自己的知识有选择的选择测试书籍，先从基础知识阅读。正式出版的书的内容质量都比较高，而测试网站和论坛的文章良莠不齐，有些只是只言片语，很多还存在错误。因此，需要有一定的鉴别能力，否则会误导，浪费时间。

      4）计算机基础知识

计算机基础知识应包括，对计算机硬件的构成，常见外设设备、网络设备、数据库知识的了解。要测试就必须搭建测试环境，要搭建测试环境就必须应对硬件有一定的了解。

5）作系统使用

　　首先必须要熟悉当前最流行的操作系统，比如现在使用比较多的是windows xp。起码的操作和快捷键使用，常用工具安装应比较熟练。

6)开发基础和测试基础

　　测试首先要了解需求和开发人员根据需求制作的技术方案。所以对软件开发的流程、开发常用的方法、架构有一定的了解，对开发中常用的名词应掌握其意思。这同时也有利于与开发人员的沟通，及测试文档的编写。

　　至少专心学习一本讲述软件测试基础知识的书，对测试工作有一个全面和系统的了解，对常用的测试名词，测试方法应掌握。

7）熟练使用word

　　编写测试用例、测试报告（BUG单）、软件使用手册是测试工程师必不可少的工作，因此wordd常用功能使用必须要熟练，如常用的插入图片、表格绘制等。

8）测试用例

　　测试用例是测试的根本，良好的测试用例，对测试起到的作用不言而喻。所以对于一个有一定基础的测试新人，应首先学习如何编写合理、有效的测试用例。

9）沟通技巧
　　学会和团队内部人员的沟通，学会如何与程序员打交道。沟通是人学习和进步的一个捷径。做为一个新人也许会有很多地方不足，如技术上的缺陷，公司业务的不了解，良好的沟通可以尽快的弥补不足。

10）学习能力

　　主动、自觉、积极是必须的，不要等着别人来教，也不要等着用的时候才去学。不会很正常，谁也不是什么都会，但学不会就不行了，那就只能被淘汰了。

对于有一定计算机专业工作经验的测试新人来说，我觉得最需要的对测试技能方面及时进行掌握：

1）测试用例

　　测试用例是测试的根本，良好的测试用例，对测试起到的作用不言而喻。所以对于一个有一定基础的测试新人，应首先学习如何编写合理、有效的测试用例。

2）测试方法

　　测试的方法有很多种，每种方法如何使用，使用的技巧，应做为一个重点去学习，毕竟发现BUG，是测试人员工作中重要的一个环节。

3）测试工具

自动化测试工具、性能测试工具及测试管理工具、配置管理工具、缺陷管理工具的使用，应至少熟悉一种工具的使用。

4）专业测试工具

根据公司需要，学习公司常用的专业工具。很多比较专业的工具，只有从事此行业才会用到，这些工具也是要尽快熟悉和掌握的。

5）业务知识

了解一定的业务知识，这个对测试非常有帮助

楠族开心果

请问，怎样做好网站测试呀？我对测试不是很了解，希望能详细了解。
wyw51testing 发表于 2012-3-5 13:51

很多人认为网站建设在程序上传那一刻就结束了，其实这个是一个很错误的想法。其实，网站建设在程序上传后，还有一个很重要的环节就是测试网站。不要小看测试环节，这个测试细节要是没到位，网站会存在很多问题，比如图片变形，网站链接错误啊，还有数据错误等等。我就从我个人的角度来谈谈网站测试要注意的事项。

      第一， 要做的事情就是看设计要求，虽然，设计师是看设计要求做，但是难免会存在失误，或者理解上的失误。按着设计的要求去测试功能。

      第二， 就是看传上去的图片是否变形，如果变形先看图片本身的规格是否是网站要求上传的规格。

      第三， 要先熟悉后台，测试每个后台上的内容是否能在前台找到。或者是否出现错误页面。

      第四， 我们作为专业的网站设计公司，要想客户没想到的东西，这么做能让网站更美观，更符合网站的整体效果，特别对于网站的色调这块。

      第五， 查看是否有404页面，这个虽然不是属于设计范围。但是，做个404页面会让使用网站的人，更加友好

PjiL

我感觉测试用例都可以套用，比如添加功能，我就会很自然的想到1.进入增加功能页面2.页面布局显示3.必填项、非必填项检查4.各字段前中后加入空格5.各字段长度校验6.各字段支持的特殊字符7.各字段输入最大长度，页面显示8.增加内容唯一性验证9.支持tab、enter键10.增加、取消成功11.增加、取消的提示信息12.增加、取消后页面显示，这样下次碰到这样的功能只要再稍加变通了，不知道是否这样学习？

Sience

新手支持、

ned747id88

做黑盒已经到瓶颈了，现在想转自动化或者性能，求指条明路

ruiny

支持一下哦！~问题有些都差不多，等着看回复。。。

木雨轩源雪

怎么对QQ软件进行测试 急急急

楠族开心果

回复 15# xgmin1203

今年才开始搞测试，正处于学习中，对于测试用例设计还不是很会，想问一个具体的问题行吗？
比如：该程序具有文件新建，复制，重命名，删除功能。如何设计测试用例呢？我怎么每一种只能想到一个或者两个测试用例呢？

假设测试目标程序只有“新建、复制、重命名、删除”4个功能。可以参考以下测试思路：
1. 根据功能特点提取公共测试点：文字框
1).文字框的测试思路大都没有什么变化，根据支持文字类型，在ASCII表中使用等价法选择具有代表意义的字符，如：A，a，特殊符号（特殊符号这部分可能还需要根据系统特色作一些山色筛选，如Windows系统的文件名对“\”,“*”等9个符号有限制）
2).如果想更深入测试，可考虑本地化测试部分，引入不同编码的字符测试，如Unicode，GB等.
3).最后使用边界值对字符长度设计一些简单的容错用例。

2. 准备好公共的功能测试点用例，则可以开始各个功能的基础功能用例设计。（这部分其实就是你提到的“每一种只能想到一个或者两个测试用例”）。而在需要用到公共用例的部分，将公共用例链接进去。如新建、重命名等涉及文字框的功能都需要导入文字框用例组。（可能不同的文字框对字符的限制不一样，如字符长度或字符类型，所以实际导入的过程中，需要进行简单的筛选）

3. 根据设计好的基础功能用例，选择出可被中断的用例组，设计交互用例组。
可被中断的用例通常满足：
1).用例单个步骤的操作需要系统响应0.5~1s.
2).用例单个步骤的操作可持续运行。（关于持续运行的概念，有两种理解。一是线程被挂起，如新建功能可在申请弹出新建编辑框后，长时间不释放资源退出。二是1个操作执行后，系统会批量处理一堆线程，如批量删除功能。两种概念都可以作为持续运行操作的选择依据，只是看用例的粒度需要达到什么成程度而已）
然后可以开始选择中断手法，常见的中断方式通常为高优先级的进程/线程或致命缺陷的到来。
高优先级的进程/线程需要对整个系统功能进行分析，如系统提示框到来（内存资源申请失败），电量不足提示（如果是有限电源的话）。
而致命缺陷通常只能从用户使用环境得到（可运用场景法和错误推断法得到），如系统崩溃，系统断电。
希望以上常规用例设计思想能对你有所帮助

楠族开心果

回复 47# shihw098

庄姐，你好，我现在做黑盒测试接近一年了，发现每次上线的产品，都还有一些未测的测试点，想问一下根据需求文档，怎么能把测试用例想全呢，覆盖率始终不好，很苦恼

2.对于一个女孩来说
想问一下黑盒测试以后的发展路线应该是怎样的？我以前是做开发的（java）的
现在正在努力学习自动化测试，很怕自己努力的方向不对，求指点！谢谢

第一个问题可以参考我之前的回答

第二个：没什么对不对的，自动化测试假如没测试基础，都是浮云

楠族开心果

回复 48# jiangpr_ok
庄姐：现在做测试一年了，都是手工测试，公司经理也不重视测试，有的时候会说是鸡蛋中挑骨头，现在很迷茫，我打算先做2-3年的黑盒测试，不知道这样的规划是够合理，请指教



参考第89楼的回答http://bbs.51testing.com/viewthread.php?tid=533885&extra=&page=5

楠族开心果

我也是才刚接触测试这块的，还在培训中，想向前辈们讨点迷津，怎样学好软件测试？我现在就感觉很糊涂
如果可以~ 发表于 2012-3-5 20:49

    首先了解什么是软件测试？软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域
软件测试的发展，是伴随着软件开发技术的进步，以及软件质量管理观念的形成。软件测试是从软件质量保证过渡而来，软件测试的职位从传统的白盒测试逐渐演变到黑盒测试，从单一的测试岗位发展到众多的测试岗位，如：WEB测试、数据库测试、安全测试、手机测试。

学好软件测试
首先，是重点概念，现在有很多同学说概念或理论自己看书就能解决，主要是没有实际工作经验，其实老师在讲解概念或理论的同时，也在不断灌输软件测试的实质，没有理论上的掌握，你就无法理解一个软件产品怎么测试，为什么这么测试，怎么去考虑测试的方法或策略，软件测试术语是怎么引申来的，其实都在启发你的逻辑思维能力；也在不断的讲授和上机练习中体验软件测试的流程，软件测试的过程，由无形到有形，从无序的知识点到有序的系统的知识体系。
其次，要有统筹兼顾，全盘考虑的思想，做测试工作不是一个孤立、片面的工作，很多同学都曾说过以前的学哥学姐都传授过经验，测试就那么回事，等到了工作单位，每天就那点活，老是机械式的重复，这些都是我们没有看到或没有意识到的，目前的软件开发与软件测试已不再是小作坊式的规模了，它需要大量的人力来协同工作，每个人的工作都是必不可少的一部分，所以需要在全局上把握，从宏观上考虑，这就是软件测试策略的由来，但是具体测试工作还是微观上的，还需要掌握软件测试的各种方法，另外还要站在项目管理的层面上，从时间上、成本上、效率上、人员分工上、测试团队的能力上、风险上等诸多方面来统筹考虑，要做到从事软件测试工作要从宏观到微观、从全面到局部去认识，不能再盲人摸象或者摸石头过河，要从认识论升华到方法论上；
最后，要多上机实践，这个是非常关键的一点，多思考，会思考，找出疑难与不解，要从软件测试实践中总结出测试理论，再用测试理论去指导实践，这是个循环往复的过程，只有当你的认识达到一定的高度，你就深刻理解了什么是软件测试，你才会发现原来软件测试是那么的有意思、那么有动力、那么具有挑战性，以后还有很多未知的迷团需要你去**，还有更多的知识需要你去掌握。软件测试技术到目前为止，还是一门新兴学科，还没有形成固定的理论体系，还需要很多人的努力，最终将这门艺术变成一种科学。

楠族开心果

回复 129# 木雨轩源雪


    QQ软件有很多种，具体指的是哪个方面？

楠族开心果

回复 60# s_spume

从事黑盒测试已经快4年了，中间穿插着做过一些自动化测试，写过一些小测试工具。感觉不管是黑盒还是自动化，测试用例都是关键。
但是很遗憾，我从来没有正儿八经的使用用例设计方法来设计测试用例。
以前做产品的测试，公司有比较正规的流程，一般情况下都会先给出需求文档，也会有评审，如此我们就有编写测试用例的依据，把需求逐步细化，结合边界值，等价类，再考虑一下异常、压力，于是就形成了一份测试用例。
现如今，做项目的测试，发现完全不一样。由于项目紧急，根本不会有需求文档，更不谈流程。
我的问题是：
1、一份需求文档，里边有很多很多功能点，就会有更多更多测试点。那么一般用用例设计方法来设计某一模块，具体操作起来是怎样的流程？那些用例设计方法的对象是功能点还是测试点？
2、根据用例设计方法来设计一个模块的测试用例，如果该模块最后有300条用例，那么一般设计这些用例需要多长时间？
3、在项目紧急，没有需求文档，没有用例评审，又只能独自完成测试的情况下，如何保证测试用例不会漏测呢？

1. 用例的根本目的是给测试人员使用，故在设计用例时，若脱离用例本身的使用环境而空空其谈，也就违背了用例设计的根基，直接导致被设计出的仅仅是无效用例而已。

所以，经常被谈到用例粒度、覆盖率等，虽然提及的次数多，但一直没有明确的标准规范。其很大程度就是因为用例本身的使用环境差异较大，若不进行实际情况分析，就无法得到恰当粒度的用例。

      比如，针对某一模块，如手机电话本进行用例设计，大致流程如下：

（1）根据电话本需求文档列举所有的功能点。若不能很好掌握功能点划分的粒度，可考虑使用UI结构图代替

（2）分类各个功能点，主要依据为在实际测试中，各个功能点是否可能被其他用例补充。如，后台运行的功能点需单独分割作为被中断用例的前置环境；被动消息同能点则会被作为中断用例的操作步骤；与其他模块存在接口的功能点则会作为其他模块的补充用例….等等

（3）根据单个功能点的复杂程度，考虑是否存在需要提取公共用例。如将各个功能点的编辑框提取出来设计单独的编辑框用例。

（4）使用常规的用例设计方法，通常为等价和边界设计基础用例。若功能点过于复杂，可考虑继续继续分割功能点或使用高级用例设计方法。

（5）完成以上4步后，使用容错和场景法对设计用例的覆盖率进行验证。

（6）最后，根据此功能模块在系统流程图中的位置，设计该模块被其他模块调用的补充用例。（若每个模块都能保证完成以上5个步骤，第6步其实可以省略）

（7）根据设计要求，考虑NFT用例的分布，通常会根据每个功能点单独提取，也可以通过用例优先级控制。（NFT用例分布策略通常取决于公司测试策略，主要适用即可，不需要太纠结于形式）

2. 排除设计人员本身技术高低或用例管理工具难易程度等其他因素，就用例本真而言，用例设计时间通常被两个因素影响：
   （1）功能复杂程度

（2）用例粒度（也可以简单理解为用例个数）

所以，建议比较合理的是自己先试验一次，然后再通过考虑其他因素影响，评估出贴近实际的时间。

3. 严格来说，这个问题只看”测试用例不会遗漏”已经是伪命题。 至今没有哪个公司敢宣称：咱们的测试用例覆盖率100%。

所以，这个问题还是回到了实际环境分析出，建议先分析以下几点得到大致的测试标准：

（1）客户对产品的质量要求程度。简单可以理解为: 客户使用什么样的方式来验收产品。常见的方式为：3个月试用、1个月客户测试团队复检、1天客户体验…不同的验收的方式在很大程度上决定了产品的预期质量目标。

（2）产品的功能覆盖和2级交互测试，一般被作为满足产品输出的最低质量保证。单黑盒方面来说，这部分可考虑自己设计功能结构图，然后通过1次功能点分类得到。

（3）再补充一个常用的用例设计信息：用例设计的时间通常不会操作测试周期总时长的1/3，用例遗漏的部分，最快速的方式是使用探索测试完成。（当然，测试人员或开发人员的实际使用测试也能为补充测试泄露提供一定程度的帮助）

楠族开心果

回复 62# zbl0531

1、对于一个复杂的java管理系统，功能中主要以增删改查、新增-审批-发布，类似这些重复的功能特性，请问在设计测试用例时，如何保证设计的全面性？
2、对于一些特殊的项目，比如说时间短，开发文档不齐全，我们是不是非要执着于去编写测试用例？如果写，时间从何而来；如果不写，如何保证测试的全面和保证测试人员测试的情况？
3、测试用例是去设计，还是去复制？对于一个工作三四年的测试人员来说，产品的重复性更新，功能的递增其实都是很普通普通的功能，我们在长时间的锻炼中，发现每次编写的测试用例都是那些功能特性，基本都是考虑边界值、有效类划分。对于测试人员的测试用例设计能力根本得不到提升，请问，如何真正的提升测试人员的用例设计能力？

另外，专家只针对测试用例设计，其他的就不为难你了，呵呵

1.  （1）先按照流程图或场景法先清理测试点的思路框架。

         （2）提取多次被重用的子功能测试点单独设计公共用例组。公共用例组保证为子功能的最大合集，并注意分类方式，方便被提取时，可快速删选。需要注意公共用例组的粒度，可能它不仅仅只是一个小功能，比如编辑框；在某些情况下，也可以考虑将一小段流程整个作为公共用例组，如审批过程。

        （ 3）由于ERP系统完整流程运行一次的时间较长，且可被中断的测试点较多，通常会将交互用例组单独分割出来，然后逐个重新加载到需要模块基础功能测试用例组中。

    （4）NFT的部分，可参考交互用例组的处理方式。

        （5）最后，留下设计用例整个周期约1/4左右的时间评审和完善用例组。

       （6）至于黑盒外的测试用例组，除使用标准的白盒用例设计方法外，在测试数据选择方面，建议考虑以量的方式来补足。毕竟白盒测试的运行速度远远高于黑盒用例。

   2..除了经常涉及的简化测试用例的方法外，针对极限条件（无需求，无测试用例），提供一些相关信息，供参考：

必要条件：

（1）测试领导者对测试原理有较深刻认识（至少需要达到裁剪测试流程水平）

（2）
测试团队具备较高的可控性（至少能理解测试领导者每个测试任务的实际内容，并且能”踏实”的完成执行测试）

（3）测试团队仅限于单个site。（跨Site测试团队合作项目，可考虑每个独立测试团队分派不同的任务）

测试策略：

极限测试条件下，首先需要高度保证测试过程的运行策略的易操作性。

虽然复杂的测试策略的风险更小，但是它需要消耗更多的时间去理清信息和调整。在极限条件下不可能有那么多的时间和资源完成，所以，把握测试的核心，以1己之力，牵动整个团队的步伐，达到最终的目标。（这里并不是说决策者不会失误，只是单个决策者比多个决策者的效率更高而已。）

    测试执行：

（1）测试任务每日分派，任务来源与测试计划的细化。（至少需要细化到每个人。当然，如果小组长技能水平较高，可考虑细化到小组）

（2）每日周期跟踪各个单位任务执行状态（比较合理的周期可考虑 取决于 跟踪单位任务执行消耗的时间为决策者1/2的工作总时间）

（3）每日对当天的bug进行分析，将分析结果转化为测试点分配到各个负责单位。每周进行一次bug分析汇总，修订周测试计划的重点。

（4）每周进行一次测试状态检查，可选择的方式有交叉测试或核心测试人员抽检。

（5）测试决策者每日与RD就bug修改方案沟通的时间不少于总时间的1/4。

（6）至于其他特殊环境或情况，只能说：见招拆招。

（7）第一阶段为复制。适用于测试新手，基本所有的测试人员设计用例都是从这个出发点开始的。

（8）第二阶段为重置。通常在测试人员入行半年以后开始，通过对之前人员设计用例的模仿，加上自己对测试功能的理解，运用简单的测试方法，重新设计属于自己风格的测试用例。

（9）第三阶段为扩展。努力的测试人员在1年后开始进入此阶段，其表现基本与你现在的状态基本一致。此阶段的根本目的是了解和学习更多测试用例设计相关信息和资料，最终掌握它们，周期因为个人的努力程度和机遇，各有不同。列举一些此方面的需要了解和掌握的信息：系统原理、硬件特性、驱动原理、软件设计、市场信息、编码技术、自动化测试技术、自动化工具原理、缺陷管理工具原理….

其实可以用简单一句话概括：所有与测试相关的技术，均需要了解。

第四阶段为大同。当在第三阶段收集的信息数量达到满足自身测试的需求后，可开始通过各种信息直接提炼出新的测试点，对第二阶段测试用例的遗漏点进行补足，进一步提升测试用例的覆盖率。

楠族开心果

我N个输入条件时怎样用正交法设计测试用例？
jianmin0614 发表于 2012-3-1 16:13

通常，正交表解决问题分类两类：
1. 测试元素满足标准正交表条件，可直接套用。
查正交表具体可以参考ttp://www.york.ac.uk/depts/maths/tables/orthogonal.htm
2. 当测试元素不满足标准正交表条件时，可先考虑测试元素是否是某个标准正交表的子集。
如，某个功能有4个测试元素（因子），每个测试元素的水平分布如下：A4，B3，C2，D2 。
我们可以直接选择L16（5^4）正交表，将仅有的4个测试元素和水平放入表内，得到16组测试用例。
也可以选择先将某些测试元素的水平先组合再分离的方式来设计。如上述例子使用将A元素的4个水平中的两个组合在一起看做1个水平。然后套用L9(4^3)，得到9组用例后，再将A元素组合的两个水平拆开（包含组合水平的用例有2个），得到4个新的用例，最终得到12个用例组成的新用例组。

楠族开心果

回复 73# zbl0531
问题2：
1、如果某个项目，很大，时间很长，写出来的用例都是上千上万的，请问，测试用例用什么样的模板比较好，word还是excel？

2、关于测试用例的修改问题：    测试前期，需求、设计发生变化，需要去修改原先的测试用例，这个无可厚非，但问题是如果已经开始测试了，发现自己写的测试用例部分不符合需求与设计、发现可以新增一些测试思路、用例。请问：在这种情况下，我们还要去修改、新增用例嘛？
         时间从何而来？
         已经测试的用例，在去补充，有这个必要嘛？
         有人会说，可以等项目测试完了，再去补充，有这个必要嘛？如果项目一个接着一个，没这个时间，又咋办？

1.条件允许的情况下，建议使用专门的用例管理工具。没有条件的情况下，强烈建议使用Excel而非Word。原因很简单，单是数据统计一项，Word已经捉襟见肘。而且一个excel文件可以包含多个表

2.若用例与需求完全不符，需立即修改。若用例存在遗漏，可先只增加基础功能用例，其他类型用例组有时间再增加。（增加用例的原则，可考虑根据用例的实际用途，如，首先保证关键里程碑用例组的完整性）

时间问题，可以说有也可以说没有。举个例子，当1个bug的来源不是用例时，即说明此用例有泄露，报完bug后，将bug的步骤作为用例步骤增加到响应模块。也就只是增加了1,2分钟而已。建议举一反三，时间问题其实关键只在于做与不做。

若此部分用例后期不再被使用，则可考虑不补充。若后期仍会复用的用例，建议还是早补早好。

个人认为，项目完了再补不科学,当然项目实在急在不得已的情况下可以后补。但要明白“今天的事明天做”的道理,切勿耽误工作。

hclovezz1314

回复 59# zbj793989849


    想想你能做什么性能，你会做什么，当你没有基础，想让公司带你做性能，手把手教么，用我们老大的话说：想做性能，你会做什么，我怎么相信你能做性能；性能不是你说想就能做的，他也不是会用loadrunner就完事了，牵扯很多，还是希望所有想学习性能的朋友，戒躁，慢慢来，先看看云老大的书，然后慢慢自己摸索下，加个QQ群，就算不回答，看别人怎么说也能学到不少的，不要总算怨老大们不给机会你们做性能，还是老话，你会做性能么，别别人问你什么是tps都不知道，那如何做性能，踏实点、我也不会，就自己学，自己看，主要还是做黑盒，慢慢的趁空了就学习性能，自己看看51testing，看看云老大他们说的写的做的，积累到差不多可以稍微进项目组了，老大们自然会让你进性能组。

hclovezz1314

回复 129# 木雨轩源雪


    性能，功能，都一样，还是那些测试点

hclovezz1314

回复 62# zbl0531


    系统除了增删查改还能有什么其他功能么，