PHPUnit+ZendFramework ::如何同时测试多用户会话？
我是初学者程序员，没有任何 QA 经验
（只有我在没有 PHPUnit 或其他工具的情况下编写的简单测试）
如何创建同时测试多用户会话的测试？
( >PHPUnit+ZendFramework）
我想做的基本测试示例（我不是 QA - 如果我错了，我会很抱歉）：
- 用户在用户购买过程的同时登录
- - 只有 1 个用户可以写入，其余的只能读取。
- 服务器在同一时间内可以处理多少会话。 等等..
谢谢
I beginer programmer,and don't have any QA experience
(only simple test that i write without PHPUnit or other tool)
How I can create test for testing multi users sessions in the same time?
(PHPUnit+ZendFramework)
basic tests examples that I thinking to do (I am not QA - I soory if i wrong):
- users logins in the same time
- users buy process - only 1 user can write and the rest only read.
- How much session the server can handle in the same time.
etc..
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于第三点，你真正谈论的是基准测试，而不是测试。看一下 ab - Apache 基准测试工具
您可以执行以下命令，该命令一次发送 5 个并发请求，总共向网站发送 1000 个请求：
ab -n 1000 -c 5 http://domain.com/index.php
For number 3, you're really talking about benchmarking, not testing. Take a look at ab - Apache Benchmarking tool
You can do things like the command below, which sends 5 concurrent requests at a time and sends 1000 requests overall to the website:
ab -n 1000 -c 5 http://domain.com/index.php
感谢您对采埃孚和测试驱动开发的兴趣。它们都是值得学习的好东西。
在创建测试来专门检查您的应用程序在您提供的情况下是否正常工作时，您将遇到问题。
单元测试通常用于较小的原子行为。您将需要创建测试来断言您的应用程序执行此工作流程的必要组件，但将它们全部放在一起实际上超出了单元测试的范围。
您可以解决这个问题，并且仍然通过适当地实现状态设计模式来使用测试，该模式将确定，例如，当模拟用户购买某个正在购买的特定模拟商品时，该商品是否处于“锁定”状态。当然，创建稳定的模拟对象，使其行为方式与数据构建到模型中时的方式一致是另一个问题。
最后，#3 有点问题，因为这没有什么可测试的。如果您的服务器超出容量，您将做什么 - 关闭该网站？测试驱动的方法与容量问题并不完全兼容。您需要主动分析网站的速度和内存消耗，并监控真实的用户行为。如果您发现自己的容量已接近极限，那么升级您的硬件或托管将是一个好主意。
Kudos to your interest in both ZF and test-driven development. They're both great things to be learning.
You are going to run into a problem when creating tests to specifically check that your application is working correctly under the circumstances you provided.
Unit testing is generally intended for smaller atomic behaviors. You will need to create tests that assert your application performs a necessary component of this workflow, but bringing them all together is actually beyond unit testing's scope.
You can work around this and still use tests by appropriately implementing a state design pattern which will determine, for instance, if a particular mock item being bought is in a 'locked' state when a mock user purchases it. Of course, creating stable mock objects that behave the way your data should when built into models is another issue all together.
Finally, #3 is a little problematic, because that's not anything to test. If your server is over capacity, what are you going to do -- shut down the site? A test-driven approach isn't exactly compatible with the issue of capacity. You will want to actively profile the speed and memory consumption of your site, as well as monitor real user behavior. If you find yourself at a point where you are coming close to capacity, then it will be a good idea to upgrade your hardware or hosting.