事务是在脚本中定义的某个操作Q而点?yn)L在测试中产生?/span> http h?/span>
例如Q我定义了一个提?/span> form 的事务，我关心的也就是这个提交操作的数量与分值及(qing)响应旉的关pR而实际上q个 form 提交可能产生多个 http h。首先提?/span> form 本n有一?/span> http hQ如果此h被服务器端接受，则要转向到结果页面的W一个页面，又是一?/span> http hQ如果这个页面中含有囄的话Q那么每个图片都需要通过一?/span> http q接来下载?/span>
所以：(x)
事务产生的点?yn)L
Q?/span> 事务的数量＋事务的数量×事务成功概率＋事务的数量×事务成功概率×^均每个页面中含有的图片数
Q?/span>
事务的数量×（
1
Q^均事务成功概率×（
1
Q^均每个页面含有的囄敎ͼQ?/span>
]]>
80% 的Y件缺陷常常生存在软g 20% 的空间里。这个原则告诉我们，如果你想使Y件测试有效地话，C常常光(f)光危多??地段 ?。在那里发现软g~陷的可能性会(x)大的多。这一原则对于软g试人员提高?gu)试效率及(qing)缺陷发现率有着重大的意义。聪明的试人员?x)根据这个原则很快找多的~陷而愚蠢的试人员却仍在O无目的地到处搜寻?
80-20 原则的另外一U情冉|Q我们在pȝ分析、系l设计、系l实现阶D늚复审Q测试工作中能够发现和避?80% 的Y件缺P此后的系l测试能够帮助我们找出剩余缺陷中?80% Q最后的 5% 的Y件缺陷可能只有在pȝ交付使用后用L(fng)q大范围、长旉使用后才?x)曝露出来。因Y件测试只能够保证可能多地发现Y件缺P却无法保证能够发现所有的软g~陷?
80-20 原则q能反映到Y件测试的自动化方面上来，实践证明 80% 的Y件缺陷可以借助人工试而发玎ͼ 20% 的Y件缺陷可以借助自动化测试能够得以发现。由于这二者间h交叉的部分，因此有 5% 左右的Y件缺陷需要通过其他方式q行发现和修正。?br />
为效益而测?
Z么我们要实施软g试Q是Z提高目的质量效益最l以提高目的M效益。ؓ(f)此我们不隑־出我们在实施软g试应该掌握的度。Y件测试应该在软g试成本和Y件质量效益两者间扑ֈ一个^衡点。这个^衡点是我们在实施Y件测试时应该遵守的度。单斚w的追求都必然损害软g试存在的h(hun)值和意义。一般说来，在Y件测试中我们应该量C持Y件测试简单性，切勿Y件测试过度复杂化Q拿物理学家爱因斯坦的话说就是：(x) Keep it simple but not too simple ?
•?~陷的必然?
软g试中，׃错误的关联性，q不是所有的软g~陷都能够得以修复。某些Y件缺陯然能够得以修复但在修复的q程中我们会(x)隑օ引入新的软g~陷。很多Y件缺陷之间是怺矛盾的，一个矛盄消失必然?x)引发另外一个矛盄产生。比如我们在解决通用性的~陷后往往?x)带来执行效率上的缺陗更何况在缺L(fng)修复q程中，我们常常q会(x)受时间、成本等斚w的限制因此无法有效、完整地修复所有的软g~陷。因此评估Y件缺L(fng)重要度、媄响范_(d)选择一个折中的Ҏ(gu)或是从非软g的因素（比如提升g性能Q考虑软g~陷成ؓ(f)我们在面对Y件缺h一个必ȝ面的事实?
•?软g试必须有预期结?
没有预期l果的测试是不可理喻的。Y件缺hl过Ҏ(gu)而得出来的。这正如没有标准无法q行度量一栗如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解试正确性。这很容易然人感觉如盲h摸象一般，不少试人员常常凭借自w的感觉去评判Y件缺L(fng)发生Q其l果往往是把似是而非的东西作为正的l果来判断，因此常常出现误测的现象?
•?软g试的意?- 事后分析
软g试的目的单单是发现~陷q么单吗Q如果是 ???的话Q我敢保证，cM的Y件缺陷在下一ơ新目的Y件测试中q会(x)发生。古语说得好Q??不知道历史的人必然会(x)重蹈覆辙 ?。没有对软g试l果q行认真的分析，我们无法了解缺陷发生的原因和应Ҏ(gu)施，l果是我们不得不耗费的大量的人力和物力来再次查找软g~陷。很可惜Q目前大多测试团队都没有意识到这一点，试报告中缺乏测试结果分析这一环节?
l论Q?
软g试是一个需??自觉 ?的过E，作ؓ(f)一个测试h员，遇事沉着Q把持尺度，从根本上应对软g试有着正确的认识，希望本文对读者对软g试的认识有所帮助
]]>