每个项目经理都希望能有效地控制项目进度。但这件看似简单的事情，实际操作起来却常常不尽如人意。即使在成熟的大公司里，有着完善的项目管理流程，配备着一流的团队，项目延期事件还是频频发生。这里分析主要的三个原因。
常见的原因之计划不清
很多项目经理，计划做得很漂亮，却总是计划赶不上变化。原因 在于，有些时候，按工作量预估的发布日期却得不到领导的同意，领导有时会说我们现在就是和时间赛跑，这个项目必须在某某时间发布。这将致使计划推倒重来，一切都要赶进度。而对于其他团队成员来说，这份计划没有同他们商量，无异于强压任务。项目还没开始，抱怨声就不绝于耳。因此，项目工具选得好、任务划分细 致清楚只是做好计划的基础，更重要的是项目计划要得领导和团队成员的认同，并愿意为之全力以赴。
总之，想做好项目计划，要做好以下三点。
● 项目计划前，先和产品经理、上级领导沟通好，确定这个项目的轻重缓急。
● 团队成员要达成一致意见，项目经理不可独断专行。
● 项目计划要细化到天、功能点要责任到人、确定里程碑点。
常见的原因之需求问题
需求中的功能点要在PRD（产品需求文档）中罗列清楚，业务流程要写得完整清晰，交互细节要体现在视觉稿中。要组织项目组所有成员参加PRD评审，评审时要 针对具体的问题，给出明确的处理意见。暂时不能确认的问题，问题跟进人要在限定时间内给出反馈，项目经理可以制定问题跟进表格。
项目进行中 的需求变更，尽量在前期提出。在项目管理的过程中，当前期的需求和计划都确定后，项目经理不能只顾着跟进开发和测试的进度，也要阶段性地和需求方多沟通， 让他们及时反馈意见。不要等到临发布时，产品经理跑过来说“我要的不是这样的，这里要改一下”。永远不要把问题留到最后一分钟，要超前一步，留有余地。下 面是一个真实的案例。
案例情景：该项目的整个周期为2个月，有3轮功能测试。当第3轮功能测试结束时，也就是即将进入预发布阶段时，产品经理才给出用户反馈并要求按用户的反馈修改。改动的地方涉及到页面的样式、文案、SQL语句和校验逻辑等，总共可能有20多个文件要被改动。
项目经理建议只改页面的样式和文案，其他部分先不要改，等下次升级维护时再改，否则可能会影响发布。而在多次交涉无果的情况下，开发人员只能硬着头皮修改，测试人员只能再重新测一轮。虽然大家努力地按需求方的要求做了，但项目延期已不可避免了。
常见的原因之沟通不畅
为某项目临时组建的团队往往来自不同部门，团队成员之间不熟悉，此时，要为团队建立一个沟通通道，确保沟通顺畅。常用方式为：
● 建立一个内部网络空间，所有文档资源统一存放，供团队成员共享；
● 利用即时聊天工具，建立一个项目群，每天通报项目进度；
● 建立项目邮件组，所有变更达成一致后，发送邮件确认；
● 每天要开15分钟晨会，每周一次周会，每周发送项目周报；
● 跨团队项目，最好申请独立的项目室，所有项目组成员坐在一起工作，降低沟通成本。
本文选自《程序员》杂志2012年10期：http://www.programmer.com.cn/13627/
作为测试人员，几乎人人都有意无意地做着探索式测试，但真正做好探索式测试的需要大量练习。为了练习和提高探索式测试的技能，我们测试团队近期又组织了一次探索式测试道场。（关于探索式测试道场，请参考http://www.testingdojo.org/tiki-index.php?page=Testing%20Dojos）这次我们沿袭上次的新老测试人员结对的方式，只是换做老测试人员执行，新测试人员观察和建议。测试的任务是在30分钟内对一个探索式测试工具RapidReporter进行测试和评估，看是否有充足理由表明我们不能在日常工作中使用它。
作为此次活动的组织者，我观察到了一些和上次新测试人员主测时不一样的一些现象。（关于上次探索式测试道场的总结，请参考http://www.51testing.com/?uid-56882-action-viewspace-itemid-814226）本文将对这些现象进行总结。因为类似的现象或多或少在我身上也存在,本人也从个人角度提出了相应改进的建议，以供大家讨论。
我将我观察到的主要问题总结为CUTE，即Charter，User，Thinking，Experience四个方面。
问题1：Charter定得不好
因为大部分人对RapidReporter不熟悉，所以本次道场大部分测试人员制定的Charter类似于“熟悉该软件基本流程，模拟用户操作”。而针对原始目标“看是否有充足理由表明我们不能在日常工作中使用RapidReporter”，其实更应该去寻找用户可能碰到的比较严重的问题或者极限情况下不能处理的问题。因为大家把熟悉软件基本流程作为了Charter，所以在整个session中大量的时间放在了摸索一些细节的功能上，而对于其它耗时较多的或者破坏性的测试即使有想到，测试时间也不多。
缺乏清晰的指导和实例分析，我想这是我们在实践SBTM之初不太容易写好Charter的原因之一。
Charter（测试章程）是基于测程的探索式测试(SBTM)中比较核心的一个概念。根据提出SBTM方法的Bach兄弟中的Jonathan Bach在Session-based test management一文中的表述：“By‘chartered’, we mean that each session is associated with a mission—what we are testing or what problems we are looking for.”我们可以了解到Charter主要是为每一个session制定一个目标，测什么或者找什么。但在同一篇文章中稍后的部分，我们又看到了这样的描述“Session charter (includes a mission statement, and areas to be tested)”。这里表明Charter是既要包含测试目的又包含测试范围的，而不是二者之一。所以这里会让人产生一些疑问。虽然探索式方面的资料比较多，但对于什么样的Charter才是好的Charter，不好的Charter会带来哪些问题，我目前还没有找到太多资料。
制定Charter的改进方法：
在敏捷开发中描述用户故事的时候，我们常用这样的标准格式＂As a ..., I want to ..., so that ..."。为了让Charter的制定更有效和简洁，我也想用一种标准格式＂By testing ...through ... to ..."来规范Charter的制定。通过这样的格式，可以强迫你在开始测试前就明确本次测试中核心的三个元素：测试范围、测试方法、测试目标。按照这样的格式，我们可以较容易地制定出有效的Charter。比如，通过参考需求文档测试A功能来熟悉此功能与其它系统的交互；通过数据的多样性变化来测试B流程对各种数据的容错能力；通过检查UI来测试C模块是否符合UI规范。
问题2：从用户角度的测试还不够多，不够真实
针对本次道场的测试目标，如果我们从用户的角度考虑，有很多值得尝试的方向。如，不同用户环境的异构性（包括操作系统、语言包等）、工具本身对.NET 3.5的要求与我们被测系统可能的冲突、超长时间的session、记录大量数据的session、双屏下的截屏。。。从本次道场单个测试人员的思路上来看，想到的还不够多。同时，部分测试人员使用的测试数据也不够真实。比如，如果我们只用bug1这样的测试数据来作为bug记录，那么我们怎么能确认象平时一个bug的简要描述可能需要30~50个字符的时候程序确实可以正常记录呢？又如，为了造超长的字串或者特殊字符，有的测试人员在敲键盘，有的在别的文档中拷贝一段字串过来，但是是否直接把前两天你报的一个真实的带有出错日志的缺陷录入进来可能更有说服力呢？因为一个真实的出错日志，其长度和本身包含的特殊字符比我们自己臆造的要更有效。
从用户角度测试的改进方法：
如果被测系统是面向广大人民群众的，如互联网或移动类型的应用，那就做role play，把你自己想象成你熟悉的每个人：年老的父母，淘气的孩子，爱音乐的朋友，忙碌的自己。。。当然，还要知道你的产品最关注的人群，从而加强对他们特点的模拟。如果被测系统是有一定专业性的，那只有增强自己的专业知识，并运用专业知识来指导你的测试。如果可能的话，我们需要学习业务领域知识，使用业务上类似的其它软件，分析产品环境的数据，从而了解并模拟用户常用的和可能的流程、数据等。另外，去客户现场感受他们的工作环境、软硬件设备、输入习惯、出错概率、工作效率等也十分有益。当我们在戏谑不写单元测试的开发人员是不系保险绳的徒手攀岩新手，不了解用户场景的测试人员是否也一样呢？
问题3：忙于敲键盘和点鼠标，主动思考太少
虽然探索式测试讲究的是根据上一个输出决定下一步输入，但如果全是这种＂反应＂式的被动思考，那么很容易迷失测试思路。如果我一而再再而三地走一步看一步，却处处碰壁得不到想要的结果，那么我很可能在这条纵深的路上已经走了太远，心理上感到严重受挫，从而不甘心另起炉灶从零开始，于是犹豫中还会在以前走过的路径上再次盲目搜寻。这时我的输入变成一种下意识的惯性行为，测试可以说已经失控。当我在道场中观察别人操作的时候，我发现新老测试人员都会有这样的失控时刻。
思考的改进方法：
我想，如果在探索式测试中，在大量反应式的被动思考的同时结合一定的主动思考，则应该会有更好的效果。比如，我们可以在设立了测试章程后花几分钟时间用思维导图的形式主动构思几个测试方向，然后在每个方向上更多地依赖观测到的现象决定下一步。当然，我们也可能会因为收获了新的信息而修改原来的方向。但真正开始动手执行测试前让脑子先行，可以在测试的广度上有一个好的基础，辅助以执行过程中每条思路下的探索，在测试的深度上也能收放更为自如。又如，当我们碰到了测试的瓶颈，脑子暂时短路的时候，不如暂停操作，换为纯思考，好好整理一下思路，理一理头绪。
问题4：被原有测试经验所累，运用新的经验较慢
人的经验在大部分的时候都是双刃剑。丰富的测试经验在我们身上烙下深深的烙印，它有时是一种优势，有时是一种束缚。在本次道场中，虽然我们明明知道环境的兼容性是本次测试中我们更需要测试的高风险的地方，但在不知不觉中我们已经在超长字符和快捷键这种细节处浪费了太多时间。我想这是因为在过去我们的测试中，这一类型的测试是必要（用户关心）且有效的（可以找到缺陷），而我们在进入本次测试的时候没有刻意摆脱这种经验的影响。
经验主义的改进方法：
善用经验的关键是知道如何根据本次测试的上下文决定多大程度利用经验和抛弃经验。当我们测试熟悉的业务系统时，当我们的被测系统使用的是我们熟悉的技术时，当与我们合作的是熟悉的开发团队时，我们当然应该更多地参考甚至相信我们的经验。而当我们测试一个不熟悉的系统时，则更明智的选择是提醒自己不去太早地做太多假设和偏向某一种熟悉的曾经好用的测试思路，回到一些更抽象的测试模型，回到最基本的不讨巧的测试方法，紧扣本次测试任务制定相应的章程，和选择更适合本次测试的方法。
总结
下一次探索式测试，无论是一个人孤独地坐在工位上进行，还是如这次大家在一起认真练习和热烈讨论，我都希望能够再CUTE一些，以简明的章程为核心，以多样的用户场景为测试手段，积极思考，善用经验，持续练习和提高探索式测试技能。
在做软件测试工程师的这几年，收获了不少，对软件测试这一职业的理解也随着工作经验有这更加深入的了解，在这里写一篇关于“软件测试”的小文，发表一下我个人的一些拙见，供大家探讨学习之用。
软件测试
什么是软件测试？其实现在很多人对软件测试这一职业不是很了解，不知到底什么是软件测试。
关于软件测试的定义有很多种，我个人觉的比较符合的是：“使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。由于现在软件发展的十分迅速，软件的复杂度也越来越高，所以软件测试现在也变的原来越重要，软件测试贯穿于整个软件生命周期，软件测试并不局限于程序测试，它还包括对相关的需求、文档的测试，也包括一些多样化的回归测试、压力测试、性能测试等。
关于软件测试理论知识在很多书中都有详细的描写，这里就不摘抄了。但是根据我的经验，想要做好软件测试，深入了解软件测试的理论知识是必不可少的，很多很多实际遇到的问题，都是由于对软件测试的理论知识的不了解造成的。
测试心理
做好一名软件测试人员，调整好心理是必须的。
（1）“创造者”与“破坏者”
在心理上，软件开发和测试最大的区别在于前者是“创造者”而后者是“破坏者”。
对于“创造者”而言，在心理上是不会对自己“创造”出来的产品进行破坏，就像每个人都会很爱惜自己的手工作品。而对于“破坏者”，心理上应该是属于乐于看到自己测试的系统“崩塌”的场面，就像拿着别人的手工作品摔砸扔来证明那个手工不行一样。
又如在实际应用中，开发人员会说：“这个功能我测过好几遍了，没有问题了”，但测试软件却还是能在这个功能里挑出很多的问题，原因在于，开发人员测试时，心理上的关注点放在了“证明这个功能点可行”上，往往会无意识的绕过一些可能会引起问题的操作；而测试人员的关注点放在了“使这个功能点不行”上，会尝试各种可能造成问题的操作。所以“破坏者”需要利用你所有可知的测试策略与方法，对软件进行不同程度的“破坏”，检查各种状况下，软件的处理方式与系统的能力。
（2）“第三方视角”&“好奇心”
以第三方的眼光看软件产品是测试人员与开发人员在进行测试时最大的区别。除了“第三方的视角”，测试人员在心理上还要时常保持“好奇心”，随着测试的深入，测试人员应不满足于现有的测试成果，“好奇心”会让我想知道每次点击操作背后系统正在做些什么，驱使我去找程序员问个究竟或者看他们的代码是怎么写的，看看能否进一步优化系统；“好奇心”会让我想弄清楚究竟多少用户同时操作，系统就会崩溃，能否应付系统上线后的正常使用；“好奇心”会驱使我在想用户如果来使用软件的时候会如何操作，会遇到什么样的问题，会不会觉得繁琐。有了“好奇心”，才能让系统在上线前就做了更加完备的测试。
（3）“兴趣”
“兴趣”也是关键，做过软件测试工作的人知道，软件测试有时候是一个很繁琐枯燥的工作。比如测试一个表单填写提交的功能，需要使用不同数据进行填写并提交，所以非常有可能出现的情况是，这一星期，每天8小时的工作就是坐在电脑前，不停的做着“填写表单并提交”这样的简单机械时劳动，这时，“兴趣”是能让我摆脱枯燥的方法。兴趣是最好的老师，如果对测试工作真正感兴趣的，就会不断地研究测试相关的理论知识、技能技巧、工具等。就如上面说的“提交表单”测试，你可以把它当成一种挑战，目标是搞垮它，这时，就可以尝试各种各样测试方法：尝试不同的填写数字、在填数字的地方写英文、在写英文的地方写中文、将必填处留空提交、在填写框中复制上一篇10W字的文章、上传附件处上传各式各样的格式文件、上传50MB以上的图片文件、使用QTP反复快速操作、使用QTP Object对象方法篡改页面控件属性提交、使用Loadrunner模拟大量用户同时提交、提交的时候拔掉网线、用Sniffer或HttpWatch抓包进行观察等等，有太多的方法可以尝试，再使出浑身解数后，发现不知不觉中，已对表单的各种场景进行了模拟测试，提交了大量表单，时间也觉得一个星期都不够了呢。用一个比喻来说的话，如James A. Whittaker的《How to Break Software》说的，“像小时候我们拿上一个小玩具，可能就是一个陀螺，甚至是一个拖把，我们也会玩上半天也不会感到厌烦。我们会变着花样来玩它，我们扮演各种角色，把它当成道具，玩得不亦乐乎。现在的测试工作是什么，测试的对象有时候就是个玩具，只不过有些看起来过于严肃而已。如果我们能把软件当成玩具来玩，那么我们可能不会那么快就认为测试已经可以停止了。因为还有那么多有趣的玩法还没尝试。如果实在是玩腻了，还大可以把玩具狠狠地甩在地上，用脚踩几下，看它有什么反应。这也是一种测试方法！你是在进行破坏性测试！把你的小脚踏车一边又一边地从斜坡上冲下来，每次装上不同重量的东西，看装上哪一种东西会最快。哈哈，原来你是在做压力测试！”
测试方法
测试的方法太多了，不是我一篇小文能够全部概括的，在这里，我就说一些最基础的测试方法。
如测试一个登录界面。有用户名和密码框，确定和重置按钮。用户名和密码长度要求为6-12位。
（1）冒烟测试
我们测试的时候，最先需要使用正确的账号登录一遍，这叫“冒烟测试”，“冒烟测试”的作用是判断一个功能模块的最基本功能是否实现，如果“冒烟测试”能通过，则继续进行深入的测试，如果不过，则不继续进行测试。
冒烟测试是测试的第一步，当发现软件连最基本的功能都无法实现的时候，应立即终止测试，交于开发处理问题，而不是继续测试，放慢了整体研发速度。
（2）边界值&等价类
当“冒烟测试”过了，则可以进一步进行测试了。这里需要用到“边界值”和“等价类”的测试思想。何为“边界值”？边界值的概念是输入稍高于其边界值及稍低于其边界值的一种测试方法。往往会在边界值的地方发生错误或与需求文档要求的不符合。如例子中，假设限定用户名长度只能为6-12位，则我们需要分别对长度为5位、6位、7位、11位、12位、13位这6种长度进行测试，这就是“边界值”法。何为“等价类”？等价类是一种数学上的概念，在这里是将一个测试点划分为多种类的集合，如：还是长度只能为6-12位的问题，使用等价类的方法可以划分为三类：1是小于6位的情况，2是6-12位的情况，3是大于12位的情况。测试的时候，需要在这三类情况中各举出一套测试数据进行测试。这就是“等价类”。
从概念上来看，边界值和等价类的方法很好理解，这是软件测试中，最最基础的测试方法，但能真正活用于测试项目中的的确不多。从不少的来信中看到，其实还是有很多很多的测试人员不知道这两种测试方法，更不用说活用。但如电影中最厉害的大招往往是最基础的招式，小说中最厉害的人往往只是扫地僧，烹饪中最能看出能力的往往是炒蛋炒饭一样。看一个测试人员的基础和能力，看他写的测试用例就知道了。能活用与最简单的测试方法，才是最有效高效的测试。
（3）错误猜想
猜，这也是一种测试方法，这也是用的最多的一种测试方法。当然，不是胡猜，而是有依据的猜。往往经验丰富的测试人员能“猜”到更多有可能产生问题的情况，写出更加有效的测试用例。刚刚的登录例子，可以“猜”在能正常登陆的账号前或后加个空格，看看是否能正常登录；可以“猜”输入空的用户名和密码进行登录的情况；可以“猜”在登录框中粘贴进大于保存用户名变量类型的字符个数；可以“猜”在注册一些带有奇怪字符或是超出字库范围的文字后能否正常登录；可以“猜”登录瞬间关掉页面检查Sever上Session是否释放等等，能猜的内容很多很多，随着经验的增长和对系统越发的熟悉，会“猜”到更多测试方案。
（4）场景法
这也是在平时用的比较多的方法，定义不同的场景，进行有规律的测试。主要用于检查流程等，可使用在有较多分支流程中进行测试。
（5）失败测试
纯粹为了破坏而设计和执行的测试用例称为失败测试。可考察系统超出需求范围时的行为。
测试方法太多太多，这里就不一一阐述了，但是上面5种，是用的最基础也是用的最多的方法。
测试用例
测试用例的重要性不用多了，能规范化测试，记录所有可能出现的问题，随着对测试用例的扩充，能越来越达到完备的测试。关于测试用例，我想说的是两点，“预期结果”与“测试数据”。
（1）预期结果
测试用例中必须要写的中，最重要的一项是预期结果，我在指导一些网友写的测试用例的时候，发现这点很难有做的很好的。往往刚接触测试的人员会在预期结果一栏中写入诸如“登录正确”、“提交失败”等这样简单的预期结果。殊不知这样的写法和没写是差不多的，因为当另一个测试人员进行测试的时候，完全不知道“登录正确”时的表现形式，应写明页面上显示了些什么，那个角落会有什么样的显示，数据是否真正写到了数据库中而“提交失败”需写明失败提示到底是什么，是否有弹出框，是有错误图标等等的详细内容。
在预期结果中不要出现如“查看弹出框中内容是否有图片”这样的有两层意思的句子，即不要出现“是否”。因为这样的书写，在别人看来是“查看弹出框中内容是有图片”是预期结果还是“查看弹出框中内容没有图片”是预期结果，这个看来只有写这条测试用例的人自己知道了。
PS：经常有初入软件测试的人发邮件给我问，说做软件测试是如此的枯燥无味，而且很难在一个软件中找到更多的
BUG了，或是开始抱怨回归测试的无聊时，我都会告诉他，你还没找到软件测试的“兴趣”。非常有幸的，我发现了“它”，它让我工作到现在仍能在软件测试中找到无限的乐趣与挑战，也是它，迫使我学习更多的知识。
（2）测试数据
测试数据需要完整，如在某输入框中输入数据，需要写明需要输入的内容是什么，是“abcdefg”还是“1234567”，输入的账号也需要写明是什么账号，而不是写“输入正确的账号”，在别人测试过程中，是不知道什么才是正确的账号。如果这个账号不会变动（如管理员账号），则在测试数据中需写明“输入账号：admin，密码：123456”，如账号是常变动的（如用户账号），需在测试用例的前置条件中申明账号的可用性，如前置条件中写“系统存在账号为user123，密码为123456789的用户”，这时在测试数据中就可以写“试用账号user123，密码为123456789进行登录”。
总之，写测试用例的时候，注意仔细与严谨。时常检查自己写的测试用例别人是否也能看懂。小组中有多么测试人员的，需要时常对测试用例进行评审，从而保证测试用例的高质量。
BUG单
提交BUG也是一门功课，既要简单易读，又要能说明问题。所以需要在BUG单中写清楚复现的步骤，错误出现的频率，严重性和优先级，一个BUG单讲述一个问题，不可将多个问题写于同一篇BUG单中，BUG单中需注意语气，不得带有情绪，如果BUG存在争议，需要提供证据进行证明，如需求说明说，可以咨询需求人员，如果什么都没有可以参考行业软件规范。
我谈一下我在实际项目中遇到的一些问题，一次参加客户方关于提交BUG单规范的会议，发现了如下问题：
（1）客户方想只使用一个数值，来定义严重性和优先级。真是不应该的，严重性和优先级是两个不同的概念，严重性高的BUG不一定优先级就高，而严重性低的BUG很有可能优先级是最高的。如一个很少用的功能在一定的操作下会导致程序无响应，但是决定在下一个版本再进行修复，则它的严重性虽然是高，但是优先级确是低，而一个马上要投入使用的功能点中，页面上显示的标题不正确不影响使用，虽然严重性是低，但优先级确实高。像这样的情况使用一个数值便很难描述出BUG的严重情况和优先情况。
（2）客户方的部分测试人员认为一张表单上的3种不同类型的问题可以写在一个BUG单上。这也是不可以的，有时候虽然是一个页面上的，但有可能3个错误点是由3个不同的开发人员开发的。这时，让一个开发修改完成而两个开发未修改时，无法正确调整BUG单状态，导致测试进度收集也不完全，很难定位到还有多少问题需要修改。
（3）客户方将BUG的数量和测试人员的效益与开发员工的效益挂钩，这个在管理中也是万万不可以的。会导致大量BUG冗余；开发修改大量严重程度非常低的小BUG导致延缓整个项目的进度；很少有测试人员会花更多的时间去找难以发现的BUG；造成开发和测试之间如仇家等等的问题。
自动化
在进入公司后，客户方就交给了我一个非常艰巨的任务，要做现有系统的自动化测试平台。还好对QTP比较熟悉，到目前为止，已经写好BPM 1.0系统的自动化测试框架，和不少表单脚本，并将BPM 1.0的脚本经过修改后，复用至BPM 2.0版本。
如何进行自动化测试框架的搭建，我会在以后的文章中写明。
所以在这里，我说几点关于自动化测试的一些简单的知识和我的一些经验。很明显，自动化测试从字面上来理解，就是让电脑自动完成所需要的测试内容。如填写表单的测试，我可以预先将所要填写的内容写好，然后下班后，让电脑自动逐条进行填写，提交，记录测试的结果。看似很酷，但需要考虑的问题很多，最主要的是，需要有一定的编程基础，毕竟，脚本是要靠“写”的。在很多网友来信中发现，很多人对自动化的理解和自动化所能做的功能有一点偏差。主要有以下几点：
只要开发出强大的自动化测试脚本，就能将测试人员解放出来。其实不是的，很多的测试都是靠手工进行测试，自动化只是辅助。比如页面的排版是否好看，第一次测试时遇到的各种各样的问题，因为开发做了较大的改变等等一些问题时，自动化的执行就会失败。
对于需求会经常修改的系统如何进行自动化脚本的编写。对于这样需求会经常变动的系统，就不能开展自动化测试，还是老老实实的进行手工测试吧。
在软件测试理论知识还不是很牢固的情况下，不要进行自动化。对软件测试和自动化测试的错误理解会导致后期自动化进行十分的困难且根本没办法维护脚本。
在软件版本还没有稳定的情况下，不要进行自动化
领导不支持的情况下，不要进行自动化
系统中测试对象基本可以正常识别的情况下才进行自动化脚本的编写。
自动化测试一般的情况下是用来证明软件能正常运行，而不是用在证明软件这么操作一定会出错上。
记住，自动化测试最主要的是提高工作效率，正确的使用是，用1天开发一个脚本能用3个月的测试，而不是花3个月开发出一个很牛的脚本来测试1天，非常多初学者会范这个错误，我曾经也范过。
分析
学会分析数据也是软件测试中必要的一项。优秀的软件测试人员能通过各种数字，得到当前系统的各种信息。在性能测试中，分析数据显得尤为重要，一个做金融保险类系统性能测试的前辈和我说过，做性能测试，用使用Loadrunner，编写脚本设计场景，学的话几个月就能搞定，但是分析执行脚本后的数据，可能需要2-3年的工作经验，才能看到你想看到的信息。
说些简单常用的，通过分析BUG数据，就发现很多有用的信息。如：当系统刚刚开发完成，交给测试人员进行测试的时候，BUG数量一定是呈上升趋势，如果上升趋势不明显，一定是还没有做更完善的测试，说明需要投入更多的测试，随着测试的进行，BUG数量会成下降趋势，经过开发的几次调整，测试的几轮复测，BUG数量走势会在经过几次小波动后，趋于稳定，通过这些数字，就可以清楚的了解测试的进度，测试何时需要加强，何时可以退出，何时可以自动化的介入，何时可以开始进行性能测试压力测试等。
同样的BUG单的数据，通过BUG单上模块进行分类进行分析，会发现80%BUG会出现在20%的模块中，这也是经典的“二八原则”，对于拥有80%错误的20%模块，测试人员需要进行更多的测试，很有可能有更多的错误藏在这20%的模块中。这样可以划分出测试的轻重，从而能更加好的计划出测试投入的时间。
书写和演讲
测试人员平时会遇到很多需要书写文档的地方，如：测试计划文档、测试总结报告、测试用例、自动化测试用例、自动化测试报告、性能测试报告等，也需要开不少的会议，进行较多的报告演讲。这些也是一个测试人员不可缺少的素质。
我总结的经验就是：写报告要有理有据，图文并茂，提出一个点，需要给出足够的证据与分析过程来进行描述，而不是只写一个结论，要保证除测试人员外，开发、需求、架构人员也能从报告中，获取到相应的信息。至于演讲，尽量不要使用专有名词，简单明了，多做比喻，证据充足，由浅入深，才能让听的人接受你的观点，认同你的分析是正确的，能获得更多的帮助者与用户者，在日后的工作中，展开会更容易的多。
作为一名系统测试人员，还需要做到细心、耐心，多注意细节。平时也需要多做学习：系统的、网络的、软件的、硬件的、数据库的、语言的等等。总结也是必不可少的，把学到的、用到的知识，都记录下来，会对以后的工作带来非常多非常多的便利。
好了，也写了不少了，希望我写的东西，能对一些刚进入测试行业的、已进入测试行业的和一些像了解测试行业的一些开发一些帮助。
希望志同道合的朋友可以平时多交流，共同学习软件测试。
版权声明：本文出自 黑羽祭 的51Testing软件测试博客：http://www.51testing.com/?307440
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
做过几个项目的测试执行负责人，有自己单独负责测试的小项目，也有8、9个人组成的团队进行的大项目测试，以下总结下测试执行负责人的职责和整个项目把控过程中的注意事项。实际项目测试活动主要有三部分组成：测试计划，实际测试和总结文档，以下也主要从这三个部分来介绍。
测试计划
当老大告知要来一个项目，并让我们作为测试执行负责人时，欣喜之余也要开始着手准备工作，也就是制定我们的测试计划。首先要询问老大，开发人员对应的项目负责人是谁，测试执行周期多长，测试人员有哪些，环境资源能提供多少。接下来就是与开发人员项目负责人沟通，要来的项目是个全新项目还是维护项目，测试的重点是什么，如是进行主要功能测试还是详细测试等等，项目什么时候过来，有无产品需求说明书或说明文档，各个模块对应开发人员是谁及联系方式等等。在这个过程中要特别注意几点（这也是工作中遇到的问题）：项目中的功能可能有些是直接从其他开发团队引进的，如图片服务器，当我们发现图片服务器bug时，上报bug时对应的开发责任人是谁，如果是其他组的开发人员，负责人是否提前与他们沟通，毕竟这不是他们本组的项目，可能出现不接或者不处理情况；召开测试和开发人员会议，或者直接与开发人员负责人沟通，统一对bug的定义，之所以这么说是因为我遇到过一个接口测试的项目，开发人员提供一个demo，让我们测试接口调用是否正常。我是临时接的这个项目，之前已测试几轮，因为不能看源码，就与开发人员沟通，因为有些缺陷看起来是提供的demo问题，但是接口有返回码，函数对输入值的具体处理或者是否处理我们不知道，为避免遗漏bug，如我们不能判断是demo问题还是程序问题就都上报，他们最终同意这个处理意见，通过这种策略测试，发现了一些前两轮没有发现的问题。
当我们与老大和开发人员负责人沟通过之后，就开始执行测试计划，这里要强调下要注重制定测试计划过程，而不是测试计划文档结果。首先要进行任务分配，任务分配前要与各测试成员先沟通，了解下情况。就拿前阶段负责的项目来说，包括我自己有9个人参加项目测试，有几个是经验丰富的老员工，几个是刚入职的新人。因为对老员工平时的能力及负责的模块都很了解，与他们沟通后，就把相关的主要模块分配到个人，新员工主要是测试次线模块和学习。分配完任务后，制定测试方案，制定测试说明文档，测试说明文档包括项目的简单介绍，测试策略，测试重点，测试进度安排，各个测试人员负责模块，各个模块对应开发人员及联系方式，测试时间等说明，然后邮件发给各个测试人员。如果能联系到销售人员或者技术支持人员更好，邀请他们给我们测试人员讲解用户使用习惯及用户关注的主要功能，避免我们对主要功能的把握有偏差（可惜一直没有做起来）。
接下来就是具体的准备工作了，这个过程是所有测试人员都参与的，如阅读相关文档，编写测试用例（老员工编写，新员工学习），评审测试用例，搭建测试环境等，这里略过。
实际测试
实际测试直接决定测试质量。作为测试执行负责人，我们大多数情况下也是参与测试的，执行负责人与测试执行人的区别就是要放眼于整个项目，把控整个项目的进度，这意味着你要承担更多职责。还是拿上面的项目来说，首先安排冒烟测试，我们知道冒烟测试的侧重点和观察点是项目的主要功能是否有问题，是否影响后续测试，根据冒烟测试结果评估风险，判断项目是否进入系统测试。但是对于新员工来说，什么是主要功能不是很好把握，如果有整理的有冒烟checklist好办，没有的话就很纠结，当时我就给他们讲解冒烟测试，如何去测试，有什么问题问老员工，让老员工辅导新员工，但是如果冒烟测试时间很紧的话，还是有点力不从心，老员工也没有那么多时间，真心感觉到基础的培训很有必要。接着进入系统测试，当时提出让每个测试成员每天反馈执行进度及发现的主要bug，这样方便把控项目，实时调节人力资源。但是有些同事可能工作太忙很容易忘记写，没办法只能硬着头皮每天一个一个去问执行进度怎么样，能不能按时完成测试任务等等。我得出的结论就是：作为测试执行负责人，能调节大家的积极性最好，不行的话，同事不积极，你就得积极。把发现的重大问题及时向上级反映，并每天报告测试进度，让领导知道你在做什么，做到什么程度。
经手过几个项目发现，有些老同事执行测试时，不按照测试用例来走，完全按照自己的思路来走，这个问题我也想过，如果按照执行用例来走，提高不了老员工的积极性，不按照测试用例走，可能是测试用例是自己写的，每个测试点他们都知道，但是又怕同事遗漏测试点，到现场有问题。我自己的解决方法是等项目功能稳定以后按测试用例详细测试一遍，后面几轮按照员工自己执行策略来测，涉及到回归测试用例筛选和探索式测试等等。说是这么说，但是有些同事不是这么做的，感觉这个问题还是没有很好的解决，还在思考具体的解决方法，等待大侠指点。
实际执行中还遇到新员工看不懂测试用例的情况（真心感觉到测试用例很重要，特别是团队中有新人），一般测试用例都是老员工来写，新员工执行。这里主要有两个原因，一是测试用例写的不详细明了，如是这种情况，及时更新测试用例；二是新人对业务不熟悉，可通过老员工给新员工讲解业务流程或实际测试前让开发人员给测试人员进行简要培训解决。主要还是编写出高质量的测试用例最重要，我一直认为测试用例的颗粒度取决于时间和用例的可重用性，测试用例是一定要写的，时间紧的话至少有个主要功能checklist，这也是工作成果物展示的一部分。具体测试用例的编写就不介绍了，这里要提醒下编写测试用例的人员，你们编写的测试用例的质量及语言描述真的很重要。
还有就是与开发沟通问题，有些开发人员不是很好沟通，特别是新人与开发人员沟通时会遇到各种问题，这时测试执行负责人充当中间协调者的角色，一边向同事了解情况，一边与开发人员沟通，实在不行，就上报给老大，让老大跟开发人员老大沟通，现实中发现一个很奇怪的问题：测试人员软开发人员就硬，测试人员强硬点开发人员就很客气。当然和气最好，呵呵呵
总结文档
测试结束后，所有测试人员要上交测试用例执行报告或测试记录，测试执行负责人汇总后形成测试报告和总结，分析bug趋势及原因；编写主要问题说明，分析其风险，并反馈给上级和开发人员。整理出开发人员犯的低级错误，如reopen的bug，给的程序有毒，打包有误等等，提交给老大，让老大与开发负责人沟通，避免犯同样的错误，影响我们的测试。
测试结束后测试活动，我总感觉组内少了一个很重要环节：bug分类分析，持续跟踪。多数同事对提交的bug很少跟踪，提交了就提交了，没有尽量确保提交的bug修复了。缺少对bug没有分类，如哪些是功能问题，哪些是UI问题，哪些是控件问题，这样可以为下轮测试提供参考。还有就是开发人员置成Not A bug的缺陷，是测试人员理解错误还是开发人员的问题，以免下次犯同样的错误。这也是自己以后应该注意的地方。（个人感觉这个问题还是小组老大出面处理好点，因为我发现测试执行负责人的权利不够，呵呵）
名称之所以为经验总结一，我想刚作为测试执行负责人不久，对测试执行负责人的职责及项目各个阶段的把握和掌控还有很多不足和需要提高的地方，但愿明年再写一篇总结二，对测试执行负责人的职责有不一样的看法和更多的经验总结。
版权声明：本文出自 没翅膀的飞鱼 的51Testing软件测试博客：http://www.51testing.com/?363907
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
LoadRunner controller将使用驱动程序mmdrv运行Vuser。用户可以在controller的run-time setting中选择Vuser的运行方式， 是多进程方式or多线程方式。
如果选择以线程方式来运行虚拟用户：
在场景设置时，“是单行脚本，还是多行脚本”会决定系统启动的进程数的多少：假设并发用户设置为30，如果是单行30个用户，系统只需启动一个进程；假设并发用户设置为30，如果是多行，30行，每行一个用户，系统就需要启动30个进程；
如果选择以进程方式来运行虚拟用户：
那么无论脚本在场景组中怎么设置，是单行多用户还是多行少用户方式，系统需要启动的进程数是一定的，就是并发用户的总数；
进程方式和线程方式的优缺点：
如果选择按照进程方式运行，每个用户都将启动一个mmdrv进程，多个mmdrv进程会占用大量内存及其他系统资源，这就限制了可以在任一负载生成器上运行的并发用户数的数量，因为负载机的资源（内存及其他系统资源）是有限的。如果选择按照线程方式运行，在默认情况下，controller为每50个用户仅启动一个mmdrv进程，而每个用户都按线程方式来运行，这些线程用户将共享父进程的内存段，这就节省了大量内存空间，从而可以在一个负载生成器上运行更多的用户。（如果选择线程方式来运行用户，每个进程中会多出几个线程，例如是53个，多出来的进程可能是用于维护进程之间的运行的）选择线程方式虽然可以减少启动的mmdrv进程数，减少了内存的占用，但是也容易出现一个问题，例如，同一个测试场景，用线程并发就会出现超时失败或报错，而用进程并发就没错。为什么呢？因为线程的资源是从进程资源中分配出来的，因此同一个进程中的多个线程会有共享的内存空间，假设a线程要用资源就必须等待b线程释放，而b线程也在等待其他资源释放才能继续，这样就会出现这个问题。
系统需要启动的mmdrv进程数与哪些因素有关：
与在controller 的运行时设置中选择的是进程方式or线程方式来运行虚拟用户有关进程方式：无论是单行or多行脚本，需要启动的进程数就是并发用户数；线程方式：假设是单行脚本，每50个用户才启动一个进程；多行脚本，有几行（每行<50人）就启动几个进程，而不是每个用户启动一个进程。如果选择了线程方式，需启动的进程数，进一步还与脚本是单行还是多行有关单行脚本，多用户，假设少于50，只需启动一个进程，100个用户，只需启动2个进程，依此类推；多行脚本，即使每行一个用户，也需要启动一个进程，多一行就需要多启动一个进程；不是每个用户启动一个进程，有几行（每行<50人）就需要启动几个进程。在启动了IP欺骗功能后，所需启动的进程数，还与选择的是按进程还是按线程来分配IP地址有关按进程分IP：每个ip（负载生成器）就需要多启动一个进程； 按线程分IP：每个ip（负载生成器）不需要多启动一个进程。
性能测试新手误区（一）：找不到测试点，不知为何而测
性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？
性能测试新手误区（三）：用户数与压力
性能测试新手误区（四）：一切来自录制
经常会见到新人提出这样的性能问题：
“100用户时，A操作响应时间达到了XX秒，请修改。”
面对这样的问题，开发人员一定会觉得很无助，他们甚至不知道问题是什么。
即使从测试人员的角度来看，这也算不上是一个合格的问题。
那么一个好的性能问题应该是什么样呢？
好问题要描述清晰
100个用户，是指绝对并发操作么？还是什么样的场景？
是只测这一个A操作？还是有多个操作在同时进行？
如果有多个操作，是只有这一个操作变慢？还是普遍变慢？
测试环境是什么样的？测试数据量是多少？
也许开发人员理解了详细的测试场景后，会告诉你，这个场景在业务中是不可能的，或者测试数据量是不合理的。
好问题要有尽量准确的定位
只是描述清晰还不够，要明白什么是表面现象，什么才是问题。
问题是需要定位才能发现的。
“100个用户操作时，A事务的响应时间过长”，这只是一个现象，问题是什么呢？
响应慢是慢在哪？是中间件还是数据库？这是最基本的分层定位。
是服务器达到了硬件瓶颈么？如果硬件或操作系统上没有瓶颈，那么瓶颈在哪？
是不是由于一些基本配置问题导致了排队呢？比如中间件的HTTP线程数和数据库的连接数。
如果基本配置没有问题，那么再深入一些，是内部的哪些资源产生了争用和等待么？
是哪些SQL引起了数据库内部资源的争用呢？应用程序上又是哪个方法在占用资源呢？
……
定位的越深入，需要的技术能力也就越高。
好问题应该用最简单的手段复现
比如上面的100个用户，导致了数据库的一张表的争用，因此产生了大量锁等待现象，最终导致了外部的A响应时间过长。但是通过之前的分析和定位，我们发现也许引发问题的那些SQL语句，只来自100用户中的10个特殊类型的用户。那么这个问题就完全可以简化成用10个用户去复现，其他90个用户都是干扰。这样问题被简化了，开发人员也就更容易理解问题，对于测试的复测也更加方便。
不过还是要记住，最终的用户场景模拟才是决定性的验证。
最后再总结一下，性能问题到底应该如何提呢？其实只有一个标准，那就是能让开发理解问题、找到根本原因并进行修正的就够了（假设开发人员无所不能）。再进一步深入的分析，可能是为了减轻开发的一些负担，也可能是为了锻炼自己的能力，这就不是每个测试人员都会去做的了。
结果——项目简介：一旦你的测试是完全回放，结果会自动显示在Results选项卡中的项目汇总视图中
结果——组概要：可以通过点击每个组来查看测试回放的详细结果。
结果——任务简介：可以通过点击每个任务来查看测试回放的详细结果。当任务诊断失败时，这些细节是很有必要的。
结果——事件概要：可以通过点击每个事件来查看详细的测试结果。当事件诊断失败时这些细节是很有必要的。
结果-在HTML：所有结果可以导出在不同的文件格式如HTML、PDF、XML等。在这里将结果导出在HTML中。
脚本编辑器：虽然大多数功能都可以通过图形界面，但当添加需要的逻辑时，Web测试提供一个易于理解的脚本语言。该脚本编辑器可用于编写脚本。
原文出处：http://www.appperfect.com/products/web-test.html?gclid=CLab8dK31bECFQEzpQodkHgAEg
综述
所有软件的设计和开发都是用来满足特定的功能需求。一个功能需求可能是技术上的，业务上的，又或者是基于流程。功能测试是一个应用程序的预期行为可以进行测试的过程。在软件开发周期的早期为应用程序执行功能测试可以加速开发，在临近软件周期结束时可以提高质量保证和降低产品风险。
在一段时间内，大多数软件会经历一些变化。这些变化可能会出现在一个版本或跨多个版本中出现。对软件的任何修改都会增加出现错误的机会或者引入破坏现有功能的缺陷（称为回归）。回归测试是经常重新测试软件，以确保现有已知的行为或功能不会出错的过程。
AppPerfect Web Test是一个完全自动化的网页功能测试和回归测试的软件。可以测试任何通过web 浏览器访问的应用程序。AppPerfectFunctional Tester是专门为开发人员和专业QA人员而设计。它立即提供了两组有丰富功能、易于使用的方法。
AppPerfect Web Test的核心部分是提供了支持“记录”网页浏览器事件和自动“重播”这些事件。自动化的网页测试可以节省大量用在手动测试系统的时间和资源。随着应用程序的规模和复杂性的增长，随着时间的推移，确保功能的灵活度和确保没有回归会变得困难。即使一个小规模的项目也可以产生过多的排列组合的测试用例，太多的的测试用例以致人们持续不断的测试。AppPerfect Web Test为你自动执行此任务并且帮助你改善你的网页应用程序的质量，大大降低了你产品进入市场的时间。
Key Features关键属性
● 浏览器记录：用AppPerfect Web Test记录一个测试像浏览网页一样容易。您在您的网页浏览器中执行的所有的动作被自动记录和回放。不需要广泛的设置或学习任何专有的脚本语言。同时还可以录制浏览器的多个实例
● 以元素为基础的，而不是基于坐标： 它记录浏览器中真实元素的交互行为，而不仅仅是屏幕坐标。这使得此软件能更加灵活和便捷跨机器测试，而且更容易修改和更新。
● 基于UI的测试编辑：AppPerfect Web Test提供了友好的用户界面，它允许您编辑您现有的任务以及轻松地添加新的任务。这使您能够轻松地跟上目标应用程序的变化。
● 参数化测试：在实际的情况下，对于任何基于网页的应用程序，所请求的页面通常不是静态页面。大多数页面接受一些参数作为输入，然后相应地显示适当的定制化的内容。参数化的功能测试自动的向请求提供这些参数，从而帮助模拟一个真实际的使用环境。AppPerfect Functional Tester可以从文本文件、数据库等等中读值。
● 响应验证：你可以验证收到为URL请求的响应。你可以自定义基于响应代码的一个有效或无效一个URL请求响应，文本包含在响应或其他任何您需要的逻辑。
● 先进技术：AppPerfect WebTest支持基于.NET、ASP、servlet /JSP、CGI、SSL和大多数其他服务器端网页技术的功能测试应用程序。它还支持先进的网页浏览器技术的功能测试，如AJAX、Flash和Javaapplet。
● 对象抓取：AppPerfect Functional Tester提供了抓取HTML元素并获取其属性的功能。当有附加功能加入您的产品时，可以更容易得添加任何新HTML元素到你现有的功能测试脚本中，更容易构建测试用例
● 脚本支持：对于高级用户AppPerfect Functional Tester提供了脚本语言的支持。所使用脚本语言的是简单的java脚本，用户可以使用提供的脚本编辑器查看/编辑功能测试。用户可以定制一个功能测试就像他们想要使用java脚本一样。
● 支持基本的身份验证：cookies，SSL：您可以使用AppPerfectFunctional Tester功能测试那些需要基本身份验证和允许使用SSL配置的URL。如果您的应用程序使用它，还处理适当的请求下发送的cookie和支持URL重写。两个方法还支持SSL身份验证。
● 信息和用户友好的报告：AppPerfect Functional Tester提供的报告，帮助你定位功能测试的失败点。这些报告可以通过UI导出成各种格式，比如HTML、PDF、CSV、XLS、XML等。
Screenshot屏幕截图
项目属性：通过定义各种项目属性开始你的项目。网页测试提供了广泛的定制项目的行为。
记录设置：测试你的应用程序是很容易的。简单地只需使用这个记录器启动你的应用程序并开始使用。你做的每件事都会被记录。
测试编辑器——项目：你执行的所有操作的都记录下来，可以使用测试编辑器查看和修改。这个视图显示了顶级项目数据。
测试编辑器——组：点击左边树视图上的任何节点查看该节点的详细信息。你可以把一套动作聚合到一个可以单独管理的组群中
测试编辑器——任务：记录得每一个URL被称为一个任务。点击左边树视图上的任何任务节点看以查看该节点的详细信息。
测试编辑器—事件：每个任务包含有所关于这次执行的操作的细节（称为事件）
测试编辑器——参数：你可以用动态创建参数表的值取代记录值。动态值可以来自一个数据库、一个手动指定的值列表，或者一个CSV文件。
事件设置：通过事件设置选项对话框，用户可以精确地控制每个事件的属性而被记录下来。
测试回放状态视图：当一个测试被回放，你的应用程序被调用时，你会看到在你应用程序上执行每一个动作。此外，这种状态视图在Web测试还提供额外的测试信息回放。
结果——项目简介：一旦你的测试是完全回放，结果会自动显示在Results选项卡中的项目汇总视图中
结果——组概要：可以通过点击每个组来查看测试回放的详细结果。
结果——任务简介：可以通过点击每个任务来查看测试回放的详细结果。当任务诊断失败时，这些细节是很有必要的。
结果——事件概要：可以通过点击每个事件来查看详细的测试结果。当事件诊断失败时这些细节是很有必要的。
结果-在HTML：所有结果可以导出在不同的文件格式如HTML、PDF、XML等。在这里将结果导出在HTML中。
脚本编辑器：虽然大多数功能都可以通过图形界面，但当添加需要的逻辑时，Web测试提供一个易于理解的脚本语言。该脚本编辑器可用于编写脚本。
原文出处：http://www.appperfect.com/products/web-test.html?gclid=CLab8dK31bECFQEzpQodkHgAEg
白盒测试计划书着重测试软件的源代码，黑盒技术着重测试软件功能。因此，设计测试用例时，需要研究需求说明和总体设计说明中的相关程序功能或输入，输出之间的关系等信息，从而与测试后的结果进行分析比较。
在实际测试中，常常把黑盒测试常常与白盒测试联合使用，它是与白盒测试互补的测试方法。它很可能发现白盒测试不易发现的其他类型的错误。
用黑盒技术设计测试用例一般有等价类划分，边界值分析，错误推测和因果图4中方法，现在咱们分别来看看吧！
一、等价类划分法
咱们在前面曾经说过，完全的黑盒测试通常是不现实的。因此，只能选取少量最有代表性的输入数据作为测试数据，用较少的代价暴露出较多的程序错误。等价类划分法将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性，从而减少必须设计的测试用例的数目。
等价类划分法是把所有可能的输入数据或有效的和无效的划分成若干个等价类。测试每个等价类的代表值就等于对该类其他值的测试。也就是说，如果从某个等价类中任选一个测试数据未发现程序错误，该类中其他数据也不会发现程序的错误。相反地，如果一个测试用例测出一个错误，那么，这一等价类中的其余测试用例也能发现同样的错误。这样就把漫无边际的随机测试改变为有针对性的等价类测试，用少量有代表性的测试数据代替大量测试目的相同的例子，能有效提高测试效率，并取得良好的测试结果。
在划分等价类时，我们可以将其划分为两类：
1）有效等价类。是指输入完全满足程序输入的规范说明，合理的，有意义的输入数据所构成的集合，利用有效等价类可以检验程序是否满足规格说明书所规定的功能和性能。
2）无效等价类。指完全不满足程序输入的规格说明，不合理，无意义的输入数据所构成的集合。使用无效等价类可以检验程序的容错性能。
在划分等价类的时候，我们可以借鉴以下几个原则，可以让你事半功倍，同样咱们还需要丰富的经验。
（1）如果某个输入条件规定了取值范围或者输入数据的个数，则可划分出一个有效等价类和两个无效等价类。
（2）如果输入条件规定了输入数据的一组值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效等价类，此外，还有一个无效等价类。
（3）如果规定了输入数据必须遵守的规则，则可以划分出一个有效等价类和若干个无效等价类。
（4）如果规定了输入数据位证书，则可划分为正整数/零/负整数三个有效等价类，其他为无效等价类。
（5）如果在已划分出的等价类中个元素在程序中的处理方法不同，则应再将该等价类进一步划分为更小的等价类。
等价类划分好了，那么如何测试用；例呢？你会了吗？不管你会不会，我们一起来看看吧！
（1）为一个等价类规定一个唯一的编号
（2）设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被测试用例覆盖为止，即将有效等价类分割到最小。
（3）设计一个新的测试用例，使它覆盖一个而且只能覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有无效等价类都被覆盖为止。
二、边界值分析法
大量实践表明，程序在处理边界情况时最容易发生错误。边界情况值输入等价类和输出等价类边界上的情况。因为在测试过程中，可能会忽略边界值的条件，大量的错误是发生在输入或输出范围的边界上。因此，设计是程序运行在边界情况的测试用例，查出程序错误的可能性更大一些。
使用边界值分析方法设计测试用例时，一般与等价类划分方法结合起来，通常测试输入等价类和输出等价类的边界情况作为重点目标，应该选取刚好等于，小于或大于边界值的数据来进行测试，有较大可能发现错误。
在实际的软件设计过程中，会涉及到大量的边界值条件和过程，用边界值分析设计测试用例时，可以参考以下原则。
1）如果输入条件规定了值的范围，则选择刚好等于边界值的数据作为合理的测试用例，同时还要选择刚好超过边界的数据作为不合理测试用例。
2）如果输入条件规定了输入值的个数，则按最大个数，最小个数，比最大个数多1，比最小个数少1等情况分别设计测试用例。
3）度每个输出条件分别按照上述两条原则确定输出值的边界情况。
4）如果程序的输入或输出范围是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
三、错误推测法
在软件 的测试用例设计中，人们根据经验，直觉和简单的判断来推测程序中 可能存在各种错误，从而有针对性地设计测试用例，此就是错误推测法。
由于错误推测法是基于经验和只觉得，因而没有确定的设计测试用例的步骤，其基本思想是：列举出程序中可能出现的错误和容易发现的错误的症状。在咱们平常测试系统的是，这个方法用的比较多。
四、因果图法
等价类划分法和边界值分析法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误，因果图法能有效地检测输入条件的各种组合可能会引起的错误，即在测试中使用因果图，可提供对逻辑条件和相应动作的简洁表示。因果图的基本原理是通过画因果图，把因果图转换为判定表，然后为制定表的每一列至少涉及一个测试用例。
在这咱们介绍了四种黑盒测试法的方法，它们各自都有偶自己的长处和短处。使用某一种测试法涉及出来的一组测试用例，可能发现某种类型的错误，但可能对另一类错误发现不了。
因此，在实际测试中，经常是联合使用各种测试方法，通常是选用黑合法设计基本的测试用例，再用白盒法来补充一些必要的测试用例。
测试时间和测试资源总是非常有限的，而测试对象的各种组合却是非常庞大的。如何在测试时间、成本、质量等方面实现平衡，是每个测试人员需要仔细考虑的问题。本文通过采取下面的测试策略，帮助测试人员较好的实现时间、成本和质量等方面的平衡：
1）测试的尽早介入：尽早在缺陷刚刚被引入的时候就发现和修复它们，可以有效地避免缺陷的雪崩效应和缺陷的成本放大效应；
2）基于风险的测试：确保将测试资源放在最关键的测试对象功能模块中，而不将有限的测试资源浪费在无关紧要的地方；
测试的尽早介入
软件开发生命周期中的每个开发阶段都会输出本阶段的工作产品。事实证明，一半以上的软件缺陷是在需求阶段引入的。图1显示了在不同阶段缺陷引入的分布情况。
图1 不同阶段缺陷引入的分布
测试的尽早介入表现在：在项目开发的早期，测试人员通过参与相关软件工作产品的评审，以达到尽早发现和修复缺陷的目的。测试人员的尽早介入，其主要优点表现在（也是软件测试的实践经验）：
（1） 提高质量。缺陷存在放大效应（即缺陷的雪崩效应），简单的讲，在需求分析阶段引入10个缺陷，假如没有通过评审等静态测试手段发现和修复这些缺陷，那么在概要设计阶段就会变成15个，而在详细设计阶段可能就会变成25个（假设不同阶段的缺陷放大系数是1.5）；假如在项目早期进行了静态测试，遗留的后续阶段的缺陷数目将可以大大降低，从而提高产品的质量；
（2） 降低成本。因为缺陷发现和修复的成本随着开发阶段的演进而快速的上升。假如在项目早期发现和修复缺陷，将可以大大的降低整个项目的成本；
（3） 提高测试的可预测性。
基于风险的测试
由于穷尽测试是不可能的，测试人员必须在测试资源、成本和质量之间实现平衡，也即需要妥协。但这并不意味着放弃测试，只是意味着不可能有足够的时间对测试对象的方方面面进行测试。如何选择测试的重点，使得风险处于可控的状态，这就是基于风险的测试需要考虑的问题。
基于风险的测试选择测试重点，经常考虑的一个因素就是产品中不同功能的使用频率。图2是IT项目中实际功能模块使用频率的分布。
图2 IT项目实际功能模块使用频率的分布
从图2中，我们可以发现：
（1） 软件产品的每个功能模块，对于客户而言并不是是同等重要的；
（2） 同样的，测试对象中的每个功能模块，对于测试而言也不应该是同等重要的，即测试的强度和优先级是应该区别对待的；
因此，将测试资源和测试时间花费在客户经常使用的系统功能模块上是合理的。因为系统中的某部分经常被使用，假如其中存在缺陷，那么该部分频繁使用将使得出现失效的可能性大大提高。
基于风险的测试选择测试重点，另外一个经常考虑的因素是系统中最可能出现错误的模块。为什么在某些模块中存在特别大的风险，对此可能有许多不同的理由，例如：可能是由于缺少经验的开发人员编写了复杂的代码块，或者时间压力太紧、开发资源不足等。对于测试而言，要紧的是看清其中的原因，并基于这些原因作出有实际根据的决定，也即测试重点的选择。
一个项目会有很多需求，但这些需求通常并不是有相同优先级的。这就说明，这些需求的价值，有差异。为什么会有这样的差异呢？
我们的需求分析是基于原始需求的。原始需求通常很粗糙，只是客户和市场人员的直接描述，甚至连具体目标都不清楚。基于这样的资料，我们会进行分析，然后猜想用户的真正需求，围绕这些需求将我们能做到的提供给客户。通常，最终需求中会有很多需求点，并不是客户提出的，甚至并不是他们想要的。下面具体分析看看这些需求点吧。
1、客户的真实需求。
每一个软件产品或项目，都是为了解决一个问题或几个问题。这些问题就是这个软件的核心需求。即这个软件就是为了解决这个问题而诞生。这些既是需求，也是软件的目标，所以如果开发前没有目标，那么还是先不要动手的好。
2、客户需求的延伸。
直接需求通常还会衍生出一些间接需求，这些间接需求是为了更好的满足核心需求。甚至没有这些延伸，核心需求就无法完成。比如客户说，我们的系统需要登录。那么我们不但要做登录，还一定需要帐户管理功能。
3、技术性需求。
在具体的应用场合，软件的肯定会有一些技术性限制，比如网络带宽，显示分辨率，操作系统等等。这些都是我们必须要满足的，因为不满足，就无法让软件正常运作。
4、我们能够提供给客户的。
有些需求，我们能够做到，但用户未必需要，为了让软件显得功能丰富，一堆杂七杂八的东西就被提了出来。
5、我们希望提供给客户的。
我们经常希望客户除了按照他们的意愿提出功能外，还能够使用一些我们想提供给他们的功能。
上面的这些需求，都经常在项目中出现。后面要讨论的是，这些需求对于软件产品价值的影响。
从用户的角度来看需求，我们只是想要我们迫切需要的，能够直接为我们解决现实问题的。因为每一个功能都不白送，可是要花银子结帐的。所以丰富的功能，带来的就是丰富的账单，产品经理的热情未必能够让用户买账。
这里，我们可以按照需求对用户的重要度，对需求点进行分类。
1、 核心需求：用户遇到的直接问题，比如财务流程管理繁琐，效率低下。比如人工统计进销存效率低下，出错率高……总之，这些问题直接催生了软件的产生。
2、必要需求：即为了更好的满足核心需求，不得不做的一些事。
3、扩展需求：有了更好，没有也能用。但这些需求会对用户产生帮助。
如果项目中，有些需求没有包括在上述三个范围中，那这些需求基本就是浪费工作量。还是别加在项目里了。
为了更直观的看到需求点的价值，我设计了一种图——靶图。
我们假设有如下需求：
一个工厂为了提高办公效率，定制一套OA，需要有请假管理、日报系统和办公流程自动化、以及会议管理系统。
那么可以有如下分析
核心需求：加快办公流程——杜绝人情因素影响办公流程；将员工的请假和工作量透明化。减少不必要的会议。
必要需求：帐户管理、权限管理；mail会议通知；数据报表；工作流；
扩展需求：操作简单方便；界面美观；支持移动设备；
一目了然的靶图就出来了。我们可以清楚的看到，哪些需求是最具客户价值的，那些是可有可无的。
同时，软件产品的价值也取决于我们为客户解决了多少问题，而不是我们提供了多少功能。所以以客户的角度去分析，才能更客观的评价一个软件产品的价值。如果是自主研发的话，最好也虚拟一个客户的角色。换位思考哪些需求才是重要的。像超市一样买二送一的方式卖软件是不可取的，能够为客户解决多大的问题，软件就值多少钱。所以，专业，简单，关注焦点，才是软件开发中应该做的